
Today we will look at the VPN configuration options provided by NSX Edge.
In general, we can divide VPN technologies into two key types:
- Site-to-site VPN. IPSec is most commonly used to create a secure tunnel, for example, between the head office network and a remote site or in the cloud.
- Remote Access VPN. This is used to connect individual users to the organization's private networks via VPN client software.
NSX Edge allows us to use both options.
We will perform the setup using a test stand with two NSX Edge devices, a Linux server with the daemon and a Windows laptop for testing the Remote Access VPN.
IPsec
- In the vCloud Director interface, go to the Administration section and select the vDC. On the Edge Gateways tab, choose the Edge we need, right-click and select Edge Gateway Services.

- In the NSX Edge interface, go to the VPN-IPsec VPN tab, then to the IPsec VPN Sites section and click + to add a new site.

- Fill in the required fields:
- Enabled – activates the remote site.
- PFS – ensures that each new cryptographic key is not related to any previous key.
- Local ID and Local Endpoint– the external address of NSX Edge.
- Local Subnets– the local networks that will use IPsec VPN.
- Peer ID and Peer Endpoint – the address of the remote site.
- Peer Subnets – the networks that will use IPsec VPN on the remote side.
- Encryption Algorithm – the encryption algorithm of the tunnel.

- Authentication – how we will authenticate the peer. We can use a Pre-Shared Key or a certificate.
- Pre-Shared Key – specify the key that will be used for authentication and must match on both sides.
- Diffie-Hellman Group – the key exchange algorithm.
After filling in the necessary fields, click Keep.

- Done.

- After adding the site, go to the Activation Status tab and activate the IPsec Service.

- After the settings are applied, go to the Statistics -> IPsec VPN tab and check the tunnel status. We see that the tunnel is up.

- Check the tunnel status from the Edge gateway console:
- show service ipsec – check the service status.

- show service ipsec site – information about the site status and agreed parameters.

- show service ipsec sa – check the status of the Security Association (SA).

- show service ipsec – check the service status.
- Check connectivity with the remote site:
root@racoon:~# ifconfig eth0:1 | grep inet inet 10.255.255.1 netmask 255.255.255.0 broadcast 0.0.0.0 root@racoon:~# ping -c1 -I 10.255.255.1 192.168.0.10 PING 192.168.0.10 (192.168.0.10) from 10.255.255.1 : 56(84) bytes of data. 64 bytes from 192.168.0.10: icmp_seq=1 ttl=63 time=59.9 ms --- 192.168.0.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 59.941/59.941/59.941/0.000 msConfiguration files and additional commands for diagnostics from the remote Linux server:
root@racoon:~# cat /etc/racoon/racoon.conf log debug; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; listen { isakmp 80.211.43.73 [500]; strict_address; } remote 185.148.83.16 { exchange_mode main,aggressive; proposal { encryption_algorithm aes256; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1536; } generate_policy on; } sainfo address 10.255.255.0/24 any address 192.168.0.0/24 any { encryption_algorithm aes256; authentication_algorithm hmac_sha1; compression_algorithm deflate; } === root@racoon:~# cat /etc/racoon/psk.txt 185.148.83.16 testkey === root@racoon:~# cat /etc/ipsec-tools.conf #! /usr/sbin/setkey -f flush; spdflush; spdadd 192.168.0.0/24 10.255.255.0/24 any -P in ipsec esp/tunnel/185.148.83.16-80.211.43.73/require; spdadd 10.255.255.0/24 192.168.0.0/24 any -P out ipsec esp/tunnel/80.211.43.73-185.148.83.16/require; === root@racoon:~# racoonctl show-sa isakmp Destination Cookies Created 185.148.83.16.500 2088977aceb1b512:a4c470cb8f9d57e9 2019-05-22 13:46:13 === root@racoon:~# racoonctl show-sa esp 80.211.43.73 185.148.83.16 esp mode=tunnel spi=1646662778(0x6226147a) reqid=0(0x00000000) E: aes-cbc 00064df4 454d14bc 9444b428 00e2296e c7bb1e03 06937597 1e522ce0 641e704d A: hmac-sha1 aa9e7cd7 51653621 67b3b2e9 64818de5 df848792 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 22 13:46:13 2019 current: May 22 14:07:43 2019 diff: 1290(s) hard: 3600(s) soft: 2880(s) last: May 22 13:46:13 2019 hard: 0(s) soft: 0(s) current: 72240(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 860 hard: 0 soft: 0 sadb_seq=1 pid=7739 refcnt=0 185.148.83.16 80.211.43.73 esp mode=tunnel spi=88535449(0x0546f199) reqid=0(0x00000000) E: aes-cbc c812505a 9c30515e 9edc8c4a b3393125 ade4c320 9bde04f0 94e7ba9d 28e61044 A: hmac-sha1 cd9d6f6e 06dbcd6d da4d14f8 6d1a6239 38589878 seq=0x00000000 replay=4 flags=0x00000000 state=mature created: May 22 13:46:13 2019 current: May 22 14:07:43 2019 diff: 1290(s) hard: 3600(s) soft: 2880(s) last: May 22 13:46:13 2019 hard: 0(s) soft: 0(s) current: 72240(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 860 hard: 0 soft: 0 sadb_seq=0 pid=7739 refcnt=0 - All set, the site-to-site IPsec VPN is configured and operational.
In this example, we used a PSK for peer authentication, but certificate-based authentication is also possible. To do this, you need to go to the Global Configuration tab, enable certificate authentication, and select the certificate itself.
Additionally, in the site settings, you will need to change the authentication method.


