Chromebook连接OpenVPN后无法路由流量问题求助

Hey there, let’s work through this problem step by step. The fact you can connect and ping the pfSense server’s internal IP tells us the VPN tunnel itself is up—but missing routes and no other traffic points to a routing misconfiguration, either on your Chromebook or the pfSense server side. Here’s what to check:

1. Verify Chromebook’s OpenVPN Client Traffic Routing Setting #

First, double-check the core setting that forces all traffic over VPN:

• Open your Chromebook’s Settings > Network > VPN, select your OpenVPN profile, and click Edit.
• Look for an option like "Send all traffic over VPN connection" (labeling varies slightly by ChromeOS version) and make sure it’s checked. If this is disabled, only traffic targeted at your private subnet will go through the VPN, not all internet traffic.
• If you imported a .ovpn file to set up the VPN, open the file in a text editor and confirm it includes the line redirect-gateway def1—this is the command that tells the client to route all traffic through the VPN. If it’s missing, add it, re-save the file, and re-import the profile.

2. Manually Inspect and Add Routes via crosh #

Since you already have access to crosh, let’s dig into the routing table:

1. Open crosh (press Ctrl + Alt + T), then type shell to access the Linux environment.
2. Run ip route list to view all active routes. You should see a default route (0.0.0.0/0) pointing to your OpenVPN tunnel gateway (usually something like 10.8.0.1, depending on your pfSense VPN subnet).
3. If the default VPN route is missing, add it manually:

   # Replace 10.8.0.1 with your pfSense OpenVPN tunnel gateway IP, and tun0 with your VPN interface name
   sudo ip route add 0.0.0.0/0 via 10.8.0.1 dev tun0
   

   You can confirm the VPN interface name with ip link show (it’ll be labeled tun0 or tap0 depending on your OpenVPN setup). After adding the route, test accessing a private resource or external site—if traffic flows, the issue was a missing route push.

3. Check pfSense OpenVPN Server Route Push Configuration #

Let’s make sure pfSense is sending the correct routing instructions to clients:

• Log into your pfSense web UI, go to VPN > OpenVPN > Servers, and edit your active OpenVPN server.
• Under Client Settings, ensure "Redirect Gateway" is checked—this tells the server to push the default route to clients, forcing all traffic through the VPN.
• Also, confirm the IPv4 Local Networks field includes all private subnets you need to access (if you want to push only private traffic) or leave it blank if you’re using Redirect Gateway for full traffic routing.
• Don’t forget to check Push DNS Servers: if clients are using their local DNS instead of the one pushed by pfSense, they might fail to resolve private resource names, making it look like no traffic is flowing.

4. Fix MTU Mismatch Issues #

Sometimes a mismatched MTU (Maximum Transmission Unit) will let small ping packets through but block larger traffic. Here’s how to test:

1. In the crosh shell, run ip link show tun0 to check the current MTU of your VPN interface (default is usually 1500).
2. Try lowering it to 1400 or 1450 with this command:

   sudo ip link set tun0 mtu 1400
   

   Test accessing resources again—if this works, you can add mtu 1400 to your .ovpn profile to make the change permanent.

5. Rule Out Managed Chromebook Policy Restrictions #

If this Chromebook is part of an enterprise domain, IT policies might block full VPN routing:

• Open Chrome and go to chrome://policy to view active policies. Look for policies like AllowedVPNConfigurations or VPNAlwaysOn that might restrict route pushing.
• If you see restrictive policies, reach out to your IT admin to confirm whether full VPN traffic routing is permitted.

Start with the client-side "send all traffic" setting—it’s the most common fix for this exact scenario. If that checks out, work through the pfSense and manual routing steps, and don’t overlook MTU issues—they’re easy to miss but can cause this exact symptom.

内容的提问来源于stack exchange，提问作者Tom Ribbens