Here’s a refined and expanded version of your blog draft with polished language, Obsidian-style callouts, and smoothly integrated command explanations. I’ve kept the writing elegant but still technical, so English readers can follow along without being familiar with PKU-specific network quirks.

Debugging VPN and Network Connectivity on Campus WiFi#

Intro#

It is common to encounter stubborn network issues when setting up a new computer or switching to a new Internet environment. For me, the case is returning from CMU to PKU: my VPN that previously worked flawlessly suddenly refused to connect when I joined PKU Secure, the campus WiFi.

This blog documents my debugging journey, where the culprit turned out to be a gateway problem, and along the way introduces a set of standard tools for network debugging on macOS and Linux systems.

Mistakes are bound to happen, so if you spot anything inaccurate, please feel free to reach out via email or comments.

Problem: VPN Fails on Campus WIFI#

My VPN connects perfectly over a mobile hotspot, but fails on PKU Secure.

The key difference:

• Hotspot uses public IPv4 addresses.

• PKU Secure assigns addresses in a special subnet (10.x.x.x) with stricter campus-side firewall rules.

Analysis
Two potential causes stand out:

1. Local restrictions — my computer’s firewall could be blocking routes to these private subnets.

2. Campus network policies — PKU Secure itself may prohibit certain types of forwarding or tunneling.

To untangle these, I turned to a set of well-known command-line tools.

Tools and Commands#

1. Routing and Gateway Inspection — netstat#

netstat -rn
netstat -rn | grep -i default

• Shows the routing table.

• Look for the default gateway: if you don’t see one pointing to the campus network, your packets won’t make it past the first hop.

2. Firewall Rules — pfctl#

sudo pfctl -sr    # Show current firewall rules
sudo pfctl -d     # Temporarily disable packet filter

• macOS uses pf as its built-in firewall.

• Checking rules helps confirm whether connections to 10.x subnets are being silently dropped.

3. DNS Resolution — dig#

dig +short jt6t2204.epicgames.ink

• Resolves domain names to IPs.

• This step ensures the problem isn’t with name resolution, but rather with routing.

4. Path Testing — traceroute#

traceroute -n <target-server>

• Shows the hops between your computer and the target server.

• In my case, the traceroute couldn’t make a second hop because I wasn’t connected to the campus gateway at all.

• Note that some intermediate hops, especially on .edu networks, may deliberately block ICMP or UDP trace packets. Seeing * * * for a hop therefore does not necessarily mean the forward path is broken; it may only mean that that router declined to respond to the trace probes.

• How traceroute ends: it stops when the destination returns an ICMP Port Unreachable (i.e., the probe reached the host) or when the probe TTL reaches the configured maximum number of hops (the default is usually 30). It does not run forever — if intermediate hops never respond you will see repeated * * * lines up to the max-hops limit, and then traceroute exits.

5. Network Service State — networksetup & scutil#

networksetup -listallnetworkservices
scutil --nwi
sudo scutil --nc list

• networksetup: Lists all network interfaces (WiFi, Ethernet, VPN).

• scutil: Reveals per-service connectivity and VPN states.

6. System Profiles and Extensions#

sudo profiles -L
systemextensionsctl list

• Useful for checking whether enterprise profiles or third-party system extensions are enforcing policies on your Mac.

7. Interface Inspection — ifconfig#

ifconfig -a | grep utun
ifconfig utun0

• VPN tunnels usually appear as utun interfaces on macOS.

• Checking them confirms whether the VPN connection was established at all.

8. Connectivity Testing — curl#

curl --interface en0 -4 www.baidu.com
curl -4 www.baidu.com
curl -6 www.baidu.com

• Forces traffic over specific interfaces (en0 for WiFi).

• Helps compare IPv4 vs IPv6 connectivity.

9. Open Sockets — lsof#

sudo lsof | grep -i utun

• Lists processes bound to VPN interfaces.

• Useful for verifying whether your VPN client is holding a proper tunnel.

Takeaway#

The real culprit was simple yet fundamental: my machine wasn’t connected to the gateway of PKU Secure at all, so packets couldn’t escape beyond the first hop.

In practice, network debugging often requires peeling away multiple layers:

• Routing tables tell you where packets should go.

• Traceroute shows whether they actually go there.

• Firewalls and profiles reveal hidden restrictions.

And when in doubt, test with both IPv4 and IPv6, as campus networks sometimes block or misconfigure one of them.