Mac VPN utun interface up but traffic failing? Check ifconfig

You connected the VPN, ran ifconfig, and found a utun4 entry with an address on it. The site you needed still times out. That gap is normal: the listing proves a virtual interface exists, not that your client owns it, that the route you care about selects it, or that packets are crossing it. I stopped trusting the interface name after an afternoon spent blaming the wrong tunnel on a laptop that already had three utun entries before I installed anything.

What a utun line actually contains

Run ifconfig -a when you want the whole picture. Called with no arguments, ifconfig prints only interfaces that are currently up, which is why a tunnel that failed to start can be missing from the output people paste into tickets. ifconfig -l returns just the names, and that is the quickest way to tell whether a new utun appeared after you connected.

Reading a single interface is where the useful detail lives. A connected tunnel typically looks like this:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Three fields carry the answer. UP and RUNNING say the kernel is willing to use the interface. POINTOPOINT plus the --> peer address is the signature of a tunnel rather than a physical link. The mtu value explains a whole class of "connects, then stalls" reports, because utun interfaces usually come up with a reduced MTU, 1380 in several macOS builds, and the client may override it. The field list is short enough to skim once in the ifconfig manual Apple ships.

Find the process behind the interface

ifconfig has no concept of an owning application. Two VPN clients, a system service and a leftover tunnel from last week all produce entries that look identical at this level. On my own Mac, utun0 through utun3 existed before I configured anything; Continuity and iCloud Private Relay use tunnels too, and none of them is the connection you are troubleshooting.

For tunnels that register a configuration with the system, scutil --nc list is the fastest correlation. It prints each configuration with its status and service ID, and a connected one is marked as such:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Clients that run their own tunnel process instead of registering a configuration never appear there. Tunnelblick and a command-line openvpn instance fall into that group, so check the process table as well: ps -Ao pid,comm | grep -i openvpn. Once a process owns the tunnel, the utun number belongs to that process and to nothing else.

Test the address before you test the route

An interface can be up with no usable address. An IPv6-only profile shows a link-local fe80:: entry and nothing in the inet line, and a client that failed to apply a pushed address leaves exactly the same shape. If your destination is IPv4 and the tunnel has no IPv4 address, the routing question is already settled.

MTU deserves a separate check, because the failure does not look like a size problem. It looks like a connection that authenticates and then goes quiet as soon as a large transfer starts. Send a probe that must not be fragmented, sized so the packet matches the interface MTU; for an MTU of 1400 the payload is 1372 bytes:

ping -D -s 1372 10.8.0.5

A reply means packets of that size traverse the tunnel. Silence while small pings succeed points at MTU or at something dropping ICMP on the path, not at authentication, which already completed before you got an interface at all.

Prove the destination picks the tunnel

The question that matters is not whether utun4 exists but whether traffic to one specific address leaves through it. route -n get answers that for a single destination and prints the gateway and interface it would use:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

If the same command reports en0, your split-tunnel configuration is doing what it was told and no amount of interface inspection will change it. Use netstat -rn -f inet when you need the default route and the whole table in one view.

Counters settle whether packets actually move. netstat -ib reports per-interface packet and byte totals, utun entries included; the numbers are cumulative, so read them twice with a gap and compare:

netstat -ib | grep utun4

Counters frozen while the application keeps retrying mean the kernel never handed a packet to the interface. Counters climbing in both directions while the application still fails move the investigation to the far end of the tunnel.

When no utun appears at all

An empty interface list after a login that looked successful usually means the tunnel never started, not that ifconfig is hiding it. Check the client's own status, then the system's: a Network Extension that was never approved, or that macOS disabled after an update, leaves no interface behind. The approval lives in System Settings under Login Items & Extensions, and a stale entry there is worth re-toggling before you reinstall anything.

utun numbering is not stable across reconnects. You can get utun5 where utun4 existed ten minutes ago, because the old interface is torn down and the kernel hands out the next free index. Scripts that hardcode a name break silently at that moment; match on the address or on the route instead.

Keep the reading side read-only. sudo ifconfig utun4 down interrupts the tunnel, and on a full-tunnel profile it takes your remote session with it, which is a poor trade when you were only trying to gather evidence. Nothing you need here requires root: reading flags, addresses and counters all work as your normal user.

Work the checks in order next time a Mac tunnel misbehaves: confirm a utun appeared with ifconfig -l, read its flags, addresses and MTU, attribute it to a process, ask route -n get which interface the destination uses, then watch netstat -ib move. Each step rules out a different layer, and the first one that comes back wrong is where the fix belongs.