Tag Archives: VPN

Veeam Powered Network v2 Azure Marketplace Deployment

Last month Veeam PN v2 went GA and was available for download and install from the veeam.com download page. As an update to that, we published v2 to the Azure Marketplace which is now available for deployment. As a quick refresher, Veeam PN was initially released as part of Direct Recovery to Azure and was marketed through the Azure Marketplace. In addition to that, for the initial release I went through a number of use cases for Veeam PN which are all still relevant with the release of v2:

With the addition of WireGuard replacing OpenVPN for site-to-site connectivity the list of use cases will be expanded and the use cased above enhanced. For most of my own use of Veeam PN, I have the Hub living in an Azure Region which I connect up into where ever I am around the world.

Now that the Veeam PN v2 is available from the Azure Marketplace I have created a quick deployment video that can be viewed below. For those that want a more step by step guide as a working example, you can reference this post from v1… essentially the process is the same.

  • Deploy Veeam PN Appliance from Azure Marketplace
  • Perform Initial Veeam PN Configuration to connect Azure
  • Configure SiteGateway and Clients

NOTE: One of the challenges that we introduced by shifting over to WireGuard is that there is no direct upgrade path from v1 to v2. With that, there needs to be a side by side stand up of v2 and v1 to enable a configuration migration… which at the moment if a manual process.

References:

https://anthonyspiteri.net/veeam-powered-network-azure-and-remote-site-configuration/

Released : Veeam PN v2…Making VPNs Simple, Reliable and Scalable

When it comes to connecting remote sites, branch offices or extending on-premises networks to the cloud that level of complexity has traditionally always been high. Networking has always been the most complex part of any IT platform. There has also always been a high level of cost associated with connecting sites…both from a hardware or a software point of view. There are also the man hours to ensure things are setup correctly and will continue to work. As well and that, security and performance are also important factors in any networking solution..

Simplifying Networking with Veeam

At VeeamOn in 2017, we announced the release candidate for Veeam Powered Network (Veeam PN) which in combination with our Restore to Azure functionality created a new solution to ease the complexities around extending an on-premises network to an Azure network to ensure connectivity during restoration scenarios. In December of that year, Veeam PN went generally available as a FREE solution.

What Veeam PN does well is present a simple and intuitive Web Based User Interface for the setup and configuration of site-to-site and point-to-site VPNs. Moving away from the intended use case, Veeam PN became popular in the IT enthusiast and home lab worlds as a simple and reliable way to remain connected while on the road, or to mesh together with ease networks that where spread across disparate platforms.

By utilizing OpenVPN under the surface and automating and orchestrating the setup of site-to-site and point-to-site networks, we leveraged a mature Open Source tool that offered a level of reliability and performance that suited most use cases. However, we didn’t want to stop there and looked at ways in which we could continue to enhance Veeam PN to make it more useful for IT organizations and start to look to increase underlying performance to maximize potential use cases.

Introducing Veeam Powered Network v2 featuring WireGuard®

With the release of Veeam PN v2, we have enhanced what is possible for site-to-site connectivity by incorporating WireGuard into the solution (replacing OpenVPN for site-to-site) as well as enhancing usability. We also added the ability to better connect to remote devices with the support of DNS for site-to-site connectivity.

WireGuard has replaced OpenVPN for site-to-site connectivity in Veeam PN v2 due to the rise of it in the Open Source world as a new standard in VPN technologies that offers a higher degree of security through enhanced cryptography and operates more efficiently, leading to increased performance and security. It achieves this by working in kernel and by using fewer lines of code (4000 compared to 600,000 in OpenVPN) and offers greater reliability when thinking about connecting hundreds of sites…therefore increasing scalability.

For a deeper look at why we chose WireGuard… have a read of my offical veeam.com blog. The story is very compelling!

Increased Security and Performance

