Hit-or-miss Wireguard connectivity on a public WiFi ... can MTU size play a role?

[darksky]

I am experiencing hit-or-miss connectivity through wireguard when connected to a specific, unsecured, public WiFi from iOS devices. Meaning, I first connect to the public WiFi at which point, wireless works fine, websites load, etc. but when I subsequently initiate a wireguard connection, most of the time, the traffic flows stops due to a connectivity issue. If I fiddle with toggling the WG connection off then on several times, it eventually works.

This is true for:

1. my OW home router running wireguard
2. a totally separate OW router running wireugard
3. a commercial VPN provider also running wireguard

The fact that the the issue is present on all VPN providers (my own and a commercial VPN), is suggestive that something on the public WiFi to which I am connected is misconfigured or their hardware is just flaky, etc.

In googling, some suggestions about lowering the MTU value to improve stability are mentioned. I tried lowering the MTU size on the interface to 1440 and then again to 1280 but neither made a difference. Wondering if more experienced people here have some suggestions or thoughts.

For reference, relevant bit of /etc/config/network:

config interface 'wg0'
  option proto 'wireguard'
  option listen_port '4500'
  list addresses '10.200.200.200/24'
  option private_key 'xxx'
  option delegate '0'
  option mtu '1440'

...

For reference, here is what I see in the iOS wireguard logs:

wireguard logs

[NET] peer(UDe2…Jcno) - Retrying handshake because we stopped hearing
back after 15 seconds
[NET] peer(UDe2…Jcno) - Sending handshake initiation
[NET] peer(UDe2…Jcno) - Handshake did not complete after 5 seconds,
retrying (try 2)
[NET] peer(UDe2…Jcno) - Sending handshake initiation
[NET] Network change detected with unsatisfied route and interface
order [en0, utun2, pdp_ip0]
[NET] DNS64: mapped 75.xxx.xxx.xxx to itself.
[NET] UAPI: Transition to peer configuration
[NET] peer(UDe2…Jcno) - UAPI: Updating endpoint
[NET] Routine: receive incoming IPv4 - stopped
[NET] Routine: receive incoming IPv6 - stopped
[NET] Routine: receive incoming IPv4 - started
[NET] Routine: receive incoming IPv6 - started
[NET] UDP bind has been updated
[NET] peer(UDe2…Jcno) - Sending keepalive packet
NET] peer(UDe2…Jcno) - Failed to send data packet write udp4
0.0.0.0:49729->75.xxx.xxx.xxx:51820: sendto: network is unreachable

[darksky]

Turns out the owner of the public WiFi was actively blocking wg's handshake thus preventing the initial connection. This strategy works for blocking new WireGuard connections but it is harmless to existing connections. Therefore, to use WireGuard on such a network, simply connect to the WireGuard peer before joining the public WiFi (for example using cellular) thus allowing the handshake to take place before the active blocking can occur.