05-20-2010 06:54 AM - edited 03-04-2019 08:33 AM
Hi all,
Have been bashing my head against this for the last couple of days and was wondering if anyone might be able to take a look at the config and point where I might be approaching this wrong...
My current lab is configured as:
Two sites (SITE1/SITE2) connected via a third third router (ISP) - There is a pure IPsec tunnel between SITE1 and SITE2. Both SITE1 and SITE2 have overlapping IP addresses (SITE1 uses 10.1.1.0/24 and SITE2 uses 10.0.0.0/16 and 192.168.80.0/24 - however, we're only presented with access to 10.81.0.0/18 via the IPsec VPN)
Okay... Overlapping NAT's - I need to remap what each end see's as its destination - SITE2 sees SITE1 as 192.168.40.0/24 (rather than 10.1.1.0/24) and SITE1 see's SITE2 without translation (as we'll never be talking to their 10.0.0.0/16 anyway, only 10.81.0.0/18 which doesn't match our internal 10.1.1.0/24 subnet)
SITE1 also has an internet connection via ISP1 which is used to simultate access to the internet via a NAT overload statement (multiple machines in SITE1 need to access the internet via a single internet IP.
SITE1's internal IP is 10.1.1.1/24
SITE1's external IP is 203.1.1.2/24
ISP1's link to SITE1 is on 203.1.1.1/24
ISP1's link to SITE2 is on 203.2.2.1/24
SITE2's internal IP's are 10.81.0.1/18 and 192.168.80.1/24.
SITE2's external IP is 203.2.2.2/24
IPsec traffic between workstations located within SITE1 to workstations within SITE2 is fine (on either 192.168.80.0/24 or 10.81.0.0/18 subnets) however, I'm unable to access the internet via the NAT overload from SITE1.
Your assistance is muchly appreciated - I'm sure it can be done and I'm positive I'm well on the way to making it happen, but for the life of me, I just can't make that last 'step' to actually having it work.
Results of "debug ip nat detailed" on SITE1 when attempting to ping from SITE1PC (10.1.1.10)
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...
*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)
Your help is VERY much appreciated
-JT
05-20-2010 10:05 PM
Before going further on the actual NAT, I fail to see how your internal subnets on both sites are overlapping.
You have listed the following:
Site 1 LAN: 10.1.1.0/24
Site 2 LAN: 10.0.0.0/16, but you only need access to 10.81.0.0/18
So I don't think the following overlaps:
10.1.1.0/24 ---> 10.1.1.1-10.1.1.255
10.0.0.0/16 ---> 10.0.0.1-10.0.255.255
10.81.0.0/18 ---> 10.81.0.1-10.81.63.255
The above 3 subnets do not overlap with each other.
If you otherwise still want to go ahead with the NAT, please let me know and I will look further. Otherwise, I would just keep it simple without the NAT.
05-21-2010 04:08 AM
Hi Halijenn,
My bad and thanks, you're the first person who's picked that up in my posting on any forums.
I meant to show Site 2 LAN actually using 10.0.0.0/8 rather than /16 - For some reason, when I typed that in I knew it was wrong but couldn't work out how (and given it was late at night here and I'd just spent another 3-4 hours trying various solutions to this before deciding to put it to the forums I think I'll excuse myself )
There is definitely NAT required - even though we're only presented with 10.81.0.0/18, the provider on the other side of the IPsec VPN is definitely using IP's within 10.0.0.0/8 - If they ever present 10.1.1.0 as an IPsec range, things could get interesting but I'd just have to present that /24 as a network NAT (back to SITE2)
Another forum has suggested using route maps rather than the 'lists' in the NAT statements before - My only experience to date (with route-maps in particular) has been with pure IPsec tunnels which require forcing the IPsec traffic to not be natted (and hence routing to a loopback interface to avoid the NAT overload) so I'm currently working my way through Cisco's policy based routing documentation.
Any suggestions from anyone for alteration of the config I'd be very much thankful for - this is all currently running within my lab at the office so we're able to recover from any suggestion, be it wrong or right (or on the right path )
Of course, this is the one piece of hardware they're yet to get SmartNet on so I can't ask TAC for support yet but the quote's on their desk and when I get into the office on Monday (having just come off 3 weeks leave) I'll be getting them to approve it and push the order through...
09-22-2010 06:06 AM
Hi Justin
I'm trying to reach the same goal as you, but I've been unable to get there as of yet.
Did you find a solution?
Best regards,
Jesper
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide