Wireguard setup

#42

To connect two Omnias (site-to-site) you can just use masquerading (for the WireGuard interface) and putting the relevant subnets into the allowed IP configuration for the two “peers” (the two Omnias).

This is similar to the configuration I have set up. It assumes that the WireGuard interface is wg0.

# Peer 1
config wireguard_wg0
        option public_key 'public_key_of_peer_2'
        list allowed_ips 'VPN_IP_OF_PEER2/32'
        # example subnet served by peer 2
        list allowed_ips '192.168.40.0/24'
        option route_allowed_ips '1'
        option endpoint_host 'endpoint_ip'

And for peer 2

# Peer 2
config wireguard_wg0
        option public_key 'public_key_of_peer_1'
        list allowed_ips 'VPN_IP_OF_PEER1/32'
        # example subnet served by peer 1
        list allowed_ips '192.168.30.0/24'
        option route_allowed_ips '1'
        option endpoint_host 'endpoint_ip'

Of course you need to make sure that the WireGuard interface is properly masqueraded.

#43

Did you ever experience that a connection was not up/working any more after some time?

root@TO1:~# wg show
peer: <public key of TO2>
  preshared key: (hidden)
  endpoint: <public IP TO2 more than 4 days ago>:27
  allowed ips: 192.168.3.0/24, 192.168.1.2/32
  latest handshake: 4 days, 17 hours, 24 minutes, 48 seconds ago
  transfer: 30.95 MiB received, 13.39 MiB sent
  persistent keepalive: every 25 seconds

Directly accessing the second TO via mobile WG-app works seamlessly and restarting wg interface on TO1 also restores the wg connection. Is there some sort of log-files one could examine?

#44

the wireguard kernel module is reporting via dmesg and shows in the syslog, hence if the module fails it would show there.

As for the connection it is being managed by netifd and its reports are also showing in syslog, however only events such as up or down. Stale wg connectivity (handshakes) are not reported anywhere in logs though, afaik.

Yes, but only if connectivity to that node was lost, which the stale handshake indicates. Afaik the handshake refreshes every 120 sec.

#45

Ok, then my case seems weird… Maybe a bug?
Will look into the logs somewhen this weekend.

#46

From what you posted earlier it would appear that wg on the TO2 node became inaccessible to to wg on the TO1 node some 4 days, 17 hours, 22 minutes, 48 seconds earlier (at that time).
Which could be a variety of reason, routing, firewall, physical connectivity.

that would likely have invoked a reload of the firewall and refresh of routing on the TO1 node.

If your node is on TOS3.x then netifd (the network management component) is outdated and buggy and might cause the issue, but that is rather speculative to assume.

#47

That is not true unless you configure it, up to my knowledge. In default wireguard won’t send keep-alive like packets so routers on the way can drop udp connection from tracked ones. Note that where tcp standardize this time in nat, udp does not. This means that real time is up to nat configuration and load and there is no magical constant that works everywhere. In case of my isp it became stable only with 30sec renewal. You have to play with that time.

#48

I got the same persistent keepalive: every 25 seconds as the OP and since ever I use wg the latest handshake does not exceed 120 seconds, unless the connectivity turns stale with the remote node turns stale.

And of course you are correct

A handshake initiation is retried after REKEY_TIMEOUT + jitter ms, if a response has not been received, where jitter is some random value between 0 and 333 ms.
If we have sent a packet to a given peer but have not received a packet after from that peer for (KEEPALIVE + REKEY_TIMEOUT) ms, we initiate a new handshake.

#49

That’s just what I configured - so my case should never happen by design - because if connection is dropped both wg if should try to reestablish connection for ever or until they succeed, right?
Edit: as a addition - both wg if were accessible before I restarted wg if on TO1 (tested with mobile phone), so it shouldn’t be a routing or firewall issue…

#50

From you reported it seems that the nodes lost physical connectivity with each other at some point and it was not re-established.

it is not likely but there could be other factors/apps on the router that could come into play, like I mentioned earlier the buggy netifd on TOS3.x.

Suppose the only way to debug the issue is monitoring the wg connectivity, see if there is a potential pattern if it happens repeatedly. Perhaps you could also

and see whether it makes an impact.

Worst case, if the issue persists, is to run a tcpdump on the wg iface(s). But that should be fine tuned with the options available to tcpdump in order to mitigate the size of the dump when running it unattended over a prolonged period.