iptables used to route RDP connection across subnet with NAT

borgy95 · 10-04-2013, 07:53 AM

First off I am assuming RDP traffic can be forwarded/NAT'd.
I've learnt this stuff from scratch to achieve this so I figure I've made a mistake along the way, so hopefully one of you seasoned iptable'rs has the answer.

I am trying to:

RDP from 10.14.136.x (subnet255.255.252.0) to 10.14.100.21. Via Eth0 10.14.138.72 forwarding to Eth1 10.14.100.2.

None of this is public, just two private networks I own but I want to keep them separate.

Code:

iptables -t nat -A PREROUTING -d 10.14.138.72 -i eth0 -j DNAT --to-destination 10.14.100.21
iptables -t nat -A POSTROUTING -s 10.14.100.21 -o eth0 -j SNAT --to-source 10.14.138.72
iptables -A FORWARD -p tcp -i eth0 -o eth1 -j ACCEPT

Do these rules makes sense? cos I'm getting stuck and I've tried a lot of revisions now...

Thanks in advance!

(as a side note, if anyone knows of a very comprehensive book/resource to crack routing with please reference it.)

Ser Olmy · 10-05-2013, 04:11 AM

RDP traffic can be NATed, as it uses the TCP transport protocol, and the application protocol itself does not make any references to IP addresses or host names.

Having said that, I'm not entirely sure about what you're trying to accomplish. I understand you have two subnets, 10.14.136.0/22 and 10.14.100.0/<something>. Communication between subnets is a simple matter of routing; the hosts on either network must be using a gateway. NAT is not required.

It seems you want the host 10.14.138.72 to forward RDP traffic destined for itself to 10.14.100.2. In that case, the first and last iptables commands will accomplish that:

Code:

iptables -t nat -A PREROUTING -d 10.14.138.72 -i eth0 -j DNAT --to-destination 10.14.100.21
iptables -A FORWARD -p tcp -i eth0 -o eth1 -j ACCEPT

The first line adds an address rewriting rule to the PREROUTING chain in the nat table, changing the destination address 10.14.138.72 into 10.14.100.21. The last line allows any TCP traffic through the FORWARD chain in the filter table. The rule is perhaps overly broad, but it will allow the NATed RDP packets through.

As mentioned, the host performing NAT in this scenario must either be assigned the 10.14.138.72 address, or it will have to be the gateway for hosts on the 10.14.136.0/22 network. It must also be able to reach the 10.14.100.0/? network via eth1.

The middle rule doesn't really make sense. It changes the source address of the NATed RDP packets to 10.14.138.72. What is the purpose of this rule?

borgy95 · 10-07-2013, 03:49 AM

Thanks Ser!

Let me try to use better english this time...

NAT host: eth0=10.14.138.72/22 eth1=10.14.100.2/25 s destination= 10.14.100.21 source= 10.14.136.0/22

Ok glad to hear the prerouting/forward are correct functional if not perfect. I had the POSTROUTING rule in there to handle the returned traffic, my logic was as RDP runs over TCP that meant there would be a two way stream of traffic and thus the router would need to know how to handle traffic coming back in the opposite direction. Is it not needed, in this context? If not in what normal context would the POSTROUTING rule be used?

Also i will tighten these up to use port 3389 for RDP connections.

Again thank you for taking the time to explain. I'll make some adjustments and post.

borgy95 · 10-07-2013, 05:53 AM

Another assumption i have made is that, when selecting the IP to connect to in the RDP window i should be entering 10.14.138.72 as this is the NIC the source client can see. Then when the traffic reaches 10.14.138.72 it will be translated by the iptables rules to go on to 10.14.100.21. Is this understanding correct?

Ser Olmy · 10-07-2013, 02:57 PM

Quote:

Originally Posted by borgy95

Another assumption i have made is that, when selecting the IP to connect to in the RDP window i should be entering 10.14.138.72 as this is the NIC the source client can see. Then when the traffic reaches 10.14.138.72 it will be translated by the iptables rules to go on to 10.14.100.21. Is this understanding correct?

Yes, that's correct.

The packet from the RDP client will go to 10.14.138.72, which doesn't actually have an RDP service running on TCP port 3389, but before it can be processed by the IP stack, it hits the PREROUTING chain of the nat table. The destination address is changed to 10.14.100.21 and, as a result, the packet is processed by the routing engine and sent out eth1.

The question then is, what happens to the return traffic? The RDP server will send reply packets to the source address of the initial packet, which will be a host on the 10.14.136.0/22 network. Unless the RDP server has a route for the 10.14.136.0/22 network with the IP address of the NATing host's address in the 10.14.100.0 network (10.14.100.2) as the next-hop address, the reply packets will never get back to the host on the 10.14.136.0/22 network.

A possible solution would be to use source NAT and change the source address to that of the eth1 interface of the NATing host. All RDP connections will appear to come from that single host, and since the client address would then be in the same network as the RDP server, no routing would be required for the return traffic. The NAT rule would look something like this:

Code:

iptables -t nat -A POSTROUTING -o eth1 -d 10.14.100.21 -p tcp --dport 3389 -j SNAT --to-source 10.14.100.2

(Assuming 10.14.100.2 is the IP address assigned to eth1 on the NATing host, while 10.14.100.21 is the RDP server.)

borgy95 · 10-14-2013, 10:48 AM

Again thanks for the detail. I've got the theory now, i understand the syntax, and its making sense etc. But no Joy I've tried alot combinations now. Including the ones in the above posts. my attempts have led me to the following:

Code:

iptables FORWARD --p tcp -i eth0 -o eth1 -j ACCEPT
iptables FORWARD -p tcp -i eth1 -o eth0 -j ACCEPT
iptables -t nat PREROUTING -s 10.14.138.72 -i eth0 -j DNAT --to-destination 10.14.100.21
iptables -t nat POSTROUTING -s 10.14.138.72 -o eth0 -j SNAT --to-source 10.14.138.72

I've tried so many i think something is out to get me and I've been pretty systematic about it all.

I've now disabled apparmor... But I'm thinking since SLES has both rcSuSEfirewall2 and iptables could there be a conflict? or are they both the same? By running the

Code:

/sbinrcSuSEfirewall2 restart

am I really refreshing the iptables so the rules take hold? Also I'm concerned that when I

Code:

tail /var/logs/messages

the firewall logs show nothing is happening much is happening even though I've been attempting to send RDP traffic through? I would have expected to at least something about packets dropping? perhaps there is somewhere I can view the logs in more detail, maybe this is the wrong place?