HairPin Nat/Loop back NAT

[PeterG]

Is it possible to put a Hairpin NAT into the MX?

I have a Voice server which has a DNS record externally with which I could put a stub DNS record in for but I would then miss out everything else in that zone.

Appreciate your time.

[jdsilva]

I don't think you can... The MX only NAT's between WAN and LAN interfaces... There's no way that I'm aware of to do a LAN to LAN or WAN to WAN NAT on it. 

But... Maybe you can sort of do the same thing if you create a 1:1 or 1:Many NAT... Hang on let me try this...

[jdsilva · Accepted solution]

Holy crap! I can't believe that worked!

OK, so if you want to do a LAN to LAN hairpin you can leverage the 1:Many NAT feature to make this happen. To test this I have a Raspberry Pi behind an MX on VLAN 10 with an IP of 192.168.100.5. I then created the following 1:Many Nat rule under Security appliance > firewall:

So then as a test I then SSH'd to the 1:Many IP, which "hairpins" me back to the same Raspberry PI. 

Very cool. I expect this would work the same for a 1:1 NAT as well. So while not quite a true hairpin, it does the exact same thing. 

[PeterG]

Thanks for your help.  I'll give that a go.

[GiacomoS]

@jdsilva, I'll let you in on a secret. We don't really care what you NAT from and to... You can use whichever address you want on either end of the NAT 😉 Obviously from a WAN perspective you need to make sure that the IP address is assigned to you otherwise you won't go very far! XD

Giacomo

[Grillface]

Hi Giacomo......can the "Allowed remote IPs" field contain the LAN subnet even though "remote" is in the field title?  In other words, are you able to perform Loopback NAT from LAN to LAN with the Public IP being one from your Public IP block that includes the MX public IP address, but it NOT the MX public IP address?

[GiacomoS]

Hey Grillface!

I'm not sure if I understood your objective properly here, but I'll try and break the question down.

The Allowed Remote IPs field is sort of an access list. The only purpose is to restrict which IP addresses can make use of the NAT rule you created. The following is an example of a valid configuration, that would allow only 1.1.1.2 to use 1.1.1.1:12345 to access 192.168.0.52:54321

If I was instead coming from 2.2.2.2, the Allowed remote IPs list would stop me from accessing the server.

In terms of what you can put in that field, we would allow any IP address or range, but remember that the MX would evaluate this from its WAN's perspective. Traffic from the LAN would never be inbound on the WAN, therefore having your LAN in the Allowed remote IPs would not have any effect; in other words, if you took a packet capture on the WAN, you would never see a packet with a 192.168.0.X address in the source (unless you have an MPLS), so the Allowed remote IPs rule would never kick in. 

On the second part of your question, am I understanding it right that what you are trying to achieve is NAT subnet A onto Public IP A, for it to then talk via Public IP B to subnet B (using the 1:Many NAT)?

Many thanks!
Giacomo

[Jeizzen]

Ok

and your 10.0.0.1 refers to what interface ?

[jdsilva]

10.0.0.1 does not refer to any interface. In this case it's a virtual IP (VIP). It's not actually assigned anywhere. 

[webmanaus]

I think this is the problem, in the real world, you have a valid external IP address which is advertised via DNS, this IP is either the MX WAN IP or another IP routed to the MX on the WAN interface. However, when I'm using my mobile on the WiFi connected via VLAN to the LAN interface of the MX, my mobile finds the external IP in DNS but can't connect (just times out).

It seems there are two solutions to this problem

1) (Untested) Have a subnet of IP's routed to your MX WAN IP (minimum of /30), allocate one IP to your MX on a VLAN, allocate another IP in the range to your device. This would avoid using NAT, and therefore should work. I assume you need to allow the traffic on the WAN via your firewall. This wastes two globally valid IP's, and also means you can't use a single IP for different services on different internal machines.

2) (Tested) Use a Internal DNS server that can "see" the request is coming from an internal device, and therefore return the internal IP. When the request is coming from "external" then return the external IP and allow the MX to NAT as normal.

It would be great if we could simply use both NAT for incoming and normal DNS to allow the internal client to connect to the external MX WAN IP and the MX would be smart enough to still NAT that back inside.

