On Fri, May 13, 2022 at 11:10:41PM +0200, n18fu...@tutanota.com wrote: > Hi, > > I've set up an OpenBSD server on the Cloud, set up a Wireguard tunnel, and > configured default route through that server. I've noticed that I can't > access some websites: my browser was not able to complete TLS handshakes > with some servers. I've traced the issue to the fact that the MTU on my > server's network interface is 1500 while the default MTU on a wg0 > interface is 1420. So when a large enough packet has a DF flag set it > would not make it through the smaller wg0 interface. I've fixed the > problem by adding a "scrub" option to server's pf.conf like this: > > match out on egress from (wg0:network) nat-to (egress:0) scrub (no-df > random-id) > > But I'm surprised that I did not see anyone mentioning this problem. I > also did not see that "scrub" option included in any examples of Wireguard > setup that I was able to find. > > I'm not a networking expert, so I wonder if using a "scrub" option like > that is a good idea.
Seems like ICMP responses are being dropped. In such cases the proper solution is fix whatever is filtering out ICMP responses. However, according to https://github.com/QubesOS/qubes-issues/issues/5264#issuecomment-683177300 Wireguard deliberately drops ICMP responses to its UDP transport packets. If this is the case in your situation, the better solution might be to drop the MTU on the Wireguard interfaces so oversized packets are rejected before they're encapsulated. A common fail-safe MTU for VPN interfaces is 1300 or 1280. Another alternative might be to switch to IPSec+IKEv2. If there's no NAT between your tunnel endpoints, it won't need to use UDP encapsulation, so packet overhead would be smaller. But even with NAT traversal, OpenBSD's iked might handle things better (e.g. permitting fragmentation of its UDP packet, or mirroring ICMP responses), though I don't know specifically if this would the case.
