iptables - INPUT DROP ignore FORWARD rules?

[Hjalmar]

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 succeded with so that is all fine, just want to give you the back story.

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 forwardning so I'm very confused why those ports wont work. I started using iptables yesterday so it might be something very obvious however I don't know how to google this.

My setup:

Code: Select all

$ iptables -L -n 
Chain INPUT (policy DROP) 
target    prot opt source               destination         
ACCEPT     tcp  --  192.168.0.0/24      0.0.0.0/0            tcp dpt:22 
Chain FORWARD (policy ACCEPT) 
target     prot opt source               destination 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            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  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:11111 to:192.168.0.50:3389 <-(RDP server) 
Chain INPUT (policy ACCEPT) 
target     prot opt source               destination 
Chain POSTROUTING (policy ACCEPT) 
target     prot opt source               destination 
SNAT       all  --  192.168.0.0/24      0.0.0.0/0            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? and how do I solve so I use the DROP policy and still forward the 11111 traffic to 3389 at my local RDP server?

[p.H]

do the policy for INPUT also define the traffic for forward chain?

Indirectly, when the host is a VPN endpoint. INPUT and OUTPUT chains must accept the encrypted VPN traffic.

Notes :

1) Use "iptables-save" or "iptables -S" instead of "iptables -L" to print the ruleset; It is much better.
2) The rule in the FORWARD chain is pointless.

[Hjalmar]

1) Use "iptables-save" or "iptables -S" instead of "iptables -L" to print the ruleset; It is much better.

Okey, it looks like this:
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 11111 -j ACCEPT

nat:
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -p tcp -m tcp --dport 11111 -j DNAT --to-destination 192.168.0.50:3389
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j SNAT --to-source [Public IP]

2) The rule in the FORWARD chain is pointless.

Are they pointless just for my setup or are the FORWARD chain pointless in general?

I tried to remove the rule from FORWARDNING to INPUT but did not solve it either.
iptables -D FORWARD -p tcp -m tcp --dport 11111 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 11111 -j ACCEPT

[p.H]

Are they pointless just for my setup or are the FORWARD chain pointless in general?
I tried to remove the rule from FORWARDNING to INPUT but did not solve it either.

This rule is pointless in this setup. I did not say it was causing the issue. It is just useless.
1) The FORWARD policy is ACCEPT so there is no need for ACCEPT rules except if there are DROP or REJECt rules.
2) There is no reason that packets with destination port 1111 be forwarded (at least, no more reason that any other port, and actually a bit less because of the DNAT rule).
A rule which would be useful in a more restricted setup to accept packets after the DNAT rule is :

Code: Select all

iptables -A FORWARD -i tun0 -d 192.168.0.50 -p tcp --dport 3389 -j ACCEPT

Putting the rule in the INPUT chain is also pointless and useless. INPUT is for packets destined to the host (after PREROUTING).

I repeat :

INPUT and OUTPUT chains must accept the encrypted VPN traffic.

The simpler way to do this if all OUTPUT traffic is allowed is to use connection tracking for reply traffic :

Code: Select all

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

[Hjalmar]

Hi,

Thank you for all your help. I have done as you said and found other stuff on the web.
As for now the setup looks like this and it's almost working:

Code: Select all

# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i ens192 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.0.50/32 -j LOG --log-prefix "** TRACING FORWARD CHAIN **"
-A FORWARD -d 192.168.0.50/32 -i tun0 -p tcp -m tcp --dport 3389 -j ACCEPT
# iptables -S -t nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -p tcp -m tcp --dport 11111 -j DNAT --to-destination 192.168.0.50:3389
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j SNAT --to-source [Public IP]

And I have to thank you for this, it's not all done yet though. With the "Tracing forward chain"-rule I found out that the RDP traffic is going through the router and to the RDP server.
So I got wireshark to the RDP and see that the traffic is reaching the server, wohow! So, I do know that it's either the POSTROUTING is wrong or I need another Forward or something. I will come with an update when and IF I succed.

[p.H]

I do not understand what is still not working as you expect.