通过pf（Murus静态NAT）共享网络/IKEv2 VPN后无法访问HTTPS版Google

Alright, let’s break down what’s going on here—you’ve got most HTTPS sites working smoothly, but Google’s acting up even though ping works and DNS resolves (just to different IPs on client vs server). Here’s the root cause and how to fix it:

Core Issue: DNS Inconsistency + Routing Mismatch #

The main problem is that your client and server are resolving google.com to different IP addresses, creating a mismatch between the client’s intended target and the server’s NAT/routing path. Google uses geographically distributed IPs, so if your server is using a different DNS (e.g., VPN-provided DNS) than your clients (router-side DNS), they’ll pull different IPs. When the client sends an HTTPS request to its local Google IP, your pf NAT might route that traffic through the wrong interface (VPN vs internet), leading to a broken TCP handshake or TLS validation failure.

Step-by-Step Fixes #

1. Align DNS Servers Across Client and Server #

First, eliminate IP resolution differences by making sure both your server and the 192.168.2.0/24 clients use the same DNS server:

• If your server uses VPN-provided DNS: Configure your router to use those same VPN DNS servers instead of its default ISP ones. This ensures clients resolve Google IPs that match the server’s VPN context.
• If your router uses a local DNS: Update your server’s DNS settings to point to the router’s IP (e.g., 192.168.2.1) so it resolves IPs the exact same way clients do.

2. Verify NAT Rules Cover All Target IPs #

Check that your Murus static NAT rules forward all traffic from 192.168.2.0/24 through the correct en4 interface:

• Open Murus and navigate to your NAT rules. Ensure there’s a catch-all outbound NAT rule for 192.168.2.0/24 to en4 (not just specific ports or IP ranges).
• If you use split-tunnel VPN, confirm all Google IP ranges are included in the VPN’s routed subnets. You can look up current resolved Google IPs with this command:

  dig google.com A +short
  

  Add any missing ranges to your VPN’s split-tunnel config or switch to full-tunnel mode to force all traffic through the VPN.

3. Inspect pf Connection States #

Use pf’s state inspection to diagnose why Google HTTPS connections are failing:

• Run this command to filter states related to Google:

  pfctl -s states | grep -i google
  

  Look for states marked SYN_SENT or CLOSED instead of ESTABLISHED—this means the TCP handshake isn’t completing. If you see mismatched interfaces (e.g., client traffic going through en0 instead of en4), your NAT rules are misconfigured.

4. Flush Stale pf States and Retest #

Stale connection states can sometimes cause odd issues. Flush them with:

pfctl -F states

Then try accessing google.com from a client again.

Final Checks #

If you’re still stuck, double-check that your IKEv2 VPN isn’t applying restrictive firewall rules that block Google’s HTTPS traffic. Also, make sure your server’s system time is synchronized—TLS certificate validation relies on accurate time.

内容的提问来源于stack exchange，提问作者Walrus the Cat