L2TP/IPsec

L2TP/IPsec (which stands for Layer 2 Tunneling Protocol and Internet Protocol Security, respectively) is another method of implementing VPNs. L2TP is the tunneling protocol used, and provides no security, and so is often used in conjunction with IPsec, hence why it is commonly know as L2TP/IPsec.

Remote Access VPNs

For these scenarios let's assume we will be using the same IP addresses used in the PPTP remote access section, that is, a public IP of 23.90.55.23 on interface eth1 and a desired client IP pool of 172.16.0.100-172.16.0.200 (connecting clients will be assigned an IP from this IP range).

Using L2TP/IPsec with Pre-Shared Secret

In this scenario we will be using a pre-shared secret, as well as a username and password.

Firstly, IPsec first needs to be configured. We need to use the public interface (eth1), and are for nat traversal as well as allowing connections from anywhere (so an allowed network of 0.0.0.0/0).

configure
set vpn ipsec ipsec-interfaces interface eth1
set vpn ipsec nat-networks allowed-network 0.0.0.0/0
set vpn ipsec nat-traversal enable

Now L2TP needs to be configured (similar setup to PPTP). The local user is also created here.

edit vpn l2tp remote-access
set outside-address 23.90.55.23
set client-ip-pool start 172.16.0.100
set client-ip-pool stop 172.16.0.200
set authentication mode local
set authentication local‐users username <USERNAME> password <PASSWORD>

top

After this we need to set the authentication mode that will be used (pre-shared secret).

edit ipsec-settings authentication
set mode pre‐shared‐secret
set pre-shared-secret <PRE-SHARED-SECRET>

This completes the configuration.

commit
save

Using L2TP/IPsec with x509 Certificates

This configuration is similar to above, but is much stronger. A server certificate is required for this section, as well as client certificates for any clients wishing to connect to this VPN.

We will assume all the certificates have already been made, and are stored in /config/auth/keys. If this is not the case then they need to be generated, either by following the instructions under Creating x509 Certificates, generated using other software or obtained through a third party.

If the certificates used in this section are generated using easyrsa, note that they should be built with ./build-key. A server certificate is required for the VyOS machine, and a separate client certificate for each client.

As with before, IPsec first needs to be configured.

configure
set vpn ipsec ipsec-interfaces interface eth1
set vpn ipsec nat-networks allowed-network 0.0.0.0/0
set vpn ipsec nat-traversal enable

Now L2TP also needs to be configured as before and the local user created.

edit vpn l2tp remote-access
set outside-address 23.90.55.23
set client-ip-pool start 172.16.0.100
set client-ip-pool stop 172.16.0.200
set authentication mode local
set authentication local‐users username <USERNAME> password <PASSWORD>

top

Now, instead of using a pre-shared secret like above, we use x509 instead, and specify the locations of the relevant certificates. In this case it is assumed:

  • The CA certificate is stored at /config/auth/keys/ca.crt
  • The server certificate is stored at /config/auth/keys/server.crt
  • The server key is stored at /config/auth/keys/server.key

Replace these files with the relevant files.

edit vpn l2tp remote-access ipsec-settings authentication
set mode x509

edit x509
set ca-cert-file /config/auth/keys/ca.crt
set server-cert-file /config/auth/keys/server.crt
set server-key-file /config/auth/keys/server.key

If a crl file is also used, it can be set here (if using easyrsa, this will be automatically generated when you revoke certificates).

set crl-file /config/auth/keys/crl.pem

Finally we can commit and save.

commit
save

Your client should have the respective client certificate files and CA needed to connect. If you need to convert the certificates to pkcs12 format (eg. for Windows), it can be done using openssl (from the terminal).

openssl pkcs12 -export -out client.p12 -inkey client.key -in client.crt 

Site-to-Site VPN

For these scenarios we will assume that site 1 has a public IP of 23.90.55.5 and private IP of 10.0.0.1/24, and that site 2 has a public IP of 23.90.55.6 and a private IP of 192.168.0.1/24.

For each of the following configurations, the configuration following is required (you do not need to repeat this if it has already been set).

Let's assume we are on site 1. First we need to set the IPsec interface.

