We have an IPSec tunnel established with a 3rd party. They assign us an IP range for us to use on “our side”. So we have to NAT our internal IP’s to their assigned IP’s. The net effect is similar to what you need to do if both networks were using the same IP range. To avoid this situation, they actually have non-routable public IP’s that they give us and that’s what we present to them. Getting the tunnel established was easy as on the IPSEC VPN Profile, I’m able to add an additional “Local Networks” to specify the IP range they provided. But once the tunnel is established, I’m unable to NAT map those VPN “Local” IP’s to my real IP’s. In the NAT Mappings, I can set Inbound and Outbound Mappings but those force me to select one of the WAN connections to select the IP’s. I can assign those IP’s on the WAN connections but then I’m pretty sure the traffic will only NAT “outside” the tunnel and not “inside” (I did of course try and it didn’t work).
Here’s a post on how to “NAT inside the tunnel” with a Cisco ASA and here’s an article on doing it with a WatchGuard firewall where they discuss NAT’ing the real address to the “masquerade” address.
Is this possible with a Balance and if so how? My situation is a little unique in that they are assigning me IP’s to use as my local IP’s inside the tunnel but the same situation would occur if both sides has the same IP range as the Cisco and WatchGuard articles address. One other twist is that the 30 or so IP’s that I need to map are all part of my PepVPN so it’s not just the first network on the Balance but static LAN IP’s on devices in the PepVPN tunnel. So I’m not sure if the Balance will publish that IPSec VPN route to the PepVPN networks devices below or if I have to add a static route on each PepLink device to route that traffic through the PepVPN.
My other option is to add a firewall to handle the VPN tunnel to the 3rd party but this client has purchased a dedicated Internet connection just for this Balance VPN network so it would be much cleaner if the Balance could handle this.
Thanks,
John