getting openconnect vpn to work through network-manager











up vote
8
down vote

favorite
4












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.










share|improve this question
























  • 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















up vote
8
down vote

favorite
4












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.










share|improve this question
























  • 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













up vote
8
down vote

favorite
4









up vote
8
down vote

favorite
4






4





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.










share|improve this question















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.







network-manager vpn dns resolv.conf cisco






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 13 '17 at 12:23









Community

1




1










asked Jun 3 '15 at 13:41









zee

4113




4113












  • 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


















  • 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
















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




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




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






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




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




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










2 Answers
2






active

oldest

votes

















up vote
0
down vote













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.






share|improve this answer




























    up vote
    0
    down vote













    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.






    share|improve this answer





















      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f631810%2fgetting-openconnect-vpn-to-work-through-network-manager%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      0
      down vote













      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.






      share|improve this answer

























        up vote
        0
        down vote













        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.






        share|improve this answer























          up vote
          0
          down vote










          up vote
          0
          down vote









          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.






          share|improve this answer












          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Dec 5 '16 at 19:12









          jdhildeb

          1053




          1053
























              up vote
              0
              down vote













              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.






              share|improve this answer

























                up vote
                0
                down vote













                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.






                share|improve this answer























                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  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.






                  share|improve this answer












                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jun 29 '17 at 23:37









                  Seanchán

                  25635




                  25635






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f631810%2fgetting-openconnect-vpn-to-work-through-network-manager%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Ellipse (mathématiques)

                      Quarter-circle Tiles

                      Mont Emei