PostUp = iptables -A FORWARD -i %i -j ACCEPT iptables -t nat -A POSTROUTING -d 10.10.10.0/24 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING ! -d 10.10.10.0/24 -o pia -j MASQUERADE Since it works fine when I'm connected to my home Wi-Fi, I'm at a loss as to what to look for other that port forwarding, but that works fine as far as I can tell. Peer(.) - Handshake did not complete after 5 seconds, retrying (try 2) On my phone, I see the following: peer(.) - Sending handshake initiation Mar 23 17:49:50 wireguard kernel: wireguard: wg0: Keypair 9894 destroyed for peer 16 Mar 23 17:49:50 wireguard kernel: wireguard: wg0: Sending handshake response to peer 16 (:40061) Mar 23 17:49:50 wireguard kernel: wireguard: wg0: Receiving handshake initiation from peer 16 (:40061) Mar 23 17:49:45 wireguard kernel: wireguard: wg0: Keypair 9894 created for peer 16 Mar 23 17:49:45 wireguard kernel: wireguard: wg0: Keypair 9893 destroyed for peer 16 Mar 23 17:49:45 wireguard kernel: wireguard: wg0: Sending handshake response to peer 16 (:40061) Mar 23 17:49:45 wireguard kernel: wireguard: wg0: Receiving handshake initiation from peer 16 (:40061) Here are the logs on my server that appear when I'm trying to connect from my phone (via 4G) Mar 23 17:49:36 wireguard kernel: wireguard: wg0: Keypair 9893 created for peer 16 I've enabled kernel logging for Wireguard to help me troubleshoot this but sadly I haven't been able to find what's wrong with my setup. On my phone, I connect to the VPN using the DNS name (:51820) On my router, I have UDP port 51820 forwarded to my Wireguard server. The problem comes when I disconnect from the Wi-Fi and go on 4G, now my phone is unable to complete the handshake with my server. Hopefully this helps someone get some machines back to functioning somewhat normally.I have a Wireguard server on my home network which works fine on all my devices, including my phone when it's connected on Wi-Fi.

Apple really needs to fix this issue! I have had numerous users with useless computers for the last couple days while we try to fix this issue. Though I have been reading about 1.1.1.1 not working for people also. Seems like there is a bug with have 2 DNS servers and 8.8.8.8 as the secondary. I have found that if I replace the 8.8.8.8 with 1.1.1.1 or 208.67.222.222 (OpenDNS) it immediately fixes the issue, and I can resolve internal DNS as expected again. As soon as I remove the 8.8.8.8 from the DNS settings and leave just our internal DNS, it immediately fixes itself. Any time someone would try to contact an internal URL/Intranet site it would not use our internal DNS server to resolve the name. From our internal DHCP we issue 2 DNS servers (1. I am experiencing the same issue on all our company MacBook's and even some of our iPad's that have updated to Ventura and iPad OS 16. Appreciate some immediate help on this regard. iPads, iPhones, and other devices are working without any such issue.

Wondering how Crome can work without setting manually the DNS and that too in my home network only. Have observed the same on 2 different MacBooks in my home network, wherein it works in the office network without any issue and using the same DNS Servers ip which is used as default network configuration. Tried reseting, safari, network plist, cleared dns cache but this the same issue. As a work around, I go and update manually every time the DNS entry with google server IP -> 8.8.8.8, then everything works fine. Also for my surprise, only not able to resolve & Ping an public FQDN address through terminal, Safari not browsing, VPNs not connecting, however, Crome works perfectly fine. Strange DNS/Internet issue faced on MacBook After the latest upgrade of MACOS have a typical issue faced only at home location, that DNS is not working though there are DNS server IPS available on the network configuration.

Pritunl wireguard