No internet connection if Wireguard active

Software SW help
1

Originally, I used to connect to my router via the OpenVPN provided by Forris. Unfortunately, a few months ago this broke and even after reinstalling the firmware I couldn’t make it work. So I abandond that solution and tried the tutorial for Wireguard instead.

The setup was quite easy and my clients are happily connecting to the router over Wireguard. The only porblem: Once connceted, I loose all internet connectivity on the client or to be more precise, websites take endless to load, pinging doesn’t work at all. I tried already to change the DNS server to 1.1.1.1 and verified my firewall setup but I couldn’t figure out the problem which is why I would like to ask here for insights.

Following the output of wg show:

interface: wg0
  public key: GZPtM3mYWNjzLV+ko8bAWoxE1Lvd24DU8FIAz9knqyw=
  private key: (hidden)
  listening port: 1234

peer: PrbKll3uiHQaMiuXyg17NFUiDIq21HvbSvfUMVl+/ho=
  preshared key: (hidden)
  endpoint: 192.168.1.111:58299
  allowed ips: (none)
  latest handshake: 30 seconds ago
  transfer: 572 B received, 8.97 KiB sent
  persistent keepalive: every 25 seconds

And here the client log output:

2019-07-04 19:09:00.708910: [APP] startActivation: Entering (tunnel: Turris Omnia)
2019-07-04 19:09:00.709873: [APP] startActivation: Starting tunnel
2019-07-04 19:09:00.710675: [APP] startActivation: Success
2019-07-04 19:09:00.714439: [APP] Tunnel 'Turris Omnia' connection status changed to 'connecting'
2019-07-04 19:09:00.897840: [NET] App version: 0.0.20190610 (13); Go backend version: 0.0.20190517
2019-07-04 19:09:00.898314: [NET] Starting tunnel from the app
2019-07-04 19:09:00.993114: [NET] Tunnel interface is utun2
2019-07-04 19:09:00.993874: [NET] Attaching to interface
2019-07-04 19:09:00.994927: [NET] Routine: handshake worker - started
2019-07-04 19:09:00.995115: [NET] Routine: decryption worker - started
2019-07-04 19:09:00.995213: [NET] Routine: decryption worker - started
2019-07-04 19:09:00.995384: [NET] Routine: encryption worker - started
2019-07-04 19:09:00.995472: [NET] Routine: decryption worker - started
2019-07-04 19:09:00.995675: [NET] Routine: handshake worker - started
2019-07-04 19:09:00.995848: [NET] Routine: encryption worker - started
2019-07-04 19:09:00.996037: [NET] Routine: encryption worker - started
2019-07-04 19:09:00.996172: [NET] Routine: event worker - started
2019-07-04 19:09:00.996271: [NET] Routine: TUN reader - started
2019-07-04 19:09:00.996449: [NET] Routine: handshake worker - started
2019-07-04 19:09:00.996541: [NET] Routine: decryption worker - started
2019-07-04 19:09:00.996666: [NET] Routine: encryption worker - started
2019-07-04 19:09:00.996786: [NET] Routine: handshake worker - started
2019-07-04 19:09:00.996975: [NET] UAPI: Updating private key
2019-07-04 19:09:00.997181: [NET] UAPI: Removing all peers
2019-07-04 19:09:00.997271: [NET] UAPI: Transition to peer configuration
2019-07-04 19:09:00.997636: [NET] peer(GZPt…nqyw) - UAPI: Created
2019-07-04 19:09:00.997751: [NET] peer(GZPt…nqyw) - UAPI: Updating preshared key
2019-07-04 19:09:00.997878: [NET] peer(GZPt…nqyw) - UAPI: Updating endpoint
2019-07-04 19:09:00.998045: [NET] peer(GZPt…nqyw) - UAPI: Updating persistent keepalive interval
2019-07-04 19:09:00.998135: [NET] peer(GZPt…nqyw) - UAPI: Removing all allowedips
2019-07-04 19:09:00.998267: [NET] peer(GZPt…nqyw) - UAPI: Adding allowedip
2019-07-04 19:09:00.998844: [NET] Routine: receive incoming IPv4 - started
2019-07-04 19:09:00.998981: [NET] Routine: receive incoming IPv6 - started
2019-07-04 19:09:00.999092: [NET] UDP bind has been updated
2019-07-04 19:09:00.999204: [NET] peer(GZPt…nqyw) - Starting...
2019-07-04 19:09:00.999422: [NET] peer(GZPt…nqyw) - Routine: sequential receiver - started
2019-07-04 19:09:00.999521: [NET] peer(GZPt…nqyw) - Routine: nonce worker - started
2019-07-04 19:09:00.999656: [NET] peer(GZPt…nqyw) - Routine: sequential sender - started
2019-07-04 19:09:00.999798: [NET] peer(GZPt…nqyw) - Sending keepalive packet
2019-07-04 19:09:00.999898: [NET] Device started
2019-07-04 19:09:00.999915: [NET] peer(GZPt…nqyw) - Sending handshake initiation
2019-07-04 19:09:01.000944: [NET] peer(GZPt…nqyw) - Awaiting keypair
2019-07-04 19:09:01.001646: [APP] Tunnel 'Turris Omnia' connection status changed to 'connected'
2019-07-04 19:09:01.074334: [NET] peer(GZPt…nqyw) - Received handshake response
2019-07-04 19:09:01.074505: [NET] peer(GZPt…nqyw) - Obtained awaited keypair
2019-07-04 19:09:01.100630: [NET] peer(GZPt…nqyw) - Receiving keepalive packet
2019-07-04 19:09:05.711688: [APP] Status update notification timeout for tunnel 'Turris Omnia'. Tunnel status is now 'connected'.
2019-07-04 19:09:11.356410: [NET] peer(GZPt…nqyw) - Receiving keepalive packet
2019-07-04 19:09:21.412977: [NET] peer(GZPt…nqyw) - Receiving keepalive packet
2019-07-04 19:09:31.458707: [NET] peer(GZPt…nqyw) - Receiving keepalive packet
2019-07-04 19:09:41.985503: [NET] peer(GZPt…nqyw) - Receiving keepalive packet
2019-07-04 19:09:52.165449: [NET] peer(GZPt…nqyw) - Receiving keepalive packet

