On Tue, 15 Nov 2005, Adam Rosi-Kessel wrote: > Jozsef Kadlecsik wrote: > >> Okay--would it be sufficient to grep on port 500? conntrack tracks by port, > >> right? So as long as there are *no* entries in ip_conntrack for port 500 at > >> any point while I'm trying to make this connection, doesn't it mean that > >> conntrack isn't handling the packets? > > Yes. And if conntrack does not handle them, NAT won't do either. > > Actually, now that I've *triple*-checked, I got a different result. I'm not > sure why this wasn't happening before, or if I was misreading the > ip_conntrack table, but now I *am* seeing the connection in question on port > 500. It is marked as ASSURED which I understand to mean that two way > traffic has occurred. Yes. Do you see the effect of the NAT table on the conntrack entry? > So, setting aside the question of why I wasn't seeing that before, shouldn't > I be able to see the incoming packets as they are routed to the internal > client machine, even if they are tracked connections? When I watch the > inward-facing interface with tcpdump, I don't see any of these packets > getting routed to that machine, although I do see the outbound packets. I don't clearly understand you here. It is always best to run tcpdump on both interfaces so that one can compare what packets are routed properly and how they were mangled/NAT-ed by the firewall. If some packets are missing from either side then that's a clear sign that those packets were dropped by either a matching rule/policy or by the system itself. Did the logging produce anything? Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
