Iptables for NAT on CentOS 5. Routing problems
 

Hello,

Let me dive right in and try to explain my setup...




ISP Cable Modem -WAN IP
|
|
Airlink101 Wired Router AR504 -192.168.2.1
|
|
5 Port 100Mbps HUB
| | | |
| | | |
| | | |
| | | --- WinXP Pro SP3 -192.168.2.2
| | (Open Ports: 3389)^
| | --- WinXP Pro SP3 -192.168.2.3
| | (Open Ports: 3389)^
| --- Slackware 12 -192.168.2.5 (Kernel 2.6.x)
| (Open ports: 22,5901,18600,18601)^
--- Slackware 12 -192.168.2.4 (Kernel 2.6.x) (Open ports: 22,5901)
|
VmWare Workstation v6.5
| |
| --- WinXP Pro SP3 Perf. Ed. -192.168.2.6
| (Open Ports: 3389,5901)^
--- CentOS 5 -192.168.2.20 (Kernel 2.6.x)
(Open Ports: 22,5901)

I think I have covered the layout of my internal network. So my current sitution are this. My router does have a limited NAT capability, by that I mean I am able to configure the router to take an incoming connection on port 3389 (for instance) and redirect that connection to an internal machine (i.e: 192.168.2.2)

But I have no option in my router for taking and incoming connection on port 18605 and directing it to 192.168.2.5 on port 5901

So I have done some reading online and in the 'man iptables' on my CentOS system. My understand is that I should be able to tell the iptables to take an incoming connection on port 18605 and redirect it and all subsequent connections in the same stream to 192.168.2.5 on port 5901.

I have tried entering rules in the nat table of iptables, things like...

/usr/sbin/iptables -t nat -A PREROUTING -p tcp -m tcp -d 192.168.2.20 --dport 18605 -j DNAT --to-destination 192.168.2.5:5901

I have also entered a rule into the filter table...

/usr/sbin/iptables -A INPUT -p tcp -m tcp --dport 186005 -j ACCEPT

I have also enabled IP forwarding via...

echo "1" > /proc/sys/net/ipv4/ip_forward

I hope I have provided enough information regarding my situation. I would like any help anyone could give me. I have a good understand of the linux O/S. And I would always rather learn than have it done for me. :-)

If any1 needs more information i will be happy to provide it in futher posts. Thanks in advance.

Wasn't it supposed to be 18605 ?

Despite that, it seems everything's right on your Linux config.

On this case, your router should also be redirecting all the traffic to your linux box in order to the iptables rules get any effect.

Right... this should mostly work, BUT:

1. Ensure the router is configured to send packets destined for port 18605 to 192.168.2.20 (I assume this is the machine you've set up the iptables rules on).

and

2. The filter table rule should be in the FORWARD, not INPUT chain. Also, the destination port in that rule might need to be 5901, depending on whether iptables passes the packet through the nat or filter tables first. Don't quote me on this, but I think the PREROUTING chains (in all tables) are traversed first, such that when the packet arrives in the FORWARD chain in the filter table, its destination port will be 5901. I'm sure there's a pretty picture on the netfilter website that shows how the tables are traversed.

P.S. The LOG target is always useful in these situations. ;)

Hope this helps.

I just realised there's another problem with this configuration. When the packet arrives at 192.168.2.5, its source address will be the internet address that the packet originated from. 192.168.2.5 will reply directly to this address. Fine, you may think. Wrong! The destination port has been changed on the way in from 18605 to 5901. The reply from 192.168.2.5 to the originator will be from source port 5901, but the originator expects its reply to come from port 18605. The source port number in the outgoing direction needs to be changed back for the reply to be valid. See RFC793. It'd take me some serious thinking to figure out how to do this, if it can be done at all. You need to change the source address of the incoming packet to make 192.168.2.5 send any replies back via the iptables NAT router. The router will need to keep track of the original address from which the connection originated. You might be able to do this with an SNAT or MASQUERADE rule in the POSTROUTING chain, if it can be done at all.

I see that exact problem you describe when I look at the logs gathered from wireshark.

I will have to go back to the drawing board on this one I guess. If anyone have any suggestions as to how i may accomplish what I am after would be great thanks.

And Thanks dCriminal