eg, MX external IP is 1.1.1.1, we have configured 1:Many NAT so that port 80 is directed to 192.168.0.10:80

DNS says www.meraki.com points to 1.1.1.1

Some random internet user tries to browse to www.meraki.com hits the MX and is NATted to 192.168.0.10:80, which replies and works well. (this currently works)

Some internal user on 192.168.0.22 tries to browse to www.meraki.com, connects to 1.1.1.1:80, hits the MX, and the MX redirects (wit NAT) to 192.168.0.10:80, which replies and would work well (currently down't work).

I hope I've explained this well enough, if there is a solution to this problem, then I'd love to hear about it. It would save me having to use my desktop hosts file to fudge it.

[GiacomoS]

Hey folks,

@webmanaus I think I understand what you are trying to achieve. In my experience with other vendors, I have observed the same behaviour; my gut reaction here is, why would you want an internal client to go through the LAN of the MX, being filtered, shaped, routed, NATted, fragmented, go out of the WAN and be back in the WAN to then be filtered, shaped, routed, NATted, reassembled, to go back into the LAN? 😛 

In your situation, if you have a DNS server internally, I'd actually create an entry for the server that resolves locally, so you also don't have to modify every single host file out there. If you don't have an internal DNS, I'd consider Cisco Umbrella, as you can do this kind of split DNS resolution with a cloud managed platform.

@phelpsa06 at the moment this is not possible with the MX. There is a source NAT feature in development, so this should eventually appear in one of the future firmware releases, but that's not available just yet. 

Hope this helps!

Giac

[Jeizzen]

Hi GiacomoS,

One example or reason for that is that we could have a Guest subnet  that we want to be able to access LAN webserver.

But : we don't want to give them access to any LAN, and no internal DNS is available.

So we want them to go out and reach Public IP of MX, and then MX would realize it is destined for itself, and make them immediately come back in,  to reach LAN webserver. 

So yeah, a real NAT loopback ( or Source NAT, Hairpinnig, U-Turn NAT or NAT Reflection as I've seen all around) is not a confirmed official feature for now ?

if we want to create a real Hairpin, which is : LAN host only knows real Public IP of  MX Internet port to reach LAN webserver. Is MX able to handle this kind of request from host and create functional back-and-forth traffic ?

thanks,

[jdsilva]

Hey @Jeizzen ,

While I disagree with you on the definition of what a "real" hairpin NAT is, I can tell you with confidence that what you are asking does indeed work just fine with no special configuration. LAN hosts can reach another LAN host via it's public IP if at least one of a port forward, a 1:1 NAT or 1:Many NAT s configured correctly for the destination. 

Hope that helps!

Jason

[Jeizzen]

Hey Jason

Yeah might have been a little hard on the 'real' term 🙂

I just meant private IP --> to Public IP --> to private IP back-and-forth

I wonder now what is meant an the end of this topic that true SourceNAT is not supported.....

https://community.meraki.com/t5/Security-SD-WAN/NAT-hairpin-question/td-p/55741 

thanks for your details,

[jdsilva]

I think I can help with that clarification too 🙂

The MX can only have NAT rules that are based on the destination IP address of a given flow. Note that I said 'flow' and not 'packet', because obviously the source IP address field in a _response_ packet is NAT'd, but you can never create a rule that intentionally modifies the source IP for a flow. 

If you're clever enough there are actually ways to write rules to make this happen for very specific use cases, but I would suggest these configs are bad practice as they are not intuitive and really just taking advantage of side effects of certain configurations. You would be running the risk of no one else understanding your config, and perhaps even Meraki breaking the functionality in future updates as it's not technically supported 🙂

[phelpsa06]

Hey is it possible to NAT between 2 LAN connections? 

Example, LAN1 10.1.1.0/24, LAN2 192.168.1.0/24.  Anything coming from LAN2 could be translated to 10.1.1.0/24. 

Meraki Uplink-10.1.1.117/24

Source IP-10.1.1.167

Destination-10.1.1.118

Translated Source Address-192.168.1.253

Translated Destination Address-192.168.1.10

Sorry to revive an old post, I am trying to replace an old firewall with a Z3 or spare MX.  All this firewall does is NAT between 2 different networks like the example above.

Thanks!

[Jeizzen]

thanks,