NAT HAIRPINNING

[Luigi Celeste]

Hi! who can paste a sample of an NAT HAIRPINNING running config for Cisco IOS?

Thank's.

Gigi

[Peter Paluch · Accepted solution]

Luigi,

Here you go:

ip access-list standard PBR
 permit 10.0.1.0 0.0.0.255
!
route-map PBRNAT permit 10
 match ip address PBR
 set interface Loopback0
! 
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip nat inside
 ip virtual-reassembly
!
interface FastEthernet0/0
 ip address 192.0.2.1 255.255.255.0 secondary
 ip address 10.0.1.1 255.255.255.0
 ip nat outside
 ip policy route-map PBRNAT
!
ip nat pool NATPOOL 192.0.2.11 192.0.2.20 prefix-length 24
ip nat inside source list PBR pool NATPOOL overload

Alternatively, the new way of configuring of NAT-on-stick using a so-called NVI is as follows:

interface FastEthernet0/0
 ip address 192.0.2.1 255.255.255.0 secondary
 ip address 10.0.1.1 255.255.255.0
 no ip redirects
 ip nat enable
!
ip nat pool NATPOOL 192.0.2.11 192.0.2.20 prefix-length 24
ip nat source list NAT pool NATPOOL overload
!
ip access-list standard NAT
 permit 10.0.1.0 0.0.0.255

While these simple examples should be self-explanatory, please feel welcome to ask further.

Best regards,

Peter

[Luigi Celeste]

Dear Peter,

Finally i've found a person who don't look me as a crazy when I talk about Hairpinning!! :-D

That's great!!

First, i want to thank you for your fast answer, and the probable solution. But before I apply changes on my router configuration, because is a production router, I would to ask you another pair of things that are unclear for me.

For example, I make a draft of my topology, and designed what I need to do in that topology:

With this scenario, I would to reach my webserver from my internal LAN, on public IP of the web server (in this case 10.10.10.154). As we know, with a "normal" configuration my HTTP request fail, because my request to 10.10.10.154 from 192.168.100.10 goes toward the router, who knows that 10.10.10.154 is statically natted to 192.168.100.254, then he route our packet directly to 192.168.100.254 without go out from our LAN. The web server see the HTTP request from 192.168.100.10 then reply directly to that IP. The 3-way Handshake fail because our PC expects a reply from 10.10.10.154 and not from 192.168.100.254.

Now...this is my configuration:

-- omitted --

interface FastEthernet0/0

ip address 10.10.10.146 255.255.255.240

ip nat outside

ip virtual-reassembly max-reassemblies 1024

duplex auto

speed auto

no cdp enable

!

interface FastEthernet0/1

ip address 192.168.100.254 255.255.255.0

ip nat inside

ip virtual-reassembly max-reassemblies 1024

!

ip route 0.0.0.0 0.0.0.0 10.10.10.145

!

ip nat pool 100net 10.10.10.146 10.10.10.146 netmask 255.255.255.240

ip nat inside source list NAT100net pool 100net overload

ip nat inside source stati 192.168.100.246 10.10.10.154 exendable

!

ip access-list extended NAT100net

permit ip 192.168.100.0 0.0.0.255 any

-- omitted --

Now, based on your answers, and on my topology, I can't understand something, then I've some question to do for you :-)

1) Why you configure 2 IP addresses on the same interface for both your examples?

2) What is the difference between NAT Hairpin and NAT-On-A-Stick? How it works in detail NAT on-a-stick? How can recognize "inside and outside" without specify them?

3) NAT-On-A-Stick can be expensive for router's CPU ?

4) Which can be a working configuration for my topology?

Thank's for your grate commitment, I thank you in advance for your answers!!

Best regards,

Gigi

[paul driver · Accepted solution]

Hello

Nat on a stick is basically used when you usually have only one physical interface on the router and you have a requirement to perform nat translation say on your internal network.

As nat basically requires two physical interfaces towork you can utilise a virtual interface of the router ( in this case the loopback)

