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. 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. Does that mean that something is going wrong with the connection tracking, or that I'm misunderstanding tcpdump, or something else? -- Adam Rosi-Kessel http://adam.rosi-kessel.org
Attachment:
signature.asc
Description: OpenPGP digital signature
