Problems with macOS 13.2, TAP, and DHCP? AKA, "Default go poof!"

Got a problem with Viscosity or need help? Ask here!

sigsegv

Posts: 12
Joined: Fri Mar 06, 2020 9:33 am

Post by sigsegv » Thu Jan 26, 2023 8:23 am
We have about 20 laptops with Ventura. Slightly less than half of them have updated to 13.2, and I'm advising the remainder to hold on 13.1 for the time being.

We use a TAP VPN config with specific networks routed over the VPN:
Code: Select all
route 1.2.3.0 255.255.254.0 default default
Since traffic to the network that the VPN servers are on should normally be over the VPN, we also have specific routes for the VPN servers telling the client to _not_ use the VPN:
Code: Select all
route 1.2.3.4 255.255.255.255 net_gateway default
The server tells the clients that the "gateway address will be extracted from a DHCP negotiation with the OpenVPN server-side LAN" (from the reference manual):
Code: Select all
push "route-gateway dhcp"
The VPN clients receive DHCP leases from the DHCP server on the network that the VPN bridges. This works fine for all of our clients. The VPN interface receives an IP on this network, and all network routes configured to use the "default" gateway are directed to the default gateway provided by the DHCP server.

The problem comes when the DHCP lease on the VPN interface is renewed.
  • Clients before 13.2: things "just work." The lease is renewed, and everything keeps working as expected.
  • macOS 13.2 clients: the default route in the client's IPv4 routing table suddenly disappears. The VPN remains up and continues to work -- because of the static routes to the VPN servers in the client configs? -- but services like Slack and Zoom start failing because the OS can no longer route packets to those servers. Users, thinking that the VPN has broken, close the connection. This restores the default route, and functionality returns to normal (until they reconnect to the VPN and the next DHCP lease renewal happens).
Note: for the 13.2 clients, manually adding the default route on the command line seems to restore all functionality. I'm told that this route also eventually disappears too, but it lasts longer than the 30 minutes that it would if the VPN were restarted instead. I have yet to be able to confirm this myself.

Every client running macOS 13.2 that we've been able to test loses its default route at VPN connect time + 30 minutes. (The default DHCP lease time is 1 hour.) This does not happen on any macOS 13.1 clients we've tested.

This is using Viscosity versions 1.10.2 and 1.10.4.

Is anyone else seeing this problem? Suggestions for how to fix this? (We can extend the DHCP lease time to move the renewal out a bunch, and we might want to do that eventually anyway, but that feels more like a workaround than a fix.)

James

User avatar
Posts: 2312
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Thu Jan 26, 2023 3:29 pm
Hi sigsegv,

Could you send along a copy of the items requested in the following article so we can take a closer look? You may want to send these to us via email rather than posting publicly on the forum.
https://www.sparklabs.com/support/kb/ar ... ort-staff/

I also recommend checking what options your DHCP server is pushing. In particular, is it pushing a default gateway (Option 3) or any static routes (Options 33/121)?

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

sigsegv

Posts: 12
Joined: Fri Mar 06, 2020 9:33 am

Post by sigsegv » Fri Jan 27, 2023 5:23 am
Thanks, James. I'll take this over to a support submission and include the configs and connection log.

As for your DHCP server questions, it is pushing a default gateway, but it is not pushing any static routes. I suspect that this is where things are going bad, and macOS 13.2 is handling the DHCP renewal differently than previous macOS versions.

sigsegv

Posts: 12
Joined: Fri Mar 06, 2020 9:33 am

Post by sigsegv » Fri May 05, 2023 4:53 am
Just noting here that after taking this to email, James and company were able to replicate this behavior. It would seem that our usage is fairly ~odd~ niche. :) Once they were able to replicate, they found a fix that's included in 1.10.6b7.

Our workaround between the release of macOS 13.2 and 1.10.6b7 was to add these two routes to approximate the default route behavior:
Code: Select all
route 0 128.0.0.0 net_gateway default
route 128.0.0.0 128.0.0.0 net_gateway default
Thank you, SparkLabs, for all your help getting to the bottom of this.
4 posts Page 1 of 1