Note that the number of IPsec tunnels depends on the size of the deployed Edge Gateway (read about this in our ).
SSL VPN
SSL VPN-Plus is one option for Remote Access VPN. It allows individual remote users to securely connect to private networks behind the NSX Edge gateway. An encrypted tunnel in the case of SSL VPN-Plus is established between the client (Windows, Linux, Mac) and the NSX Edge.
- Let's start configuring. In the Edge Gateway services control panel, go to the SSL VPN-Plus tab, then to Server Settings. Choose the address and port where the server will listen for incoming connections, enable logging, and select the necessary encryption algorithms.

Here you can also change the certificate that the server will use.
- Once everything is ready, turn on the server and don't forget to save the settings.

- Next, we need to configure a pool of addresses that we will assign to clients upon connection. This network is separate from any existing subnet in your NSX environment, and there's no need to configure it on other devices in the physical networks, except for the routes pointing to it.
Go to the IP Pools tab and click +.

- Select addresses, subnet mask, and gateway. You can also adjust the settings for the DNS and WINS servers here.

- The resulting pool.

- Now let's add the networks that VPN users will have access to. Go to the Private Networks tab and click +.

- Fill in:
- Network — the local network to which remote users will have access.
- Send traffic, which has two options:
— over tunnel – send traffic to the network through the tunnel,
— bypass tunnel – send traffic to the network directly, bypassing the tunnel. - Enable TCP Optimization – check this if you selected the over tunnel option. When optimization is enabled, you can specify port numbers for which traffic needs to be optimized. Traffic for other ports in this specific network will not be optimized. If port numbers are not specified, traffic for all ports will be optimized. More on this feature can be found .

- Next, we go to the Authentication tab and click +. For authentication, we will use the local server on the NSX Edge itself.

- Here we can select policies for generating new passwords and set options for blocking user accounts (e.g., the number of retry attempts for incorrect password entry).


- Since we use local authentication, it's necessary to create users.

- In addition to basic things like username and password, you can, for example, prevent the user from changing their password or, conversely, require them to change their password at the next login.

- After all necessary users are added, let's go to the Installation Packages tab, click +, and create the installer that will be downloaded for the remote employee's installation.

