pdfcrowd.

com
Feb
15
7Comments
TheInsideandOutsideofNAT
PostedbyPetrLapukhov,4xCCIE/CCDEinCCIER&S,IPServices
About Petr Lapukhov, 4xCCIE/CCDE:
PetrLapukhov'scareerinITbegainin1988withaf ocusoncomputerprogramming,andprogressedintonetworking
withhisf irstexposuretoNovellNetWarein1991.InitiallyinvolvedwithKazanStateUniversity'scampusnetwork
supportandUNIXsystemadministration,hewentthroughthepathof becominganetworkingconsultant,takingpartin
manynetworkdeploymentprojects.Petrcurrentlyhasover12yearsof experienceworkingintheCisconetworking
f ield,andistheonlypersonintheworldtohaveobtainedf ourCCIEsinundertwoyears,passingeachonhisf irst
attempt.Petrisanexceptionalcaseinthathehasbeenworkingwithallof thetechnologiescoveredinhisf ourCCIE
tracks(R&S,Security,SP,andVoice)onadailybasisf ormanyyears.Whennotactivelyteachingclasses,developing
self -pacedproducts,studyingf ortheCCDEPractical&theCCIEStorageLabExam,andcompletinghisPhDinApplied
Mathematics.
Find all posts by Petr Lapukhov, 4xCCIE/CCDE|Visit Website
The Inside and Outside of Nat : CCIE Journey
February15,2008at5:20am
Ivan
February24,2008at10:49pm
Entendendo NAT em Roteadores Cisco Rodrigo Carran
May8,2009at4:40pm
Carlos Anjos
March5,2010at9:38am
Ian Finlayson
Apri l 7,2010at5:18am
Blog Post Catalogue | CCIE Blog
September21,2010at4:56am
Yuri
June7,2011at9:45pm
Quitemanypeopledontpayattentiontothedifferenceinhandlingpacketsoninterfacesconfiguredfor
NATinsideandoutside.HereisanexampletodemonstratehowNATdomainsinteractwithrouting.
Considerthreeroutersconnectedinthefollowingmanner:
Forthisscenariowehavenoroutingconfigured.LetsusestaticNATtoprovideconnectivitybetweenR1andR2.
R2wouldseeR1asahostonlocalconnectedsegmentwiththeIPaddress155.1.23.1andR1wouldseeR2asa
hostonitslocalsegmentwiththeIPaddress155.1.13.2.Thisgoalcouldbeachievedwiththefollowing
configuration:
R3:
!
interface Serial 1/0.301 point-to-point
ip address 155.1.13.3 255.255.255.0
ip nat inside
no ip route-cache
!
interface Serial 1/0.302 multipoint
ip address 155.1.23.3 255.255.255.0
frame-relay map ip 155.1.23.2 302
ip nat outside
no ip route-cache
!
! Static NAT: translations are effectively bi-directional
!
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
R2:
!
! 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
Letsseehowitsworking.Notethatwedisabledroute-cacheonbothinterfacestointerceptpacketsviaCPU.
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)
Hmmitfails.LookatthedebuggingoutputonR3:
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
OKholdhereforasecond..NowwerecallthatforinsideNATroutingistriedfirst,andonlythenthepacketis
translatedaccordingtotheNATrules.ThisishowtheNATorderofoperationsworksontheinside.Sonowits
clear:IOSfirsttriestoroutepacketto155.1.13.2whichisthesameinterfaceasitcamein..thereforetheinside-
>outsidetranslationneveroccurs!Tofixthis,letsaddastaticrouteonR3:
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.Sonowweknowthedifferenceforsure:packetsontheNAToutsidearefirsttranslatedandthenrouted.On
theinsideinterfaceroutingdecisionkicksinfirstandonlythentranslationrulesgetappliedfollowedbyforwarding.
Beforewefinishwiththat,recallnew12.3TfeaturecalledNAT Virtual Interface.Withthisfeaturewecannow
configureanyinterfaceasNATenabledangetridofthoseinsideandoutsidedomains.AllNATtraffic
passedthroughnewvirtualinterfacecalledNVI,insymmetricmanner.Letsreconfigureouttaskusingthisnew
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
SowhatsthedifferencewithNVI?First,weseethatnowNATbehavessymmetrically.Next,weseethatNAT
translationtablesareusedtotakearoutingdecisiontosendpackettovirtualinterface.Packetistranslated
thereandthenanotherroutingdecisiontakesplace,followedbypacketforwarding.Sothedifferencefromtheold
modelisthatnowroutingdecisionistakentwice:beforeandaftertranslation.Thisallowstogetridofanystatic
routesneededbylegacyNAT,sincelookupisperformedaftertranslation.
Tosummarize:Domain-basedNATusesdifferentordersofoperationsforinsideandoutsidedomain.NVIbased
NATissymmetricalandperformsroutinglookuptwice:firsttosendpackettoNVI,secondtoroutepacketusingthe
post-translatedaddresses.
Links:
NATOrderofOperation
Tags:inside,nat,outside,static,tricks
DownloadthispageasaPDF
Youcanleavearesponse,ortrackbackfromyourownsite.
7ResponsestoTheInsideandOutsideofNAT

