To connect, you only need the ip/hostname of the remote IPsec gateway you want to connect to, as well as the IPv4 addressing there. After that, you have to decide to which of your sites you want the IPsec tunnel to connect to and which of your network zones should have access to the remote network.
You can add multiple network zones from your site if needed (also from different sites, which will send traffic first through an AutoVPN tunnel and than through the ClassicVPN tunnel to the 3rd party). All the transit routing gets configured fully automatically! Cool hey?
Once you create the tunnel, you get all the information needed to configure the remote site. We preselected secure encryption parameters and generated a secure Preshared Key.
On top of that, we want to make it very easy to configure the remote gateway, that’s why we added configuration helpers that give you cut and paste ready config snippets like for Cisco gateways:
Common challenge – IP address conflicts
One very common issue when connecting networks via VPN is that there might be the same IP addresses used on both sides, making it impossible to just create a simple IPsec tunnel, as routing through the tunnel would not work.
It is often unpractical (or even impossible) to change the IP addresses on either side. This is happening more often now with all the cloud computing services like Amazon VPC, Google Compute Engine or Microsoft Azure, as the default IP addresses in these environments are often the same and rarely ever get changed by their users.
To overcome this, we added an integrated Network Address Translation (NAT) Layer, in which you can map an overlapping network one-to-one into a virtual network.
This means you can communicate with the remote location using the virtual NAT network, yet prior entering to the tunnel, we will transparently replace IPv4 addresses with the matching one from the remote side, allowing both networks to remain unchanged!
In the diagram above, our first ping went through the tunnel without the 1:1 NAT network configured. Once this feature is enabled, the real IP addresses no longer work, as you can see in the second ping set, yet if you try to access the same host on the NAT network, it automatically works. The cool thing at Riverbed is, you don’t need to change your security policy rules, as they get translated automatically as well.
If needed, you can also translate the source and the destination network at the same time, this allows also VPN tunnels between two completely identical networks, which is barely possible with some other solutions, and then only with a very complex, extensive configuration.
Connecting two Riverbed organizations
This feature can also be used to interconnect two Riverbed organizations by creating a ClassicVPN tunnel on both orgs, with the mirrored settings.
Each side will create its own preshared key, in order to get this tunnel working, you need to copy the key from Org1 and paste it into the Preshared Key field listed below.
If you don’t have static IP addresses in the two sites, that is not an issue, as the Riverbed system comes with a built-in, free of charge dynamic DNS service.
Each site and each uplink gets a randomly created, never-changing dynamic DNS name assigned and updated. You can find them in the Uplinks or Sites configurations:
This way you can quickly setup flexible VPN tunnels to remote IPsec gateways to connect contractors, partners or home office workers.
