NAT is not a good thing, but it is frequently a necessity. Here are some of my quick tips to diagnosing the problems and some duct tape solutions with Mikrotik routers.
This last week I ran into a somewhat interesting problem and I figured it might be helpful for people for their own diagnostics. The company has a half dozen monitoring devices that they want to monitor from remote locations. These devices all require you to “pull” the data (which means that some app or service needs to log into the device and get the data) so each device needs to have a port forwarded to it from the router.
Not a big deal in Mikrotik just add a rule like this:
ip firewall nat add chain=dstnat dst-address=192.0.2.89 protocol=tcp dst-port=8888 action=dst-nat to-addresses=192.168.1.20 to-ports=22
Make sure to have the correct protocol, external IP and Port as well as the correct internal IP and Port and you are done. (Probably a good idea to statically assign the IP of whatever device you are port forwarding to) At least most of the time. If you want to be a bit more secure about this you can have add “src-address=” or if you have multiple addresses “src-address-list=” and limit what addresses will be port forwarded from. (Not great security, but better then opening up the port for the whole wide world.)
Sometimes this doesn’t work. I was called this week and the company was saying that many of the port forwards they had me doing on their hosted Mikrotik router were not working.
My first question is always if the network service can be reached from a device that is on the same network as the device hosting the service. If that’s not the case then it’s normally a firewall or port issue on the device and I leave that to whoever is setting up the device to figure out. If local devices can access the service, then it’s time to knuckle down and figure out where the problem is.
Since I run windows and I am cheap, I like to use Packet Sender to just check to see if from a management IP (which I normally allow everything to/from, not great for security, but is worth it in time saved in diagnostics) just to see if the device is accessible. That will indicate where the issue could be, either in the firewall or probably some sort of network issue. I am sure you could possibly use the Packet Generator in Mikrotik to help with diagnostics, but I don’t know it well enough to do so.
Either result will still mean a cursory glance at the firewall rules just to make sure standard firewall rules are in place and working. Firewall rules that could be blocking. Input and Output rules do not matter because DST-NAT happens in Mikrotik packet flow before Input and Output firewall rules. But Forwarding rules can get you into trouble.
Next up is to check to make sure your port forward rule is setup and working as expected. Checking to see if the NAT rules are building up packets and bytes can let you know if you might have goofed up somewhere in your configuration. You can also use Packet Sender and it should increment your counters each time you send a packet, make sure the right counters are getting incremented, you could have another DST-NAT rule picking up your traffic.
ip firewall nat print stats
If you are seeing the correct rule incrementing at the correct times, then it’s likely a network issue of one type or another, especially if you are like me and don’t do a lot of blocking of traffic on your network. Though a good idea might be to just torch the interfaces and make sure you see the traffic coming and going correctly.
Sometimes you might want to do this earlier, especially if you don’t trust your customers to do network configuration correctly, but at this point you really ought to try pinging the device and see if it’s at least at the correct IP.
Sometimes the device won’t respond to Pings, because of an overactive firewall policy, at which point you should check in your routers ARP table to make sure the device is showing up there (Note, make sure to have an active Ping going to the device so you will know that the ARP table entry will be populated even if the device doesn’t respond to ICMP queries.)
ip arp print
Once you see the ARP entry, it’s not a bad idea to check to make sure what your router is seeing for the MAC address is the correct MAC address of the device. Plenty of bad network configs can happen with Static IP addressing.
At this point we are back to some sort of problem in the device hosting the service. If you can ping the device from the router’s LAN IP then the next step is to check to see if the device itself can send packets back out to the wider network, if it can’t access the wider internet then it’s diagnostics on that. Unfortunately, some devices are pretty stupid and don’t give you access to a utility for testing this. Fortunately for us, we have a Swiss Army knife for a router.
ping src-address=192.0.2.89 address=192.168.1.20
Make sure to use the WAN IP of your router and make sure you allow ICMP packets to your WAN IP on the router, but this can indicate to you whether or not the device’s network is setup correctly. If this fails, but you just want to get things working, there is one more trick you can use:
ip firewall nat add chain=srcnat dst-address=192.168.1.20 protocol=tcp dst-port=8888 src-address=!192.168.1.0/24 to-addresses=192.168.1.1
Make sure to use the LAN IP of your router in the “to-addresses” field. Again the packet flow diagram will help us here, DST-NAT chain happens way before SRC-NAT chain. So what happens is the router DST-NATs the packets the packets go through the forwarding firewall chain, then right before it sends out the packet it SRC-NATs the packet. Input and Output rules for the router can be completely skipped, most of the time. If you still are having issues you can put in specific input and output rules to allow this traffic through, but that’s for another time.
Now, this could cause some issues with the device in question depending on how smart it is about connection tracking, some devices won’t appreciate it that there are multiple connections coming from a single IP, in which case issues can arise. At that point you would have to either get creative with multiple IP addresses you SRC-NAT to, or fix whatever the networking issue is with the device limiting it to only being able to send traffic to the local network.
Another option, which would be more secure would be to setup a VPN that will make all the traffic appear to be on the local network. This probably would be preferable in a lot of cases, and then you can up sell to a more expensive router to handle the increased CPU load.