NOTE to Grant: The below might explain some of my issues Re: Linux forwarding Win XP hosts VERY slowly Please comment on your thoughts...
Matt,
Take a look at: /proc/net/ip_conntrack
I'm dealing with a lot of weird issues with an appliance I've made that does captive portaling and completely dynamic multiple gateway authorzation.
I'm starting to think some of my issues, that I thought were locking, are now actually connecting that are locked up.
Where I know this was a problem was in my captive portal redirecting. I have 2 dnsmasq's running. One on port 53 and one on 5353. The 5353 one replies with a dummy IP to DNS responses to allow the browser to attempt a connection...my firewall rules then REDIRECT to the appliance, and ultimatly the login page.
The problem is once that 53->5353 redirection conneciton is established, it's kept alive, even when a new rule is added that should exclude it.
Example: #Default rule
iptables -t nat -A PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 5353
#Host then logins in and authorizes. (Notice these are inserted before #the above.) iptables -t nat -I PREROUTING -d %(hostip)s -j ACCEPT iptables -t nat -I PREROUTING -s %(hostip)s -j ACCEPT
Should be ok, right? No. That host will continue to get REDIRECTed to port 5353.
How I solved this was: echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
Which forces the connection to time out in a 1 second.
I figured this would only be an issue with UDP connections like DNS. But after reviewing /proc/net/ip_conntrack 2 days ago when it seemed a host could no longer connect to the appliance's web server, I'm thinking this might be a similar issue of TCP connections going stale and no longer jibing with the rule set. (This may be caused by or compounded by buggy Windows traffic.)
So if things seem to get 'out of sync' again, you might try lowering some of the timeout values in /proc/sys/net/ipv4/netfilter/. I'm going to try this myself and see if it helps.
Very interesting. This makes me think that there is a kernel routing caching type issue. I expect that if this is indeed the case there could (or should) easily be a way to flush said cache or adjust a garbage collection interval. This might need to be (summarized and) cross posted to a kernel developers mailing list to get their thoughts on it.
Grant. . . .
