Peter,
I had not fully considered the effect that NAT could have on the GRE header of packets flowing outbound from the router. I had assumed that NAT would not touch these packets.
Once I got home I decided to put your theory to the test in my home lab, and my testing results confirm your analysis that NAT disrupted functionality of the GRE tunnel and thus resulted in termination of my telnet session. Please see below.
1. I configured Router 1 with a config similar to the one that I shared in my intial post (routing config not shown):
Router 1
interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 192.168.1.1 255.255.255.128
ip nat inside
ip virtual-reassembly
end
interface Serial0/0/0
ip address 192.168.100.1 255.255.255.252
ip nat outside
ip virtual-reassembly
service-module t1 timeslots 1-24
end
interface Tunnel10
ip address 10.0.1.1 255.255.255.252
ip nat outside
ip virtual-reassembly
tunnel source Loopback100
tunnel destination 172.16.1.2
end
ip nat inside source route-map NAT_TO_ISP interface Serial0/0/0 overload
ip nat inside source route-map NAT_TO_SERVER interface FastEthernet0/0.1 overload
route-map NAT_TO_ISP permit 10
match ip address NAT_TO_ISP
match interface Serial0/0/0
!
route-map NAT_TO_SERVER permit 10
match ip address NAT_TO_SERVER
match interface Tunnel10
Router 2
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
Serial0/0 192.168.100.2 YES manual up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Serial0/1 unassigned YES NVRAM administratively down down
NVI0 192.168.100.2 YES unset up up
Loopback100 172.16.1.2 YES manual up up
Tunnel10 10.0.1.2 YES manual up up
2. On Router 2, pings to 192.168.1.1 (Router 1) were successful:
Router2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
3. On Router 2, I established a telnet session to 192.168.1.1 (Router 1).
4. On Router 1, I deleted the NAT_TO_SERVER route-map and then recreated it without any match statements.
5. On Router 2, I lost my telnet session to Router1 and pings to 192.168.1.1 (Router 1) were unsuccessful:
Router2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
6. On Router 1, I captured the following NAT debug output (not all output shown):
*Jul 27 04:28:00.495: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [617]
*Jul 27 04:28:00.651: NAT: translation failed (A), dropping packet s=10.0.1.1 d=224.0.0.10
*Jul 27 04:28:02.095: NAT: translation failed (A), dropping packet s=10.0.1.1 d=10.0.1.2
*Jul 27 04:28:02.499: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [618]
*Jul 27 04:28:04.499: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [619]
*Jul 27 04:28:05.123: NAT: translation failed (A), dropping packet s=10.0.1.1 d=224.0.0.10
*Jul 27 04:28:06.499: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [620]
*Jul 27 04:28:07.095: NAT: translation failed (A), dropping packet s=10.0.1.1 d=10.0.1.2
*Jul 27 04:28:08.503: NAT: s=172.16.1.1->192.168.1.1, d=172.16.1.2 [621]
*Jul 27 04:29:02.099: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.1.2 (Tunnel10) is down: retry limit exceeded
This debug output shows that Router 1 started to translate GRE packets to the 192.168.1.1 address, which resulted in the GRE tunnel going down. (This debug output also shows that EIGRP packets were dropped, due to the GRE tunnel going down.)
Thank you again for your quick replies and for guiding me in the right direction!
Oscar
