Re: Private IP getting past IPTables NAT

["Gáspár Lajos" <swifty@freemail.hu>]

Hi,

2012-03-02 04:53 keltezéssel, Lesley Kimmel írta:
> I apologize if this is a duplicate email.  I have sent several times 
> as I was having issues with the spam filter.
>
> All;
>
> We have a Linux virtual server which we use as a NAT/Router (running 
> IPTables 1.2.11) to front-end a set of virtual machines on a private 
> (192.168.0.x) network.  In this private network are two web servers 
> and a few other application servers.  Our intent is to utilize two 
> public IP addresses on the NAT server to NAT to each back-end web server:
>
> External Interfaces:
> eth1 = abc.abc.abc.1 => 192.168.0.1 (webserver #1)
> eth1:0 = abc.abc.abc.2 => 192.168.0.2 (webserver #2)
> Internal Interface:
> eth0 = 192.168.0.3
>
> We had accomplished this with the following IPTables configuration
> Table: nat
> Chain PREROUTING (policy DROP)
Please do not filter in the nat table. It is used only for address 
rewriting and therefore is sees only the first packet in a connection!!!

> target    prot    in    out    source        destination
> DNAT        tcp    eth1    any    anywhere        abc.abc.abc.1 
> to:192.168.0.1
> DNAT        tcp    eth1    any    anywhere        abc.abc.abc.2 
> to:192.168.0.2
If these are only webservers then use the --dport 80 option...

> ACCEPT    all    eth0    any    192.168.0.0/24    anywhere    #(to 
> allow all outgoing traffic)
Again! Do not filter in nat!

>
> Chain POSTROUTING (policy DROP)
> target    prot    in    out    source        destination
> SNAT        all    any    eth1    192.168.0.1    anywhere 
> to:abc.abc.abc.1
(You do not really need this here, because you have a redundant rule 
(192.168.0.0/24 -> abc.abc.abc.1). But you can keep it :D )

> SNAT        all    any    eth1    192.168.0.2    anywhere 
> to:abc.abc.abc.2
> SNAT        all    any    eth1    192.168.0.0/24    anywhere 
> to:abc.abc.abc.1   #SNAT all other traffic to ip #1
Again! Do not filter in nat!

> Chain OUTPUT (policy ACCEPT)
>
> Table: filter
> Chain Input (policy ACCEPT)
> target    prot    in    out    source        destination
Set up here the enabled services... and use here the drop policy for any 
non enabled service
iptables -t filter -A INPUT -j ACCEPT -i lo
iptables -t filter -A INPUT -j ACCEPT -m conntrack --state 
ESTABLISHED,RELATED

> Chain FORWARD (policy ACCEPT)
> target    prot    in    out    source        destination
Set up here the forwarded services... and drop policy again... be aware 
that here you can filter the in_to_out and the out_to_in connections too..
iptables -t filter -A FORWARD -j ACCEPT -m conntrack --state 
ESTABLISHED,RELATED
iptables -t filter -A FORWARD -j ACCEPT -i eth0 -s 192.168.0.0/24
iptables -t filter -A FORWARD -j ACCEPT -o eth0 -d 192.168.0.1 --dport 80
iptables -t filter -A FORWARD -j ACCEPT -o eth0 -d 192.168.0.2 --dport 80

> Chain OUTPUT (policy ACCEPT)
> target    prot    in    out    source        destination
You can ignore this chain, but mainly this is the place for to filter 
all outgoing connections...
iptables -t filter -A OUTPUT -j ACCEPT -o lo

> Everything APPEARS to work correctly with this configuration.  
> However, several times a day network monitoring tools on the public 
> side of the NAT server see packets with source addresses from the 
> private network (e.g. 192.168.0.4).  In order to troubleshoot we 
> minimized our configuration to try to isolate the problem.  We took 
> out the NATing for the second IP:
Yes. It should work correctly... :-\

> With this configuration the 'leaking' of the private IP addresses 
> seems to stop.  However, we need to have the functionality of the 
> second IP address. Any insight into why the 'leak' is happening and 
> how we can add the second IP back in?
>
> Also, I have monitored the traffic across the NAT box with tcpdump.  
> The majority of traffic is NAT'd as expected.  Only occasionally do 
> packets 'escape'.  These packets have always been either FIN or RST 
> packets.
tcpdump is a very interesting tool... it sees packets on the line even 
before the iptables does...

AFAIK: RST and FIN packets are not considered as part of the 
connection... so maybe they do not hit the nat table anyhow... but this 
is very odd...
Two more things:
  1. your iptables version is VERY VERY VERY old...
  2. maybe there is a problem with your "virtual server" setup...

Swifty