Issues starting Wireguard connection on Mac and iOS

[Mighty Guava]

Hi all,

I’ve been having issues with the iOS (iPhone 12) and Mac (MacBook M1)
clients for Wireguard when starting a connection. It usually takes
several attempts to start a connection. Specifically, one of the
following things occur when activating Wireguard:

* It shows “Data sent: 148b”, incrementing a small amount every 5
seconds-ish with nothing showing for Data Received.
* It shows “Data received: 96b” incrementing a small amount every 5
seconds, while “Data sent” is going up by about 20MB/s every second,
effectively saturating my uplink. Statistics on my router does show
the data actually going somewhere. Wireguard logs on the peer it’s
connecting to though do not show anything unusual.

In both cases, the connection isn’t actually successful, and I am
unable to access vpn network. The connection is successful for me
about 1 out of 5 times, though it’s not deterministic.

I’ve had no issues connecting from an Android client. It succeeds
every time. When my Mac or iOS clients succeed in making a connection,
I also see no problems.

The same issue occurs when connecting to 3 completely different peers
from the Mac/iOS device: 1 running Raspberry Pi OS (Debian based), 1
running weejewel/wg-easy Docker container, 1 running on an Asus
RT-AX86U Router using their software. All wireguard packages up to
date.

I’ve tried upping MTU to 1500 and shortening keep alive but neither successful.

There’s a serverfault topic for this issue as well (not created by me)
with several people reporting similar experiences.
https://serverfault.com/questions/1129770/wireguard-clients-need-to-make-many-attempts-to-connect-before-receiving-data

Client config below:

[Interface]
PrivateKey = <pub key>
Address = 10.6.0.3/32

[Peer]
PublicKey = <pub key>
AllowedIPs = 0.0.0.0/0
Endpoint = <server address>
PersistentKeepalive = 25

DNS is pointed to an internal DNS server on my intranet. I've tried
removing it to not override DNS, but it does not seem to have an
impact.

Hoping someone on this list has leads on how I might be able to fix this.

Thanks,
Yunchi