captive web system using DNAT and SNAT

captive web system using DNAT and SNAT

[Matt Zagrabelny]

hello,

i am working on a captive web system and am using DNAT and SNAT to
accomplish this. things are going well, but i am have hit a road block.

currently our router is configured (via next hop routing) to send
traffic to the firewall for certain vlans on our network. thus i am
dealing with an asymmetrical route map. traffic coming from a vlan is
sent to the firewall, but traffic destined for the same vlan does not
pass through the firewall. this is fine, but it does make the problem a
little more challenging.

so in order to make the system captive, i am using DNAT. since it is an
asymmetrical route map, i am using SNAT.

DNAT ensures that web traffic goes to the box i want, and SNAT ensures
that the web talks back to firewall instead of directly to the original
client (who is not expecting to be getting traffic from *that* web
server).

the problem is that if the client has traffic destined for the captive
web server, then i dont want the firewall to DNAT or SNAT the traffic, i
just want to let it go peacefully.

here is my small firewall script that accomplishes the captive part:

# catch all redirects to registration server
iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j DNAT
--to-destination ${REGISTRATION_SERVER}

iptables -t nat -A POSTROUTING -o eth0 -p tcp -dport 80 -j SNAT
--to-source ${EXTERNAL_ADDRESS}

iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j DNAT
--to-destination ${REGISTRATION_SERVER}

iptables -t nat -A POSTROUTING -o eth0 -p tcp -dport 80 -j SNAT
--to-source ${EXTERNAL_ADDRESS}

so the above works for me. on my client machine i go to google.com the
firewall redirects me to the registration server (${REGISTRATION_SERVER}
and all is good.

what i want to do is if i type in ${REGISTRATION_SERVER} in my address
bar on the client system, then i dont want the firewall to do any DNAT
or SNAT. what is the best way to accomplish this?

thanks, 

matt zagrabelny

Re: captive web system using DNAT and SNAT

[Taylor, Grant]

> # catch all redirects to registration server
> iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j DNAT
> --to-destination ${REGISTRATION_SERVER}
> 
> iptables -t nat -A POSTROUTING -o eth0 -p tcp -dport 80 -j SNAT
> --to-source ${EXTERNAL_ADDRESS}
> 
> iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j DNAT
> --to-destination ${REGISTRATION_SERVER}
> 
> iptables -t nat -A POSTROUTING -o eth0 -p tcp -dport 80 -j SNAT
> --to-source ${EXTERNAL_ADDRESS}

Did you mean to post the same rules twice?  Or am I really just missing something?

> what i want to do is if i type in ${REGISTRATION_SERVER} in my address
> bar on the client system, then i dont want the firewall to do any DNAT
> or SNAT. what is the best way to accomplish this?

Try changing your DNAT rule to be like the following:

iptables -t nat -A PREROUTING -i eth1 -p tcp -d ! ${REGISTRATION_SERVER} -dport 80 -j DNAT --to-destination ${REGISTRATION_SERVER}

As this will DNAT any traffic that is not going to your ${REGISTRATION_SERVER} directly.



Grant. . . .

Re: captive web system using DNAT and SNAT

[Matt Zagrabelny]

On Thu, 2005-05-05 at 21:27 -0500, Taylor, Grant wrote:
> > # catch all redirects to registration server
> > iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j DNAT
> > --to-destination ${REGISTRATION_SERVER}
> > 
> > iptables -t nat -A POSTROUTING -o eth0 -p tcp -dport 80 -j SNAT
> > --to-source ${EXTERNAL_ADDRESS}
> > 
> > iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j DNAT
> > --to-destination ${REGISTRATION_SERVER}
> > 
> > iptables -t nat -A POSTROUTING -o eth0 -p tcp -dport 80 -j SNAT
> > --to-source ${EXTERNAL_ADDRESS}
> 
> Did you mean to post the same rules twice?  Or am I really just missing something?
> 

sort of. for the second set of rules s/80/443.

> > what i want to do is if i type in ${REGISTRATION_SERVER} in my address
> > bar on the client system, then i dont want the firewall to do any DNAT
> > or SNAT. what is the best way to accomplish this?
> 
> Try changing your DNAT rule to be like the following:
> 
> iptables -t nat -A PREROUTING -i eth1 -p tcp -d ! ${REGISTRATION_SERVER} -dport 80 -j DNAT --to-destination ${REGISTRATION_SERVER}

but the problem is that the traffic leaving the firewall will be SNATed.
so all traffic will be essentially go to the ${REGISTRATION_SERVER} but
i dont want to SNAT traffic that isnt DNATed.

ive tried the following yesterday:

iptables -t mangle -A PREROUTING -i eth1 -d ${REGISTRATION_SERVER} -j
MARK --set-mark 123

iptables -t nat -A PREROUTING -i eth1 -m mark --mark 123 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -m mark --mark 123 -j ACCEPT

iptables -t nat -A PREROUTING -i eth1 -p tcp -dport 80 -j DNAT
--to-destination ${REGISTRATION_SERVER}

iptables -t nat -A POSTROUTING -o eth0 -p tcp -dport 80 -j SNAT
--to-source ${EXTERNAL_ADDRESS}

and everything was still being DNATed and SNATed (including the traffic
destined for ${REGISTRATION_SERVER}). after a reboot this morning, the
above rules work. (yes, i was flushing my tables (nat, mangle, filter)).

any thoughts?

so my problem is solved, but i am curious why a reboot changes the way
the packet filtering/natting is done.

thanks,

matt zagrabelny

Re: captive web system using DNAT and SNAT

[Dave Cinege]

On Wednesday 31 December 1969 18:59, netfilter-request@lists.netfilter.org 
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

Re: captive web system using DNAT and SNAT

[Taylor, Grant]

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

Re: captive web system using DNAT and SNAT

[Jason Opperisano]

On Wed, May 11, 2005 at 01:36:45PM -0500, Taylor, Grant wrote:
> 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.

i'm pretty sure there's a known memory leak related to the kernel route
cache in the 2.6 kernel (don't recall kernel version the OP has), that
should have been fixed in 2.6.11.

-j

--
"Susan Sarandon: I'm Susan Sarandon. Most of you know me as Tim
 Robbins' mother, but actually I'm his wife!"
        --Family Guy

Re: captive web system using DNAT and SNAT

[Dave Cinege]

On Wednesday 31 December 1969 18:59, netfilter-request@lists.netfilter.org 
wrote:

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

You just spurred an idea in me:

My appliance works by creating a separate routing table for each gateway 
connection that is online. As hosts are authorized, to a particular gateway 
aside form the predictable firewall rules,  they get a routing rule, to use 
the proper default route for that gateway.  Like this:
  /sbin/ip rule add from %(hostip)s lookup %(gwtablename)s
  /sbin/ip route flush cache

When the host is deauthorized:
  /sbin/ip rule del from %(hostip)s lookup %(gwtablename)s
  /sbin/ip route flush cache

Maybe I need some more 'flush cache' calls around where I make that routing 
table and destory it...if it's not that there's a bug someplace in the cache 
code.