set vpn ipsec ipsec-interfaces interface eth1
set vpn ipsec nat-networks allowed-network 0.0.0.0/0
set vpn ipsec nat-traversal enable

Next we need to create our ike and esp groups and set the encryption it has to use for each proposal. There are two phases when authenticating, and the encryption that should be used is dictated here.

edit vpn ipsec ike-group ike-site1
set proposal 1 encryption aes256
set proposal 1 hash sha1
set proposal 2 encryption aes128
set proposal 2 hash sha1
set lifetime 3600

top

edit vpn ipsec esp-group esp-site1
set proposal 1 encryption aes256
set proposal 1 hash sha1
set proposal 2 encryption 3des
set proposal 2 hash md5
set lifetime 1800

top

Finally, we need to prevent masquerading from occurring, and so we exclude it from the nat source (remember that rules are carried out sequentially, starting from the lowest first, and the masquerade was set as rule 100).

In this case site 1 has a private network of 10.0.0.0/24 and site 2 has a private network of 192.168.0.0/24.

edit nat source rule 10
set destination address 192.168.0.0/24
set exclude
set outbound-interface eth1
set source address 10.0.0.0/24

top

Now we need to associate the ike and esp groups with the site-to-site connection (the peer always refers to the remote site).

edit vpn ipsec site-to-site peer 23.90.55.6
set default-esp-group esp-site1
set ike-group ike-site1

We also need to set our local address (our public IP).

set local-address 23.90.55.5

The tunnel also needs to be configured. Here the subnet's for both sides of the tunnel needs to be specified.

set tunnel 1 local prefix 10.0.0.0/24
set tunnel 1 remote prefix 192.168.0.0/24

top

This then needs to be repeated on site 2 (with appropriate substitutions).

These settings will remain constant despite the authentication method used, and for each of the following configurations below it will be assumed that the above has already been set.

Using L2TP/IPsec with Pre-Shared Secret

Here we use a pre-shared secret for authentication. All we need to do is set the authentication mode to pre-shared-secret and specified the pre-shared secret.

edit vpn ipsec site-to-site peer 23.90.55.6 authentication
set mode pre-shared-secret
set pre-shared-secret <PRE-SHARED-SECRET>

This completes the configuration.

commit
save

Now this needs to be duplicated on site 2, with the address swapped around to mirror this configuration.

Using L2TP/IPsec with RSA Keys

This uses a similar configuration as with using a pre-shared secret. First we need to generate a RSA key, for both site 1 and site 2. Let's assume we are on site 1.

generate vpn rsa-key
Your new local RSA key has been generated
The public portion of the key is:

By default, this key (including the private portion of the key) is stored in /config/ipsec.d/rsa‐keys/localhost.key
0sAQN2XnsW72mjb8QsZ9hVoAj0+slp/YQ8PvkxdOZFprERNw==

Note that this will take a while as by default it generates using /dev/random. /dev/urandom can be used instead to speed it up.

generate vpn rsa-key bits 1024 random /dev/urandom

This will generate a both a private and public key. The key will be stored locally (location is mentioned once the key is generated), and the public part of the key is displayed. Now we need to move across to site 2, and store this public part of the key there, under some key name.

set vpn rsa‐keys rsa‐key‐name <SITE-1-KEY-NAME> rsa-key 0sAQN2XnsW72mjb8QsZ9hVoAj0+slp/YQ8PvkxdOZFprERNw==

This needs to be repeated on site 2, to provide site 1 with a public key (belonging to site 2).

Now, back on site 1, follow the same steps as with using a pre-shared secret. When setting the authentication mode, the following should be used instead (the peer always refers to the remote site).

edit vpn ipsec site-to-site peer 23.90.55.6 authentication
set mode rsa
set rsa-key-name site2-key

Finally, commit and save.

commit
save

Again, this needs to be duplicated on site2, with the configuration changed accordingly.

Using L2TP/IPsec with x509 Certificates

When using x509 certificates for site-to-site VPNs, each site will need its own certificate. These can either be generated using easyrsa, or through other means.

The authentication mode for site 1 now needs to be set to x509.

edit vpn ipsec site-to-site peer 23.90.55.6 authentication
set mode x509

The remote-id also needs to be set. This should point to the distinguished name of the remote site's certificate

