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.
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.
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.
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:
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.
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).
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...