Re: Private IP getting past IPTables NAT
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.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!!!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 destinationDNAT 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!
(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 )Chain POSTROUTING (policy DROP) target prot in out source destinationSNAT 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
Again! Do not filter in nat!
Set up here the enabled services... and use here the drop policy for any non enabled serviceChain OUTPUT (policy ACCEPT) Table: filter Chain Input (policy ACCEPT) target prot in out source destination
iptables -t filter -A INPUT -j ACCEPT -i loiptables -t filter -A INPUT -j ACCEPT -m conntrack --state ESTABLISHED,RELATED
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,RELATEDChain FORWARD (policy ACCEPT) target prot in out source destination
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
You can ignore this chain, but mainly this is the place for to filter all outgoing connections...Chain OUTPUT (policy ACCEPT) target prot in out source destination
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?tcpdump is a very interesting tool... it sees packets on the line even before the iptables does...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.
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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html