On studying NAT - RouterOS - MikroTik Documentation Hairpin NAT section, I notice that the picture calls the local network interface ‘bridge1’ (like the automatically created bridge interface in my RouterOS). However, the instructions below for setting up Hairpin NAT includes a reference to a ‘LAN’ interface that is not explained or defined on the page.
Thanks for the comments all! For my hairpin NAT src-nat rule I went with “out-interface=bridge”, but I trust “out-interface-list=LAN” would work equally well for home network Mikrotik users where the only entry in the LAN list is in fact bridge.
After this change to my configuration, I still couldn’t get the hairpin NAT to work. It was only after I found this post Hairpin NAT doesn't work - #14 by Josephny that I found that in fact my misconfiguration happens in the accompanying dst-nat rule.
Since it took ages for me to figure this one out, I echo the solution here: make sure that your dst-nat rule does not include an in-interface!
Of course the example in the documentation is correct and defines the WAN-IP dst-address in the dst-nat rule and not an in-interface. But for home network Mikrotik users with a dynamic WAN-IP, you might hesitate to put the (changing) WAN-IP in your dst-nat rule. And from outside your network, in-interface=WAN works equally well (but not when you want to hairpin NAT).
The link above provides an elegant example. If you use dst-address-type=local instead of dst-address=WAN-ip, you make a dynamic reference to all IP’s that are ‘local to the router’, e.g. both the WAN IP and the LAN-IP.
In general, hairpin nat is required for traffic going to a server within the same subnet as users.
The easy fix is to move servers or users to a different subnet.
Port forwarding requires the use of dstnat rules, and one needs to identify the in-interface aspect. For a static WANIP, use of dst-address works for both external and internal users. For dynamic WANIP, one has to get a bit creative and we can do that easily by creating a dst-address-list.
The standard hairpin and port forwarding rules are:
Note1: The generic hairpin nat rule above, is simple, works and covers off 1 OR MORE servers. Done!!
Note2A: I am not fond of the local address usage, as that will only work if you have a single subnet on the network and if you have other subnets, then you have to add other manipulations to the rule. In other words, its potentially limiting, one might get away with it for obscure ports but not 433!!
Note2B: Using the generic dst-address-list=MyWAN works with 1 OR MORE subnets. Done!
In case all port-forwarding rules keep the destination ports intact (no mapping from 8443 to 443 for example), it might be preferable to, in addition to hairpin-NAT, also implement split DNS.
We would have different subdomains for each of the service hosts. From the outside, all the subdomains point to the public WAN IP address, and DSTNAT is set up. But locally in the LAN, the local DNS resolver will resolve the subdomains directly to their local IP addresses.
LAN devices in the same subnet as the service hosts will then be able to make direct connections to them, bypassing the router (and skip hairpin-NAT), which should improve performance considerably, especially for high throughput services like NAS.
Of course, hairpin-NAT is still configured, for devices that don't use the local DNS servers.
It's used as an example for a domain / subdomain pointing to the WAN IP address (when using IP cloud you would put the xxxxxx.sn.mynetname.net in that address list entry).
Yep, I understand, but then it is far from being "generic", it assumes that you have a domain/subdomain on the WAN IP address, which may or may not be the case.
Can it be replaced by an actual (WAN) IP or not?
Also the OP has the src-nat with a specific dst-address (dst-address=192.168.1.7) whilst anav's example has the subnet (dst-address=192.168.1.0/24)?
But when you use port forwarding from the outside, you usually have a domain/subdomain (can of course be one of those from DDNS services too) pointing at the public IP address. That's the domain/subdomain you can use to put in the address list. The address list will automatically resolve the domain in to proper IP addresses, and also handle TTL correctly.
Specifying that address list in the rule (dst-address-list) is a better replacement for manually having dst-address=ip.add.re.ss when the WAN IP is dynamic.
Great to learn about the domain lookup trick to have one place to create the link between the WAN IP and the DDNS service domain name. It is indeed my use case to use the DDNS domain name to access the reverse proxy on port 443 both from outside and inside the network. I plan to implement this and update my other dst-nat rules as well to use this approach instead of the in-interface=WAN.
I tried first to use the split DNS trick and have the DDNS domain name in the local DNS server point to the local IP. This kind of works, but my mobile phone does not play along. Perhaps the DNS lease time is to blame? Not sure. So I have in fact implemented both the split DNS trick and the hairpin NAT trick to use the DDNS domain name to reach the reverse proxy.
As far as I now understand NAT rules, the hairpin NAT proposed by anav would result in all local connections between devices to appear to originate from the router, correct? Or is this only triggered when the traffic is directed to the WAN IP and then of course a dst-nat rule needs to be in place to jump back into the local network for that specific destination?
But only within the same subnet. Not when you go from VLAN 20 to VLAN 30 for example. And normally, when DSTNAT is not in action, devices in the same subnet communicate directly with each other on the Layer 2 (the switch layer) and don't use the gateway (the router) as middleman, the firewall will normally not be hit and no NAT will be performed.
The exception is that when the devices are connected to the different ports of the router and "Use IP Firewall" is turned on in the Bridge Settings. In that case communication between those devices in the same Layer 2 will also go through the firewall.
@anav, will this DNS look-up function if I also have the split DNS trick implemented? E.g. where the router itself has the DNS setting to return the local IP for the domainname.
Jaclaz, if someone is port forwarding, the assumption is that they have a fixed public WANIP, a dynamic public IP, or an ISP modem/router (with public IP), that they can forward ports to the MT device (double nat).
Hence they can either use the ip cloud name, or their own dyndns URL (for dynamic wanip).
In the case of using DNS for internal and Hairpin nat for external, I would tend to use one system not both but never thought about the efficiency that CGGX described. So it may be applicable!
Also DNS settings have improved and it may be easier than older methods.