By incorporating WireGuard into Veeam PN we have further simplified the already simple WireGuard setup and allow users of Veeam PN to consume it for site-to-site connectivity even faster via the Veeam PN Web Console. Security is always a concern with any VPN and WireGuard again takes a more simplistic approach to security by relying on crypto versioning to deal with cryptographic attacks… in a nutshell it is easier to move through versions of primitives to authenticate rather than client server negotiation of cipher type and key lengths.

Because of this streamlined approach to encryption in addition to the efficiency of the code WireGaurd can out perform OpenVPN, meaning that Veeam PN can sustain significantly higher throughputs (testing has shown performance increases of 5x to 20x depending on CPU configuration) which opens up the use cases to be for more than just basic remote office or homelab use. Veeam PN can now be considered as a way to connect multiple sites together and have the ability to transfer and sustain hundreds of Mb/s which is perfect for data protection and disaster recovery scenarios.

Other Enhancements

The addition of WireGuard is easily the biggest enhancement from Veeam PN v1, however there are a number of other enhancements listed below

  • DNS forwarding and configuring to resolve FQDNs in connected sites.
  • New deployment process report.
  • Microsoft Azure integration enhancements.
  • Easy manual product deployment.
Conclusion

Once again, the premise of Veeam PN is to offer Veeam customers a free tool that simplifies the traditionally complex process around the configuration, creation and management of site-to-site and point-to-site VPN networks. The addition of WireGuard as the site-to-site VPN platform will allow Veeam PN to go beyond the initial basic use cases and become an option for more business-critical applications due to the enhancements that WireGuard offers.

Quick Post – Installing WireGuard® Client on MacOS

For those that have been monitoring my Twitter posts over the past month of so, i’ve been hinting at some upcoming news around WireGuard and the research i’ve been doing by way of getting to know about what makes it tick. In a nutshell, WireGuard is a VPN protocol similar to OpenVPN or IPsec, but modern and more streamlined

WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be fastersimpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it is now cross-platform and widely deployable. It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.

This specific post isn’t about the installation and configuration of WireGuard in the context of a VPN server (Stand by for some news about that over the next couple of days), but a quick look at how to install the WireGuard Toolkit on a MacOS system. Unlike OpenVPN, that has clients for almost any platform you can think of, WireGuard is still in its infancy when it comes to stable clients.

Even the offical Installation Page state that a lot of the steps and clients involved are in the experimental stages. For me, on my MBP running Mojave 10.14.2, I was having issues installing the Toolkit from the Apple Store.

It wouldn’t install the client full stop. I’m not sure why exactly, but rather than troubleshoot… I decided to go down the tried and tested path of using HomeBrew to try install it. Below are the very quick and easy steps to install from the Terminal.

Once installed, you can start the desktop tray application by searching for WireGuard. The WireGuard Toolkit icon will appear in the tray as show below

From here you can Manage the Tunnels manually or import the configuration from a file obtained from a WireGuard Server.

And that’s it… the Client has a similar look and feel to the TunnelBlick OpenVPN Client I have been using to connect up to my Veeam PN network while I am on the road… maybe in that there is a clue as to why I have been looking at WireGuard… or maybe not.

Either way, the easiest way to install the WireGuard Toolkit client on MacOS is with Home Brew as shown above…quick, simple and no fuss!

WireGuard is a registered trademark of Jason A. Donenfeld.

References:

https://www.wireguard.com

https://www.stavros.io/posts/how-to-configure-wireguard

Deploying Veeam Powered Network into a AWS VPC

Veeam PN is a very cool product that has been GA for about four months now. Initially we combined the free product together with Veeam Direct Restore to Microsoft Azure to create Veeam Recovery to Microsoft Azure. Of late there has been a push to get Veeam PN out in the community as a standalone product that’s capable of simplifying the orchestration of site-to-site and point-to-site VPNs.

