From mboxrd@z Thu Jan 1 00:00:00 1970 From: Filip Sneppe Subject: Re: trouble with expect_related Date: 07 Jan 2003 18:07:43 +0100 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <1041959263.502.248.camel@xbox> References: <1041651291.1637.41.camel@exile> <1041933003.502.23.camel@xbox> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org Return-path: To: Rich Wellner In-Reply-To: Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org On Tue, 2003-01-07 at 16:59, Rich Wellner wrote: > Filip Sneppe writes: > > Do you see the expected connection in /proc/net/ip_conntrack? It should > > be preceded by "EXPECTING:" if it hasn't seen any traffic yet. > > Ok, this is very helpful. I didn't know about that vfile. There is the line > I expect there. > > EXPECTING: proto=6 src=131.225.80.34 dst=207.252.250.2 sport=0 dport=41209 > > I don't know where to look to find out what proto 6 is, but the rest *seems* > ok. proto=6 means it's a tcp packet. /etc/protocols has all the protocol numbers. > The src, 131.225.80.34 is the machine I expect to be calling me back. The > sport of 0 should be ok because I don't have that byte masked in my call to > expect_related the dport is correct. > > I wasn't sure if the dst should be the NAT node or the private net node, so > I've tried it both ways: > > EXPECTING: proto=6 src=131.225.80.34 dst=192.168.1.2 sport=0 dport=41330 > > And neither forwarded the connection. Judging by the FTP example the dst > should be the private node, right? I *think* that EXPECTING should show the packet as it appears on the wire, since you should call ip_conntrack_change_expect in the nat helper code to change the expectation. Not 100% sure though. You could try without NAT. > And I reconfirmed using tcpdump that the incoming connection is still being > attempted and is on the correct port. > As I pointed this out in my very first reply, and I suspect that this may be the cause of the problem: Are you letting the RELATED traffic in with the appropriate iptables rules ? Can you post your firewall script, chain policies etc ? I have never seen any reports of the connection tracking code not picking up related TCP packets unless they were being blocked by policy. Regards, Filip