set remote-id "C=AU, ST=NSW, L=Sydney, CN=site2"

The distinguished name of the certificate for site 2 can be obtained using openssl (note that you will need to be in the terminal).

openssl x509 -noout -in /config/auth/keys/site2.crt –subject
subject= /C=AU/ST=NSW/L=Sydney/CN=site1

From above the C=AU/ST=NSW/L=Sydney/CN=site1 is the distinguished name of the certificate, and needs to be used, although the '/' replaced with ' , ' beforehand. There might be more or less information, depending on what you input when creating the certificate.

Finally, the location of the certificates needs to be set.

edit x509
set ca-cert-file /config/auth/keys/ca.crt
set cert-file /config/auth/keys/site1.crt
set key file /config/auth/keys/site1.key

If a password was set, it also needs to be added to the configuration.

set key password site1password

If a crl file is used, it can also be set here.

set crl-file /config/auth/keys/crl.pem

Finally, commit and save.

commit
save

As with all the previous cases, this needs to be duplicated on site2, with the configuration changed accordingly.

3 Way Fully-Meshed VPN

All the above site-to-site VPN examples used 2 sites, however it is possible to add more sites. In this example we will be using pre-shared secrets as our authentication method, however any of the above authentication methods can be used in it's place.

We will be adding a third site with a public IP of 23.90.55.7 and a private IP of 172.16.0.1/24, and assume that a site-to-site VPN has already been set up between site 1 and site 2 using pre-shared secrets.

In site 1, the next step would be to follow the steps under Site-to-Site VPN, but for a second peer. We will use the same ike-group and esp-group, however it is possible to use a different one for each peer.

The IPsec interface should already be configured, what needs to be done now is to define a nat source rule.

edit nat source rule 20
set destination address 172.16.0.0/24
set exclude
set outbound-interface eth1
set source address 10.0.0.0/24

top

Next we would need to associate with the ike and esp groups with this peer.

edit vpn ipsec site-to-site peer 23.90.55.7
set default-esp-group esp-site1
set ike-group ike-site1

The local address needs to be set again for this peer.

set local-address 23.90.55.5

The tunnel for this peer now needs to be configured.

set tunnel 1 local prefix 10.0.0.0/24
set tunnel 1 remote prefix 172.16.0.0/24

top

Finally, the authentication method needs to be set.

edit vpn ipsec site-to-site peer 23.90.55.7 authentication
set mode pre-shared-secret
set pre-shared-secret <PRE-SHARED-SECRET>

This completes the configuration for site 1.

commit
save

This needs to be repeated on site 2 to connect to site 3. On site 3, two new peers need to be added for site 1 and site 2.

3 Way Dynamic-Multipoint VPN

A dynamic-multipoint VPN (DMVPN) allows for a Hub and Spoke VPN network to be setup without having to pre-configure all peers and tunnels as with above. In this scenario we will set up a 3 way DMVPN, however this can be scaled up to include many more sites.

It will be assumed that the hub will have a public IP of 23.90.55.5, a private IP of 10.0.0.1, and a tunnel IP of 10.1.1.1/24, spoke 1 will have a public IP of 23.90.55.6, a private IP of 192.168.0.1, and a tunnel IP of 10.1.1.2/24, and spoke 2 will have a public IP of 23.90.55.7, a private IP of 172.16.0.1/24, and a tunnel IP of 10.1.1.3/24.

Firstly the hub will be configured. The tunnel interface needs to be first set up. We will be using gre for encapsulation.

edit interfaces tunnel tun0
set address 10.1.1.1/24
set encapsulation gre
set local-ip 23.90.55.5
set multicast enable
set parameters ip key 1

top

Next we need to set up the next hop resolution protocol (NHRP) and set our passphrase for cisco authentication.

edit protocols nhrp tunnel tun0
set cisco-authentication <SECRET>
set holding-time 300
set multicast dynamic
set redirect

top

Our ike and esp groups also need to be set up.

edit vpn ipsec ike-group esp-hub
set proposal 1 encryption aes256
set proposal 1 hash sha1
set proposal 2 encryption aes128
set proposal 2 hash sha1
set lifetime 3600

top