[...]Fullarticlehere[...]
Reply
Greatpost,thankyou!ItalsowillbeniceifyouexpainNAT-PToperation
Reply
[...]Vejaquedessaformanonecessriodeclararnenhumainterfacecomoinsideououtside,oumesmodeclararosentido
detraduonocomandodeNATesttico.Estanovafuncionalidaderesolvetambmoproblemadetraduopara
endereosroteadosparaumamesmainterfacedeentrada(jquepodeexistircasosemqueumpacotepodeentrarporuma
interfaceoutsideenuncaalcanarainterfaceinsidecorrespondente,conformedescritonesteartigo).[...]
Reply
VerifytheperformanceofarouterwithNVIfeatureactivetoacessInternet.
ItestedwithavarietyofbandwidthstoInternetandisveryverybad.
Totest,toverifyveryquicklytheperformanceoftherouter,configuretherouterandaccesstoaspeedmeterofortrustwiththetwo
solutionsofNATTheNATlegacyandtheNVI.
Reply
ExcellentarticlePetrThankyouforthisitwasagreatread..
Justacoupleofquestionsforyouthough..
IsthatatypointheFRconfigforR2Legacyconfig???
YouputinamaptoitsownIPAddressshouldthisnothavebeen155.1.23.1??
AlsoiftheWANhadofbeenEthernetandnotFR,theL2resolutionwouldhaverequiredARPrequests,wouldR3haveusedProxy
ArpfortheNATdaddressesinthisscenario,i.e.whenR2pingedfortheaddress155.1.23.1,wouldR3havesentanARPReplyfor
thataddress???
Thanks,
Ian.
Reply
[...]TheInsideandOutsideofNAT[...]
Reply
Inthefirstworkaround,couldntyouusetheadd-routekeywordintheipnatoutsidecommandinsteadofmanuallyaddingthe
staticroute?Ibelievethiswouldaccomplishthesamething.
Reply

LeaveaReply
Name(required)
Mail(willnotbepublished)(required)
Website
Submit Comment
Search
Search
Submit
Categories
SelectCategory
CCIE Bloggers
BrianDennisCCIE#2210
Routing&Switching
ISPDial
Security
ServiceProvider
Voice
BrianMcGahanCCIE#8593
Routing&Switching
Security
ServiceProvider
PetrLapukhovCCIE#16379
Routing&Switching
Security
ServiceProvider
Voice
MarkSnowCCIE#14073
Voice
Security
Popular Posts
NewUpcomingClassesf or
CCNA/CCNP/CCIESecurity&
CCIEServiceProviderv3.0
SubmitYourTopicRequestsf or
theNewCCIESecurity&CCIESP
ATCs
CongratulationsMutasem
(Monty)Bashkami,CCIEVoice#
26926!
twitter.com/inetraining
CCNAVoice,CCNPVoiceandCCIE
VoiceProductsUpdate
http://bit.ly/qQqbjD
Ciusempowerscustomer
relationshipmanagement
http://dlvr.it/Zxrwf
Telecommunicationsprovider
recognizedasacertif iedCisco
partnerhttp://dlvr.it/ZmHrw
BlogHome|INEHome|Members|ContactUs|Subscribe
2010InternetworkExpert,Inc.,AllRightsReserved
Free Resources View Archives All Access Pass CCIE Bloggers