Can't resolve VPN nameserver IP on macOS Sierra only (older OS X versions work fine)

[al...@brandwatch.com]

We use the following line in our config:

push "dhcp-option DNS 169.254.169.250"

This correctly allows clients to use 169.254.169.250 as the DNS nameserver when connected over the VPN.

This works absolutely fine for OS X El Capitan users, but macOS Sierra users cannot resolve the IP address 169.254.169.250 while connected to the VPN using Tunnelblick, and as such DNS resolution does not work when connected to the VPN.

It seems that Tunnelblick still correctly sets the nameserver to be 169.254.169.250, it's just that it cannot route that IP.  I'm not sure if anything changed in Sierra to route IPs on the subnet 169.254.*.* differently to older versions.

Other IPs on the VPN route just fine, for example I can SSH onto servers in the 10.1.*.* subnet.

Any ideas for what might be causing the problem would be greatly appreciated.  Here is an excerpt from my routing table (netstat -nr):

Destination        Gateway            Flags        Refs      Use   Netif Expire

...

10/24              10.192.0.9         UGSc            1        0   utun1

...

10.1/16            10.192.0.9         UGSc            1        0   utun1

...

10.192/24          10.192.0.9         UGSc            1        0   utun1

10.192.0.9         10.192.0.10        UH              8        0   utun1

...

169.254.169.250/32 10.192.0.9         UGSc            1        0   utun1

...

[andizi1...@gmail.com]

I think I have the same problem. Once connected to the Server, I can ssh/vcn to it via 10.8.0.1 - however the nameservers are not pushed properly, leading to non-reachable websites etc..

[charles....@gmail.com]

I'm seeing the same thing - was working in Yosemite, did not work in Sierra with no other changes. Interestingly "netstat" and "route" disagree on the gateway for the DNS server:

$ netstat -nr

default            192.168.1.254      UGSc           12        0     en1

10                 172.16.0.57        UGSc            0        0   utun1

127                127.0.0.1          UCS             0        0     lo0

127.0.0.1          127.0.0.1          UH              3     5138     lo0

169.254.169.253/32 172.16.0.57        UGSc            1        0   utun1

172.16.0.1/32      172.16.0.57        UGSc            0        0   utun1

172.16.0.57        172.16.0.58        UH              3        0   utun1

$ route -n get 169.254.169.253

   route to: 169.254.169.253

destination: 169.254.169.253

    gateway: 192.168.1.254

  interface: en1

      flags: <UP,GATEWAY,HOST,DONE,b016,WASCLONED>

 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire

       0         0         0         0         0         0      1500         0 

If I run this command it fixes things:

$ route -n modify 169.254.169.253 172.16.0.57 255.255.255.255

Interestingly if I watch the route table while tunnelblick is connecting I can see it go from the default gateway then to 192.168.1.254 then to 172.16.0.57 and finally back to 192.168.1.254 where it stays.

Haven't found a proper fix yet.

[charles....@gmail.com]

If I remove "push "dhcp-option DNS 169.254.169.253"" from my server config the gateway for 169.254.169.253 is correct (of course client's won't have the correct resolv.conf setting so still can't resolve things). So it seems like something in how tunnelblick sets the DNS config in OSX causes the DNS server route to get clobbered.

[Tunnelblick developer]

This seems to be the problem described in GitHub Issue #377.