Author: Humphrey Mpairwe
Last Updated: Fri, Oct 21, 2022This article explains how to connect an On-Premises network to a Vultr Virtual Private Cloud (VPC) network using Internet Protocol Security (IPsec) to create a site-to-site tunnel. Internet Key Exchange (IKE) V2 is used to create and authenticate the secure IPsec tunnel between hosts as it supports more features, is more secure, and faster than IKEV1.
IPsec is a group of network protocols that create a secure connection between two or more devices by authenticating and encrypting packets over Internet Protocol (IP) networks such as the Internet. To establish a Virtual Private Network (VPN) tunnel between devices, IPSec uses multiple protocols, including the following.
Authentication Header (AH): Ensures that data packets are not tampered with and come from a secure source device.
Encapsulating Security Protocol (ESP): Encrypts the IP header and payload for each data packet by adding a new header and trailer.
Security Association (SA): Negotiates encryption keys and algorithms between devices in a tunnel using protocols such as Internet Key Exchange (IKE), and the Internet Security Association and Key Management Protocol (ISAKMP)
Before you begin, make sure you have:
An active Vultr account. If not, sign up for one today.
An On-Premises or office network with a static public IP address.
An active domain name. This article uses vpn.example.com
. Replace all occurrences with your actual domain name.
IPsec IKEV2 requires valid SSL certificates for host authentication within a tunnel. For production, an active domain name masks the main server IP address and is used in self-signed certificates.
This article follows the example network simulation in the graphic below. The On-Premises network has two hosts as deployed with the local network address 192.168.1.0/24
and the public network with example IP address 192.0.2.0/24
. The Vultr VPC has two hosts with the local network address 203.0.113.0/24
, and the public IP address 198.51.100.0/24
.
Replace all example IP addresses used in this article with your real-world public and private IP addresses on both networks, respectively.
In a single Vultr location:
Deploy a Ubuntu 22.04 instance to work as the main server.
Deploy a Debian 11 instance to work as an application server.
Add both servers to the same Vultr Virtual Private Cloud (VPC).
At the On-Premises network:
Deploy a Ubuntu 22.04 server to work as the main network server.
Deploy a Windows client machine to work as a client device.
To set up IPsec on the server, install an open-source implementation tool such as Openswan, Libreswan, or strongSwan on the server. For purposes of this article, install strongSwan (strong secure wan), which uses the native IPsec stack, and is actively maintained. It supports both Internet Key exchange (IKE) protocols, IKEV1 and IKEV2 protocols, to create an IPsec tunnel between two or more hosts.
Update the server.
$ sudo apt update
Install strongSwan and all required packages.
$ sudo apt install strongswan strongswan-pki libcharon-extra-plugins libcharon-extauth-plugins libstrongswan-extra-plugins -y
Enable strongSwan to start at boot time.
$ sudo systemctl enable strongswan
Start strongSwan.
$ sudo systemctl start strongswan
Verify that the strongSwan daemon is up and running.
$ sudo systemctl status strongswan
Verify the IPsec tunnel status.
$ sudo ipsec status
Output:
Security Associations (0 up, 0 connecting):
none
A valid SSL certificate allows the server to identify itself to clients and mask its public IP address. For compatibility with the strongSwan configurations, generate self-signed SSL certificates on the server using the strongswan-pki
utility.
Create a private key for the root Certificate Authority (CA).
$ sudo ipsec pki --gen --size 4096 --type rsa --outform pem > /etc/ipsec.d/private/ca.key.pem
Create and sign the root CA using the key generated above.
$ sudo ipsec pki --self --in /etc/ipsec.d/private/ca.key.pem --type rsa --dn "CN=Vultr VPC VPN Server" --ca --lifetime 3650 --outform pem > /etc/ipsec.d/cacerts/ca.cert.pem
Create the VPN server private key.
$ sudo ipsec pki --gen --size 4096 --type rsa --outform pem > /etc/ipsec.d/private/server.key.pem
Generate and sign the VPN server certificate using the CA key using the following command. Replace vpn.example.com
with your actual domain name.
$ sudo ipsec pki --pub --in /etc/ipsec.d/private/server.key.pem --type rsa | ipsec pki --issue --lifetime 2750 --cacert /etc/ipsec.d/cacerts/ca.cert.pem --cakey /etc/ipsec.d/private/ca.key.pem --dn "CN=vpn.example.com" --san="vpn.example.com" --flag serverAuth --flag ikeIntermediate --outform pem > /etc/ipsec.d/certs/server.cert.pem
Back up the original IPsec configuration file.
$ sudo mv /etc/ipsec.conf /etc/ipsec.ORIG
Create a new configuration file.
$ sudo touch /etc/ipsec.conf
Using a text editor, open and edit the file.
$ sudo nano /etc/ipsec.conf
Add the following configurations to the file. Replace vpn.example.com
with your domain name.
config setup
charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2, mgr 2"
strictcrlpolicy=no
uniqueids=yes
cachecrls=no
conn vultr-onpremises-vpn
auto=start
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
rekey=no
leftauth=pubkey
left=%any
leftid=@vpn.example.com
leftcert=server.cert.pem
leftsendcert=always
leftsubnet=203.0.113.2/24
right=192.0.2.2
rightid=vultruser
rightsubnet=192.168.1.1/24
rightauth=eap-mschapv2
rightsendcert=never
eap_identity=%identity
Save and close the file.
Here is what key configuration lines represent:
auto=
: The automatic operation starts with the IPsec daemon, start
loads and starts up the IPsec connection, add
loads a connection but does not start it, ignore
ignores the connection until started by the user.
type=
: The type of IPsec connection, tunnel
represents host to host, transport
host to host transport mode, drop
discards all signifying packets.
keyexchange=
: Method of exchange to use in the IPsec connection, ike
defaults to ikev2, ikev1
assigns IKEV1 to the connection.
leftauth=
: The local server authentication type, accepted values include pubkey
, psk
, xauth
, and eap
.
left=
: The local server's public IP address.
leftcert=
: Server certificate located in the /etc/ipsec.d/certs
directory.
leftsubnet=
: Local IP address of the Vultr VPC network interface.
right=
: The Remote Server's public IP address. For this article, the On-Premises server's IP address.
rightid=
: How the remote On-Premises server authenticates. vultruser
represents the username in your secrets file. Other accepted values can be the IP address, or a fully qualified domain name (FQDN)
rightsubnet=
: The Local On-Premises network behind the main server or gateway.
rightauth=
: The remote server authentication type, IKEV2 supports multiple methods such as eap-mschapv2
, IKEV1 only supports XAuth
.
Back up the original IPsec secrets file.
$ sudo mv /etc/ipsec.secrets /etc/ipsec.ORIG
Create a new secrets file.
$ sudo touch /etc/ipsec.secrets
Open and edit the file.
$ sudo nano /etc/ipsec.secrets
Add the following configurations to the file. Replace vpn.example.com
with your domain name.
vpn.example.com : RSA server.key.pem
vultruser : EAP "strong-password"
Save and close the file.
You can create multiple users in the user : EAP password
format.
Restart the IPsec daemon.
$ sudo ipsec restart
To allow the On-Premises server to communicate with hosts on your Vultr VPC network, enable kernel packet forwarding on the server as described below.
Back up the original sysctl.conf
configuration file.
$ sudo cp /etc/sysctl.conf /etc/sysctl.ORIG
Add new forwarding rules to the file using the following command.
$ sudo echo " net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0 " > /etc/sysctl.conf
Reload kernel settings using the sysctl
utility.
$ sudo sysctl -p
View all the server network interfaces.
$ ip addr
Your output should look like the one below.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 56:00:04:27:fb:84 brd ff:ff:ff:ff:ff:ff
inet 198.51.100.1/24 brd 198.51.100.255 scope global dynamic enp1s0
valid_lft 47693sec preferred_lft 47693sec
3: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc mq state UP group default qlen 1000
link/ether 5a:00:04:27:fb:84 brd ff:ff:ff:ff:ff:ff
inet 203.0.113.2/24 brd 203.0.113.255 scope global enp6s0
valid_lft forever preferred_lft forever
Using the iptables
utility, forward all incoming network requests to the VPC network interface.
$ sudo iptables -t nat -A POSTROUTING -o enp6s0 -j MASQUERADE
To enable internet access on the IPsec tunnel, also forward network traffic to the public network interface.
$ sudo iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
Restart the IPsec daemon.
$ sudo ipsec restart
By default, Uncomplicated Firewall (UFW) is pre-configured, and active on Vultr Ubuntu servers, configure the firewall to allow IPsec traffic to the server.
Verify that the firewall is running.
$ sudo ufw status
If inactive, activate it using the following command.
$ sudo ufw enable
Allow IPsec connections on UDPs port 500
, and 4500
.
$ sudo ufw allow 500,4500/udp
Verify the rules in your firewall table.
$ sudo ufw status
Your output should look like the one below.
Status: active
To Action From
-- ------ ----
22 ALLOW Anywhere
500,4500/udp ALLOW Anywhere
22 (v6) ALLOW Anywhere (v6)
500,4500/udp (v6) ALLOW Anywhere (v6)
Restart the firewall to load changes.
$ sudo ufw reload
Using SSH, access the Debian Vultr VPC application server.
$ ssh example-user@198.51.100.2
Ping the main Vultr server VPC address.
$ ping 203.0.113.2
Output:
PING 203.0.113.2 (203.0.113.2) 56(84) bytes of data.
64 bytes from 203.0.113.2: icmp_seq=1 ttl=63 time=21.0 ms
64 bytes from 203.0.113.2: icmp_seq=2 ttl=63 time=17.7 ms
64 bytes from 203.0.113.2: icmp_seq=3 ttl=63 time=17.7 ms
64 bytes from 203.0.113.2: icmp_seq=4 ttl=63 time=19.4 ms
^C
--- 203.0.113.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Press Control + C to stop the utility replies.
Verify your VPC network interface IP address.
$ ip addr
Define a route to the On-Premises network with the main Vultr VPC server as the next hop.
$ sudo ip route add 192.168.1.0/24 via 203.0.113.2 dev eth1 src 203.0.113.3
Apply the above configuration on all hosts in the Vultr VPC network.
For purposes of this article, set up a basic web application on the server.
First, install Nginx as the web server application.
$ sudo apt install nginx -y
Start Nginx.
$ sudo systemctl start nginx
Create a new index.html
file in the /var/www/html
web root directory.
$ sudo touch /var/www/html/index.html
Open and edit the file.
$ sudo nano /var/www/html/index.html
Add the following contents to the file.
<html>
<head>
<title>Sample web application on a Debian Vultr VPC server</title>
<style>
h1{
text-align:center;
font-size: 8em;
margin: 0;
margin-top: 1em;
margin-bottom: 0;
font-style: bold;
color: red;
}
</style>
</head>
<body>
<div>
<h1>Awesome!!!! The Vultr IPsec tunnel works!!!! </h1>
</div>
</body>
</html>
Save and close the file.
Allow HTTP traffic on port 80
through the firewall.
$ sudo ufw allow 80/tcp
Restart Nginx.
$ sudo systemctl restart nginx
This section describes configurations you should apply on the main On-Premises server. These should be like those set on the main Vultr VPC server to create an IPsec tunnel successfully.
Use SSH to access a terminal session of your On-Premises server, or open a terminal session (Ctrl + Alt + T) if the server runs a desktop environment.
Install strongSwan and its extra plugins.
$ sudo apt install strongswan libcharon-extra-plugins -y
Using a secure terminal file transfer utility such as SCP
or SFTP
, connect to the Vultr VPC server and download the ca.cert.pem
file to your server.
$ sudo scp user@198.51.100.1:/etc/ipsec.d/cacerts/ca.cert.pem /etc/ipsec.d/cacerts/
Back up the IPsec configuration file.
$ sudo mv /etc/ipsec.conf /etc/ipsec.ORIG
Create a new configuration file.
$ sudo touch /etc/ipsec.conf
Open and edit the file.
$ sudo nano /etc/ipsec.conf
Add the following configurations to the file. Replace 192.0.2.2
with your static public server IP address, and 192.168.1.1/24
with your actual local On-Premises network.
conn onpremises-to-vultr-vpc
auto=start
right=vpn.example.com
rightid=vpn.example.com
rightsubnet=203.0.113.2/24
rightauth=pubkey
left=192.0.2.2
leftid=vultruser
leftsubnet=192.168.1.1/24
leftauth=eap-mschapv2
eap_identity=%identity
Save and close the file.
Back up the IPsec secrets file.
$ sudo mv /etc/ipsec.secrets /etc/ipsec-secrets.ORIG
Create a new file.
$ sudo touch /etc/ipsec.secrets
Open and edit the file.
$ sudo nano /etc/ipsec.secrets
Add the following configurations to the file.
vultruser : EAP "strong-password"
Save and close the file.
Make sure the username and password records match (except for the certificate directive) with those in the Vultr VPC server ipsec.secrets
file.
Restart the IPsec daemon.
$ sudo ipsec restart
Allow SSH port 22
through the firewall.
$ sudo ufw allow 22/tcp
Enable UFW on the On-Premises Ubuntu server if it's inactive.
$ sudo ufw enable
Allow IPsec UDP ports 500
and 4500
.
$ sudo ufw allow 500,4500/udp
Verify the rules in your firewall table.
$ sudo ufw status
Restart the firewall to load changes.
$ sudo ufw reload
Back up the original systcl.conf
file.
$ sudo cp /etc/sysctl.conf /etc/sysctl.ORIG.BAK
Create and edit a new configuration file.
$ sudo nano /etc/sysctl.conf
Add forwarding rules to the file using the following command.
$ sudo echo " net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0 " > /etc/sysctl.conf
Save and close the file.
Verify changes and reload settings.
$ sudo sysctl -p
View the server network interfaces, and keep note of the local interface.
$ ip addr
Using iptables, forward incoming requests to the local network interface.
$ sudo iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Access the Windows client machine on the host network.
Open the Windows command prompt or PowerShell from the start menu.
Ping the main On-Premises server local interface address.
> ping 192.168.1.1
Output:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=21.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=17.7 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=17.7 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=19.4 ms
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Add a static route to the Vultr VPC network with the main OnPremises server as the next hop.
> route ADD 203.0.113.0 MASK 255.255.255.0 192.168.1.1
View the Windows routing table.
> route print
This section describes steps to test a successful connection between the On-Premises network and the Vultr VPC. If you have followed all steps correctly, you should be able to ping the main Vultr VPC server network address and access the internet through the IPsec tunnel. Likewise, the Vultr server should reach your On-Premises server's private address.
Hosts on both the On-Premises network must be able to reach hosts in the Vultr VPC. For this article, the Windows client machine should be able to reach the Debian application server. Likewise, the Debian server should be able to reach the Windows client machine.
Access the main On-Premises server.
Restart the IPsec daemon.
$ sudo ipsec restart
Connect to the IPsec tunnel profile as defined in your configuration file.
$ sudo ipsec up onpremises-to-vultr-vpc
A successful connection output should look like the one below:
ipsec up onpremises-to-vultr-vpc
establishing CHILD_SA onpremises-to-vultr-vpc{9}
generating CREATE_CHILD_SA request 8 [ SA No TSi TSr ]
sending packet: from 192.0.2.2[4500] to 198.51.100.1[4500] (256 bytes)
received packet: from 198.51.100.1[4500] to 192.0.2.2[4500] (208 bytes)
parsed CREATE_CHILD_SA response 8 [ SA No TSi TSr ]
selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
CHILD_SA onpremises-to-vultr-vpc{9} established with SPIs c67cbf3e_i c42445d9_o and TS 203.0.113.3/24 === 192.168.1.0/24
connection 'onpremises-to-vultr-vpc' established successfully
If the tunnel connection fails, details of the error display in your command output.
Verify the IPsec tunnel status.
$ sudo ipsec status
Your output should look like the one below:
onpremises-to-vultr-vpc[1]: ESTABLISHED 5 seconds ago, 192.0.2.2[vultruser]...198.51.100.1[vpn.example.com]
onpremises-to-vultr-vpc{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c17666e4_i cfd39c84_o
onpremises-to-vultr-vpc{1}: 192.168.0.0/24 === 203.0.113.0/24
Using the ping
utility, test the connection to the Vultr VPC interface.
$ ping 203.0.113.2
Output:
PING 203.0.113.2 (203.0.113.2) 56(84) bytes of data.
64 bytes from 203.0.113.2: icmp_seq=1 ttl=63 time=21.0 ms
64 bytes from 203.0.113.2: icmp_seq=2 ttl=63 time=17.7 ms
64 bytes from 203.0.113.2: icmp_seq=3 ttl=63 time=17.7 ms
64 bytes from 203.0.113.2: icmp_seq=4 ttl=63 time=19.4 ms
--- 203.0.113.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Test the connection to your Vultr VPC web application server.
$ ping 203.0.113.3
Output:
PING 203.0.113.3 (203.0.113.3) 56(84) bytes of data.
64 bytes from 203.0.113.3: icmp_seq=1 ttl=63 time=21.0 ms
64 bytes from 203.0.113.3: icmp_seq=2 ttl=63 time=17.7 ms
64 bytes from 203.0.113.3: icmp_seq=3 ttl=63 time=17.7 ms
64 bytes from 203.0.113.3: icmp_seq=4 ttl=63 time=19.4 ms
--- 203.0.113.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Access the main Vultr VPC server.
Verify that the IPsec tunnel is up.
$ sudo ipsec status
Output:
vultr-onpremises-vpn[7]: ESTABLISHED 6 minutes ago, 198.51.100.1[vpn.example.com]...192.0.2.2[vultruser]
vultr-onpremises-vpn{5}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cfd39c84_i c17666e4_o
vultr-onpremises-vpn{5}: 203.0.113.0/24 === 192.168.1.0/24
Ping the main On-Premises server private IP address.
$ ping 192.168.1.1
Output:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=21.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=17.7 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=17.7 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=19.4 ms
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Ping the Windows client machine.
$ ping 192.169.1.2
Output:
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=63 time=21.0 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=63 time=17.7 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=63 time=17.7 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=63 time=19.4 ms
--- 192.168.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Access the Vultr VPC application server.
Ping the main On-Premises server private IP address.
$ ping 192.168.1.1
Ping the Windows client machine.
$ ping 192.168.1.2
Access the On-Premises Windows client machine.
Open the Windows command prompt.
Ping the Debian application server.
> ping 203.0.113.3
Output:
PING 203.0.113.3 (203.0.113.3) 56(84) bytes of data.
64 bytes from 203.0.113.3: icmp_seq=1 ttl=63 time=21.0 ms
64 bytes from 203.0.113.3: icmp_seq=2 ttl=63 time=17.7 ms
64 bytes from 203.0.113.3: icmp_seq=3 ttl=63 time=17.7 ms
64 bytes from 203.0.113.3: icmp_seq=4 ttl=63 time=19.4 ms
--- 203.0.113.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Using a web browser such as Chrome, visit the Vultr web application server VPC address.
http://203.0.113.3
Your Web Application should display in the browser window.
Road Warriors are devices that are not directly connected to the On-Premises Network. For example, multiple remote users who work from home, another office, or a public place such as a coffee shop or restaurant.
This section describes how you can allow Road Warriors to access the On-Premises to Vultr VPC network tunnel resources. These include a secure Internet connection through the VPC server and the ability to reach all hosts on both sides of the tunnel.
Access the main Vultr VPC server.
Back up the IPsec configuration file.
$ sudo cp /etc/ipsec.conf /etc/ipsec.conf.BAK
Open and edit the IPsec configuration file.
$ sudo nano /etc/ipsec.conf
Add the following configurations at the end of the file.
conn remote-to-vultr-to-onpremises
auto=start
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
rekey=no
left=vpn.example.com
leftid=@vpn.example.com
leftcert=server.cert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightsourceip=192.5.2.0/24
rightdns=1.1.1.1
rightsendcert=never
eap_identity=%identity
Save and close the file.
The above configuration creates a new IPsec tunnel profile with different settings from the main On-Premises to Vultr VPC tunnel.
Open and edit the ipsec.secrets
file.
$ sudo nano /etc/ipsec.secrets
Add the following directives at the end of the file to add new users.
user1 : EAP "22"
user2 : EAP "22"
remoteuser3 : EAP "22"
Save and close the file.
Your edited file should look like the one below.
vpn.example.com : RSA server.key.pem
vultr-user : EAP "strong-password"
user1 : EAP "22"
user2 : EAP "22"
remoteuser3 : EAP "22"
Restart IPsec.
$ sudo ipsec restart
Verify the IPsec status and confirm that the main On-Premises to Vultr tunnel is active.
$ sudo ipsec status
If disconnected, re-establish the tunnel using the following command.
$ sudo ipsec up vultr-onpremises-vpn
This section describes how Road Warriors can connect to the main Vultr VPC through a different IPsec tunnel that interconnects to the main On-Premises network tunnel. IPsec supports all types of devices, and on a smartphone, you should download the strongSwan
application from the respective device store.
For a road warrior to successfully establish a tunnel connection, you must import the Vultr VPC server certificate to the device, then enter a valid username and password combination as set in the ipsec.secrets
file. This article connects a macOS road warrior device to the Vultr VPC network through the following steps.
Open the Terminal application.
Using SCP
, download the Vultr VPC server chain.pem
certificate.
% scp root@138.68.87.87:/etc/ipsec.d/cacerts/ca.cert.pem warrior.pem
Enter your server SSH password when prompted.
Open the mac Finder Application.
Navigate to the directory where you downloaded the server certificate.
Double-click the certificate to open the Keychain access application and add it to your trusted server certificates.
In the Keychain access window, click Certificates
in the left bottom Category section.
Enter your domain name in the search field to reveal your server certificate on the list.
Double-click the server certificate to open a separate pop-up window.
Expand Trust, and click the drop-down field next to IP Security (IPsec), then select Always Trust from the list of options.
Close the window and enter your mac user password to update settings.
Open System Preferences and navigate to Network.
Click the + create a new service
symbol in the bottom left corner.
Click the Interface: drop-down and select VPN from the list.
Keep IKEV2 as the VPN type, and enter a custom Service Name: for your network.
Enter your domain name in the Server Address:, Remote ID: fields, then, enter your username in the Local ID: field.
Click Authentication Settingsâ¦, keep Username selected, then enter your username and associated password.
Click Apply, then click Connect to establish a connection to the Vultr VPC server.
When successful, open the Terminal app, then ping the main On-Premises server local address.
$ ping 192.168.1.1
Ping the On-Premises Windows host.
$ ping 192.168.1.2
Ping the Vultr VPC web application server.
$ ping 203.0.113.3
All requests should be successful, and users should be able to access both On-Premises, and Vultr VPC networks.
On other devices, such as Windows, or Linux desktop, find the VPN network settings from your Network and Sharing menu.
Define static routes on each direct local network host with the main server as the next hop.
$ sudo ip route add 192.168.1.0/24 via 203.0.113.2 dev eth1 src 203.0.113.3
$ sudo ip route add 203.0.113.0/24 via 192.168.1.1 dev eth1 src 192.168.1.2
Setup proper iptables forwarding to the correct local network interface on both main tunnel servers.
$ sudo iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
$ sudo iptables -t nat -A POSTROUTING -o enp6s0 -j MASQUERADE
Install and configure the iptables persistent package to load forwarding rules even after a restart.
Oct 4 10:51:13 example charon: 13[IKE] IKE_SA vultr-onpremises-vpn[2] state change: CONNECTING => ESTABLISHED
Oct 4 10:51:13 example charon: 13[CFG] looking for a child config for 203.0.113.3/24 === 192.0.2.2/32
Oct 4 10:51:13 example charon: 13[CFG] proposing traffic selectors for us:
Oct 4 10:51:13 example charon: 13[CFG] 203.0.113.3/24
Oct 4 10:51:13 example charon: 13[CFG] proposing traffic selectors for other:
Oct 4 10:51:13 example charon: 13[CFG] 10.24.96.0/20
Oct 4 10:51:13 example charon: 13[IKE] traffic selectors 203.0.113.3/24 === 192.0.2.2/32 unacceptable`
Verify that you set the correct leftsubnet=
and rightsubnet=
network values in both main server configuration files.
$ sudo cat /etc/ipsec.conf
Oct 4 11:30:37 example charon: 11[NET] received packet: from 192.0.2.2[4500] to 198.51.100.1[4500] (208 bytes)
Oct 4 11:30:37 example charon: 11[ENC] parsed IKE_AUTH response 1 [ IDr SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) ]
Oct 4 11:30:37 example charon: 11[IKE] do not allow non-mutual EAP-only authentication
Oct 4 11:30:37 example charon: 11[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]`
Verify that you set the correct rightid
, and the ipsec.secrets
file settings are correct on both servers.
$ sudo cat /etc/ipsec.secrets
You have configured and connected your On-Premises network to a Vultr Virtual Private Cloud (VPC). The IPsec tunnel remains connected until the daemon receives a user action, such as shutting down or restarting the tunnel.
IPsec also supports multiple gateway devices, such as routers and firewalls, if your On-Premises network uses a static address on the main gateway interface, please visit the router documentation to connect your network to the Vultr VPC. For more information, please visit the following articles.