Wireguard randomly hangs when the request is originated from a different AppVM

[mmo...@disroot.org]

Hi,

I'm having random issues while on wireguard where request to some sites simply stalls until it times out. If I reload the pages often enough I will finally able to get the response, although this happens randomly, currently I'm able to reproduce this issue in ever few requests. When the request doesn't hangs I've noticed that the loading of some sites like speedtest, github,..etc takes longer than usual (when compared with openvpn or with traffic without any aditional encapsulation).

This only happens when traffic is originated from any AppVM is routed through a NetVM that runs wireguard. When I use openvpn in the same NetVM everything works fine without any timeout or delays. Everything also works perfectly fine on wireguard if the request is originated form the NetVM where wireguard runs. The problem only happens when the NetVM runs wireguard and the traffic is routed from another AppVM.

Based on the packet captures I took, I can see that the TLS handshake for some sites stalls, after the client hello is sent and the connection then hangs until it times out.

I don't know what's tampering with the traffic but it only happens with wireguard and only if traffic is routed from another AppVM to the NetVM that runs wireguard.

Any ideas what might be causing this erratic behavior?

[mmo...@disroot.org]

Well after some more troubleshooting I found the root cause. It seems to be related with the MTU.
Wireguard by default sets its vif with a MTU of 1420 while the other AppVms are using a default MTU of 1500 which causes the hanging and stall in the connection request.

When I set the interfaces of the AppVms to 1420 the problem is solved. However I wonder if it's possible to preserve this change for any AppVm?

Does anyone knows?

Thank you

[Chris Laprise]

On 6/8/19 6:16 PM, mmo...@disroot.org wrote:
> Well after some more troubleshooting I found the root cause. It seems to
> be related with the MTU.
> Wireguard by default sets its vif with a MTU of 1420 while the other
> AppVms are using a default MTU of 1500 which causes the hanging and
> stall in the connection request.
>
> When I set the interfaces of the AppVms to 1420 the problem is solved.
> However I wonder if it's possible to preserve this change for any AppVm?
>
> Does anyone knows?

Search on 'packet fragmentation' here and elsewhere. You should at least
find discussion about openvpn probing the MTU and handling packet
fragmentation. I wonder if this is a case of Wireguard requiring manual
configuration where openvpn does not.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Chris Laprise]

On 6/8/19 6:16 PM, mmo...@disroot.org wrote:

> Well after some more troubleshooting I found the root cause. It seems to
> be related with the MTU.
> Wireguard by default sets its vif with a MTU of 1420 while the other
> AppVms are using a default MTU of 1500 which causes the hanging and
> stall in the connection request.
>
> When I set the interfaces of the AppVms to 1420 the problem is solved.
> However I wonder if it's possible to preserve this change for any AppVm?
>
> Does anyone knows?
>
> Thank you

The old Qubes R3 firewall could run a user script each time a new vif
(downstream vm) was connected to the proxy vm. Finding a similar hook in
R4 would allow you to set the MTU automatically.

Given that wireguard is becoming popular on routers, and Qubes proxy vms
are basically routers, you might find some good tips for dealing with
this around the web.