edit vpn ipsec esp-group esp-hub
set proposal 1 encryption aes256
set proposal 1 hash sha1
set proposal 2 encryption 3des
set proposal 2 hash md5
set lifetime 1800
set pfs dh-group2

top

A VPN IPsec profile now needs to be set up, and associated with the tunnel, esp and ike groups. The only authentication mode available is pre-shared secrets.

edit vpn ipsec profile NHRPVPN
set authentication mode pre-shared-secret
set authentication pre-shared-secret <PRE-SHARED-SECRET>
set bind tunnel tun0
set esp-group esp-hub
set ike-group ike-hub

top

Finally, static routes need to be set up so that traffic gets routed through the correct tunnels (spoke 1 and spoke 2).

set protocols static route 192.168.0.0/24 next-hop 10.1.1.2
set protocols static route 172.16.0.0/24 next-hop 10.1.1.3

This completes the configuration for the hub.

commit
save

Each spoke now also needs to be configured. Assume we are now on spoke 1. Firstly the tunnel needs to be configured. The local-ip can either be specified or left as 0.0.0.0 if using dhcp.

edit interfaces tunnel tun0
set address 10.1.1.2/24
set encapsulation gre
set local-ip 23.90.55.6
set multicast enable
set parameters ip key 1

top

The next hop resolution protocol (NHRP) now needs to be set up. Use the same secret used for the hub. The HUB tunnel also needs to be mapped.

edit protocols nhrp tunnel tun0
set cisco-authentication <SECRET>
set map 10.1.1.1/24 nbma-address 23.90.55.5
set map 10.1.1.1/24 register
set multicast nhs
set redirect
set shortcut

top

The ike and esp groups need to be configured.

edit vpn ipsec ike-group esp-spoke
set proposal 1 encryption aes256
set proposal 1 hash sha1
set proposal 2 encryption aes128
set proposal 2 hash sha1
set lifetime 3600

top

edit vpn ipsec esp-group esp-spoke
set proposal 1 encryption aes256
set proposal 1 hash sha1
set proposal 2 encryption 3des
set proposal 2 hash md5
set lifetime 1800
set pfs dh-group2

top

The VPN IPsec profile should also be set up, similar to what was done on the hub.

edit vpn ipsec profile NHRPVPN
set authentication mode pre-shared-secret
set authentication pre-shared-secret <PRE-SHARED-SECRET>
set bind tunnel tun0
set esp-group esp-spoke
set ike-group ike-spoke

top

Finally, static routes need to be set up so that traffic gets routed through the correct tunnels (the hub and spoke 2).

set protocols static route 10.0.0.0/24 next-hop 10.1.1.1
set protocols static route 172.16.0.0/24 next-hop 10.1.1.3

This completes the configuration for spoke 1. It should be repeated for spoke 2, with the necessary substitutions made, and should complete the DMVPN setup.

Using a Virtual Tunnel Interface (VTI)

A Virtual Tunnel Interface (VTI) can be set up on top of your site-to-site vpn. The main benefit of this is that it allows the vpn to act as an interface, and so can be treated as such (firewalls can be attached, etc...).

Let's assume we already have a site-to-site VPN set up with one of the above authentication methods. First we need to set up the VTI interface. Let's assume that the VTI on site 1's side will take address of 172.16.0.1, and site 2 will take 172.16.0.2, and that we are on site 1 currently.

set interfaces vti vti0 address 172.16.0.1/30

Next, we need to delete the default esp group setting and the tunnel.

delete vpn ipsec site‐to‐site peer 23.90.55.6 default-esp-group
delete vpn ipsec site-to-site peer 23.90.55.6 tunnel 1

Now we need to set up the VTI.

edit vpn ipsec site‐to‐site peer 23.90.55.6 vti
set bind vti0
set esp-group esp-site1

Lastly we need to set up the routing, so that any traffic destined for site 2 goes through the tunnel.

set protocols static interface-route 192.168.0.0/24 next-hop-interface vti0
commit
save

This then needs to be repeated on site 2.

Using a firewall with the VTI interface

Since an VTI interface is being used, a firewall can also be set up on it.

set firewall name vti-local
.....
set interfaces vti vti0 firewall local name vti-local
commit
save