MTU, and beyond static routes
Every tunnel costs some bytes per packet. WireGuard adds its own header plus a new outer IP and UDP header, so VyOS gives wg0 an MTU of 1420 instead of Ethernet's 1500.
Test it from host A with "don't fragment" pings: a 1392-byte payload (1420 bytes with its ICMP and IP headers) gets through, and one byte more gets an immediate Frag needed and DF set (mtu = 1420) from R1. That's path MTU discovery working as it should. TCP connections learn the smaller size from it, and so do most applications.
It breaks when a firewall somewhere drops that ICMP message: large packets vanish while small ones work, the "MTU black hole" from Packets That Never Come Back. The common defence on tunnel routers is to clamp TCP MSS on the tunnel interface (VyOS: set interfaces wireguard wg0 ip adjust-mss clamp-mss-to-pmtu), so TCP never sends segments that won't fit, even if the ICMP gets lost.
Beyond static routes
With more than two sites, or more prefixes, run a routing protocol over the tunnels instead of static routes: OSPF on the wg interfaces, or BGP between tunnel addresses. Two things matter then. First, include the routing protocol's addresses in AllowedIPs (or use 0.0.0.0/0 on point-to-point tunnels where only one peer exists). Second, apply a firewall to the tunnel interface like any other: the far site is another network, not part of yours.
vyos@R1:~$ show interfaces wireguard wg0
wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.255.0.1/30 brd 10.255.0.3 scope global wg0
valid_lft forever preferred_lft forever
inet6 fe80::fd34:acff:fe4d:336f/64 scope link
root@hosta:~# ping -c 1 -M do -s 1392 10.2.0.10
PING 10.2.0.10 (10.2.0.10) 1392(1420) bytes of data.
1400 bytes from 10.2.0.10: icmp_seq=1 ttl=62 time=4.90 ms
--- 10.2.0.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.900/4.900/4.900/0.000 ms
root@hosta:~# ping -c 1 -M do -s 1393 10.2.0.10
PING 10.2.0.10 (10.2.0.10) 1393(1421) bytes of data.
From 10.1.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
--- 10.2.0.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms- Line 2: 1420: Ethernet's 1500 minus WireGuard's overhead.
- Lines 8–9: 1420 bytes fits…
- Line 15: …1421 doesn't, and R1 says so.
Check your understanding
Large file transfers through a tunnel hang while small requests work. What's the best first fix?
- Clamp TCP MSS on the tunnel interface
- Raise the tunnel's MTU to 1500
- Use a different UDP port
- Add more AllowedIPs