NAT overlaps with ports
Hi,
I have the following setup
kernel: 2.6.30.5-43.fc11
iptables-1.4.3.1-1.fc11
192.168.1.0/24 is my public IP range (eth0)
10.0.0.0/24 is my private IP range (eth1)
192.168.1.1 public IP of server
10.0.0.1 private IP of server
I'd like to add the following rules in the nat table:
[1] -A PREROUTING -i eth0 -d 192.168.1.1 -p tcp --dport 8080 -j DNAT --to-destination 10.0.0.1:8080
[2] -A POSTROUTING -o eth0 -s 10.0.0.1 -p tcp --sport 8080 -j SNAT --to-source 192.168.1.1:8080
[3] -A POSTROUTING -o eth0 -s 10.0.0.0/24 --to-source 192.168.1.1-192.168.1.10
According to http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html
iptables is clever enough to avoid overlaps and clashes.
Are we sure that there isn't any chance to map a random packet (not from the server) to 192.168.1.1:8080 in rule [3]?
I mean, does rule [2] reserve port 8080 of 192.168.1.1 ?
best regards,
Giannis
Hello,
Quoted 2 lines · Kapetanakis Giannis
192.168.1.0/24 is my public IP range (eth0)
This IP range is private, not public.
If you made it up, please use the 192.0.2.0/24 range reserved for examples and documentation instead.
Quoted 4 lines
10.0.0.0/24 is my private IP range (eth1)
192.168.1.1 public IP of server
10.0.0.1 private IP of server
Quoted 8 lines
I'd like to add the following rules in the nat table:
[1] -A PREROUTING -i eth0 -d 192.168.1.1 -p tcp --dport 8080 -j DNAT --to-destination 10.0.0.1:8080
[2] -A POSTROUTING -o eth0 -s 10.0.0.1 -p tcp --sport 8080 -j SNAT --to-source 192.168.1.1:8080
[3] -A POSTROUTING -o eth0 -s 10.0.0.0/24 --to-source 192.168.1.1-192.168.1.10
Rule [2] is pointless. Packets with source port 8080 are obviously replies, and Netfilter NAT implicitly takes care of reply packets packets. Actually, the 'nat' chains don't even see reply packets.
Quoted 5 lines
According to http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html
iptables is clever enough to avoid overlaps and clashes.
Are we sure that there isn't any chance to map a random packet (not from the server)
to 192.168.1.1:8080 in rule [3]?
No. That could happen as long as it does not create a collision with an existing mapping. Why do you worry about it ?
The important point is that netfilter avoids collisions between existing NAT mappings. Rules do not create mappings by themselves, a mapping is created only for each new connection created by a packet.
Quoted 1 line
I mean, does rule [2] reserve port 8080 of 192.168.1.1 ?
No. NAT rules do not reserve anything.
Quoted 4 lines · Pascal Hambourg
This IP range is private, not public.
If you made it up, please use the 192.0.2.0/24 range reserved for examples and documentation instead.
Yes I made it up.
Quoted 13 lines
Quoted 4 lines
10.0.0.0/24 is my private IP range (eth1)
192.168.1.1 public IP of server
10.0.0.1 private IP of serverQuoted 9 lines
I'd like to add the following rules in the nat table:
[1] -A PREROUTING -i eth0 -d 192.168.1.1 -p tcp --dport 8080 -j DNAT --to-destination 10.0.0.1:8080
[2] -A POSTROUTING -o eth0 -s 10.0.0.1 -p tcp --sport 8080 -j SNAT --to-source 192.168.1.1:8080
[3] -A POSTROUTING -o eth0 -s 10.0.0.0/24 --to-source 192.168.1.1-192.168.1.10
Quoted 4 lines
Rule [2] is pointless. Packets with source port 8080 are obviously replies, and Netfilter NAT implicitly takes care of reply packets packets. Actually, the 'nat' chains don't even see reply packets.
You're right, I will remove it.
Quoted 6 lines
Quoted 6 lines
According to http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html
iptables is clever enough to avoid overlaps and clashes.
Are we sure that there isn't any chance to map a random packet (not from the server)
to 192.168.1.1:8080 in rule [3]?
Quoted 6 lines
No. That could happen as long as it does not create a collision with an existing mapping. Why do you worry about it ?
The important point is that netfilter avoids collisions between existing NAT mappings. Rules do not create mappings by themselves, a mapping is created only for each new connection created by a packet.
What I'm worried of is than a random connection could be created which uses the mapping of port 8080 of 192.168.1.1 and then the internal server would not be available. But I guess this is not a problem since a connection has 4 parameters src/dst ip/port.
thanks for answering
Giannis
Quoted 6 lines · Kapetanakis Giannis
What I'm worried of is than a random connection could be created which uses the mapping of port 8080 of 192.168.1.1 and then the internal server would not be available.
But I guess this is not a problem since a connection has 4 parameters src/dst ip/port.
Indeed, if some random outgoing connection to a remote host is mapped on source port 8080 it is very unlikely to disrupt access to the internal server, and it would only affect access from that remote host during a short delay after the connection has been terminated (until the mapping is deleted).