- Click +. Select the address and port of the server to which the client will connect, and the platforms for which the installation package needs to be generated.

Below in this window, you can specify the client parameters for Windows. Choose:- start client on logon – the VPN client will be added to the startup on the remote machine;
- create desktop icon – will create a VPN client icon on the desktop;
- server security certificate validation – will validate the server certificate upon connection.
Server configuration is complete.

- Now let's download the installer package we created in the last step to the remote PC. In the server setup, we specified its external address (185.148.83.16) and port (445). We need to access this address in a web browser. In my case, that is :445.
In the login window, you need to enter the credentials for the user we created earlier.

- After authorization, we see a list of created installation packages available for download. We created only one – and that's the one we'll download.

- Click on the link, and the client download will start.

- Unzip the downloaded archive and run the installer.

- After installation, launch the client and click Login in the authorization window.

- In the certificate check window, select Yes.

- Enter the credentials for the previously created user and see that the connection has been successfully completed.


- Check the VPN client statistics on the local computer.


- In the Windows command line (ipconfig /all), we see that an additional virtual adapter has appeared and there is connectivity with the remote network; everything is working:


- And finally – a check from the Edge Gateway console.

L2 VPN
L2VPN will be needed when you need to connect multiple geographically
distributed networks into a single broadcast domain.
This can be useful, for example, during the migration of a virtual machine: when moving a VM to another geographical site, the machine will retain its IP address settings and will not lose connectivity with other machines in the same L2 domain.
In our test environment, we will connect two sites to each other, calling them A and B, respectively. We have two NSX and two equally created routable networks tied to different Edges. Machine A has the address 10.10.10.250/24, machine B – 10.10.10.2/24.
- In vCloud Director, go to the Administration tab, enter the required VDC, go to the Org VDC Networks tab, and add two new networks.

- Select the routed network type and link this network to our NSX. Check the box Create as subinterface.

- As a result, we should have two networks. In our example, they are called network-a and network-b with identical gateway settings and the same mask.


- Now let's go to the settings of the first NSX. This will be the NSX to which network A is connected. It will act as the server.
Return to the NSX Edge interface / Go to the VPN tab -> L2VPN. Enable L2VPN, select Server mode, in the Server Global settings, specify the external IP address of the NSX that will listen on the port for the tunnel. By default, the socket will open on port 443, but it can be changed. Don't forget to choose the encryption settings for the future tunnel.

- Go to the Server Sites tab and add a peer.

- Enable the peer, set a name, description if needed, and set the username and password. This information will be needed later when configuring the client site.
In Egress Optimization Gateway Address, specify the gateway address. This is necessary to avoid IP address conflicts since the gateways of our networks have the same address. After that, click the SELECT SUB-INTERFACES button.

- Here, select the required subinterface. Save the settings.

- We see that the newly created client site has appeared in the settings.

- Now let's move on to configuring NSX from the client side.
Log into NSX on side B, go to VPN -> L2VPN, enable L2VPN, and set the L2VPN mode to client mode. In the Client Global tab, specify the address and port of NSX A that we previously designated as Listening IP and Port on the server side. It is also necessary to set identical encryption settings to ensure they agree when establishing the tunnel.

Scroll down to select the subinterface through which the tunnel for L2VPN will be built.
In the Egress Optimization Gateway Address, set the gateway address. Enter the user ID and password. Select the subinterface and don't forget to save the settings.
- That's it. The client and server-side settings are practically identical, with a few nuances.
- Now we can check that our tunnel is working by going to Statistics -> L2VPN on any NSX.

- If we now go to the console of any Edge Gateway, we will see the addresses of both VMs in the ARP table on each of them.

That's all I have about VPN on NSX Edge. Feel free to ask if anything is unclear. This is also the last part of the series on working with NSX Edge. We hope you found it helpful 🙂
Source: habr.com























































