I can bet that you say that to configure NAT/PAT, ip nat inside and ip nat outside commands are always needed. I will show you example where we can translate IPs just with ip nat outside.
Specific exception is traffic generated from the router itself. Let’s play with NAT, configure PAT with simple ACL and compare difference for traffic generated from host that resides behind the router and for traffic from the router itself.
I would to translate all traffic from LAN network to Internet and will use fa0/0 interface IP. Instead use specific subnet IP I’m going to configure any/any in ACL (this will make me in trouble ). I just configure ip nat outside command under fa0/0 interface that simulates internet subnet.
Here you are my base config. R1 and R2 are connected directly via fa0/0 interfaces.
Specific exception is traffic generated from the router itself. Let’s play with NAT, configure PAT with simple ACL and compare difference for traffic generated from host that resides behind the router and for traffic from the router itself.
I would to translate all traffic from LAN network to Internet and will use fa0/0 interface IP. Instead use specific subnet IP I’m going to configure any/any in ACL (this will make me in trouble ). I just configure ip nat outside command under fa0/0 interface that simulates internet subnet.
Here you are my base config. R1 and R2 are connected directly via fa0/0 interfaces.
Let’s first generate telnet traffic from the host.
As you see user has been connected from 192.168.1.105.
At R1 no translation appear, so NAT does not work and user’s telnet traffic has been simply routed with translation. To resolve this problem ip nat inside under int fa0/1 needs to be added.
Before we add it let’s generate test traffic from router itself.
NAT is working fine without ip nat inside even if we generated traffic with source fa0/1, telnet traffic has been translated to fa0/0 10.0.12.1.
Translation has been added.
What about traffic generated from the router itself. Let’s ping R2.
R1 has translated own generated traffic. This test show us one important issue that can influence traffic from and to router. Because NAT is enabled on outside interface via ip nat outside command router verifies NAT policy, traffic matches ACL and source IP is translated to fa0/0 interface IP. For traffic passing thru the router for example from the host behind the router ip nat inside and ip nat outside commands are required to properly NAT traffic. Because NAT works also for traffic generated from the router itself even if we have just ip nat outside configured under outside interface traffic from the router will be translated. Important thing is to properly define source and/or destination traffic in ACL otherwise all traffic that match ACL will be nated. Improper ACL configuration can break our management traffic and thus we lose access to our box.
For example. I have configured simple PAT but didn’t add ip nat outside yet to fa0/0. I was able to established telnet session to the router. Once I added ip nat outside router started translate source TCP port due to PAT configured so port TCP 23 has been translated to TCP 3. Then TCP stack on PC from where I’m trying connect will drop these packets because they are not related to this session (wrong source port). If you would like to establish new telnet session to R1 from R2 you will get the same issue, R2 will sent SYN/ACK to reponse for SYN packet but source port 23 will be translated to different one, R2 will replay via RST packet because of wrong source port. Hope it was interesting post for you.
For example. I have configured simple PAT but didn’t add ip nat outside yet to fa0/0. I was able to established telnet session to the router. Once I added ip nat outside router started translate source TCP port due to PAT configured so port TCP 23 has been translated to TCP 3. Then TCP stack on PC from where I’m trying connect will drop these packets because they are not related to this session (wrong source port). If you would like to establish new telnet session to R1 from R2 you will get the same issue, R2 will sent SYN/ACK to reponse for SYN packet but source port 23 will be translated to different one, R2 will replay via RST packet because of wrong source port. Hope it was interesting post for you.
