I have a Linux machine and a Windows machine behind a router that implements NAT (the diagram might be overkill, but was fun to make):

network setup

I am forwarding RDP port (3389) on the router to the Linux machine because I want to audit RDP connections. For the Linux machine to forward RDP traffic, I wrote these iptables rules:

iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination win-box
iptables -A FORWARD -p tcp --dport 3389 -j ACCEPT

The port is listening on the Windows machine:

C:\Users\nimmy>netstat -a

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP           WIN-BOX:0         LISTENING

And the port is forwarding on the Linux machine:

# tcpdump port 3389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
01:33:11.451663 IP shieldsup.grc.com.56387 > linux-box.myapt.lan.ms-wbt-server: Flags [S], seq 94663035, win 8192, options [mss 1460], length 0
01:33:11.451846 IP shieldsup.grc.com.56387 > win-box.myapt.lan.ms-wbt-server: Flags [S], seq 94663035, win 8192, options [mss 1460], length 0

However, I am not getting any successful RDP connections from the outside. The port is not even responding:

C:\Users\outside-nimmy>telnet example.com 3389
Connecting To example.com...Could not open connection to the host, on port 3389: Connect failed

Any ideas?


Per @Zhiqiang Ma, I looked at nf_conntrack proc file during a connection attempt and this is what I see ( = linux-box, = win-box):

# cat /proc/net/nf_conntrack | grep 3389
ipv4     2 tcp      6 118 SYN_SENT src= dst= sport=43142 dport=3389 packets=6 bytes=264 [UNREPLIED] src= dst= sport=3389 dport=43142 packets=0 bytes=0 mark=0 secmark=0 zone=0 use=2

2nd update

Got tcpdump on the router and it seems that win-box is sending an RST packet:

21:20:24.767792 IP shieldsup.grc.com.45349 > linux-box.myapt.lan.3389: S 19088743:19088743(0) win 8192 <mss 1460>
21:20:24.768038 IP shieldsup.grc.com.45349 > win-box.myapt.lan.3389: S 19088743:19088743(0) win 8192 <mss 1460>
21:20:24.770674 IP win-box.myapt.lan.3389 > shieldsup.grc.com.45349: R 721745706:721745706(0) ack 755785049 win 0

Why would Windows be doing this?


Add port in iptables rules?:

iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination win-box:3389
iptables -A FORWARD -p tcp --dport 3389 -j ACCEPT

I am not very sure it's the reason. But I usually do it in this way: http://www.systutorials.com/816/port-forwarding-using-iptables/

You can all try flush the tables first: iptables -t nat -F; iptables -F and then add these two rules in case other rules in your iptables block the connection.

You may also

cat /proc/net/nf_conntrack

and see the content there. Each forwarding connection has entries there.

Note: MASQUERADE is required as well if the outbound route from windows does not by default pass through the iptables box; see comments below ( you may need to unhide).

  • Hi there! 8 out of 10 posts refer to your own blog. Though you do quote some information too: is referring to that blog really needed? – Arjan Dec 8 '10 at 23:45
  • @Zhigiang Ma: I added an update. – Belmin Fernandez Dec 8 '10 at 23:48
  • @Arjan Hi! Thanks for pointing it out. I will take care. Actually, I refer to my own blog which solves similar problem before and then I answer these questions. The answer is short usually and to the point and the blog provides more details. But I will take care of this and only add the link when it is very helpful to the answer. – ericzma Dec 9 '10 at 3:39
  • 1
    @Nimmy Lebby I think Router is the gateway of both linux-box and win-box. Am I right? Then do you mind make the linux-box the gateway of the win-box? That may solve the problem. The incoming packet goes in this way: Internet -> Router -> linux-box -> win-box. But the outgoing packet goes in different way: win-box -> Router -> Internet. linux-box is confused and mark the incoming packet as "[UNREPLIED]". I use port-forwarding on the gateway, which works quite well and I believe the two rules by now should work if linux-box is win-box's gateway. – ericzma Dec 9 '10 at 3:53
  • 1
    I enabled Masquerading /sbin/iptables -t nat -A POSTROUTING MASQUERADE and that did the trick. Thanks! – Belmin Fernandez Dec 22 '10 at 11:06

I saw you solved the issue with MASQUERADE. I didn't notice that last comment was hidden, so I had to solve the question for my own, thanks to the great Iptables Tutorial (look for it in Freshmeat). I did almost the same as you, but doing a SNAT instead of MASQUERADE, since the linux box has a static local IP. MASQUERADE would be more appropriate if the linux box had its IP given by DHCP, otherwise it's told to be a more processor consuming task.

I didn't need any FORWARD rule, although I had to

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

  • Yeah, this seems like the correct answer to me. SNAT sould work well for connections that come from a known IP range, MASQUERADE worked well for my case ( the outbound proxy was not the default route back on the windows side) – Daniel Farrell Aug 11 '15 at 20:06

This was my method on CentOS 7:

First, enable IPv4 forwarding - in /etc/sysctl.conf ensure there is the following line:


Then configure iptables:

iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination <WINDOWS SERVER IP>

iptables -A FORWARD -p tcp --dport 3389 -j ACCEPT

iptables -t nat -A POSTROUTING -j MASQUERADE

Finally, ensure iptables applies these rules on boot - many guides on the internet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.