dstnat doesn't work on L009UiGS-RM Router

[Techsystem]

Hello to all Mikrotik enthusiasts,

Merry Christmas and Happy New Year!

I recently purchased a new Mikrotik L009UiGS-RM. Using the default configuration, I’m trying to open port 443 (and other ports) on it, but for some reason—unknown to me—I haven’t been able to.

The ether1 interface has a WAN connection with the public IP address xxx.xx.xx.123. There is another public IP (xxx.xx.xx.122) on the same interface, but you can ignore it for now.

the ip 192.168.88.200 represent my server.

So please advise.
here is my configuration:

[b]# 2024-12-28 18:54:30 by RouterOS 7.12.2
# software id = 
#
# model = L009UiGS
# serial number = 

/interface bridge
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.190
/ip dhcp-server
add address-pool=default-dhcp interface=bridge lease-time=10m name=defconf
/port
set 0 name=serial0
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8

/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN

/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
    192.168.88.0

add address=xxx.xx.xx.123/24 interface=ether1 network=xxx.xx.xx.0
add address=xxx.xx.xx.122/24 interface=ether1 network=xxx.xx.xx.0

/ip dhcp-client
add comment=defconf interface=ether1

/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=\
    192.168.88.1

/ip dns
set allow-remote-requests=yes servers=1.1.1.1
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/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=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
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 hw-offload=yes
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=src-nat chain=srcnat comment="defconf: masquerade" ipsec-policy=\
    out,none out-interface-list=WAN src-address=192.168.88.0/24 to-addresses=\
    xxx.xx.xx.123
add action=src-nat chain=srcnat comment="defconf: masquerade" ipsec-policy=\
    out,none out-interface-list=WAN src-address=192.168.88.0/24 to-addresses=\
    xxx.xx.xx.122

add action=dst-nat chain=dstnat dst-address=xxx.xx.xx.123 dst-port=443 \
    protocol=tcp to-addresses=192.168.88.200 to-ports=443
add action=dst-nat chain=dstnat dst-address=xxx.xx.xx.123 dst-port=443 \
    protocol=udp to-addresses=192.168.88.200 to-ports=443
add action=dst-nat chain=dstnat dst-address=xxx.xx.xx.123 dst-port=3306 \
    protocol=tcp to-addresses=192.168.88.200 to-ports=3306
add action=dst-nat chain=dstnat dst-address=xxx.xx.xx.123 dst-port=115 \
    protocol=tcp to-addresses=192.168.88.200 to-ports=115
add action=dst-nat chain=dstnat dst-address=xxx.xx.xx.123 dst-port=3389 \
    protocol=tcp to-addresses=192.168.88.200 to-ports=3389
add action=dst-nat chain=dstnat dst-address=xxx.xx.xx.123 dst-port=22 \
    protocol=tcp to-addresses=192.168.88.200 to-ports=22
add action=dst-nat chain=dstnat dst-address=xxx.xx.xx.123 dst-port=80 \
    protocol=tcp to-addresses=192.168.88.200 to-ports=80

/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=xxx.xx.xx.1 routing-table=main \
    suppress-hw-offload=no

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes

/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6

/ipv6 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 ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
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 packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=
/system note
set show-at-login=no
/system routerboard settings
set enter-setup-on=delete-key
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN[/b]

[sindy]

There is nothing unusual in your configuration, so since it “doesn’t work”, my first question is how do you test it. If you try to connect to x.x.x.123 from a device in 192.168.88.0/24, you would have to set up a “hairpin NAT” to make it work when the server is also in 192.168.88.0/24. But there are better approaches if you need clients in LAN to access a server in LAN via the public address, and if you only need it for testing, it is better to test it from the internet, i.e. the same way it will work in production.

Also, you only need to set to-ports in NAT rules if you want them to change the ports - in your case, it is not necessary. But nor is it harmful.

[Techsystem]

There is nothing unusual in your configuration, so since it “doesn’t work”, my first question is how do you test it. If you try to connect to x.x.x.123 from a device in 192.168.88.0/24, you would have to set up a “hairpin NAT” to make it work when the server is also in 192.168.88.0/24. But there are better approaches if you need clients in LAN to access a server in LAN via the public address, and if you only need it for testing, it is better to test it from the internet, i.e. the same way it will work in production.

Also, you only need to set to-ports in NAT rules if you want them to change the ports - in your case, it is not necessary. But nor is it harmful.

Hello Sindy.
1-I am testing from outside, but that doesn’t matter—it should work from both sides. I have the exact same setup with my CCR2004, and I can see the port is open from both outside and inside.
2-No, I want to open this port to make my server accessible from outside my LAN.

[BartoszP]

@Techsystem: could you be so kind and edit your post to apply proper tags for code?

[sindy]

1-I am testing from outside, but that doesn’t matter—it should work from both sides. I have the exact same setup with my CCR2004, and I can see the port is open from both outside and inside.

Open a command line window, make it as wide as your screen allows, run /tool sniffer quick port=3389 in it, and try establishing a RDP connection from the test client to the server. It should show you whether the connection attempt arrives at all and if yes, what happens next.

[Techsystem]

@Techsystem: could you be so kind and edit your post to apply proper tags for code?

Hey BartoszP, You mean like this above..?
recheck the post.

[BartoszP]

Perfetto as would Italian say.

[Techsystem]

1-I am testing from outside, but that doesn’t matter—it should work from both sides. I have the exact same setup with my CCR2004, and I can see the port is open from both outside and inside.