I’ve written a few posts on some of the use cases of Veeam PN as a standalone product. This post will focus on getting Veeam PN installed into an AWS VPC to be used as the VPN gateway. Given that AWS has VPN solutions built in, why would you look to use Veeam PN? The answer to that is one of the core reasons why I believe Veeam PN is a solid networking tool…The simplicity of the setup and ease of use for those looking to connect or extend on-premises or cloud networks quickly and efficiently.

Overview of Use Case and Solution:

My main user case for my wanting to extend the AWS VPC network into an existing Veeam PN Hub connected to my my Homelab and Veeam Product Strategy Lab was to test out using an EC2 instance as a remote Veeam Linux Repository. Having a look at the diagram below you can see the basics of the design with the blue dotted line representing the traffic flow.

 

The traffic flows between the Linux Repository EC2 instance and the Veeam Backup & Replication server in my Homelab through the Veeam PN EC2 instance. That is via the Veeam PN Hub that lives in Azure and the Veeam PN Site Gateway in the Homelab.

The configuration for this includes the following:

  • A virtual private cloud with a public subnet with a size /24 IPv4 CIDR (10.0.100.0/24). The public subnet is associated with the main route table that routes to the Internet gateway.
  • An Internet gateway that connects the VPC to the Internet and to other AWS products.
  • The VPN connection between the VPC network and the Homelab network. The VPN connection consists of a Veeam PN Site Gateway located in the AWS VPC and a the Veeam PN HUB and Site Gateway located at the Homelab side of the VPN connection.
  • Instances in the External subnet with Elastic IP addresses that enable them to be reached from the Internet for management.
  • The main route table associated with the public subnet. The route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC, and two entries that enables instances in the subnet to communicate with the remote subnets (172.17.0.0/24 and 10.0.30.0/24).

AWS has a lot of knobs that need adjusting even for what would normally be assumed functionality. With that I had to work out which knobs to turn to make things work as expected and get the traffic flowing between sites.

Veeam PN Site Gateway Configuration:

To get a Veeam PN instance working within AWS you need to deploy an Ubuntu 16.04 LTS form the Instance Wizard or Marketplace into the VPC (see below for specific configuration items). In this scenario a t2.small instance works well with a 16GB SSD hard drive as provided by the instance wizard. To install the Veeam PN services onto the EC2 instance, follow my previous blog post on Installing Veeam Powered Network Direct from a Linux Repo.

Once deployed along with the EC2 instance that I am using as a Veeam Linux Repository I have two EC2 instances in the AWS Console that are part of the VPC.

From here you can configure the Veeam PN instance as a Site Gateway. This can be done via the exposed HTTP/S Web Console of the deployed VM. First you need to create a new Entire Site Client from the HUB Veeam PN Web Console with the network address of the VPC as shown below.

Once the configuration file is imported into the AWS Veeam PN instance it should connect up automatically.

Jumping on the Veeam PN instance to view the routing table, you can see what networks the Veeam HUB has connected to.

The last two entries there are referenced in the design diagram and are the subnets that have the static routes configured in the VPC. You can see the path the traffic takes, which is reflected in the diagram as well.

Looking at the same info from the Linux Repository instance you can see standard routing for a locally connected server without any specific routes to the 172.17.0.0/24 or 10.0.30.0/24 subnets.

Notice though with the traffic path to get to the 172.17.0.0/24 subnet it’s now going through an extra hop which is the Veeam PN instance.

Amazon VPC Configuration:

For the most part this was a straightforward VPC creation with a IPv4 CIDR block of 10.0.100.0/24 configured. However, to make the routing work and the traffic flowing as desired you need to tweak some settings. After initial deployment of the Veeam PN EC2 instance I had some issues resolving both forward and reverse DNS entries which meant I couldn’t update the servers or install anything off the Veeam Linux software repositories.

By default there are a couple of VPC options that is turned off for some reason which makes all that work.

Enable both DNS Resolution and DNS Hostnames via the menu options highlighted above.

