You probably know the feeling when something works, but you don't know why it works, because it shouldn't
Here's the example of the topology I am working with:
The case is the following:
Two loopback addresses lo1 and lo2 on the CE router are being used for management purposes, including SNMP monitoring source addresses for various different monitoring servers each accepting the traffic only from one of the loopback addresses. 10.0.0.20 host is used for management purposes but it also acts as SNMP monitoring server and only accepts traffic originated by lo2, however lo1 is set as snmp-server trap-source, so the following global statement exist in the configuration:
ip nat inside source static 10.0.120.1 10.0.130.1 route-map SNMPLOGGING
Obviously, lo2 is configured with:
ip nat inside
SNMPLOGGING route-map includes the routes to those SNMP servers accepting the traffic only from lo2:
route-map SNMPLOGGING, permit, sequence 10
ip address (access-lists): 199
Policy routing matches: 0 packets, 0 bytes ---
Extended IP access list 199
10 permit ip host 10.0.130.1 host 10.0.0.20
20 permit ip host 10.0.130.1 host 10.0.0.24
30 permit ip host 10.0.130.1 host 10.0.0.21
40 permit ip host 10.0.130.1 host 10.0.0.22
50 permit ip host 10.0.130.1 host 10.1.0.20
Routes to LAN subnet and lo2 are being advertised from CE router to PE router via BGP.
The problem is the following: SSH to CE router lo2 (10.0.130.1) doesn't work from 10.0.0.20. It seems like it's attempting to connect infinitely (via bash). I managed to fix it by adding ip nat outside statement to Se0/0/0 of the CE router, but I just can't understand why it fixes the problem. I added it because I saw that in the debug output of the CE router while attempting establishing SSH session from 10.0.0.20:
008157: Dec 11 13:04:40: IP: s=10.0.0.20 (Serial0/0/0), d=10.0.120.1, len 52, input feature <-- note that destination is 10.0.120.1, whilst I was connecting to 10.0.130.1
0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
The only reason for that I could think of is PE router doing the destionation NAT from 10.0.120.1 to 10.0.130.1but it doesn't! There's no NAT happening on the PE router at all.
So if someone could just explain me why adding ip nat outside statement to Se0/0/0 of the CE router helps to get the SSH traffic going it will definitely save me from the headache , I just don't see why NAT is happening here if traffic is originated from 10.0.0.20 as global NAT statement only specifies 10.0.120.1 as the source address for translation...
I am slightly confused as you seem to be saying before you enabled "ip nat outside" on the s0/0/0 interface everything worked except for ssh but i would have expected you to have to have configured that for anything to work ?
In answer to your specific question -
I just don't see why NAT is happening here if traffic is originated from 10.0.0.20 as global NAT statement only specifies 10.0.120.1 as the source address for translation...
The source and destination are relative to the interface they are coming in on. So when you configure a static NAT statement like this -
ip nat inside source static 192.168.5.1 184.108.40.206
this creates a permanent entry in the NAT table. What it means is -
1) any traffic from the inside where the source IP is 192.168.5.1 will have the source IP translated to 220.127.116.11
2) any traffic from the outside where the destination IP is 18.104.22.168 will have the destination IP changed to 192.168.5.1
note that inside and outside in the above are defined by the "ip nat ..." statements on your router. It has to work like this because you need to NAT the IP both ways.
Both dynamic and static NAT need to translate the addresses in both directions. The difference with a static NAT is that because it creates a permanent entry in the translation table the traffic can be initiated from either the inside or the outside. In your case it is being initiated from the outside.
A very common use of static NAT is for internet services eg. you have a web server on private addressing and you want it to be accessible from the internet. So using the example above your web server has a real IP of 192.168.5.1 but this is not routable on the internet so you allocate the public IP of 22.214.171.124 to it. So if a user on the internet connects to the web server it would look like -
src IP 126.96.36.199 -> dst IP 188.8.131.52 (translated to 192.168.5.1)
src IP 192.168.5.1 (translated to 184.108.40.206) -> dst IP 220.127.116.11
notice that this is exactly the behaviour you are seeing when you connect from the outside to your loopback interface.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...