Re: captive web system using DNAT and SNAT

["Taylor, Grant" <gtaylor@riverviewtech.net>]

> 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. . . .