For the Network ACLs the default Allows ALL/ALL for inbound and outbound can be left as is. In terms of Security Groups, I created a new one and added both the Veeam PN and Linux Repository instances into the group. Inbound we are catering for SSH access to connect to and configure the instances externally and as shown below there are also rules in there to allow HTTP and HTTPS traffic to access the Veeam PN Web Console.

These, along with the Network ACLs are pretty open rules so feel free to get more granular if you like.

From the Route Table menu, I added the static routes for the remote subnets so that anything on the 10.0.100.0/24 network trying to get to 172.17.0.0/24 or 10.0.30.0/24 will use the Veeam PN EC2 instance as it’s next hop target.

EC2 Configuration Gotchya:

A big shout out to James Kilby who helped me diagnose an initial static routing issue by discovering that you need to adjust the Source/Destination Check attribute which controls whether source/destination checking is enabled on the instance. This can be done either against the EC2 instance right click menu, or on the Network Interfaces menu as shown below.

Disabling this attribute enables an instance to handle network traffic that isn’t specifically destined for the instance. For example, instances running services such as network address translation, routing, or a firewall should set this value to disabled. The default value is enabled.

Conclusion:

The end result of all that was the ability to configure my Veeam Backup & Replication server in my Homeland to add the EC2 Veeam Linux instance as a repository which allowed me to backup to AWS from home through the Veeam PN network site-to-site connectivity.

Bear in mind this is a POC, however the ability to consider Veeam PN as another options for extending AWS VPCs to other networks in a quick and easy fashion should make you think of the possabilities. Once the VPC/EC2 knobs where turned and the correct settings put in place, the end to end deployment, setup and connecting into the extended Veeam PN HUB network took no more than 10 minutes.

That is the true power of the Veeam Powered Network!

References:

https://docs.aws.amazon.com/glue/latest/dg/set-up-vpc-dns.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#change_source_dest_check

Connecting to Home or Office Networks with Veeam Powered Network

A few weeks ago I wrote an article on how Veeam Powered Network can make accessing your homelab easy with it’s straight forward approach to creating and connection site-to-site and point-to-site VPN connections. Since then I’ve done a couple of webinars on Veeam PN and I was asked a number of times if Veeam PN can be setup without the use of a central hub appliance.

To refresh the use case that I went through in my first post, I wanted to access my homelab/office machines while on the road.

Click here to enlarge.

With the use of the Tunnelblick OpenVPN Client on my MBP I am able to create a point-to-site connection to the Veeam PN HUB which is in turn connected via site-to-site to each of the subnets I want to connect into.

Single Veeam PN Appliance Deployment Model

After fielding a couple of similar questions during the webinars it became apparent that the first use case I described was probably more complicated than it needed to be for the average home office user…that is create a simple point-to-site VPN to allows remote access into the network. This use case can also be used to access a simple (flat) company network for remote users.

In this scenario I want to have access via the OpenVPN endpoint client to my internal network of 192.168.1.0/24 via a single Veeam PN appliance that’s been deployed in my home office network. To go over the Veeam PN deployment process read my first post and also visit this VeeamKB that describes where to get the OVA and how to deploy and configure the appliance for first use.

Components

  • Veeam PN Hub Appliance x 1
  • OpenVPN Client

Networking Requirements

  • Veeam PN Hub Appliance – Incoming Ports UDP 1194, 6179 and TCP 443
  • OpenVPN Client – Outgoing access to at least UDP 6179

In my setup the Veeam PN Hub Appliance has been deployed into VMware Workstation and has picked up a DHCP address. Unlike the Azure Market Place deployment you need to go through an initial configuration wizard to setup the Hub appliance to be ready to accept connections. Go to the Veeam PN URL, enter in the default username and password and click through to the Initial Configuration wizard.

Next step is to configure the SSL certificate that is used for a number of services, but importantly is used to facilitate authentication between the Hub, site and endpoints.

