8

this is the same issue as here: Getting openconnect vpn to work through gui , but my additions to it were deleted and i was asked to create a new question.

in fact, there are a number of folks asking similar questions here, all with 0 responses.

software versions: ubuntu 14.04, openconnect 5.02

main issue: i'm trying to add a vpn connection into network-manager, using openconnect. when i supply my vpn username and password, it connects successfully, but i can't resolve dns.

if i run openconnect in the terminal via sudo, dns works.

sudo openconnect -u <username> https://<vpn concentrator name>

more details:

1a. when connecting via openconnect and network-manager even though i've explicitly added dns and a search domain under the ipv4 tab, only the search domain ends up in /etc/resolv.conf. even if i don't supply dns and search domains, i can see in the logs that it's getting that information from the vpn concentrator. again, the search domain is updated properly. [log below]

1b. when connecting via sudo on in a terminal, resolv.conf is populated properly with dns and search domains even though i haven't added that information in the command line or provided a path to a vpnc-script. it must be getting it from the vpn concentrator. [log also below]

2a. when connecting via openconnect and network-manager, a new interface 'vpn0' is created.

2b. when connecting via sudo and command line, a new interface 'tun0' is created.

log when connecting via network-manager:

NetworkManager[784]: <info> Starting VPN service 'openconnect'...
NetworkManager[784]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 4513
NetworkManager[784]: <info> VPN service 'openconnect' appeared; activating connections
NetworkManager[784]: <info> VPN plugin state changed: init (1)

this is where it asks for my password

NetworkManager[784]: <info> VPN plugin state changed: starting (3)
NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/vpn0, iface: vpn0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/vpn0, iface: vpn0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/vpn0: couldn't determine device driver; ignoring...
NetworkManager[784]: <info> VPN connection '<connection name>' (Connect) reply received.
openconnect[4544]: Attempting to connect to server <ip address>:443
openconnect[4544]: SSL negotiation with <correctly identified vpn server>
openconnect[4544]: Connected to HTTPS on <correctly identified vpn server>
openconnect[4544]: Got CONNECT response: HTTP/1.1 200 OK
openconnect[4544]: CSTP connected. DPD 30, Keepalive 20
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP4 Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP6 Config Get) reply received.
NetworkManager[784]: <info> VPN Gateway: <ip address>
NetworkManager[784]: <info> Tunnel Device: vpn0
NetworkManager[784]: <info> IPv4 configuration:
NetworkManager[784]: <info>   Internal Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Internal Prefix: 19
NetworkManager[784]: <info>   Internal Point-to-Point Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   DNS Domain: '(none)'
NetworkManager[784]: <info> IPv6 configuration:
NetworkManager[784]: <info>   Internal Address: <ipv6 ip>
NetworkManager[784]: <info>   Internal Prefix: 64
NetworkManager[784]: <info>   Internal Point-to-Point Address: <ipv6 ip>
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   DNS Domain: '(none)'
openconnect[4544]: Connected vpn0 as <ip address> + <ipv6 ip>, using SSL
openconnect[4544]: Established DTLS connection (using OpenSSL)
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) complete.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv4 routing and DNS.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv6 routing and DNS.
NetworkManager[784]: <info> Writing DNS information to /sbin/resolvconf
dnsmasq[1027]: setting upstream servers from DBus
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <home search domain>
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dbus[471]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
NetworkManager[784]: <info> VPN plugin state changed: started (4)
NetworkManager[784]:    keyfile: updating /etc/NetworkManager/system-connections/<connection name>-6a503043-13b0-4ce7-9749-29cd3054cae3
dbus[471]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

despite all the noise in the log about updating resolv.conf it removes the nameservers but doesn't replace them with the ip addresses in the log. it does update the search domain correctly, so it's likely not a permissions issue.

log when connecting using sudo openconnect in terminal:

NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
dbus[471]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper)
kernel: [ 3258.725774] systemd-hostnamed[4927]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
dbus[471]: [system] Successfully activated service 'org.freedesktop.hostname1'

nothing about updating resolv.conf, and yet it properly updates the name servers and the search domain.

update if i ignore all the warnings in resolv.conf and add the vpn concentrator nameservers to it, i'm instantly able to browse. of course as soon as i disconnect, those changes are overwritten.

there was a bug on this, back in 2012, but it expired. the issue seems to be the vpnc script.

i tried manually updating my vpnc-scripts to the latest versions, but to no avail.

some further research turns up that as of 12.04 resolv.conf is no longer where nameservers go for dns resolution when using network-manager. that's why it works when i use the command line, but not when using network-manager. rather the nameserver 127.0.1.1 [dnsmasq] is added and that nameserver is told the ip addresses of the actual nameservers.

The big advantage is that if you connect to a VPN, instead of having all your DNS traffic be routed through the VPN like in the past, you’ll instead only send DNS queries related to the subnet and domains announced by that VPN

update disabling dnsmasq as explained in link above solves the issue because /etc/resolv.conf is populated.

