So, when you have services available to the world through your external address/hostname, it’s nice to be able to access them via that as well. “Hairpinning” or Hairpin NAT is the term for the NAT redirection required to make this work.
Update 14/3/16: It’s been raised to me that it’s best to use split-DNS for this particular example, but it’s designed to be a simple one for documentation purposes. There’s much better ways of solving the problem, but:
- you don’t always control DNS,
- the service might be entirely IP-based - like IPsec,
- the service might have different internal ports to what’s externally facing (and can’t be reconfigured)
Amongst a whole host of other reasons. Just trust me 😉
Consider the following configuration:
- LAN address space: 10.0.0.0/8
- LAN server IP: 10.0.0.210
- Service is running on: TCP/5222.
- WAN interface: pppoe-out1
- WAN IP: 126.96.36.199
- Router LAN interface: ether2-master-local
The standard source NAT rule to allow masquerade internal clients for accessing the internet is as follows:
Basically “if it’s going out, NAT it.”
To allow external clients to access an internal service, a destination NAT rule is created. The important part that most documentation doesn’t specify is that you should set the dst-address-type to local, and set the dst-address to the WAN IP instead of just using the WAN interface.
To allow internal clients to access the service, a source NAT rule is required.
The general idea is that if it’s coming from the local LAN address space, and going to the local LAN address space, masquerade it. You’ll lose the source IP address when doing things like tcpdump etc, but that’s what you get.