Next step is to configure the Site-to-site and the Point-to-site VPN settings which will be used in the OVPN configuration files that are generated later on.

Once that’s done you are sent to the Veeam PN home dashboard page. In order to have the 192.168.1.0/24 network accessible remotely you need to configure it as a site, as shown below from the Clients menu. This is a bit of a workaround to ensure that the correct static routes are included in the endpoint OVPN configuration files but note that the site will never become connected in the client status window.

To be able to connect into my home office when on the road the final step is to register a standalone client. Again, because Veeam PN is leveraging OpenVPN what we are producing here is an OVPN configuration file that has all the details required to create the point-to-site connection…noting that there isn’t any requirement to enter in a username and password as Veeam PN is authenticating using SSL authentication. As a recap from my previous post, for my MPB I’m using the Tunnelblick OpenVPN Client that I’ve found it to be an excellent client but obviously being OpenVPN there are a bunch of other clients for pretty much any platform you might be running. Once I’ve imported the OVPN configuration file into the client I am able to authenticate against the Hub Appliance endpoint and the home office routing is injected into the network settings.

You can see above that the 192.168.1.0 static route has been added and set to use the tunnel interfaces default gateway which is on the Hub Appliance running in my home office. This means that from my MPB I can now get to any device on that subnets no matter where I am in the world…in this case I can RDP to my Windows workstation, and access other resources on 192.168.1.0/24.

Conclusion:

Summerizing the steps that where taken in order to setup and configure remote access into my home office using Veeam PN:

  • Deploy and configure Veeam PN Hub Appliance
  • Go through initial Hub Network Wizard
  • Register local network as a Site
  • Register Endpoints
  • Setup Endpoint and connect to Hub Appliance

Those five steps took me less than 10 minutes which also took into consideration the OVA deployment as well. The simplicity of the solution is what makes it very useful for home users wanting a quick and easy way to access their systems…but also, as mentioned for configuring external access to simple office networks!

Again, Veeam PN is free and is deployable from the Azure Marketplace to help extend availability for Microsoft Azure…or downloadable in OVA format directly from the veeam.com site.

 

Homelab – Lab Access Made Easy with Free Veeam Powered Network

A couple of weeks ago at VeeamON we announced the RC of Veeam PN which is a lightweight SDN appliance that has been released for free. While the main messaging is focused around extending network availability for Microsoft Azure, Veeam PN can be deployed as a stand alone solution via a downloadable OVA from the veeam.com site. While testing the product through it’s early dev cycles I immediately put into action a use case that allowed me to access my homelab and other home devices while I was on the road…all without having to setup and configure relatively complex VPN or remote access solutions.

There are a lot of existing solutions that do what Veeam PN does and a lot of them are decent at what they do, however the biggest difference for me with comparing say the VPN functionality with a pfSense is that Veeam PN is purpose built and can be setup within a couple of clicks. The underlying technology is built upon OpenVPN so there is a level of familiarity and trust with what lies under the hood. The other great thing about leveraging OpenVPN is that any Windows, MacOS or Linux client will work with the configuration files generated for point-to-site connectivity.

Homelab Remote Connectivity Overview:

While on the road I wanted to access my homelab/office machines with minimal effort and without the reliance on published services externally via my entry level Belkin router. I also didn’t have a static IP which always proved problematic for remote services. At home I run a desktop that acts as my primary Windows workstation which also has VMware Workstation installed. I then have my SuperMicro 5028D-TNT4 server that has ESXi installed and runs my NestedESXi lab. I need access to at least RDP into that Windows workstation, but also get access to the management vCenter, SuperMicro IPMI and other systems that are running on the 192.168.1.0/24 subnet.

