Blog Home | INE Home | Members | Contact Us | Subscribe

Free Resources

View Archives

All Access Pass

Inside and Outside of NAT

15 The
Posted by Petr Lapukhov, 4xCCIE/CCDE in CCIE R&S,IP Services

CCIE Bloggers

Search

Feb

11 Comments

Quite many people dont pay attention to the difference in handling packets on interfaces configured for
NAT inside and outside. Here is an example to demonstrate how NAT domains interact with routing.
Consider three routers connected in the following manner:

Search
Submit

Categories
Select Category

CCIE Bloggers
For this scenario we have no routing configured. Lets use static NAT to provide connectivity between R1 and R2.
R2 would see R1 as a host on local connected segment with the IP address 155.1.23.1 and R1 would see R2 as a
host on its local segment with the IP address 155.1.13.2. This goal could be achieved with the following
configuration:

Brian Dennis, CCIEx5 #2210

Routing & Sw itching
Voice
Security
Service Provider
ISP Dial
Brian McGahan, CCIEx4 #8593,
CCDE #2013::13
Design
Data Center
Routing & Sw itching
Security
Service Provider

R3:
!
interface Serial 1/0.301 point-to-point
ip address 155.1.13.3 255.255.255.0

Mark Snow , CCIEx4 #14073

ip nat inside

Data Center
Collaboration
Security
Voice

no ip route-cache
!
interface Serial 1/0.302 multipoint
ip address 155.1.23.3 255.255.255.0

Petr Lapukhov, CCIEx4 #16379,

CCDE #2010::7
Design
Routing & Sw itching
Security
Service Provider
Voice

frame-relay map ip 155.1.23.2 302

ip nat outside
no ip route-cache
!
! Static NAT: translations are effectively bi-directional
!

Popular Posts

ip nat inside source static 155.1.13.1 155.1.23.1

ip nat outside source static 155.1.23.2 155.1.13.2

CCIE RSv5 Lab Cram Session &

New CCIE RSv5 Mock Labs Now

R2:

Available

!
! Add a Frame-Relay mapping for the new IP (representing R1)
! so that R2 would know how to reach the address over multipoint FR interface
!
interface Serial 1/0.203 multipoint
ip address 155.1.23.2 255.255.255.0
frame-relay map ip 155.1.23.3 203
frame-relay map ip 155.1.23.2 203

Lets see how its working. Note that we disabled route-cache on both interfaces to intercept packets via CPU.

Rack1R3#debug ip nat detailed

IP NAT detailed debugging is on
Rack1R3#debug ip packet detail
IP packet debugging is on (detailed)
Rack1R2#ping 155.1.23.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Hmmit fails. Look at the debugging output on R3:

Rack1R3#
!
! Packet on NAT outside (o - for outside) hits the interface
!
NAT*: o: icmp (155.1.23.2, 16) -> (155.1.23.1, 16) [84]
!
! Source and destination for the packet rewritten according to NAT rules
!
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [84]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [84]
!
! The packet is routed after translation (with new source and destination IPs). Note that routing
decision
! and the actual forwarding take place only after translation rules were triggered by NAT tables
!
P: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
ICMP type=8, code=0
!
! The response packet from R1 comes in - to destination 155.1.13.2 -

routed via RIB (to the same

interface)
! But no NAT rules were triggered since the destination interface is the same as input interface!
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB
IP: s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), len 100, rcvd 3
ICMP type=0, code=0

OK hold here for a second.. Now we recall that for inside NAT routing is tried first, and only then the packet is
translated according to the NAT rules. This is how the NAT order of operations works on the inside. So now its
clear: IOS first tries to route packet to 155.1.13.2 which is the same interface as it came in.. therefore the inside>outside translation never occurs! To fix this, lets add a static route on R3:

R3:
ip route 155.1.13.2 255.255.255.255 155.1.23.2

Verification:

Rack1R2#ping 155.1.23.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/33/52 ms
Rack1R3#
!
! Outside: translate & route
!
NAT*: o: icmp (155.1.23.2, 17) -> (155.1.23.1, 17) [89]
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [89]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [89]
!
! Routing decision and forwarding
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
ICMP type=8, code=0
!
! Inside: Routing decision - the packet is routed using our fixup static route
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.302), routed via RIB
!
! NAT rule (i - for inside) is triggered by the packet
!
NAT: i: icmp (155.1.13.1, 17) -> (155.1.13.2, 17) [89]
!
! Source and destination addresses rewritten in the "opposite" direction
!
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [89]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [89]
!
! Packet is sent to R2 (with the new source and destination) - forwarding takes place
!
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
ICMP type=0, code=0

Nice. So now we know the difference for sure: packets on the NAT outside are first translated and then routed. On
the inside interface routing decision kicks in first and only then translation rules get applied followed by forwarding.
Before we finish with that, recall new 12.3T feature called NAT Virtual Interface. With this feature we can now
configure any interface as NAT enabled an get rid of those inside and outside domains . All NAT traffic
passed through new virtual interface called NVI, in symmetric manner. Lets reconfigure out task using this new
concepts.

R3:
interface Serial 1/0.301 point-to-point
no ip nat inside
ip nat enable
!
interface Serial 1/0.302 multipoint
no ip nat outside
ip nat enable
!
!

Remove old rules

!
no ip nat inside source static 155.1.13.1 155.1.23.1
no ip nat outside source static 155.1.23.2 155.1.13.2
!
! Add "domainless" rules
!
ip nat source static 155.1.13.1 155.1.23.1
ip nat source static 155.1.23.2 155.1.13.2
no ip route 155.1.13.2 255.255.255.255 155.1.23.2

