That's in line with what I thought. So I'm back to not having an explanation for why some packets would get rejected as not part of an existing connection. So at this point best bet is >60 second delay somewhere? That doesn't seem likely... if I log all port 80 traffic, and wait until I see another drop, I should be able to correlate the two and verify that. Is that my best option? ----- Original Message ----- From: "Antony Stone" <Antony@xxxxxxxxxxxxxxxxxxxx> To: <netfilter@xxxxxxxxxxxxxxxxxxx> Sent: Friday, December 12, 2003 8:59 AM Subject: Re: Weird TCP flags? > > > iptables -A FORWARD -i ppp0 -o eth1 -p tcp --dport 80 -d 192.168.254.242 > > > -j ACCEPT > > > iptables -t nat -A PREROUTING -i ppp0 -d <my.public.ip.here> -p tcp > > > --dport 80 -j DNAT --to-destination 192.168.254.242 > > > > > > If I want to forward port 80 to that box, isn't that the way to do it? > > > How would a connection escape conntrack? > > > You never told it to make an entry in conntrack. Try this: > > iptables -A FORWARD -i ppp0 -o eth1 -p tcp --dport 80 -d 192.168.254.242 > > -m state --state NEW -j ACCEPT > > I disagree with this. > > Making the rule more explicit by matching state NEW is not a bad idea, but it > has nothing to do with whether a conntrack table entry gets created or not. > If you have compiled in connection tracking, or loaded the module, then all > connections which are ACCEPTed will result in a conntrack table entry. > There's no way to stop that happening on a connection-by-connection basis.
