VyOS - Blog

Which VPN protocol to use

e.altunbas@vyos.io (Erkin Batu Altunbas) — Wed, 04 May 2022 09:45:50 GMT

Hello Community!

A question that often comes up in networking software discussions is "which VPN protocol should I use?" followed by "why should I use that one when there are so many others?" I'm going to try to tackle these questions in lay terms here.

Using DMVPN and BGP to interconnect your sites

christian@poessinger.com (Christian Pössinger) — Sun, 31 Oct 2021 13:04:02 GMT

Hello, Community!

Some weeks ago a very close friend of mine approached me and asked about an issue in his VyOS installation. He is using several WireGuard tunnels in a star topology connecting his private sites with a central hub. All of his traffic is forced to traverse the hub - which adds additional latency to the connections.

He wanted to change the design so that individual spokes are able to talk to one another, directly. This requires a topology change to a full-mesh when sticking with WireGuard. A fully meshed WireGuard installation with 4 sites will require you to configure 3 WireGuard tunnels per individual site, leading to a total of 12 tunnels—too complex!

I then explained how to use DMVPN (Dynamic Multipoint Virtual Private Network) with VyOS—and as there is a new LTS release on the way, it is time for some in-depth testing of a very old feature! As DMVPN was the initial reason I choose VyOS (1.1.7, more than 5 years ago), it is fun for me to write about the same topic in 2021.

PKI and IPSec IKEv2 remote-access VPN

christian@poessinger.com (Christian Pössinger) — Sun, 01 Aug 2021 20:30:39 GMT

Hello!

VyOS was always strong in supporting a multitude of different VPN techniques ranging from old school IPsec site-to-site/DMVPN setups to new kids on the block like SSTP, OpenVPN, and WireGuard. Today I want to present a new feature that was added to VyOS in the current 1.4 (Sagitta) development cycle — IKEv2 remote-access VPN.

Given the fact this is actually not a "new" technology, it is still a very interesting one as it is natively supported on all major operating systems!

Take a third option: site to site OpenVPN

daniil@sentrium.io (Daniil Baturin) — Fri, 30 Mar 2018 10:38:22 GMT

I've written a long series of post about setting up IPsec VPNs between NATed machines. As you've already seen, with some creative configuration it's possible, but is it always worth the sacrifice? Sometimes performance requirements, or lack of support for anything else on the other side make it necessary, but if the other side is also a VyOS, or another open source system, there's an alternative.

While OpenVPN is usually associated with road warrior VPN setups, it is not limited to it. It does have a site to site option and it's very quick and easy to setup. For some strange reason, that option is neglected by just about everyone who otherwise supports OpenVPN: in OpenWRT it's possible to setup through custom config options, while in Mikrotik RouterOS it's not possible to setup at all. In VyOS we have an explicit option for it. OPNsense also supports site to site OpenVPN out of the box (I thought it doesn't, but the authors corrected me).

The advantages are that it takes very few commands to get a tunnel to work, and that it will work in any network where you can forward a single port, even is both sides are behind double NAT. The downside is performance: squeezing even 100mbit/s of encrypted traffic out of it can be impossible, typical iperf figures are 10-20 mbit/s. For many use cases that performance is more than enough, though if you plan to use the tunnel for storage replication or another high-traffic job, that option is definitely not for you and you'll have to resort to IPsec.

Setting up site to site OpenVPN

Generating a key