this is not a real solution though it's a fallback.

  • Why does NetworkManager list 127.0.0.1 in addition to the two other redacted IP addresses? What nameserver is running locally and listening at 127.0.0.1 and able to resolve VPN names? – jdthood Jun 3 '15 at 20:42
  • i think that's just for dns caching. it's not a "real" nameserver. – zee Jun 3 '15 at 20:56
  • Address 127.0.0.1 is listed as a nameserver address obtained by NetworkManager. NetworkManager passes this address to dnsmasq to use as a forwarding address. Dnsmasq will try to forward queries to this address which is a loopback address. Is there actually a nameserver running on the local machine which listens for queries at that address? And even if so, why is NetworkManager reporting the address during the VPN initiation? It looks to me as if your VPN server is misconfigured to supply 127.0.0.1 as a nameserver address on the VPN. – jdthood Jun 4 '15 at 20:42
  • interestingly when i tried my connection this morning that line is now gone, so it's just the 2 dns servers from the concentrator. – zee Jun 5 '15 at 13:14
  • And can you now resolve Internet names? VPN names? Local names? Please post the actual contents of resolv.conf which you say isn't being updated properly. Did you know that NetworkManager by default runs a forwarding nameserver — an instance of dnsmasq — which listens at 127.0.1.1 and forwards queries to nameservers at addresses given to it by NetworkManager via DBus? When this forwarding nameserver is used, only its listen address is listed on a nameserver line in /etc/resolv.conf, regardless of how many forwardee nameservers are in use. – jdthood Jun 5 '15 at 13:29
0

Check if there is a mismatch between the host you are trying to resolve via the VPN and the "DNS Domain" that the Cisco VPN server is sending.

To check for this, open a terminal and run:

tail -f /var/log/syslog

Then start openconnect via network manager. You'll see a whole bunch of output come through, including some lines like this:

Dec 5 12:54:31 canoe NetworkManager[1266]: Internal DNS: 10.0.20.21

Dec 5 12:54:31 canoe NetworkManager[1266]: Internal DNS: 10.10.3.32

Dec 5 12:54:31 canoe NetworkManager[1266]: DNS Domain: 'internal.example.com'

And further down you'll see

Dec 5 12:54:31 canoe dnsmasq[1871]: using nameserver 10.0.20.21#53 for domain internal.example.com

This means that the VPN server is instructing the client that the DNS servers should be used to resolve hosts within internal.example.com, such as server.internal.example.com.

In my case, I need to resolve server.example.com (and was not getting any result).

The solution for me was to go into the VPN settings and add example.com as an additional search domain:

enter image description here

Don't forget to disconnect VPN and then re-connect for the setting to take effect.

0

So I have resolved this for myself satisfactorily enough. I am on Mint 18 / Ubuntu 16.04

My problem was that once I connected to the Openconnect VPN through NetworkManager I could no longer resolve DNS for domains outside of my work domains. I.e. I lost internet!

My fix was this:

  1. In NetworkManager, I edited the VPN Connection under "Network Connections".
  2. In the IPv4 tab, changed method to "Automatic (VPN) Addresses Only"
  3. Added my work DNS server (e.g. 10.10.10.100) and "Search domain" of "mywork.tld"
  4. Click on "Routes".
  5. Add a route that covers my work network, e.g. 10.10.0.0 / 255.255.0.0 and gateway of 10.10.10.253 <-- VPN gateway I got from a "traceroute".
  6. Then I ticked both options: i. "Ignore automatically optained routes" ii. "Use this connection only for resources on its network"

Works on my computer.

My understanding of what happened is that:

  1. My /etc/resolv.conf is setup with dnsmasq and is pointing to 127.0.1.1
  2. dnsmasq is using my ISP's DNS servers for general internet DNS resolution. For example, ISP DNS is let's say 8.8.8.8.
  3. I connect to VPN, DNS server of 10.10.10.100 is added as an additional server to dnsmasq to be used for "mywork.tld" DNS resolution.
  4. Once I am on the VPN, my work firewall no longer allows me to use port 53 to 8.8.8.8 so my general internet resolution goes away. DNS should timeout and go to the secondary DNS server, but it doesn't for some reason?
  5. I am left only with access to DNS resolution for "server01.mywork.tld" because this query goes to 10.10.10.100 which I have access to over the VPN.
  6. If I query for www.google.com it fails, even though my internal DNS can forward. I can only assume that my internal DNS is never asked.

My fix seems to stay working so long as my work doesn't change their network or DNS server IP address.

I'm a bit hazy about it, but I think it works for me because once this is done my Wireless NIC becomes my default network connection. So DNS queries go to 8.8.8.8 over wifi. Any query for "xyz.mywork.tld" is told by dnsmasq to go to 10.10.10.100. I have set a route for that, so that goes over "vpn0" NIC which returns the correct 10.10.10.x IP address for "xyz.mywork.tld". Bingo bango DNS resolution for internal and external networks and everyone is happy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.