some traffic not being routed over VPN

[David Woodhouse]

On Wed, 2015-07-01 at 12:14 -0400, Patrick O'Brien wrote:
> 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.

If you run openconnect with the '-v' argument, are there *any* X-CSTP-*
headers which do contain the full list of domains?

If not, you'll probably need to override it. You can use the --script
argument to point it at a vpnc-script replacement of your own... which
does nothing except set some environment variables (like
CISCO_DEF_DOMAIN) and then exec the real vpnc-script.

I think we also need a fix to vpnc-script to make it cope with multiple
domain names in $CISCO_DEF_DOMAIN. Currently it'll put the whole list
into a 'domain' line in resolv.conf, which is invalid. It'll need to
use just the first.

Or we introduce a new variable for $CISCO_SEARCH_DOMAINS, and put a
*list* in that instead?

> 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?

If you're using NetworkManager, it should work this way. It uses
dnsmasq to provide a local nameserver, which behaves as you describe.

It would be possible to make vpnc-script set up dnsmasq in the same
way, and you're not the first person to ask. I wonder if it can be
implemented purely with a 'connect' hook which starts up dnsmasq and
then overrides the INTERNAL_IP4_DNS to point to localhost, and a 'post
-disconnect' hook which kills dnsmasq again? I'd prefer that to adding
even more complexity to vpnc-script...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150702/1d3ce1f0/attachment.bin>