Verification:

Rack1R2#ping 155.1.23.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/40/60 ms
Rack1R3#
!
! Routing decision it taken: packet classified for NAT, since destination is in NAT table
! Note that no actual forwarding occurs, just routing decision to send packet
!
IP: tableid=0, s=155.1.23.2 (Serial1/0.302), d=155.1.23.1 (Serial1/0.302), routed via RIB
!
! Packet translated according to NAT rules (note "i" for inside NAT)
!
NAT: i: icmp (155.1.23.2, 19) -> (155.1.23.1, 19) [95]
NAT: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [95]
NAT: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [95]
!
! Another routing decision, for translated packet - now actual forwarding occurs
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
ICMP type=8, code=0
!
! Response comes in, first routing decision - NAT table entry matched
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB
!
! Packet translated ("i" - inside NAT)
!
NAT: i: icmp (155.1.13.1, 19) -> (155.1.13.2, 19) [95]
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [95]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [95]
!
! Another routing decision, for post-translated packet, followed by forwarding
!
IP: tableid=0, s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), routed via RIB
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
ICMP type=0, code=0

So whats the difference with NVI? First, we see that now NAT behaves symmetrically. Next, we see that NAT
translation tables are used to take a routing decision to send packet to virtual interface. Packet is translated
there and then another routing decision takes place, followed by packet forwarding. So the difference from the old
model is that now routing decision is taken twice: before and after translation. This allows to get rid of any static
routes needed by legacy NAT, since lookup is performed after translation.
To summarize: Domain-based NAT uses different orders of operations for inside and outside domain. NVI based
NAT is symmetrical and performs routing lookup twice: first to send packet to NVI, second to route packet using the
post-translated addresses.
Links:
NAT Order of Operation
Tags: inside, nat, outside, static, tricks
Download this page as a PDF
About Petr Lapukhov, 4xCCIE/CCDE:
Petr Lapukhov's career in IT begain in 1988 w ith a focus on computer programming, and progressed into netw orking
w ith his first exposure to Novell NetWare in 1991. Initially involved w ith Kazan State University's campus netw ork
support and UNIX system administration, he w ent through the path of becoming a netw orking consultant, taking part in
many netw ork deployment projects. Petr currently has over 12 years of experience w orking in the Cisco netw orking
field, and is the only person in the w orld to have obtained four CCIEs in under tw o years, passing each on his first
attempt. Petr is an exceptional case in that he has been w orking w ith all of the technologies covered in his four CCIE
tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing
self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied
Mathematics.
Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

11 Responses to The Inside and Outside of NAT

February 15, 2008 at 5:20 am

The Inside and Outside of Nat : CCIE Journey

[...] Full article here [...]

Reply
February 24, 2008 at 10:49 pm

Ivan
Great post, thank you! It also will be nice if you expain NAT-PT operation

Reply
May 8, 2009 at 4:40 pm

Entendendo NAT em Roteadores Cisco Rodrigo Carran

[...] Veja que dessa forma no necessrio declarar nenhuma interface como inside ou outside, ou mesmo declarar o sentido de
traduo no comando de NAT esttico. Esta nova funcionalidade resolve tambm o problema de traduo para endereos
roteados para uma mesma interface de entrada (j que pode existir casos em que um pacote pode entrar por uma interface
outside e nunca alcanar a interface inside correspondente, conforme descrito neste artigo). [...]

Reply
Marc h 5, 2010 at 9:38 am

Carlos Anjos
Verify the performance of a router with NVI feature active to acess Internet.
I tested with a variety of bandwidths to Internet and is very very bad.
To test, to verify very quickly the performance of the router, configure the router and access to a speedmeter of or trust with the two
solutions of NAT The NAT legacy and the NVI.

Reply
April 17, 2013 at 12:06 am

john doe
I can confirm this, the performance is very bad when using nat virtual interface

Reply
April 7, 2010 at 5:18 am

Ian Finlayson
Excellent article Petr Thank you for this it was a great read..
Just a couple of questions for you though..
Is that a typo in the FR config for R2 Legacy config???
You put in a map to its own IP Address should this not have been 155.1.23.1??
Also if the WAN had of been Ethernet and not FR, the L2 resolution would have required ARP requests, would R3 have used Proxy
Arp for the NATd addresses in this scenario, i.e. when R2 pinged for the address 155.1.23.1, would R3 have sent an ARP Reply for
that address???
Thanks,
Ian.

Reply
September 21, 2010 at 4:56 am

Blog Post Catalogue | CCIE Blog

[...] The Inside and Outside of NAT [...]

Reply
June 7, 2011 at 9:45 pm

Yuri
In the first work around, couldnt you use the add-route keyword in the ip nat outside command instead of manually adding the
static route? I believe this would accomplish the same thing.

Reply
January 20, 2012 at 8:29 am

NAT on a Stick Mostly Networking

[...] additional reading on NAT, check http://blog.ine.com/2008/02/15/the-inside-and-outside-of-nat/ and
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml. [...]

Reply
February 4, 2012 at 6:13 pm

Jon Hartman
This was a great article. I labbed it up to make it stick.
Thanks for posting this.
-Jon

Reply
October 9, 2013 at 11:16 am

mohammadreza
awesome job
thanks Quad

Reply

Leave a Reply
Name (required)

Mail (will not be published) (required)

Submit Comment

twitter.com/ine

2011 INE, Inc., All Rights Reserved

pdfcrowd.com