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.
opcinstalls 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--onlydoes 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/resolverpath added in #16.opc 0.1.0, macOS 15 (Darwin 25.2.0), Prisma Access gateway.
The gateway assigns
172.20.196.199and pushes172.20.196.1as DNS. opc writes:and installs routes for the two
--onlyprefixes only: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:Two things make this hard to spot:
digreads/etc/resolv.confand ignores macOS scoped resolvers, so command-line checks report the zone resolving fine while browsers andsshfail.--onlyprefixes keeps working throughout, so a health check built on a TCP probe stays green.Adding the missing route confirms the nameserver itself is fine:
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-routeinstalls only the--onlyprefixes today, and the nameservers arrive separately viaoc_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.