Port Forwarding Broken?

[bambinobub]

Quick background:
Attempting to get OpenVPN running on network using a raspberry pi. I have the server configured, client configurations distributed, etc. UFW on the pi has both 443/tcp and 1194/udp open.
DST-NAT on the router appears to be broken. I cannot forward or open ANY ports in NAT and I’m 99% certain I have the rules appropriately configured.

I’ve pasted my firewall config below. Local VPN address is 192.168.88.94.

/ip firewall filter
add action=passthrough chain=forward dst-port=44695 log=yes log-prefix=44695_forward protocol=tcp
add action=passthrough chain=input dst-port=44695 log=yes log-prefix=44695_input protocol=tcp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment=OpenVPNServer_UDP/1194 dst-address=192.168.88.94 dst-port=1194 log=yes \
    log-prefix=OpenVPN_UDP protocol=udp to-addresses=192.168.88.94 to-ports=1194
add action=dst-nat chain=dstnat comment=OpenVPNServer_TCP/443 dst-address=192.168.88.94 dst-port=443 log=yes \
    log-prefix=OpenVPN_TCP protocol=tcp to-addresses=192.168.88.94 to-ports=443

To troubleshoot, I added a couple rules to the router firewall filter:

add action=passthrough chain=forward dst-port=44695 log=yes log-prefix=44695_forward protocol=tcp
add action=passthrough chain=input dst-port=44695 log=yes log-prefix=44695_input protocol=tcp

…and pushed them to the top of the list.

In telnet, I try to open a connection to my home IP via port 44695 and connection fails:

Connecting To 69.207.177.35...Could not open connection to the host, on port 44695: Connect failed

However, the INPUT chain rule above receives packets and data, while the FORWARD chain rule does not show any traffic.


Not sure what is causing packets to be blocked despite having NAT configured. Help is appreciated.

[sindy]

In both your dst-nat rules, dst-address (match condition) is the same like to-addresses (parameter of the dst-nat action), and dst-port is the same like to-ports, so the rules effectively do nothing.

Correct rules should say something like dst-address=wan.ip.of.the.router dst-port=44695 action=dst-nat to-addresses=192.168.88.94 to-ports=1194.

Since no dst-nat rule handles the incoming packets to port 44695 and the destination address of these packets is an own one of the router, these packets end in chain input.

filter follows nat, so once you fix the dst-nat rules, the passthrough rules in filter will not count either, because when reaching filter, the packets will already be dst-nated to port 1194.

[bambinobub]

In both your dst-nat rules, dst-address (match condition) is the same like to-addresses (parameter of the dst-nat action), and dst-port is the same like to-ports, so the rules effectively do nothing.

Correct rules should say something like dst-address=wan.ip.of.the.router dst-port=44695 action=dst-nat to-addresses=192.168.88.94 to-ports=1194.

Since no dst-nat rule handles the incoming packets to port 44695 and the destination address of these packets is an own one of the router, these packets end in chain input.

filter follows nat, so once you fix the dst-nat rules, the passthrough rules in filter will not count either, because when reaching filter, the packets will already be dst-nated to port 1194.

Hey, sindy. Thanks for the reply. Apologies for taking a while to get back to you. I didn’t receive an email when you replied and didn’t realize my post was even approved yet.

I have a followup question.

I rewrote the DST-NAT rules and removed the filter rules as follows, with my public IP address where it says “my_public_ip” in the dst-nat rules. I assumed my wan ip for my router is my public IP. Please correct if I am wrong.

I’m still unable to get packets through that port. Any other diagnostics I could run for you?

/ip firewall filter
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=
established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
add action=accept chain=forward comment=“defconf: accept in ipsec policy” ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy” ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=
established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment=“defconf: masquerade” ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment=OpenVPNServer_UDP/1194 dst-address=“my_public_ip” dst-port=1194 log=yes
log-prefix=OpenVPN_UDP protocol=udp to-addresses=192.168.88.94 to-ports=1194
add action=dst-nat chain=dstnat comment=OpenVPNServer_TCP/443 dst-address=“my_public_ip” dst-port=443 log=yes
log-prefix=OpenVPN_TCP protocol=tcp to-addresses=192.168.88.94 to-ports=443

[bambinobub]

[quote=anav post_id=978056 time=1673908754 user_id=115581]
1once again (pun intended) 99% arrogance fails to 1% truth.
[/quote]

Sorry, I don’t understand what you’re trying to say. I’m assuming it’s an insult.

[anav]

No, just an observation, you are neither the first or last to think there is nothing wrong on the configuration, truth be told I am also equally guilty often providing configs that conrtain errors Its very difficult to get a complete config right the first time and thus why one of the keys to any MT config is make it as simple and clear as possible starting with firewall rules…

[sindy]

I rewrote the DST-NAT rules and removed the filter rules as follows, with my public IP address where it says “my_public_ip” in the dst-nat rules. I assumed my wan ip for my router is my public IP.

It’s not clear from what you have posted so far whether your Mikrotik has a public IP directly on its WAN or whether it is connected to the LAN of some other router provided by ISP.

In any case, the dst-nat rules you have posted now still match on dst-port=1194 and dst-port=443, whereas your telnet test shows that you’ve tried to connect to port 44695. So maybe that’s the issue?

Another question is whether you do the tests from LAN of the same router or from outside (e.g. your mobile phone connected via the mobile network).