Wi-Fi after Internet Sharing: returning a Mac to client mode

Turning Internet Sharing off does not put Wi-Fi back the way it was, and the menu bar will not tell you which of three states you are in. The radio may be unavailable, it may be fine but unassociated, or it may be associated while a VPN policy blocks traffic. Each has a different fix, and only one of them involves the VPN at all. Decide which one you are looking at before touching a network service.

Decide what Wi-Fi should be doing now

During Internet Sharing the Wi-Fi interface serves other devices, which is a different job from joining a router as a client. Those are not two settings of one thing; they are two modes of the same hardware. Write down which one you want next, because every later check depends on it. If the answer is ordinary client access, the sharing arrangement has to be gone first. If someone else administers that sharing configuration, agree the change with them rather than switching it off unilaterally.

A VPN dropping is a separate event. It can explain blocked traffic, and it cannot explain a radio that will not come up.

Stop the sharing role first

Turn the sharing arrangement off in the sharing panel and save your work first. The interface that was serving other devices stops doing so immediately, and anything connected to it loses its path. That is expected rather than a fault. Confirm the downstream interface is no longer in that role before you look at Wi-Fi at all.

A bridge interface created by the sharing service can linger in the interface list. networksetup -listallhardwareports maps names to hardware, which settles which device is which before you start guessing. Read it instead of trusting the order in a menu.

Separate the three failure shapes

Radio unavailable is a hardware or driver finding. Record the macOS release and whether the sharing state was active, then use the supported diagnostics path; no routing change brings back an interface the system cannot see. Not associated is a joining problem: pick the approved network, complete its authentication, and check that the Mac behaves as a client rather than still acting as a gateway. Associated but no access is a policy problem, and the VPN client's documented disconnected behaviour is the first place to look.

Those three need different owners as well as different fixes. The first goes to hardware support, the second to whoever holds the credentials, the third to whoever administers the VPN client. Mixing them produces a ticket nobody can action.

Run diagnostics inside their scope

Wireless Diagnostics earns its place when the Mac associates but struggles to reach the internet. It analyses and reports rather than repairing, and it does not change your settings.

Open it from the Wi-Fi status menu with Option held, follow the prompts, and read the archive before sending it anywhere, because network details can be sensitive. What it will not do is bring back an interface the system does not see, so a clean report is not proof that the radio is healthy. If a restart is appropriate, capture the useful observations first. The report is evidence, not a fix.

Recreating a service is not a toggle

Deleting and re-adding the Wi-Fi network service is a far larger change than switching sharing off. It discards manual addressing, DNS entries, proxy settings and any 802.1X configuration attached to that service. Write those down before you consider it, and check whether the installed release has a documented procedure.

The comparison settles it: toggling sharing is reversible in seconds and changes one role, while recreating a service can cost an afternoon and an administrator to restore. Reach for the second only when the first has failed and you can name what the recreated service must contain. Once the Mac has its ordinary connection back, make one allowed request, then reconnect the VPN and its private resource. Leave Internet Sharing off unless you deliberately want that gateway role again.