All configurations are as described in the tutorial except that I added multiple clients, i.e. have multiple config wireguard_wg0 entries in my /etc/config/network file.

Any help is much appreciated, thanks a lot in advance.

2

could be a potential MTU issue, depending on the router’s upstream connection, e.g. DSL PPPoE. If you haven’t yet you could try enabling MSS clamping and see if it makes a difference.

3

Thanks a lot for your suggestion. Unfortunately, turning MSS clamping on didn’t change anything.

4

all clients are the same OS type? Are sqm-scripts installed/active?

5

Nope, I tried it on macOS as well as iOS devices. And no, I don’t have any sqm-scripts actively running.

6

isn’t the iOS | macOS WG client still in early beta of sorts? If recall correctly there were some issue reports on the WG mailing list concerning those OSs

7

This dos not seem normal. You do not allow any ip.
If you want all peer traffic through wireguard, use 0.0.0.0/0 for allowed ips

MTU is not usually configured correctly via MSS claping.
Try to use
MTU = 1380
for example in the peer and/or the server

Also, you do not need multiple conf files. One with multiple peers is ok.

Edit: use 0.0.0.0/0 for allowed ips in the peer conf and the peer (wg) ip in the server conf

8

You probably know more about this than me. At least both apps are already released on the official stores so I guess they have reached a certain stable state.

9

I just did, wg show now shows the following:

peer: PrbKll3uiHQaMiuXyg17NFUiDIq21HvbSvfUMVl+/ho=
  preshared key: (hidden)
  endpoint: 192.168.1.111:61914
  allowed ips: 0.0.0.0/0
  latest handshake: 2 seconds ago
  transfer: 1.33 KiB received, 12.82 KiB sent
  persistent keepalive: every 25 seconds

But I’m still not able to have any internet connection.

Edit: Actually, setting the list allowed_ips '0.0.0.0/0' for the client in question disables my entire home network requiring me to rollback the changes and restart the router. I assume there seems to be an issue with my /etc/config/network file.

Are you speaning about the wg config? When I tried to add the MTU parameter in the client setting the client refused to save - it seems like it is a parameter currently not understood by the macOS client software.

I did so to have different preshared client secrets.

10

I actually just figured out what the problem was. All my clients had the same IP associated in their client config file:

[Interface]
Address = 10.0.10.X/24
...

As soon as I adapted all client’s config files accordingly, it worked. Seems strange to me, that this was the error as I never connected multiple clients at the same time but I’m glad it is fixed. Thanks a lot for your help anyway.

1 Like