As seen above I also wanted to directly access workloads in the NestedESXi environment specifically on the 172.17.0.1/24 and 172.17.1.1/24 networks. A little more detail on my use case in a follow up post but as you can see from the diagram above, with the use of the Tunnelblick OpenVPN Client on my MBP I am able to create a point-to-site connection to the Veeam PN HUB which is in turn connected via site-to-site to each of the subnets I want to connect into.

Deploying and Configuring Veeam Powered Network:

As mentioned above you will need to download the Veeam PN OVA from the veeam.com website. This VeeamKB describes where to get the OVA and how to deploy and configure the appliance for first use. If you don’t have a DHCP enabled subnet to deploy the appliance into you can configure the network as a static by accessing the VM console, logging in with the default credentials and modifying the /etc/networking/interface file as described here.

Components

  • Veeam PN Hub Appliance x 1
  • Veeam PN Site Gateway x number of sites/subnets required
  • OpenVPN Client

The OVA is 1.5GB and when deployed the Virtual Machine has the base specifications of 1x vCPU, 1GB of vRAM and a 16GB of storage, which if thin provisioned consumes a tick over 5GB initially.

Networking Requirements

  • Veeam PN Hub Appliance – Incoming Ports TCP/UDP 1194, 6179 and TCP 443
  • Veeam PN Site Gateway – Outgoing access to at least TCP/UDP 1194
  • OpenVPN Client – Outgoing access to at least TCP/UDP 6179

Note that as part of the initial configuration you can configure the site-to-site and point-to-site protocol and ports which is handy if you are deploying into a locked down environment and want to have Veeam PN listen on different port numbers.

In my setup the Veeam PN Hub Appliance has been deployed into Azure mainly because that’s where I was able to test out the product initially, but also because in theory it provides a centralised, highly available location for all the site-to-site connections to terminate into. This central Hub can be deployed anywhere and as long as it’s got HTTPS connectivity configured correctly you can access the web interface and start to configure your site and standalone clients.

Configuring Site Clients (site-to-site):

To complete the configuration of the Veeam PN Site Gateway you need to register the sites from the Veeam PN Hub Appliance. When you register a client, Veeam PN generates a configuration file that contains VPN connection settings for the client. You must use the configuration file (downloadable as an XML) to set up the Site Gateway’s. Referencing the digram at the beginning of the post I needed to register three seperate client configurations as shown below.

Once this has been completed I deployed three Veeam PN Site Gateway’s on my Home Office infrastructure as shown in the diagram…one for each Site or subnet I wanted to have extended through the central Hub. I deployed one to my Windows VMware Workstation instance  on the 192.168.1.0/24 subnet and as shown below I deployed two Site Gateway’s into my NestedESXi lab on the 172.17.0.0/24 and 172.17.0.1/24 subnets respectively.

From there I imported the site configuration file into each corresponding Site Gateway that was generated from the central Hub Appliance and in as little as three clicks on each one, all three networks where joined using site-to-site connectivity to the central Hub.

Configuring Remote Clients (point-to-site):

To be able to connect into my home office and home lab which on the road the final step is to register a standalone client from the central Hub Appliance. Again, because Veeam PN is leveraging OpenVPN what we are producing here is an OVPN configuration file that has all the details required to create the point-to-site connection…noting that there isn’t any requirement to enter in a username and password as Veeam PN is authenticating using SSL authentication.

For my MPB I’m using the Tunnelblick OpenVPN Client I’ve found it to be an excellent client but obviously being OpenVPN there are a bunch of other clients for pretty much any platform you might be running. Once I’ve imported the OVPN configuration file into the client I am able to authenticate against the Hub Appliance endpoint as the site-to-site routing is injected into the network settings.

You can see above that the 192.168.1.0, 172.17.0.0 and 172.17.0.1 static routes have been added and set to use the tunnel interfaces default gateway which is on the central Hub Appliance. This means that from my MPB I can now get to any device on any of those three subnets no matter where I am in the world…in this case I can RDP to my Windows workstation, connect to vCenter or ssh into my ESXi hosts.

Conclusion:

