Re: captive web system using DNAT and SNAT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 31 December 1969 18:59, netfilter-request@xxxxxxxxxxxxxxxxxxx 
wrote:

> any thoughts?

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. 

Dave



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux