To quote the homepage:
WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPSec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it plans to be cross-platform and widely deployable. It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.
Example configuration for dn42
Wireguard is a Layer3 VPN. In theory it allows multiple peers to be served with one interface/port, but it does internal routing based on the peer's public key. This means you will need one interface per peering on dn42 to allow your BGP daemon instead to do routing. This approach is comparable to OpenVPN p2p tunnels.
First generate on each peer public and private keys.
$ wg genkey | tee privatekey | wg pubkey > publickey
# tunnel.conf [Interface] PrivateKey = <private_key> ListenPort = <YOUR_LOCAL_UDP_PORT> [Peer] PublicKey = <public_key_of_your_peer> # OPTIONAL, its also possible to define a pre-shared key for additional security PresharedKey = <pre-shared key> # at least one peer needs to provide this one Endpoint = <end_point_hostname_or_ip:port> # in theory this could be restricted to dn42 networks, # however it is easier to do this with iptables/bgp filters/routing table # instead just like for openvpn-based peerings AllowedIPs = 0.0.0.0/0,::/0
Wireguard comes with its own interface type. It supports link-local addresses for IPv6 and single /32 addresses for IPv4, which can be used for peering.
$ ip link add dev <interface_name> type wireguard $ wg setconf <interface_name> tunnel.conf # both side pick a different link-local ipv6 address $ ip addr add fe80::<some_random_suffix>/64 dev <interface_name> # choose the first ip from your subnet and the second one from the peer $ ip addr add 172.xx.xx.xx/32 peer 172.xx.xx.xx/32 dev <interface_name> $ ip link set <interface_name> up
Maybe you should check the MTU to your peer with e.g.
ping -s 1472 <end_point_hostname_or_ip>. If your output looks like
From gateway.local (192.168.0.1) icmp_seq=1 Frag needed and DF set (mtu = 1440) substract
80 from the MTU and set it via
ip link set dev <interface_name> mtu <calculated_mtu>
(For older iputils, use
Afterwards configure your BGP session as usual
The wireguard kernel module on linux has support for enabling dynamic debugging. This can be useful to help track down some problems, e.g. if public keys don't match.
Debug messages are logged via dmesg and can be enabled using:
$ echo 'module wireguard +p' > /sys/kernel/debug/dynamic_debug/control
To disable debug:
$ echo 'module wireguard -p' > /sys/kernel/debug/dynamic_debug/control
wg-quick is a script that is shipped with Wireguard to help users bring up tunnels in some common use cases.
It is designed for users with simple needs, and users with more advanced needs are highly encouraged to use a more specific tool, a more complete network manager, or otherwise just use wg(8) and ip(8), as usual.
The script makes some changes that are not valid when used for DN42 tunnels, and which must be worked around:
By default, the script will add a routing policy that routes the 'AllowedIP' ranges through the tunnel. In DN42, route selection is managed by BGP so the routing policy must be removed to avoid problems. This is achieved by adding the 'Table = off' directive.
- Warning: a common pattern for DN42 tunnels is to use
AllowedIPs = 0.0.0.0/0or
AllowedIPs = ::/0then use firewall rules to limit source and destination addresses. If you do not add 'Table = off' this could cause you to route clearnet traffic via your peer and potentially lose connectivity to your node!
- Warning: a common pattern for DN42 tunnels is to use
It is common in DN42 to use Point-to-Point addressing schemes on tunnel interfaces (that is, using IPv4/32 and IPv6/128 addresses); this is not supported by wg-quick. To configure PTP addresses you must add a 'PostUp' statement that first removes the addresses that wg-quick has configured and then re-add them. On Linux, this will typically be done using
An example wg-quick script that incorporates the above two workarounds is below, where
<MyIPv> are the DN42 IP addresses of your node and
<PeerIPv> are the IP addresses for your peer.
[Interface] PrivateKey = <your private key> Address = <MyIPv4>/32, <MyIPv6>/128 PostUp = /sbin/ip addr del dev wg0 <MyIPv4>/32 && /sbin/ip addr add dev wg0 <MyIPv4>/32 peer <PeerIPv4>/32 PostUp = /sbin/ip addr del dev wg0 <MyIPv6>/128 && /sbin/ip addr add dev wg0 <MyIPv6>/128 peer <PeerIPv6>/128 Table = off [Peer] Endpoint = <your peer's wireguard endpoint> PublicKey = <your peer's public key> AllowedIPs = 172.16.0.0/12, 10.0.0.0/8, fd00::/8, fe80::/10
which ipto get the full path to your ip binary.
Example configuration for systemd-networkd.
[NetDev] Name=<ifname> Kind=wireguard [WireGuard] PrivateKey=<your private key> ListenPort=<your listen port> [WireGuardPeer] PublicKey=<peer public key> # OPTIONAL, pre-shared key PresharedKey=<pre-shared key> Endpoint=<peer host and port, e.g. 126.96.36.199:9876> AllowedIPs=fe80::/64 AllowedIPs=fd00::/8 AllowedIPs=0.0.0.0/0
[Match] Name=<ifname> [Network] DHCP=no IPv6AcceptRA=false IPForward=yes # for networkd >= 244 KeepConfiguration stops networkd from # removing routes on this interface when restarting KeepConfiguration=yes # for networkd < 244 the CriticalConnection parameter achieves # the same thing [DHCP] CriticalConnection=true # if using link local addresses for peering [Address] Address=fe80::xx:xx:xx:xx/64 # if using IPv6 point to point [Address] Address=<your ipv6 address>/128 Peer=<your peer's IPv6 address>/128 # IPv4 point to point [Address] Address=<your IPv4 address>/32 Peer=<your peer's IPv4 address>/32