VPN

What does WireGuard AllowedIPs actually do?

Wireguard’s allowed_ips field does two different things. Let’s consider the following WireGuard config (generated by the WireguardConfig Site2Site example):

[Interface]
# Name = office1.mydomain.org
PrivateKey = ......
Address = 10.82.85.1/24
ListenPort = 19628

[Peer]
# Name = office2.mydomain.org
PublicKey = ...
AllowedIPs = 10.82.85.2/32, 192.168.200.0/24
PersistentKeepalive = 60

We can see that for the peer office2.mydomain.org the AllowedIPs field is set to 10.82.85.2/32, 192.168.200.0/24.

AllowedIPs does two things:

  • It adds a route to the given networks, i.e. packets addressed to 10.82.85.2/32 or to 192.168.200.0/24 will be routed through the WireGuard interface to that peer
  • It will allow packets with the source IPs 10.82.85.2/32 or 192.168.200.0/24 to be routed from the given peer on the WireGuard interface

Note especially the second point. Any packet from the given peer with a source IP address which is not listed in AllowedIPs will be discarded! While this does not replace a firewall, it serves a an integral part of Wireguard’s security model.

Posted by Uli Köhler in VPN, Wireguard

How to migrate from OpenVPN to Wireguard for Site-to-Site VPNs

The following diagram will assist you in transitioning your VPNs from OpenVPN to Wireguard.

Many users have difficulties in grasping the allowed_ips concept, even though it’s mostly similar to OpenVPN’s route and the architecture where no. In most usecases, you can consider any WireGuard instance with ListenPort = ... to be a server and any WireGuard instance with Endpoint = ... defined for a given peer as client.

Diagram source

The WireGuard config is available as WireguardConfig example Site2Site.json

Posted by Uli Köhler in OpenVPN, VPN, Wireguard

Real-world data on CRS309-1G-8S+ RouterOS Wireguard throughput

Also see Wireguard bandwidth performance of the MikroTik CRS326-24G-2S+

We tested the throughput of the new Wireguard functionality MikroTik CRS309-1G-8S+ running on RouterOS 7.1beta6.

Our test setup consists of a Desktop PC with 1GBase-T connection and a virtualized server on XCP-NG, attached with a 10GB shared connection, both running Ubuntu. Note that the L2 switching infrastructure (consisting only of MikroTik CRS3xx and CRS610 switching with complete hardware offloading) is ignored here because due to 100% hardware offloading to the marvelous Marvell switch chips it has orders of magnitude higher performance compared to any L3 function, hence it will only have minimal impact only the overall performance.

Wireguard was being used without preshared keys. Hitherto, it is unknown to us whether PSKs will have an impact on throughput.

The command on the Desktop was

dd if=/dev/urandom bs=100M | netcat -v 10.185.244.199 2222

whereas the command on the server was

netcat -vvnlp 2222 > /dev/null

As we expected with an uncompressed protocol like Wireguard, there is no difference if you pipe the data from /dev/urandom as opposed to /dev/zero.

Scenario: Routing from Wireguard to local routed VLAN

With IP firewall

The Desktop was connected to the CRS309-1G-8S+ using Wireguard. The virtual server was connected to the CRS309 as default gateway within a separate VLAN that was designed to be routed. The CRS309 L3 hardware offloading capability was disabled.

The IP firewall contained 8 simple accept and fasttrack rules. All the WireGuard traffic only matched the last (8th) rule and was accepted. It has not been tested whether fasttracking the Wireguard connection would increase performance

The throughput results showed a steady rate of 131 Mbit/s (unidirectional, bidirectional not tested), but up to 160 Mbit/s. It is unknown what caused the increase in speed, but it’s possible that additional traffic was L3-forwarded over the switch during the test.

Without IP firewall

The same test was repeated with the IP firewall being disabled in the Bridge Settings.

As expected, disabling additional IP firewall processing caused the throughput to increase, but only by a small margin. The typical speed was around 160 Mbit/s (unidirectional), with peaks up to 185 Mbit/s.

Conclusion

It should be pretty obvious that the CRS309-1G-S+ outperforms most conventional VPN solutions when using Wireguard. For a street price of ~175€, it is not only an awesome switch, but also doubles as a more than adequate Wireguard router for most practical applications.

Reliablity considerations

Note that at the moment of writing this article, Wireguard is only available in the RouterOS 7.1beta6 firmware, which is not yet considered stable. While I have not experienced any problems that have affected reliability in any way, if you run a network where it hurts if it fails, you should consider using alternative solutions in the meantime.

Posted by Uli Köhler in MikroTik, Networking, VPN, Wireguard

Wireguard bandwidth performance of the MikroTik CRS326-24G-2S+

Also see Real-world data on CRS309-1G-8S+ RouterOS Wireguard throughput

We tested the new Wireguard functionality MikroTik CRS326-24G-2S+ running on RouterOS 7.1beta6.

Our test setup consists of a Desktop PC with 1GBase-T connection and a virtualized server on XCP-NG, attached with a 10GB shared connection, both running Ubuntu. Note that the L2 switching infrastructure (consisting only of MikroTik CRS3xx and CRS610 switching with complete hardware offloading) is ignored here because due to 100% hardware offloading to the marvelous Marvell switch chips it has orders of magnitude higher performance compared to any L3 function, hence it will only have minimal impact only the overall performance.