Summerizing the steps that where taken in order to setup and configure the extension of my home office network using Veeam PN through its site-to-site connectivity feature to allow me to access systems and services via a point-to-site VPN:

  • Deploy and configure Veeam PN Hub Appliance
  • Register Sites
  • Register Endpoints
  • Deploy and configure Veeam PN Site Gateway
  • Setup Endpoint and connect to Hub Appliance

Those five steps took me less than 15 minutes which also took into consideration the OVA deployments as well…that to me is extremely streamlined, efficient process to achieve what in the past, could have taken hours and certainly would have involved a more complex set of commands and configuration steps. The simplicity of the solution is what makes it very useful for home labbers wanting a quick and easy way to access their systems…it just works!

Again, Veeam PN is free and is deployable from the Azure Marketplace to help extend availability for Microsoft Azure…or downloadable in OVA format directly from the veeam.com site. The use case i’ve described and have been using without issue for a number of months adds to the flexibility of the Veeam Powered Network solution.

References:

https://helpcenter.veeam.com/docs/veeampn/userguide/overview.html?ver=10

https://www.veeam.com/kb2271

 

NSX Edge vs vShield Edge: Part 3 – IPsec and L2 VPN

Overview:

NSX and vShield Edges support site to site IPSec VPN between Edge instances and remote sites. Behind each remote VPN router, you can configure multiple subnets to connect to the internal network behind an Edge through IPSec tunnels. These subnets and the internal network behind the Edges must have address ranges that do not overlap. You can have a maximum of 64 tunnels across a maximum of 10 sites.

NSX Edges are also capable of L2 VPNs where you can stretch both VXLAN and VLAN across geographical sites…This allows VMs to remain on the same subnet when they are moved between sites with the IP addresses not changing. L2 VPN allows seamless migration of workloads backed by VXLAN or VLAN between physically separated locations. Specifically for Service Providers L2 VPN provides a mechanism to on-board tenants without modifying IP addresses for VM workloads.

In this post I am only going to go through IPsec VPN configuration…feel there is a whole separate post required to do L2 VPN justice. The biggest difference between an NSX and vShield Edge when looking to configure VPNs is that when you are managing a vShield Edge you will not see the options to configure L2 VPN as shown in the configuration example below.

Configuring IPsec VPN From Web Client:

Configuration Items Required:

  • Local Endpoint
  • Local Subnets
  • Peer Endpoint
  • Peer Subnets
  • Encryption Algorithm and Authentication mechanism
  • Pre Shared Key
  • Diffie-Hellman Group

Double Click on the Edge under the NSX Edge Menu Option in Networking and Security, In the VPN Tab under Configuration click on Enable next to IPsec VPN Service Status and then hit Publish Changes

To create a new Tunnel, click on + and enter in the details collected as per the items listed above.

Click ok and then Publish the Changes…from there the Status should show a green tick. Once the other side has been configured check to see that the Tunnel(s) are up by clicking on Show IPsec Statistics.

If both sides are happy you should be able to talk between the configured subnets. Shown below you see an example of a Site to Site with One Tunnel configured up…and one down.

Configuring IPsec VPN From vCloud Director UI:

For vShield Edges managed via vCloud Director, head to the vCD UI and under Administration and the Edge Gateways. Right Click on the Edge and Configure Services. Under the VPN Tab you first want to Enable VPN and Configure the Public IPs.

Enter in the Public IP as shown above and click ok.

Click on Add and enter in the details collected. For Site to Site VPNs drop down the Establish VPN to: dropdown to a remote network and configure the rest of the settings.

Once done, you should see the Enabled and Status Column with green ticks.

A nice addition to the vCD UI (sometimes the UI team gets things right) is the Peer Settings Button which shows you the bits required to configure the other end of the connection.

Enabling/Disabling/Viewing IPsec With REST API:

Below are the key API commands to configure and manage IPsec VPN.