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>