Wireguard was being used without preshared keys. Hitherto, it is unknown to us whether PSKs will have an impact on throughput.

Scenario: Routing between two wireguard VPNs

Both the Desktop and the server were connected to two different Wireguard interfaces on the CRS326-24G-2S+.

The CRS326 routed between those interfaces. The virtualized server ran a netcat server while the Desktop ran the wireguard client. IP firewall was disabled during this test, but the switch still had to L3 forward the packets.

Throughput results

The effective throughput of L3 forwarding, doing one Wireguard decryption and one WireGuard encryption operation (both without PSK) is 108.1 Mbit/s (unidirectional. Bidirectional has not been tested)

This is an awesome result, considering that the CRS326-24G-2S+ is only ~120€ street price and is an awesome switch. But it seems like Wireguard is capable of making a high performance VPN router from just a managed MikroTik switch.

Reliablity considerations

Note that at the moment of writing this article, Wireguard is only available in the RouterOS 7.1beta6 firmware, which is not yet considered stable. While I have not experienced any problems that have affected reliability in any way, if you run a network where it hurts if it fails, you should consider using alternative solutions in the meantime.

Posted by Uli Köhler in MikroTik, Networking, VPN, Wireguard

Best practice for installing & autostarting OpenVPN client/server configurations on Ubuntu

This post details my systemd-based setup for installing and activating OpenVPN client or server configs on Ubuntu. It might also work for other Linux distributions that are based on systemd..

First, place the OpenVPN config (usually a .ovpn file, but it can also be a .conf file) in /etc/openvpnYou need to change the filename extension to .conf.ovpn won’t work. Furthermore, ensure that there are no spaces in the filename.

In this example, our original OpenVPN config will be called techoverflow.ovpn, hence it needs to be copied to /etc/openvpn/techoverflow.conf!

Now we can enable (i.e. autostart on boot – but not start immediately) the config using

sudo systemctl enable [email protected]

For techoverflow.conf you need to systemctl enable[email protected] whereas for a hypothetical foo.conf you would need to systemctl enable [email protected].

Now we can start the VPN config – i.e. run it immediately using

sudo systemctl start [email protected]

Now your VPN client or server is running – or is it? We shall check the logs using

journalctl -xfu [email protected]

In order to manually restart the VPN client or server use

sudo systemctl restart [email protected]

and similarly run this to stop the VPN client or server:

sudo systemctl stop [email protected]

In order to show if the instance is running – i.e. show its status, use

sudo systemctl status [email protected]

Example output for an OpenVPN client:

[email protected] - OpenVPN connection to techoverflow
     Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-11-29 03:37:52 CET; 953ms ago
       Docs: man:openvpn(8)
             https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
             https://community.openvpn.net/openvpn/wiki/HOWTO
   Main PID: 4123809 (openvpn)
     Status: "Pre-connection initialization successful"
      Tasks: 1 (limit: 18689)
     Memory: 1.3M
     CGroup: /system.slice/system-openvpn.slice/[email protected]
             └─4123809 /usr/sbin/openvpn --daemon ovpn-techoverflow --status /run/openvpn/techoverflow.status 10 --cd /etc/openvpn --script-security 2 --config /etc/ope>

Nov 29 03:37:52 localgrid systemd[1]: Starting OpenVPN connection to techoverflow...
Nov 29 03:37:52 localgrid ovpn-techoverflow[4123809]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep >
Nov 29 03:37:52 localgrid ovpn-techoverflow[4123809]: library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Nov 29 03:37:52 localgrid systemd[1]: Started OpenVPN connection to techoverflow.
Nov 29 03:37:52 localgrid ovpn-techoverflow[4123809]: TCP/UDP: Preserving recently used remote address: [AF_INET]83.135.163.227:19011
Nov 29 03:37:52 localgrid ovpn-techoverflow[4123809]: UDPv4 link local (bound): [AF_INET][undef]:1194
Nov 29 03:37:52 localgrid ovpn-techoverflow[4123809]: UDPv4 link remote: [AF_INET]83.135.163.22:19011
Nov 29 03:37:53 localgrid ovpn-techoverflow[4123809]: [nas-vpn.haar.techoverflow.net] Peer Connection Initiated with [AF_INET]83.135.163.227:19011

 

Posted by Uli Köhler in Linux, VPN

How to fix OpenVPN “TLS Error: cannot locate HMAC in incoming packet from …”

Problem:

Your OpenVPN clients can’t connect to your OpenVPN server and the server log shows an error message like

TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:187.100.14.13:41874 (via ::ffff:25.16.25.29%xn0)

Solution:

You have enabled a TLS key (tls-auth option) in your OpenVPN configuration, but your client does not know that it should use the additional layer of authentication.

The server is looking for the HMAC in the incoming packets but can’t find it.

Either disable the tls-auth option in your server config. The config line will look like

tls-auth /var/etc/openvpn/server2.tls-auth 0

or

Enable the correct tls-auth configuration in your client. Remember that you also need to share the correct key.

Posted by Uli Köhler in Networking, OpenVPN, VPN