From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vimal Subject: Re: iptables not prevent access Date: Mon, 15 Sep 2008 17:41:53 +0530 Message-ID: References: <9518B26607784D55A361431633134C9B@dcyb.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=G3MTB5lsdvKfJe7Rj7MXhymPP14ib9hAEMZllJH3mBg=; b=Tb3/wa0rN61bbx7NI+i6RiDoqXF/LHd7TjDxD6xd4Kp+HAjy/1hKIZMop5NVjKM9Sn Aw37jnMrgtOzNJgbkkhBo4Iuanjw1/r1Siz8m5nf0Ktom4Eo7H4dpLKv5r0TvEv2sBJ8 QbbH6HQ7U3bhI/95uMorVgqDyp7g6URyHrDNI= In-Reply-To: Content-Disposition: inline Sender: netfilter-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: "Xu, Qiang (FXSGSC)" Cc: "netfilter@vger.kernel.org" [Screenshots] Looks like nothing is wrong. Another possibility is that your gateway's netmask isn't defined properly. When you want to contact the server, the client issues an ARP request to find out the Mac address of the destination, since the destination is on the same network as the client (source). It is quite possible that the gateway's netmask (something other than 255.255.255.0) makes it respond to this ARP, thinking that it should route this packet to the destination. In fact, try this one too: * From the client, access the webpage * From the server, check the access logs, and see which IP had accessed the particular webpage you did in the previous step. The two should be equal. But, what continues to baffle me is the fact that no requests were coming from your client's ethernet interface! -- Vimal