In the example peter has posted the secondary IP address on the physical interface would be for a next hop segment lets say of an external network and utilising NAT-pining ( nat on a stick) you would be able to nat traffic internal /external from the same physical interface.

As you can see any LAN traffic that matches the acl and comes from the LAN on the physical interface (fa0/0) is PBR'd to the loopback 0 interface (inside nat) where then nat translation is performed towards the same physical interface fa0/0 (outside nat) from the IP address range defined in the nat pool (which as you can see matches the secondary IP address range of the physical interface )


Res
Paul


Sent from Cisco Technical Support iPad App

[Luigi Celeste]

Ok Paul, but how can I use that technology refer on my topology? please, give me the solution, not only explanation, even if the explanation is always welcome.

For example. As you can see I've 2 interfaces available (Inside Fa0/1 and Outside Fa0/0). According to yours explanation maybe I should create a PBR that say "all that arrive from LAN to IP 10.10.10.154 send it toward loopback 0". Then loopback 0 "simulate" NAT Outside, my internal host exit with a NAT overload, then I should create another PBR in loopback 0 that say "all that arrive from IP 10.10.10.146 to 10.10.10.154 send it back to LAN FastEthernet 0/1". Routing table see that FastEthernet's IP it's directly connect then send back the packet to Fa0/1. the packet is natted outside->inside, then delivered to the server. The server, however, see that the packet came from an Internal IP and delivery the packet directly to 192.168.100.10 (Internal's IP host). the TCP connection fails, because

our PC expects a reply from 10.10.10.154 and not from 192.168.100.254.

How can I fix this behavior?

Gigi

[paul driver]

Hello
The problem I see is with your request is that the hosts 192.168.100.254 and 192.168.100.10 are on the same subnet so they don't need to go via the router  for connection as traffic will be switched so NAT will not be used.

However if the hosts were on different subnet's and required connection via your router then it would be possible to perform such a NAT action as you have queried.

Possible alternative solution here would be use domain-less nat (ip nat enable) - no inside/outside domains

int x/x
ip nat enable
exit

ip nat source xxx

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Luigi Celeste]

Paul,

What I should to rate if no one is able to give me a solution.

[Sergey_F_]

Hi, folks.

May be I'm a bit late with my answer, but better late than never...

First of all, such a situation is encountered often enough.

Second, while NAT theoretically may be a solution, in practice particular vendor implementations of NAT can be restrictive and fail to support this.

One typical solution is to address the server located in the internal network by FQDN, not by the IP address. Two DNS zones are needed - one external, mapping server.example.org to the publicly known IP, and an internal, mapping the same FQDN to the private IP address of the server.

If this solution seems unacceptable, there is another one, it avoids NAT too, all that you need is to configure TCP/IP stack on the server and the LAN hosts. Do this:

(1) on the server: add public IP address (10.10.10.154 in your case) as a secondary IP address on the server's network interface with the 255.255.255.255 mask (web service or whatever you want on the server should listen on this IP address too)

(2) on LAN computers: add a host route for that public IP address, for example, for Windows hosts use the following command: route add 10.10.10.154 mask 255.255.255.255 192.168.100.254 (you can also use DHCP "static route" option to distribute the route). Or, if there is a L3 switch/router in between the clients and the Internet-facing router, configure that host route on this intermediate switch/router, not on the clients.

[Luigi Celeste]

Hi Sergey!

Don't worrie about your delay, we're always on track anyway! :-)

Thank's for the reply. At the end I solved using DNS zones, even if is not the best networking solution in my opinion, but the important is that works. The solution you give with the secondary IP address is really interesting, definitely i'll try to apply this as optional solution as soon as I meet again this problem to address.

