All of lore.kernel.org
 help / color / mirror / Atom feed
* Private IP getting past IPTables NAT
@ 2012-03-02  3:53 Lesley Kimmel
  2012-03-02 10:12 ` Gáspár Lajos
  0 siblings, 1 reply; 3+ messages in thread
From: Lesley Kimmel @ 2012-03-02  3:53 UTC (permalink / raw)
  To: netfilter

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)
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
ACCEPT    all    eth0    any    192.168.0.0/24    anywhere    #(to allow all 
outgoing traffic)

Chain POSTROUTING (policy DROP)
target    prot    in    out    source        destination
SNAT        all    any    eth1    192.168.0.1    anywhere 
to:abc.abc.abc.1
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

Chain OUTPUT (policy ACCEPT)

Table: filter
Chain Input (policy ACCEPT)
target    prot    in    out    source        destination

Chain FORWARD (policy ACCEPT)
target    prot    in    out    source        destination

Chain OUTPUT (policy ACCEPT)
target    prot    in    out    source        destination

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:

Table: nat
Chain PREROUTING (policy DROP)
target    prot    in    out    source        destination
DNAT        tcp    eth1    any    anywhere        abc.abc.abc.1 
to:192.168.0.1
ACCEPT    all    eth0    any    192.168.0.0/24    anywhere    #(to allow all 
outgoing traffic)

Chain POSTROUTING (policy DROP)
target    prot    in    out    source        destination
SNAT        all    any    eth1    192.168.0.1    anywhere 
to:abc.abc.abc.1

Chain OUTPUT (policy ACCEPT)

Table: filter
Chain Input (policy ACCEPT)
target    prot    in    out    source        destination

Chain FORWARD (policy ACCEPT)
target    prot    in    out    source        destination

Chain OUTPUT (policy ACCEPT)
target    prot    in    out    source        destination

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. 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Private IP getting past IPTables NAT
  2012-03-02  3:53 Private IP getting past IPTables NAT Lesley Kimmel
@ 2012-03-02 10:12 ` Gáspár Lajos
  2012-03-02 13:16   ` Lesley Kimmel
  0 siblings, 1 reply; 3+ messages in thread
From: Gáspár Lajos @ 2012-03-02 10:12 UTC (permalink / raw)
  To: Lesley Kimmel; +Cc: netfilter

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Private IP getting past IPTables NAT
  2012-03-02 10:12 ` Gáspár Lajos
@ 2012-03-02 13:16   ` Lesley Kimmel
  0 siblings, 0 replies; 3+ messages in thread
From: Lesley Kimmel @ 2012-03-02 13:16 UTC (permalink / raw)
  To: Gáspár Lajos; +Cc: netfilter

Swifty;

Thanks for the input.  In truth I have done much of what you said.  I had 
most of the filtering and forwarding in the filter table as you described. 
However, once we saw the problem we attempted to remove as much as we 
possibly could from the table and slowly add it back to see where the issue 
was.

We do in fact only preroute port 443 on the PREROUTING chain.  I'm sorry 
that I forgot to include that.

Do you see any issue that both of the public IP addresses are on the same 
subnet?

You bring up a good point that I was also trying to understand (rather 
unrelated to my problem).  It seems that even though connection tracking 
arguments (ESTABLISHED/RELATED) are allowed in the NAT table they don't 
really affect the outcome as only the first packet is seen as you said.  Is 
that accurate?  I had some ESTABLISHED/RELATED rules in my PREROUTING chain 
before and they never saw packets.  That must be the explanation.

-----Original Message----- 
From: Gáspár Lajos
Sent: Friday, March 02, 2012 4:12 AM
To: Lesley Kimmel
Cc: netfilter@vger.kernel.org
Subject: Re: Private IP getting past IPTables NAT

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


--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html 


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-03-02 13:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-02  3:53 Private IP getting past IPTables NAT Lesley Kimmel
2012-03-02 10:12 ` Gáspár Lajos
2012-03-02 13:16   ` Lesley Kimmel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.