OpenVPN in site to site mode supports either static pre-shared keys or x.509. For a quick tunnel setup between your own routers, the format option is a lot easier and arguably not less secure. Unlike most IPsec implementations, OpenVPN stores pre-shared keys in files, and uses keys of considerable length (default is 2038. It takes just one command to generate a suitable key:

run generate openvpn key /config/auth/mysite.key

Then you can copy the file to the remote side via SCP or something else. That command is a wrapper for "openvpn --genkey --secret" in case you want to generate a key outside VyOS. It's a good idea to store the keys in /config/auth directory that was specifically meant for authentication data, since /config will be migrated to the new image when you upgrade your system — if you put them in /etc, they will be inaccessible from the upgraded image.

Setting up the tunnel

It's quite straightforward.

Local (listening) side:

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 description 'My remote site'

set interfaces openvpn vtun10 local-host 203.0.113.50 # Listen address

set interfaces openvpn vtun10 local-address 192.168.34.1 # Tunnel address

set interfaces openvpn vtun10 local-port 8000 # Port to listen on

set interfaces openvpn vtun10 protocol udp # Can be TCP but TCP is slower

set interfaces openvpn vtun10 remote-address 192.168.34.2 # Tunnel peer address

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/mysite.key # The file you generated

Remote (connecting) side:

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 remote-host 203.0.113.50 # Remote router external address

set interfaces openvpn vtun10 local-address 192.168.34.2 # Tunnel address, don't forget to local/remote addresses for the remote side!

set interfaces openvpn vtun10 remote-port 8000 # Port to connect on

set interfaces openvpn vtun10 protocol udp # Can be TCP but TCP is slower

set interfaces openvpn vtun10 remote-address 192.168.34.1

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/mysite.key

As you can see, with less than 10 commands on each side, you can get a tunnel working.

What about x.509?

It is doable, though I'm not sure if it's really worth the trouble for site to site tunnels.

This is how it's done. Local (listening) side:

set interfaces openvpn vtun10 tls role passive

set interfaces openvpn vtun10 tls dh-file /config/auth/dh2048.pem

set interfaces openvpn vtun10 tls ca-cert-file /config/auth/ca.crt

set interfaces openvpn vtun10 tls cert-file /config/auth/local.crt

set interfaces openvpn vtun10 tls key-file /config/auth/local.key

Remote (connecting) side:

set interfaces openvpn vtun10 tls role active

set interfaces openvpn vtun10 tls ca-cert-file /config/auth/ca.crt

set interfaces openvpn vtun10 tls cert-file /config/auth/remote.crt

set interfaces openvpn vtun10 tls key-file /config/auth/remote.key

Routing

Since OpenVPN tunnels look like normal network interfaces, you can setup routing right away as if they were physical links. You can also use push-route commands through custom options (as in, openvpn-option "push ..."). Note that OpenVPN in site to site mode doesn't install any routes by default so you need to take care of it yourself.

Interaction between IPsec and NAT (on the same router)

daniil@sentrium.io (Daniil Baturin) — Thu, 01 Feb 2018 06:01:49 GMT

I've just completed a certain unusual setup that involved NATing packets before they are sent to an IPsec tunnel, so I thought I'll write about this topic. Even in perfectly ordinary setups, the interaction between the two often catches people off guard, me included.

No, this is not a premature Friday post. The Friday post will be a continuation of the little known featured of the VyOS CLI.

Most routers these days have some NAT configured, so if you setup an IPsec tunnel, you need to understand the interaction between the two. Luckily, it's pretty simple.

Every network OS has a fixed packet processing order, and for a good reason. For example, source NAT has to be performed after routing because otherwise the OS will not know which outgoing interface must be used for the packet, and will not be able to determine which SNAT rule must be applied to that packet. Likewise, destination NAT must happen before routing if we want to be able to send incoming packets to the intended host — the routing decision depends on the new destination address.

Sometimes the order is less critical but reversing it would create inconvenience for network admins. For example, in Linux (and thus in VyOS), inbound firewall rules are processed after DNAT, so the destination address the firewall will see is the internal address, and you can easily setup a firewall that mentions private addresses on your WAN interface. If it was the other way around, then if you wanted to setup firewall rules for your private addresses, you would have to assign the firewall to the out direction of the LAN interface — not quite as logical or convenient, even if the end result is the same.

Where's IPsec in that processing flow and what are the implications of its position in it?

Let's revisit the complete diagram (image by Jan Engelhardt, CC-BY-SA):

If posthaven can't handle images properly, here's a direct link to the larger version:

The box you are looking for is "XFRM". In Linux, IPsec is not a special component, but a part of the XFRM framework that can do encryption amond other things (it also does compression and header modification).

From the diagram we can see that XFRM decode step (thus IPsec encryption) is before DNAT (NAT prerouting), and IPsec decryption is after SNAT (NAT postrouting). The implications of it are twofold: first you need to be careful when setting up SNAT and IPsec on the same machine, second, you can apply NAT rules to traffic that will go to the tunnel if you really have to.

Avoiding adverse interaction

Suppose you have this config:

vyos@vyos# show vpn ipsec site-to-site

 peer 192.0.2.150 {

     [SNIP]

     tunnel 1 {

         local {

             prefix 192.168.10.0/24

         }

         remote {

             prefix 10.10.10.0/24

         }

     }

 }
vyos@vyos# show nat source

 rule 10 {

     outbound-interface eth0

     source {

         address 192.168.10.0/24

     }

     translation {

         address 203.0.113.134

     }

 }

What will happen to a packet sent by host 192.168.10.100 to host 10.10.10.200? Since SNAT is performed before IPsec, and the 192.168.10.100 source address matches the rule 10, the rule will be applied and the packet will go down the packet processing pipeline with source address 203.0.113.134, which does not match the IPsec policy from tunnel 1. The packet will be sent out of the eth0 interface, unencrypted, and destined to be dropped by the ISP due to its private destination address (or it will be sent to a wrong host, which is not any better).

In this case this order of packet processing seems to be a real hassle. There's a very easy workaround though: exclude packets with destination address 10.10.10.0/24 from SNAT, like this:

vyos@VyOS-AMI# show nat source

rule 5 {

    outbound-interface eth0

    destination {

        address 10.10.10.0/24

    }

    exclude

}

 rule 10 {

     outbound-interface eth0

     source {

         address 192.168.10.0/24

     }

     translation {

         address 203.0.113.134

     }

 }

If you've setup IPsec, the SA is up, but for some reason packets don't get through, make sure that you didn't forget to exclude traffic to the remote network from NAT. It's easy to see with tcpdump whether packets are sent the wrong way or not.

Exploiting the interaction

So far we've only seen how this particular processing order can be bad for our setup. Can it be good for anything then? Sometimes it seems like the Linux network stack was optimized to allow doing crazy things. Just a few days ago I've run into a case when this turned beneficial.

Suppose you setup an IPsec tunnel to your partner, and it turns out you both are using 192.168.10.0/24 subnet internally. None of you is willing to renumber your own network to solve the problem cleanly, but some compromise must be made. The solution is to NAT packets before they are encrypted, which works as expected precisely because IPsec happens after SNAT.

For simplicity let's assume only a single host from our network (internal address 192.168.10.45) needs to interact with a single host from the remote network (10.10.10.55). We will make up an intermediate 172.16.17.45 address and NAT the tunnel traffic to and from 10.10.10.55 host to actually be sent to the 192.168.10.45 host.

The config looks like this:

vyos@vyos# show vpn ipsec site-to-site

 peer 192.0.2.150 {

     [SNIP]

     tunnel 1 {

         local {

             prefix 172.16.17.45/32

         }

         remote {

             prefix 10.10.10.55/32

         }

     }

 }
vyos@vyos# show nat source

 rule 10 {

     outbound-interface any
     destination {
         address 10.10.10.55
     }
     source {

         address 192.168.10.45

     }
     translation {

         address 172.16.17.45

     }

 }
vyos@vyos# show nat destination

 rule 10 {

     destination {

         address 172.16.17.45

     }

     inbound-interface any

     translation {

         address 192.168.10.45

     }

 }

If IPsec was performed before source NAT, this kind of setup would be impossible.

Setting up GRE/IPsec behind NAT

daniil@sentrium.io (Daniil Baturin) — Fri, 19 Jan 2018 15:00:55 GMT

In the previous posts of this series we've discussed setting up "plain" IPsec tunnels from behind NAT.

The transparency of the plain IPsec, however, is more often a curse than a blessing. Truly transparent IPsec is only possible between publicly routed networks, and the tunnel mode creates a strange mix of the two approaches: you do not have a network interface associated with the tunnel, but the setup is not free of routing issues either, and it's often hard to test whether the tunnel actually works or not from the router itself.

GRE/IPsec (or IPIP/IPsec, or anything else) offers a convenient solution: for all intents and purposes it's a normal network interface and makes it look like the networks are connected with a wire. You can easily ping the other side, use the interface for firewall and QoS rulesets, and setup dynamic routing protocols in a straightforward way. However, NAT creates a unique challenge for this setup.

The canonical and the simplest GRE/IPsec setup looks like this:

interfaces {

  tunnel tun0 {

    address 10.0.0.2/29

    local-ip 192.0.2.10

    remote-ip 203.0.113.20

    encapsulation gre

  }

}

vpn {

  ipsec {

    site-to-site {

      peer 203.0.113.20 {

        tunnel 1 {

          protocol gre

        }

        local-address 192.0.2.10

It creates a policy that encrypts any GRE packets sent to 203.0.113.20. Of course it's not going to work with NAT because the remote side is not directly routable.

Let's see how we can get around it. Suppose you are setting up a tunnel between routers called East and West. The way to get around it is pretty simple even if not exactly intuitive and boils down to this:

Setup an additional address on a loopback or dummy interface on each router, e.g. 10.10.0.1/32 on the East and 10.10.0.2/32 on the West.
Setup GRE tunnels that are using 10.10.0.1 and .2 as local-ip and remote-ip respectively.
Setup an IPsec tunnels that uses 10.10.0.1 and .2 as local-prefix and remote-prefix respectively.

This way when traffic is sent through the GRE tunnel on the East, the GRE packets will use 10.10.0.1 as a source address, which will match the IPsec policy. Since 10.10.0.2/32 is specified as the remote-prefix of the tunnel, the IPsec process will setup a kernel route to it, and the GRE packets will reach the other side.

Let's look at the config:

interfaces {

  dummy dum0 {

    address 10.10.0.1/32

  }

  tunnel tun0 {

    address 10.0.0.1/29

    local-ip 10.10.0.1

    remote-ip 10.10.0.2

    encapsulation gre

  }

}

vpn {

  ipsec {

    site-to-site {

      peer @west {

        connection-type respond

        tunnel 1 {

          local {

            prefix 10.10.0.1/32

          }

          remote {

            prefix 10.10.0.2/32

          }

This approach also has a property that may make it useful even in publicly routed networks if you are going to use the GRE tunnel for sensitive but unencrypted traffic (I've seen that in legacy applications): unlike the canonical setup, GRE tunnel stops working when the IPsec SA goes down because the remote end becomes unreachable. The canonical setup will continue to work even without IPsec and may expose the GRE traffic to eavesdropping and MitM attacks.

This concludes the series of posts about IPsec and NAT. Next Friday I'll find something else to write about. ;)

How to setup an IPsec connection between two NATed peers: using id's and RSA keys

daniil@sentrium.io (Daniil Baturin) — Fri, 12 Jan 2018 09:05:06 GMT

In the previous post from this series, we've discussed setting up an IPsec tunnel from a NATed router to a non-NATed one. The key point is that in the presence of NAT, the non-NATed side cannot identify the NATed peer by its public address, so a manually configured id is required.

What if both peers are NATed though? Suppose you are setting up a tunnel between two EC2 instances. They are both NATed, and this creates its own unique challenges: neither of them know their public addresses or can identify their peers by their public address. So, we need to solve two problems.

In this post, we'll setup a tunnel between two routers, let's call them "east" and "west". The "east" router will be the initiator, and "west" will be the responder.

A note on pre-shared keys

While there are many issues with PSKs that public key cryptography solves in an elegant way, such as the problem of exchanging them securely, there's also a specific pitfall associated with them in VyOS: if the local-address of the peer is set to 'any' and the peer is identified by an id rather than public address, it won't allow you to use a pre-shared key for that peer. I have to admit I don't remember if this is a fundamental issue or an implementation detail, and perhaps we can lift this limitation at some point, but as of 1.1.8 and the current builds of 1.2.0, you have to use RSA keys or x.509 for authentication in this kind of setup.

Setting up RSA keys

We will not touch x.509 just yet and will focus on "certless" RSA keys in this post. They are very fast and easy to setup. The only real disadvantage is that some IPsec implementation do not support them and require either pre-shared keys or x.509 certificates, but in our example both sides are running VyOS and this is not an issue.

To generate an RSA key, use this command: "run generate vpn rsa-key bits 2048 random /dev/urandom".

Adjust the key length to match the size and style of your tinfoil hat. Mine looks fine with 2048, though setting it to 4096 won't harm. There is also an option to use /dev/random, but on virtual machines it can be impractical due to long blocking time, and contrary to the popular misconception, neither is /dev/random a source of "true" (information theoretically secure) random numbers, nor is /dev/urandom always inherently insecure. Let's generate a key on the West router.

vyos@west# run generate vpn rsa-key bits 2048 random /dev/urandom

Generating rsa-key to /config/ipsec.d/rsa-keys/localhost.key
Your new local RSA key has been generated

The public portion of the key is:
0sAQO8DJuyosdeE1VQnRUdsPGYFJ5gBsj4qYurjUv+/Jn5qSJJSvLYONNCDYfRDj/me5WGAtGwqmikD00oiLdCqR0FOZJTEQoEWeEh7YnOd4MEIWdeOLFRnGeETcoxGX63S7mxfol4/CVw/9n/kXRRHCnNsgYROsygZLlQIRK7hWAq3L6O1WT7Y3s7dHekXN+Ev6UbtZWQq8lejgmO0TR2ZAF3y6iBETW4Q93ARlhUva/ubBjg2oqtuX9u5UpxWTowuNycY44jm3+vjWczPtcYvvlXNt6nSGoORoHPdBeVyzU7yGIf+TcPKXTiro1JO20gwFv1dPTOLucmgEhjhuO86fFf

Save the public key somewhere. If you clear the screen before copying it, don't worry, you can always find the public key in /config/ipsec.d/rsa-keys/localhost.key file, in its "pubkey=..." section.

Now add the West key to the East router so that we can reference it in the IPsec settings:

vyos@east# set vpn rsa-keys rsa-key-name east rsa-key 0sAQO8DJuyosdeE1V...

Repeat the procedure on the second router.

IPsec setup

Now that both routers have each other's keys, we can setup the actual tunnel. The key points:

Since both routers do not know their effective public addresses, we set the local-address of the peer to "any".
On the initiator, we set the peer address to its public address, but on the responder we only set the id.
On the initiator, we need to set the remote-id option so that it can identify IKE traffic from the responder correctly.
On the responder, we need to set the local id so that initiator can know who's talking to it for the point #3 to work.
Don't forget to enable NAT traversal on both sides, "set vpn ipsec nat-traversal enable".

Let's look at the configs:

The East side:

vyos@east# show vpn

 ipsec {

     [SNIP, IKE/ESP groups are irrelevant]

     ipsec-interfaces {

         interface eth0

     }

     nat-traversal enable

     site-to-site {

         peer 192.0.2.60 {

             authentication {

                 id @east

                 mode rsa

                 remote-id west

                 rsa-key-name west

             }

             connection-type initiate

             default-esp-group Foo

             ike-group Foo

             local-address any

             tunnel 1 {

                 local {

                     prefix 10.36.63.0/24

                 }

                 remote {

                     prefix 10.45.54.0/24

                 }

             }

         }

     }

 }

 rsa-keys {

     rsa-key-name west {

         rsa-key 0sAQO8DJuyosdeE1VQnRUdsPGYFJ5gBsj4qYurjUv+/Jn5qSJJSvLYONNCDYfRDj/me5WGAtGwqmikD00oiLdCqR0FOZJTEQoEWeEh7YnOd4MEIWdeOLFRnGeETcoxGX63S7mxfol4/CVw/9n/kXRRHCnNsgYROsygZLlQIRK7hWAq3L6O1WT7Y3s7dHekXN+Ev6UbtZWQq8lejgmO0TR2ZAF3y6iBETW4Q93ARlhUva/ubBjg2oqtuX9u5UpxWTowuNycY44jm3+vjWczPtcYvvlXNt6nSGoORoHPdBeVyzU7yGIf+TcPKXTiro1JO20gwFv1dPTOLucmgEhjhuO86fFf

     }

 }

The West side:

vyos@west# show vpn

 ipsec {

     [SNIP]

     ipsec-interfaces {

         interface eth0

     }

     nat-traversal enable

     site-to-site {

         peer @east {

             authentication {

                 id west

                 mode rsa

                 rsa-key-name east

             }

             connection-type respond

             default-esp-group Foo

             ike-group Foo

             local-address any

             tunnel 1 {

                 local {

                     prefix 10.45.54.0/24

                 }

                 remote {

                     prefix 10.36.63.0/24

                 }

             }

         }

     }

 }

 rsa-keys {

     rsa-key-name east {

         rsa-key 0sAQO7OF/FKgx33E5I29HSy2cqLnL9hNZ6CMbR8kVRIKhqAowIAskh13+gJN2QKOvLfbjN29uy94W02tty5G7+S+xOPeMsCJyz+ofD/v5tJpqIUughngCAGEoB6uveRRfqF15sOetEgjUGPmcVU+neOJ822E2T1sYbnEVfd+vilNPFopzlY61gtWgq7m7ANe2logwSB5XWyQkgCDNi+8IqVyFhNTVbmxDyfJQ1T4/3sRgcEh5XdZhSqRIwxI7/m2jH1FfIGg0FX5+5ok0bBmRU3tMkUKMB1A4QqgXPXR5P0SMDEkfo6zkbsueAX1NEOKXO443r5aKzA1qAGKV0Zp0sriuR

     }

 }

Now if we look in the logs, we will see the following picture:

Jan 12 06:24:23 east pluto[28278]: "peer-192.0.2.60-tunnel-1" #1: enabling possible NAT-traversal with method 3

Jan 12 06:24:23 east pluto[28278]: "peer-192.0.2.60-tunnel-1" #1: NAT-Traversal: Result using RFC 3947: both are NATed

Jan 12 06:24:23 east pluto[28278]: "peer-192.0.2.60-tunnel-1" #1: we don't have a cert

Jan 12 06:24:23 east pluto[28278]: "peer-192.0.2.60-tunnel-1" #1: Peer ID is ID_FQDN: 'west'

Jan 12 06:24:23 east pluto[28278]: "peer-192.0.2.60-tunnel-1" #1: ISAKMP SA established

Jan 12 06:24:23 east pluto[28278]: "peer-192.0.2.60-tunnel-1" #2: initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}

Jan 12 06:24:23 east pluto[28278]: "peer-192.0.2.60-tunnel-1" #2: sent QI2, IPsec SA established {ESP=>0xc9bf71e1 <0xc32e1a3a NATOA=0.0.0.0}

This concludes the all-NATed IPsec setup.

Why IPsec behind 1:1 NAT is so problematic and what you can do about it

daniil@sentrium.io (Daniil Baturin) — Fri, 05 Jan 2018 23:14:16 GMT

Not so long ago the only scenario when the issues with IPsec and NAT could arise was a remote access setup, while routers invariably had real public addresses and router to router IPsec operators were incredibly unlikely to run into those issues. A router behind NAT was seen as a pathological case.

I believe it's still a pathological case, but as platforms such as Amazon EC2 that use one to one NAT to simplify IP address management rose in popularity and people started setting up their routers there, it became the new normal. This new reality became a constant source of confusion for beginner network admins and people who simply are not VPN specialists. Attempts to setup a VPN as if there's no NAT, with peer external IP addresses and pre-shared keys as it's commonly done, just fail to work.

Sometimes I'm asked why is that so, if the NAT in question is 1:1, and no other protocol just refuses to work behind it without reconfiguration. The reasons are inside the IPsec protocols themselves, and 1:1 NAT is not much better in this regard than any other kind (even though it's somewhat better than the situation when there are multiple clients behind NAT).

IPsec pre-dates NAT by over a decade, and was explicitly designed with end to end connectivity in mind. It was also designed as a way to add built-in security to the IP protocol stack rather than a new protocol within the stack, so it made heavy use of those underlying assumptions. That's why workarounds had to be added when the assumption of end to end connectivity became incorrect.

Let's look into the details and then see how IPsec can be configured to work around those issues. Incidentally, the solutions are equally applicable to machines with dynamic addresses as well as those behind a 1:1 NAT, since the root cause of the issues is not knowing beforehand what your outgoing address will be next time.

AH and ESP

We all (hopefully) remember that there are three criteria of information security: availability, confidentiality, and integrity. Availability (when required) in the IP is provided by reliable transmission protocols such as TCP and SCTP. IPsec was supposed to provide the other two.

AH (Authentication Header) was designed to ensure packet integrity. For that, it calculates a hash function from the entire packet with all its headers, including source and destination addresses. Since NAT changes the addresses, it invalidates the checksum and NATed packets would be considered corrupted. So, AH is unconditionally incompatible with NAT.

ESP only protects the payload of the packet (whether it's some protocol data, or an entire tunnelled packet), so it, luckily, can work behind NAT. The UDP encapsulation of ESP packets was introduced to allow the traffic to pass through incorrect NAT implementations that may discard non-TCP or UDP protocols, and for correct implementations this should be irrelevant (I've seen a number of SOHO routers that couldn't handle typical L2TP/IPsec connections despite that UDP encapsulation — but that's another story).

Before we can start sending ESP packets, we need to establish a "connection" (security association) though. In practice, most IPsec connections are negotiated via the IKE protocol rather than statically configured, and that's where IKE issues come into play.

IKE and pre-shared keys

To begin with, original IKE was specified to use UDP/500 for both source and destination port. Since NAT may change the source port, the specification had to be adjusted to allow other source ports. Even more issues arise when there are multiple clients behind NAT and traffic has to be multiplexed, but we'll limit the discussion to 1:1 NAT where canonical IKE might work. Let's assume the IKE exchange has gone that far.

The vast majority of IPsec setups in the wild use pre-shared keys. I've configured connections to vendors and partners on behalf of my employers and customers countless times, and I believe I've seen an x.509-based setup once or twice. In a setup with pre-shared keys, routers need to know which keys to use for which peers. How do they know? Suppose you've configured a tunnel with peer 192.0.2.10 and key "qwerty". The other side has 172.16.0.1 address NATed to 192.0.2.10. Will it be the source address of the peer that will be used for the key lookup? Not quite.

In the IKE/ISAKMP exchange, there are identifiers. It's the pairs of identifiers and pre-shared keys that must be unique to reliably tell one peer from another and use correct keys for every peer. There are several types of identifiers specified by the ISAKMP protocol: IP (v4 or v6) address, subnet, FQDN, user and FQDN pair (user@example.com), and raw byte string.

By default, most implementations (including StrongSWAN in VyOS) will use the IP address of the outgoing interface for the identifier, and it will be embedded in the IKE packet. If the host is behind NAT, that address is a private address, 172.16.0.1. When the packet passes through the NAT, the payload will obviously remain unchanged, and when it arrives, the responder will try to find the pair of 172.16.0.1:qwerty in its configuration rather than 192.0.2.1:qwerty that is has configured, and will send NO_PROPOSAL_CHOSEN to the NATed peer.

The solutions

So, how do you get around those issues? Whether IKE is configured to use NAT detection or not, you'll get to use peer identification methods that do not rely on known and fixed IP addresses.

The simplest approach is to use a manually configured peer identifier. This approach will work when one side is NATed and the other is not. The only thing you need to remember is that VyOS (right now at least) requires that FQDN identifiers are prepended with the "@" character. They also do not need to match any real domain name of your machine. You also need to set the local-address on the NATed side to "any".

Here's an example:

Non-NATed side

vpn {

  ipsec {

    site-to-site {

       peer @foo {

         authentication {

             mode pre-shared-secret

             pre-shared-secret qwerty

         }

         default-esp-group Foo

         ike-group Foo

         local-address 203.0.113.1

         tunnel 1 {

             local {

                 prefix 10.103.0.0/24

             }

             remote {

                 prefix 10.104.0.0/24

             }

         }

     }

 }

NATed side

  ipsec {

    site-to-site {

         peer 203.0.113.1 {

             authentication {

                 id @foo

                 mode pre-shared-secret

                 pre-shared-secret qwerty

             }

             default-esp-group Foo

             ike-group Foo

             local-address any

             tunnel 1 {

                 local {

                     prefix 10.104.0.0/24

                 }

                 remote {

                     prefix 10.103.0.0/24

                 }

             }

         }

     }

 }