I recently got a client-VPN at one of my Debian servers in my home network. I want to use it as another gateway in my network for certain devices. This is something I have succeeded with so that is all fine, just want to give you the backstory.

Now, I have an RDP server (WS 2019) that I'm able to connect to through WAN on my VPN as long as I don't use iptables -P INPUT DROP. However, I'm using port forwarding, so I'm very confused why those ports won't work. I started using iptables yesterday, so it might be something very obvious however I don't know how to google this.

My setup:

$ iptables -L -n  
Chain INPUT (policy DROP)  
target    prot opt source               destination         
ACCEPT     tcp  --            tcp dpt:22  
Chain FORWARD (policy ACCEPT)  
target     prot opt source               destination  
ACCEPT     tcp  --              tcp dpt:11111  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination      

$ iptables -L -n -t nat  
Chain PREROUTING (policy ACCEPT)  
target     prot opt source               destination  
DNAT       tcp  --              tcp dpt:11111 to: <-(RDP server)  
Chain INPUT (policy ACCEPT)  
target     prot opt source               destination  
target     prot opt source               destination  
SNAT       all  --            to:[my public VPN IP]  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination  

To be clear, the only thing I have to do to make everything work again is set policy for INPUT to ACCEPT, but I don't want to do that since it's a router to WAN.

So, do the policy for INPUT also define the traffic for forward chain? How do I solve this so I use the DROP policy and still forward the 11111 traffic to 3389 at my local RDP server?

  • Happy to assist. The iptables rules that you shared, are there on VPN client (Debian Server) or on the router or the VPN server? Is the RDP server located somewhere in the cloud or on your home network? Jan 26, 2021 at 15:31
  • I assume the cross-post at askubuntu.com/questions/1311020/… will be closed soon.
    – Jeff Schaller
    Jan 26, 2021 at 16:08
  • -1 because it's crossposted and the self answer (which isn't really an answer anyway) on the other site uses an answer here (LOG) without credit
    – A.B
    Jan 29, 2021 at 14:36

2 Answers 2


To ensure the traffic is actually reaching your Windows Server, I would suggest you to add a "-J LOG" at the end of your firewall script, so the package is logged right before being dropped. If you do not see the package being dropped, it is possible that Windows firewall could be dropping it. Additionally, I understand that this setup is probably a work in progress, but I am not recommend, at all, that you use ACCEPT as the default target for FORWARD chain in your firewall, since it would be very risky. You may also want to check Terminal Services log (not sure where they are), to ensure Windows is receiving and not dropping connection for any reason.

Hope this helps.


By having only the SSH port as an INPUT rule and then introducing iptables -P INPUT DROP, you are blocking incoming ICMP.

All modern operating systems (at least from Windows 95 onwards) use Path MTU Discovery (PMTUD) on TCP connections. MTU = Maximum Transfer Unit, basically the size of the largest packet that can be transmitted without splitting it into two or more smaller packets (fragmentation).

Basically, modern OSs will always send packets with the "don't fragment" flag set, and if a router somewhere finds they won't pass through a particular network hop because that hop has a smaller-than-normal maximum packet size, they'll expect that the router will send back an ICMP "Fragmentation Needed" packet that will also include the information of the largest packet size that will fit through unfragmented. Once they receive that ICMP message, they'll start using the specified size instead. As the process gets repeated on any hops with a constricting packet size, the TCP connection will automatically find the largest packet size that will be able to pass from the source all the way to the destination without fragmentation. All the routers in between can then work with optimum efficiency.

By blocking all ICMP, you've thrown a wrench into the works. Most likely your server is trying to send maximum-size packets and something else is trying to tell it "that won't fit, turn down your MTU a little". But since incoming ICMP is blocked, your server will blithely keep trying to send maximum-size packets that will never reach the intended recipient... until the connection times out.

You're also using a VPN. Because any package that gets inside a VPN tunnel will need to have a second set of address headers prefixed to it (plus perhaps some overhead for the encryption and/or for the VPN's own needs), most VPN connections will constrain the MTU to something just slightly smaller than the Ethernet's default value. So you will definitely need PMTUD to work.

Various cloud-based services may also have a slightly reduced MTU value, and not all of them have it exactly the same. So setting a smaller MTU value manually is not ideal.

You'll need to read up on ICMP, and decide for yourself which ICMP packets you consider safe enough to handle, and which ones you'll want to drop in your firewall.

Also, you should be aware that modern operating systems will already include some safeguards against ICMP-based attacks by default: for example, sending of ICMP error messages is usually considered to be of lower priority than handling any connections that are working normally. And the number of outgoing ICMP messages may already be rate-limited by the OS kernel itself: the network protocol code developers usually aren't complete fools.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .