Funny MikroTik IPSec problem

I had a funny problem with my router at home, where I have an ipsec split-tunnel to my office. You guys are probably smarter than me, so you will probably never experience this, but I thought I wanted to write a short blog post about it, because this problem I had could evolve into a serious headache, if you don’t know what you are looking at.

I have my RB750 running at home. It participates in the office VPN network through split tunnelled IPSec. Today I had to check something out on my router at home, while being in the office, but I could not connect to it, and continuously got a port unreachable error, which was a bit weird.

When I came home, I sniffed on the wan interface to figure out what was going on, and I found out that because I matched on in-interface in my NAT rules, it would also include ipsec traffic there. D’oh! So, let’s say my lan network is 192.168.1.0/24, and I have a pc on 192.168.1.10. I have a dst-nat rule pointing port 22 incoming on the wan side of the router to 192.168.1.10. If I ssh from 192.168.1.10 to 192.168.1.1, I will have access to the routers cli, while if I ssh to 192.168.1.1 from the other side of the ipsec tunnel, it will be forwarded to 192.168.1.10. The reason I saw the port unreachable message was because the NAT rule pointed to a PC that wasn’t  on… Brilliant.

So, let me write this in bold letters: Firewall rules, including NAT that match your WAN interface, will ALSO match your IPSec traffic!

If you need to match WAN traffic, match your WAN IP address instead of the ingress interface!

So, instead of this NAT rule:
/ip firewall nat add chain=dst-nat action=dst-nat in-interface=ether1 protocol=tcp dst-port=22 to-addresses=192.168.1.10

Do this:
/ip firewall add chain=dst-nat action=dst-nat dst-address=11.22.33.44 protocol=tcp dst-port=22 to-addresses=192.168.1.10

This was today’s service message from your friendly neighbourhood network guy.