3

I have a server with a static IP and a client which is located in my local network at home. What I am trying to achieve is a vpn connection between these two (might add more clients later though). I don't need to be able to connect to the internet through the vpn server, just the direct connection.

The server is running Ubuntu 18.04 LTS, but I cannot use the wireguard kernel module, because the server is an OpenVZ virtual server and therefore does not allow modifications to the kernel. So I'm using wireguard-go instead on the server. See my earlier post for the discussion on that matter.

The server is configured with

[Interface]
PrivateKey = ...
ListenPort = 51944

[Peer]
PublicKey = ...
AllowedIPs = 192.168.177.5/32

and

sudo ip addr add 192.168.177.4/32 dev wg0

to set its IP address.

The client (also Ubuntu 18.04 LTS) is configured with

[Interface]
PrivateKey = ...
Address = 192.168.177.5/32

[Peer]
PublicKey = ...
AllowedIPs = 192.168.177.4/32
Endpoint = [static IP of my server]:51944
PersistentKeepalive = 25

and started with

sudo wg-quick up wg0

In the output from sudo wg of both, server and client, I can see that the handshake works. But trying to ping either way makes the comment prompt wait forever.

Does anyone have I an idea what the problem might be?

NoThanks93330
  • 33
  • 1
  • 2
  • 4
  • I've got [an Ansible role](https://galaxy.ansible.com/consensus/wireguard_cloud_gateway) that does all of this for you (except the non-kernel-modification stuff). – colan Apr 02 '21 at 16:49

1 Answers1

2

The issue appears to be a missing route both on client and on server, rather than a WireGuard problem.

When the server is given 192.168.177.4/32 there's no provision for the route to 192.168.177.5/32. For the standard routing part, in case of doubt, run a command to ask the kernel where the route goes. For example on server:

ip route get 192.168.177.5

If it doesn't give the WireGuard interface in the answer, that means the route won't use it (and there won't be any traffic in the tunnel).

Among possible choices:

  • add the missing route

    sudo ip route add 192.168.177.5/32 dev wg0

  • add the address differently so an automatic route is included and will be added by the kernel

    • with a peer address

      sudo ip address add 192.168.177.4 peer 192.168.177.5/32 dev wg0

    • or else at least a /31 (in order to have 192.168.177.5 included in the route). A /24 would be fine too

      sudo ip address add 192.168.177.4/31 dev wg0

  • or simply add the address to the configuration, as /31 since it's the simplest, or anything larger, such as a /24. Server and client have an equivalent role, there's no reason to configure their address using a different method.

    Address = 192.168.177.4/31

Likewise, correct the client configuration:

Address = 192.168.177.5/31

Both standard routing and WireGuard's cryptokey routing (selected with AllowedIPs, which are correct for this setting here) must be correct for a working result. If you add more peers, you'll likely have to use a wider route, but keep the stricter AllowedIPs settings, as cryptokey routing requires.

A.B
  • 31,762
  • 2
  • 62
  • 101
  • Ok, `ip route get 192.168.177.4` on the client gives me `192.168.177.4 dev wg0 src 192.168.177.5 uid 0`, so this is finde because it contains `wg0`, right? `ip route get 192.168.177.5` on the server gives me `192.168.177.5 dev venet0 src [static IP of the server]`, which must be the problem then. Unfortunately when trying `sudo ip route add 192.168.177.5/32 dev wg0` I get the error `RTNETLINK answers: Network is down`. And `sudo ip address add 192.168.177.4 peer 192.168.177.5/32 dev wg0` doesn't raise an error but also does not change the output of `ip route get 192.168.177.5` – NoThanks93330 Dec 29 '20 at 01:43
  • Nevermind. An additional `sudo ip link set wg0 up` on the server solved it. Now ping works perfectly in both directions. Thanks a lot! – NoThanks93330 Dec 29 '20 at 02:54