Open a command line window, make it as wide as your screen allows, run /tool sniffer quick port=3389 in it, and try establishing a RDP connection from the test client to the server. It should show you whether the connection attempt arrives at all and if yes, what happens next.

Here is what I get when trying to establish a Remote Desktop connection to the server:

On my side, the connection keeps rendering, and in the end, I receive a “connection timeout” error.

[sindy]

What does /ip arp print where address=192.168.88.200 show? The firewall rules are OK, there are no IPsec policies, no routing tables except main, no rules in raw… so unless there is a typo in the .123 address in the dst-nat rules, if the server at 192.168.88.200 can be pinged from the router itself, it looks like a bug.

[Techsystem]

What does /ip arp print where address=192.168.88.200 show? The firewall rules are OK, there are no IPsec policies, no routing tables except main, no rules in raw… so unless there is a typo in the .123 address in the dst-nat rules, if the server at 192.168.88.200 can be pinged from the router itself, it looks like a bug.

[Techsystem]

What does /ip arp print where address=192.168.88.200 show? The firewall rules are OK, there are no IPsec policies, no routing tables except main, no rules in raw… so unless there is a typo in the .123 address in the dst-nat rules, if the server at 192.168.88.200 can be pinged from the router itself, it looks like a bug.

[jvanhambelgium]

Is the target host a Windows machine ?
No host-firewall issues ?

If a Linux, can you do a quick “tcpdump” to see what actually ARRIVES there ?
If a Windows, perhaps quickly install “Wireshark” or something for a test.

[sindy]

Have you ever modified the dst-nat rules or have you put them in exactly the way they look now?

In recent ROS 7 versions, there is a nasty bug with some configuration items - if you modify them, the changes do not make it from the “visible” configuration to the “running” one. In some cases, disabling and enabling that item helps, in other cases it apparently doesn’t. I don’t know since when the bug is there so 7.12.2 may or may not be affected.

In any case, please try the following:
/ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=3389 action=dst-nat to-addresses=192.168.88.200 place-before=[find where dst-port~“3389”]
and then try testing while sniffing like in the first case again.

[Paternot]

Are You sure Your ISP isn’t blocking the port? 443 is HTTPS - and ISPs love to block it on residential installations. Set the a firewall rule to log access to this port, and see if something is getting in.

[sindy]

@Paternot, the first sniff result shows that the initial packet for port 3389 did arrive to ether1, so the ISP does not block it.

@Techsystem, @jvanhambelgium’s suggestion made me realize I may have jumped to conclusions too quickly - for the bridge port via which the server at .88.200 is reachable, set hw on the corresponding /interface bridge port row to no and run the sniffer again. Sniffing on ports with hw=yes may not show some traffic.

[anav]

1. The first problem I see is that you have both
   an IP address for WAN on ether1 AND a dhcp client on ether1.
   It cannot be both!!!
   If your certain about the IP address disable the dhcp client.

2 Suggest changing this default rule to three rules which are clearer as to the functionality and a bit more secure as well.
from:
add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface-list=WAN
TO:
add action=accept chain=forward comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=“port forwarding” connection-nat-state=dstnat
add action=drop chain=forward comment=“drop all else”

3. Masquerade rules are misleading in that the comments should be removed ( these are action sourcenat NOT masquerade )
   I dont think you need source address of the lan either but probably no harm.

/ip firewall nat
add action=src-nat chain=srcnat comment=“defconf: masquerade”** ipsec-policy=
out,none out-interface-list=WAN src-address=192.168.88.0/24 to-addresses=
xxx.xx.xx.123
add action=src-nat chain=srcnat comment=“defconf: masquerade” ipsec-policy=
out,none out-interface-list=WAN src-address=192.168.88.0/24 to-addresses=
xxx.xx.xx.122**

4. Other than that, dont see anything.

[wrkq]

1. The first problem I see is that you have both
   an IP address for WAN on ether1 AND a dhcp client on ether1.
   It cannot be both!!!

Of course it can be both, but one need to /really/ know that’s what they want.

Case in point, DOCSIS cable modems have the hard-coded-in-standard 192.168.100.1 IP for the management interface.
I have the modem configured in bridge mode, so it assigns me an upstream IP by DHCP and a gateway IP somewhere “up there” in ISP’s network. It does not do any routing tasks.
And so, I have secondary static 192.168.100.2 IP configured on the very same WAN interface next to the DHCP client, so I can access the modem and the internet at the same time.

[Paternot]

@Paternot, the first sniff result shows that the initial packet for port 3389 did arrive to ether1, so the ISP does not block it.

Port 3389. He was complaining about port 443, wasn’t he? Here is quite common for ISPs to block ports below 1024. Don’t know about his case though.

[Techsystem]

Is the target host a Windows machine ?
No host-firewall issues ?

If a Linux, can you do a quick “tcpdump” to see what actually ARRIVES there ?
If a Windows, perhaps quickly install “Wireshark” or something for a test.

Linux..
I will when I get back to my office.

[Techsystem]

Have you ever modified the dst-nat rules or have you put them in exactly the way they look now?

In recent ROS 7 versions, there is a nasty bug with some configuration items - if you modify them, the changes do not make it from the “visible” configuration to the “running” one. In some cases, disabling and enabling that item helps, in other cases it apparently doesn’t. I don’t know since when the bug is there so 7.12.2 may or may not be affected.

In any case, please try the following:
/ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=3389 action=dst-nat to-addresses=192.168.88.200 place-before=[find where dst-port~“3389”]
and then try testing while sniffing like in the first case again.

I tried disabling and enabling all the items, but that doesn’t work.
here is the result