LAN-to-LAN VPN with Overlapping IP Ranges

Unanswered Question
Jul 17th, 2013
User Badges:

Hello,


I need to setup a LAN-to-LAN VPN with an outside vendor and we are both using 192.168.80.0/24 on our internal networks.  On my side I have an ASA5510 and I have dealt with conflicts many times before by working with the vendors to NAT across the tunnel as needed.


In this case however, the vendor has a SonicWall Pro 1260 and he says he has no way to do the NAT on his side.


Obviously I can NAT my side of the tunnel so that the vendor sees my 192.168.80. addresses as something different than what they actually are, but don't I need the vendor to do an equivalent NAT on his side as well because I also need him to present his 192.168.80. addresses to me as something different than what they actually are as well.


So the big question is - is there any way for me to handle this completely myself (without the vendor also NATting his side) or is it impossible to do this without him also NATting his side to a network that I am not using.


Thanks for any advice.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Marvin Rhoads Thu, 07/18/2013 - 07:05
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

One could come up with some tricky ways of doing this (policy-based routing to a secondary box that would do the NAT and then send it back for VPN, etc.) but they'd be ugly.


Short of you both NATting, sometimes the business need can be met by using a jumpbox or bastion host to proxy your remote connections. i.e. login to the jumpbox for which you have a policy NAT statement and then use that remote session to reach his 192.168.80.0 resources locally. It's very dependent on how much and what kind of connectivity you need though.

neilhall Thu, 07/18/2013 - 07:15
User Badges:

Thanks for the advice.  I am absolutely not opposed to telling them that they "have to" NAT their side as well.  I just wanted to get some expert advice confirming that there was no easy way around it before I played hardball with them and letting them know this is a deal breaker.


Because this is for an outside vendor, I am certainly not going to go down any crazy paths to make this work, since in my opinion, they are the ones being the problem here by not being able to perform a simple NAT on their side.

Marvin Rhoads Thu, 07/18/2013 - 07:18
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

You're welcome. I agree they should be able to do simple NAT.


Please rate the posts you find helpful.

Andrew Phirsov Thu, 07/18/2013 - 11:24
User Badges:
  • Silver, 250 points or more

Hello Neihall. I thik there's nothing wrong if they can't nat on their site. Your site can do evryting without them being involved at all. You can translate source and destination at your site.


If talking about 8.3+, you should do this:


1. Create objects:


object network OVERLAPPING_LAN

subnet 192.168.80.0 255.255.255.0


object network LOCAL_LAN_TRANSLATED

subnet 10.10.10.0 255.255.255.0


object network REMOTE_LAN_TRANSLATED

subnet 10.10.20.0 255.255.255.0


2. Create nat rules.

Here when the traffic is initiated from 192.168.80.0/24 and is going to 10.10.20.0/24 (wich is translated range from the other site), source will be translated to the 10.10.10.0/24 (host at other site will see us like from this subnet) and destination will be translated to the real IP of the other site:


nat (inside,outside) source static OVERLAPPING_LAN LOCAL_LAN_TRANSLATED destination REMOTE_LAN_TRANSLATED OVERLAPPING_LAN


Returning traffic (from 192.168.80.0 to 10.10.10.0) will hit the rule again, and source will be translated to 10.10.20.0 and destination to 192.168.80.0


3. Crypto acl would look like this:

access-list extended permit ip object LOCAL_LAN_TRANSLATED OVERLAPPING_LAN


Crypto ACL for other site will look smth like this:

access-list extended permit ip 192.168.80.0 255.255.255.0 10.10.10.0 255.255.255.0


Other site should connect to your network using 10.10.10.0/24 subnet destination IPs, so it should have a route pointing to this subnet through their VPN-gateway. Your site should connect to their network using 10.10.20.0/24 so the route through ASA towards that subnet should be present in the local LAN.

neilhall Thu, 07/18/2013 - 16:10
User Badges:

I had looked at that document as well, but that document has you perform NATs on both VPN devices which does not apply to my scenario.

The previous post indicates that I can do it all myself without having the VPN device on the other side do any NATing, but I have never done this before (nor do I really want to), and I was hoping that the answer would be that it can't be reasonably done without NATing on both sides of the tunnel, but your other post seems to indicate that it might be a reasonable thing to do (me doing the NATing for both my side and the vendor's side).

Thanks.

Sent from Cisco Technical Support iPhone App

Andrew Phirsov Thu, 07/18/2013 - 22:17
User Badges:
  • Silver, 250 points or more

So wha's wrong with doing all NATting stuff at your site?

Artem Tkachov Thu, 07/18/2013 - 23:45
User Badges:
  • Cisco Employee,

Hi Neilhall,


You need to perform NAT somewhere in your case, either on your side or on remote side. It's up to you on which side you will do NAT.


Thank you.

Actions

This Discussion