The second solution you proposed may also work too, I should try, (I saw now, I wrong IP in the drawing, but it's clear in the configuration that I pasted). With a static route on the computer I can route the traffic directed to 10.10.10.154, toward the private IP address of the server. In this way the traffic goes directly to the private IP address, but I don't know if it work because the primary request of the 3-way handshake is related to the public IP address, and a reply from the private IP address of the server may cause the fail of the handshake.

Probably a PBR on the router may also solve the problem, but I don't know now how to configure it properly.

Thank's a lot for the intervention!

[r.heitmann]

Hi Peter,

today almost everybody uses IOS XE

• NVI is gone in IOS-XE
• route-map with "set interface loopback" is not allowed since "loopback isn't treated as point-to-point-interface"
  • [messing around with /30 on Loopack and "set ip next-hop" to the foreign ip don't work at least at release 16.8.1]

So it seems, both methods to implement NAT-on-a-Stick are not available at current hardware!?

Cheers,

//Ron

[lzachery]

VASI is required to support this in IOS-XE.

[r.heitmann]

great, thank you!

I've attached a working configuration:

!
! Production-Routing
! * all Clients (192.168.116.0/24) get SRC-NATed
! * Internet-Access via 53.0.0.2 (static default-route in global-route-table missing)
!
interface GigabitEthernet1
 ip address 53.0.0.1 255.255.255.0 secondary
 ip address 192.168.116.105 255.255.255.0
 no ip redirects
 ip nat inside
 ip policy route-map RM_PBR_NAT
!
!
interface vasileft1
 ip address 1.1.1.1 255.255.255.252
 ip nat outside
 no keepalive
!
ip access-list extended ACL_PBR
 permit ip any host 53.53.53.53
 permit ip 192.168.116.0 0.0.0.255 any
!
! PBR pushes specified traffic from vasileft to right
!
route-map RM_PBR_NAT permit 10
 match ip address ACL_PBR
 set interface vasileft1
!
!
ip nat pool POOL 53.53.53.53 53.53.53.53 netmask 255.255.255.252
!
ip access-list standard ACL_NAT
 permit 192.168.116.0 0.0.0.255
!
ip nat inside source list ACL_NAT pool POOL overload


!
! VRF to push traffic back from vasiright to left
!
!
vrf definition VASINAT
 !
 address-family ipv4
 exit-address-family
!
!
interface vasiright1
 vrf forwarding VASINAT
 ip address 1.1.1.2 255.255.255.252
 no keepalive
!
ip route vrf VASINAT 0.0.0.0 0.0.0.0 vasiright1
!

[faridpangos]

Why in the domainless nat config we have to use "no ip redirects" for it to work? I've been searching online documents on this and I can't a logical explanation.

[Kyler Middleton]

Hey Luigi, 

In case anyone stumbles on this later, and is trying to get their "guest" subnet to be able to use public IPs for internal or DMZ hosts, I have a solution - run both NAT stacks (zoned/old and NVI/new) in tandem. Details here: http://systems-co.blogspot.com/2016/06/cisco-routers-easy-hair-pin-nat-for.html

Thanks!

kyler

[ChrisUK]

So, you have one router, because you are cheap like me and a website running that you can't access by its FQDN. You've been around the terminal mill, turned grey some years back and now you've gone bald.. Oh and your router hates you!

Well, I am here to tell you how to get that router playing nice with your website, it's kinda like dark magic and i half expect to see Voldermort crawl out of my router but I know harry is keeping him at bay. Besides, it's kinda cheating your router into thinking you are somewhere else, but it works. As does using a VPN, although if like me you subnet in the 10.x range then a VPN brings it's own set of issues along with it (more hair loss), for me it's ProtonVPN and they also subnet in the 10.x range. Meaning, my local addresses try to go through the VPN which is just wrong however you look at it. I worked around that by adding a static route on my desktop, not ideal but it did the trick for a while, just switching the VPN on and off was a pain in my sensitives. Anyway I digress:

THE solution is CLOUDFLARE

Cloudflare if you are not aware, amongst other things protects your web server from DDOS, the magic part however is that Cloudflare masks your public IP address. In doing so when you request your example.com website without it, you can't get there, but with cloudflare you can. This works because the websites public IP address is no longer an IP address within your network. Oh and they have a free account.

So, do yourself a flavour, get your nose out of the configs and set up cloudflare to dupe your rou... Erm, err I mean "PROTECT YOUR SERVER" Snoopies watching me.. might cut me o