Results of "debug ip nat detailed" on SITE1 when attempting to ping from SITE1PC (10.1.1.10)
Code:
SITE1#
*Mar 1 02:12:05.459: NAT*: i: icmp (10.1.1.10, 6) -> (10.81.0.10, 6) [30]
*Mar 1 02:12:05.463: NAT*: i: icmp (10.1.1.10, 6) -> (10.81.0.10, 6) [30]
*Mar 1 02:12:05.467: NAT*: s=10.1.1.10->192.168.40.10, d=10.81.0.10 [30]
*Mar 1 02:12:05.603: NAT*: o: icmp (10.81.0.10, 6) -> (192.168.40.10, 6) [30]
*Mar 1 02:12:05.607: NAT*: s=10.81.0.10, d=192.168.40.10->10.1.1.10 [30]
*Mar 1 02:12:05.663: NAT*: i: icmp (10.1.1.10, 6) -> (10.81.0.10, 6) [31]
*Mar 1 02:12:05.663: NAT*: s=10.1.1.10->192.168.40.10, d=10.81.0.10 [31]
*Mar 1 02:12:05.675: NAT*: o: icmp (10.81.0.10, 6) -> (192.168.40.10, 6) [31]
*Mar 1 02:12:05.679: NAT*: s=10.81.0.10, d=192.168.40.10->10.1.1.10 [31]
*Mar 1 02:12:05.691: NAT*: i: icmp (10.1.1.10, 6) -> (10.81.0.10, 6) [32]
*Mar 1 02:12:05.691: NAT*: s=10.1.1.10->192.168.40.10, d=10.81.0.10 [32]
*Mar 1 02:12:05.707: NAT*: o: icmp (10.81.0.10, 6) -> (192.168.40.10, 6) [32]
*Mar 1 02:12:05.711: NAT*: s=10.81.0.10, d=192.168.40.10->10.1.1.10 [32]
*Mar 1 02:12:05.723: NAT*: i: icmp (10.1.1.10, 6) -> (10.81.0.10, 6) [33]
*Mar 1 02:12:05.723: NAT*: s=10.1.1.10->192.168.40.10, d=10.81.0.10 [33]
*Mar 1 02:12:05.731: NAT*: o: icmp (10.81.0.10, 6) -> (192.168.40.10, 6) [33]
*Mar 1 02:12:05.735: NAT*: s=10.81.0.10, d=192.168.40.10->10.1.1.10 [33]
*Mar 1 02:12:05.751: NAT*: i: icmp (10.1.1.10, 6) -> (10.81.0.10, 6) [34]
*Mar 1 02:12:05.751: NAT*: s=10.1.1.10->192.168.40.10, d=10.81.0.10 [34]
*Mar 1 02:12:05.791: NAT*: o: icmp (10.81.0.10, 6) -> (192.168.40.10, 6) [34]
*Mar 1 02:12:05.795: NAT*: s=10.81.0.10, d=192.168.40.10->10.1.1.10 [34]
As we can see, 10.1.1.10 is being translated to 192.168.40.10 and then passed via IPsec to 10.81.0.10 (SITE2PC) and the same occurs coming back.
However, when attempting to ping 'an internet site' (eg, SITE2's interface on ISP1) its "also" translating the addresses across to 192.168.40.10...
Code:
*Mar 1 02:12:19.095: NAT*: i: icmp (10.1.1.10, 7) -> (203.2.2.1, 7) [35]
*Mar 1 02:12:19.099: NAT*: i: icmp (10.1.1.10, 7) -> (203.2.2.1, 7) [35]
*Mar 1 02:12:19.099: NAT*: s=10.1.1.10->192.168.40.10, d=203.2.2.1 [35]
*Mar 1 02:12:21.091: NAT*: i: icmp (10.1.1.10, 7) -> (203.2.2.1, 7) [36]
*Mar 1 02:12:21.091: NAT*: s=10.1.1.10->192.168.40.10, d=203.2.2.1 [36]
*Mar 1 02:12:23.071: NAT*: i: icmp (10.1.1.10, 7) -> (203.2.2.1, 7) [37]
*Mar 1 02:12:23.071: NAT*: s=10.1.1.10->192.168.40.10, d=203.2.2.1 [37]
*Mar 1 02:12:25.055: NAT*: i: icmp (10.1.1.10, 7) -> (203.2.2.1, 7) [38]
*Mar 1 02:12:25.055: NAT*: s=10.1.1.10->192.168.40.10, d=203.2.2.1 [38]
*Mar 1 02:12:27.071: NAT*: i: icmp (10.1.1.10, 7) -> (203.2.2.1, 7) [39]
*Mar 1 02:12:27.071: NAT*: s=10.1.1.10->192.168.40.10, d=203.2.2.1 [39]
I'm guessing this is definitely the issue - eg, it appears to be attempting to translate ALL traffic from 10.1.1.x to 192.168.40.x (where x be 10 for this test) although it should ONLY be translating 10.1.1.x to 192.168.40.x for traffic destined to 192.168.80.0/24 or 10.81.0.0/18....
Needless to say, updating the INTERNAL-OVERLOAD-TO-INTERNET ACL to allow for 192.168.40.0 doesn't work (and I dont believe it should double NAT (NAT to 192.168.40.10 and then NAT overload as 203.1.1.2)
Something to do with the route maps maybe?
Anyone know the differences between using "ip policy route-map" on the internal interface versus "ip nat inside source route-map...." at NAT level?
Obviously, pinging the external interface of SITE1 from SITE1PC (eg, 203.1.1.2 from 10.1.1.10) works fine - however, I can't ping the ISP side of the ISP-SITE1 link (203.1.1.1)