A little more information:
I did a little digging and found the root of the problem: (with some
commentary from me)
# scutil --dns
DNS configuration
resolver #1
search domain[0] : companyinternaldomain1.com
search domain[1] : home
nameserver[0] : a.a.a.a # Internal corporate DNS server #1 only
reachable via utun0
nameserver[1] : b.b.b.b # Internal corporate DNS server #2 only
reachable via utun0
nameserver[2] : 192.168.1.1 # My local DNS server #1
nameserver[3] : 8.8.8.8 # My local DNS server #2
if_index : 4 (en0)
flags : Request A records
reach : Reachable
resolver #2
domain : corporateinternaldomain1.com
nameserver[0] : a.a.a.a
nameserver[1] : b.b.b.b
flags : Request A records
reach : Reachable
order : 100600
(...cut out IPv6 stuff...)
DNS configuration (for scoped queries)
resolver #1
search domain[0] : home
nameserver[0] : a.a.a.a
nameserver[1] : b.b.b.b
nameserver[2] : 192.168.1.1
nameserver[3] : 8.8.8.8
if_index : 4 (en0)
flags : Scoped, Request A records
reach : Reachable
resolver #2
search domain[0] : companyinternaldomain1.com
nameserver[0] : a.a.a.a
nameserver[1] : b.b.b.b
if_index : 10 (utun0)
flags : Scoped, Request A records
reach : Reachable
So this explains why DNS requests for companyinternaldomain1.com
succeed (go out over utun0) while requests for companyinternaldomain2
and companyinternaldomain3 fail (go out over en0.) company.com and
all public stuff can be handled by my regular public DNS servers.
It looks like this is a failing of vpnc-script, but I'm not quite sure
what to do to correct it. I see that it correctly sets up a resolver
for CISCO_DEF_DOMAIN (which is companyinternaldomain1) but it looks
like that is a single variable for the script and not a list that I
could add to.
Ideally what I'd like to have happen is that for a list of defined
corporate domains, resolution uses a.a.a.a/b.b.b.b via utun0 and for
anything else, it uses my default (192.168.1.1/8.8.8.8) via en0. Can
this be done simply, or do I need to start hacking on vpnc-script?
Thanks!
Pat
On Tue, Jun 30, 2015 at 5:27 PM, Patrick O'Brien <pdobrien at gmail.com> wrote:
> Hi all,
>
> Having a very strange issue with openconnect on Mac OS X Yosemite. In
> short, some DNS requests are going out over the wrong interface.
>
> I've got a vpnc script set up for split mode. I've added a bunch of
> netblocks that should be routed through the tunnel like so:
>
> ---
> #!/bin/sh
>
> # debug
> #set -x
>
> add_ip()
> {
> export CISCO_SPLIT_INC_${CISCO_SPLIT_INC}_ADDR=$1
> export CISCO_SPLIT_INC_${CISCO_SPLIT_INC}_MASK=$2
> export CISCO_SPLIT_INC_${CISCO_SPLIT_INC}_MASKLEN=32
> export CISCO_SPLIT_INC=$((CISCO_SPLIT_INC + 1))
> }
>
> # Initialize empty split tunnel list
> export CISCO_SPLIT_INC=0
>
> # Delete DNS info provided by VPN server to use internet DNS
> # Comment following line to use DNS beyond VPN tunnel
> #unset INTERNAL_IP4_DNS
>
> # List of IP ranges beyond VPN tunnel
> add_ip 10.0.0.0 255.0.0.0.0 # /8 corporate internal network
> add_ip x.x.x.x 255.255.240.0 # /20 corporate network
> add_ip x.x.x.x 255.255.248.0 # /21 corporate network
> ....
>
> # Execute default script
> . /usr/local/etc/vpnc-script
> ---
>
> From an OS perspective everything looks great. If I test out the
> routing ('route get') it looks like things should be routed correctly
> (through en0 or utun0.)
>
> The VPN provides two corporate DNS servers (a.a.a.a and b.b.b.b) which
> openconnect dutifully puts at the top of the list in /etc/resolv.conf.
> If I run nslookup/dig/host while watching traffic on both the default
> and VPN interfaces, I see it properly resolving using the first
> corporate DNS server via the VPN interface (utun0).
>
> However, in browsers like Chrome and Firefox, I see a very strange
> behavoir. Most URLs resolve correctly, including some non-public
> corporate hostnames. However, for some hostnames (both corporate and
> public) I see the DNS request go out to the corporate DNS server
> a.a.a.a *but on the non-VPN interface* (en0.) I can't for the life of
> me figure out why this should be happening. I have disabled proxy at
> the OS level.
>
> For example, even though my default DNS server is a.a.a.a and I have a
> specific routing table entry that should send traffic to a.a.a.a out
> over the VPN interface like so:
> # netstat -rn | grep a.a.a.a
> a.a.a.a/32 10.154.144.146 UGSc 1 0 utun0
>
> I still see requests go out over en0 sometimes, like so:
> # tcpdump -i en0 port 53
> ...
> 16:39:27.690084 IP 192.168.1.12.56892 > a.a.a.a.domain: 29289+ A?
> corporateserver.corporation.com. (54)
> 16:39:28.776604 IP 192.168.1.12.56892 > a.a.a.a.domain: 29289+ A?
> corporateserver.corporation.com. (54)
> 16:39:29.776873 IP 192.168.1.12.56892 >
> wireless_broadband_router.home.domain: 29289+ A?
> corporateserver.corporation.com. (54)
> 16:39:29.889740 IP wireless_broadband_router.home.domain >
> 192.168.1.12.56892: 29289 NXDomain 0/1/0 (127)
> ...
> 16:37:34.567376 IP 192.168.1.12.51937 > a.a.a.a.domain: 32596+ A?
> init-p01st.push.apple.com. (43)
> 16:37:48.913744 IP 192.168.1.12.51937 > a.a.a.a.domain: 32596+ A?
> init-p01st.push.apple.com. (43)
> 16:38:03.254285 IP 192.168.1.12.51937 > b.b.b.b.domain: 32596+ A?
> init-p01st.push.apple.com. (43)
> 16:38:17.505229 IP 192.168.1.12.51937 > b.b.b.b.domain: 32596+ A?
> init-p01st.push.apple.com. (43)
> 16:38:31.839505 IP 192.168.1.12.51937 >
> wireless_broadband_router.home.domain: 32596+ A?
> init-p01st.push.apple.com. (43)
> 16:38:32.307175 IP wireless_broadband_router.home.domain >
> 192.168.1.12.51937: 32596 4/0/0 CNAME
> init-p01st.push.apple.com.edgesuite.net., CNAME a1441.g4.akamai.net.,
> A 63.130.78.130, A 63.130.78.136 (158)
>
> I'm out of ideas... any thoughts? Note that I haven't tested other
> kinds of traffic to see if it's going the wrong place as well, just
> DNS.
>
> Thanks,
> Pat