Skip to content

Split-tunnel: scoped resolver points at a pushed nameserver that is never routed into the tunnel #23

Description

@andylizf

opc installs a scoped resolver for --dns-zone, pointing at the nameserver the gateway pushes. In split-tunnel mode that nameserver usually sits in the tunnel's own subnet, which --only does not cover, so nothing routes it into the tun device. The resolver that was just installed cannot be reached.

This is on the macOS /etc/resolver path added in #16.

opc 0.1.0, macOS 15 (Darwin 25.2.0), Prisma Access gateway.

opc connect vpn.example.edu \
  --gateway us-northeast-<redacted>.gw.gpcloudservice.com \
  --only 128.112.0.0/16,140.180.0.0/16 \
  --dns-zone example.edu --hip auto --os mac --reconnect

The gateway assigns 172.20.196.199 and pushes 172.20.196.1 as DNS. opc writes:

$ cat /etc/resolver/example.edu
nameserver 172.20.196.1

and installs routes for the two --only prefixes only:

$ netstat -rn -f inet | grep -E '128\.112|140\.180'
128.112            172.20.196.197     UGSc      utun8
140.180            172.20.196.197     UGSc      utun8

$ route -n get 172.20.196.1
   gateway: 192.168.1.1
 interface: en0

Queries for the zone leave through the physical NIC. On this host they reach a LAN device that answers ICMP and refuses TCP 53, which makes the resolver look broken rather than unreachable.

Every getaddrinfo() for the zone then stalls for the resolver timeout and fails:

$ python3 -c "import socket; socket.getaddrinfo('www.cs.example.edu', 443)"
socket.gaierror: [Errno 8] nodename nor servname provided, or not known   # after 30s

Two things make this hard to spot:

  • dig reads /etc/resolv.conf and ignores macOS scoped resolvers, so command-line checks report the zone resolving fine while browsers and ssh fail.
  • TCP into the --only prefixes keeps working throughout, so a health check built on a TCP probe stays green.

Adding the missing route confirms the nameserver itself is fine:

$ sudo route -n add -host 172.20.196.1 -interface utun8
add host 172.20.196.1: gateway utun8
$ dig +short @172.20.196.1 host.example.edu
128.112.173.250

Suggested fix: when a scoped resolver is installed, add a host route through the tun interface for each pushed nameserver not already covered by the installed split-tunnel prefixes, and drop those routes on revert. gp-route installs only the --only prefixes today, and the nameservers arrive separately via oc_ip_info.dns, so neither side owns this.

Linux and Windows should have the same gap for the same reason, though I have only reproduced it on macOS.

I'll open a PR for this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions