VPNC - Centos 7 - DNS update

[blink-link]

Hi everyone,

could someone help me with my issue with vpnc (command line, not gui) and DNS (resolv.config).

So, my system: CentOS Linux release 7.1.1503 (Core)
My VPNC client: vpnc-0.5.3-22.svn457.el7.x86_64 (epel repo)
NM: NetworkManager-1.0.0-14.git20150121.b4ea599c.el7.x86_64

I am using vpnc client from terminal (not GUI), but I am using GUI NM to connect to WI-FI network.

I have /etc/vpnc/profile.conf

## generated by pcf2vpnc
IPSec ID MYID
IPSec gateway vpn.host.com
IPSec secret *******
IKE Authmode psk

## To add your username and password,
## use the following lines:
# Xauth username <your username>
# Xauth password <your password>

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1412
inet 192.168.181.103 netmask 255.255.255.255 destination 192.168.181.103
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 31 bytes 2490 (2.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 45 bytes 11151 (10.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlp3s1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.211 netmask 255.255.255.0 broadcast 192.168.1.255
ether a2:45:c2:3d:50:5d txqueuelen 1000 (Ethernet)
RX packets 182590 bytes 110519161 (105.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 160538 bytes 20947674 (19.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 8.8.8.8


Well till today everything was just great, but today I have some trouble with resolv.conf.
I have used google DNS server, and after I've made connection, google dns stood in resolv.conf and I am not able to connect to some hosts on my vpn network using their host names, I could connect only over IP.

Why my resolv.conf (dns) won't update, after I connected to my VPN, is there any solution to make it work again?

Here is a log:

Apr 21 02:15:09 my-machine NetworkManager[11717]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 28)
Apr 21 02:15:09 my-machine NetworkManager[11717]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/13
Apr 21 02:15:10 my-machine dnsmasq[1460]: reading /etc/resolv.conf
Apr 21 02:15:10 my-machine dnsmasq[1460]: using nameserver 8.8.8.8#53
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): link connected
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: starting connection 'tun0'
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 1 of 5 (Device Prepare) scheduled...
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 1 of 5 (Device Prepare) started...
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 2 of 5 (Device Configure) scheduled...
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 1 of 5 (Device Prepare) complete.
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 2 of 5 (Device Configure) starting...
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 2 of 5 (Device Configure) successful.
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 3 of 5 (IP Configure Start) scheduled.
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 2 of 5 (Device Configure) complete.
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 3 of 5 (IP Configure Start) started...
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 3 of 5 (IP Configure Start) complete.
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 5 of 5 (IPv4 Commit) started...
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: Stage 5 of 5 (IPv4 Commit) complete.
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> NetworkManager state is now CONNECTED_LOCAL
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> NetworkManager state is now CONNECTED_GLOBAL
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> Policy set 'tun0' (tun0) as default for IPv4 routing and DNS.
Apr 21 02:15:10 my-machine NetworkManager[11717]: <info> (tun0): Activation: successful, device activated.
Apr 21 02:15:10 my-machine dbus-daemon: dbus[651]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Apr 21 02:15:10 my-machine dbus[651]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' un


Thanks

[jyoung]

Will you provide the following?

Code: Select all

$ grep "\$NEW_RESOLVCONF" /etc/vpnc/vpnc-script 

Code: Select all

$ nmcli con show NAME\ OF\ CONNECTION | grep dns

Code: Select all

lsattr /etc/resolv.conf

[blink-link]

Sure,

root@centoshost:~ $ grep "\$NEW_RESOLVCONF" /etc/vpnc/vpnP1.conf
root@centoshost:~ $ nmcli con show tun0 | grep dns
ipv4.dns:
ipv4.dns-search:
ipv4.ignore-auto-dns: no
ipv6.dns:
ipv6.dns-search:
ipv6.ignore-auto-dns: no
ipv4.dns:
ipv4.dns-search:
ipv4.ignore-auto-dns: no
ipv6.dns:
ipv6.dns-search:
ipv6.ignore-auto-dns: no
root@centoshost:~ $ lsattr /etc/resolv.conf
---------------- /etc/resolv.conf
root@centoshost:~ $ cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 8.8.8.8

resolv.conf stays unchanged, after vpn connection established.

[blink-link]

This is very strange, here is from log:

NetworkManager[3333]: <info> Policy set 'tun0' (tun0) as default for IPv4 routing and DNS.
NetworkManager[3333]: <info> (tun0): Activation: successful, device activated.

But resolv.conf is always:

# Generated by NetworkManager
search localdomain
nameserver 8.8.8.8

[scottro]

Have you tried and removed NetworkManager from the equation, that is, using WPA2 or whatever you usually use to try?

I have a page, mostly designed for just checking if wireless works, but it also goes through taking NM out of the equation--it was written for older versions, but should still work.

http://srobb.net/wireless.html

[jyoung]

Sure,

root@centoshost:~ $ grep "\$NEW_RESOLVCONF" /etc/vpnc/vpnP1.conf

That's not exactly what I was asking for, but I'm not sure that you've done anything to /etc/vpnc/vpnc-script that would prevent the creation of your new resolv.conf. I use vpnc regularly, but comment a line in that script to prevent any overwriting of my nameservers. If you've not done this (commenting the line that I was having you look for), then it doesn't really matter that this didn't produce any output.

root@centoshost:~ $ nmcli con show tun0 | grep dns
ipv4.dns:
ipv4.dns-search:
ipv4.ignore-auto-dns: no
ipv6.dns:
ipv6.dns-search:
ipv6.ignore-auto-dns: no
ipv4.dns:
ipv4.dns-search:
ipv4.ignore-auto-dns: no
ipv6.dns:
ipv6.dns-search:
ipv6.ignore-auto-dns: no

Are you sure that the endpoint to which you're connecting is actually pushing nameservers to you? You're set to not ignore them, which is good, but if NetworkManager isn't getting any new nameservers to use, then you'll have to set them manually. Do you know the IPs of the nameservers you want to use? If so, why not just add them to the configuration of tun0?

[blink-link]

Sure,

root@centoshost:~ $ grep "\$NEW_RESOLVCONF" /etc/vpnc/vpnP1.conf

That's not exactly what I was asking for, but I'm not sure that you've done anything to /etc/vpnc/vpnc-script that would prevent the creation of your new resolv.conf. I use vpnc regularly, but comment a line in that script to prevent any overwriting of my nameservers. If you've not done this (commenting the line that I was having you look for), then it doesn't really matter that this didn't produce any output.

root@centoshost:~ $ nmcli con show tun0 | grep dns
ipv4.dns:
ipv4.dns-search:
ipv4.ignore-auto-dns: no
ipv6.dns:
ipv6.dns-search:
ipv6.ignore-auto-dns: no
ipv4.dns:
ipv4.dns-search:
ipv4.ignore-auto-dns: no
ipv6.dns:
ipv6.dns-search:
ipv6.ignore-auto-dns: no

Are you sure that the endpoint to which you're connecting is actually pushing nameservers to you? You're set to not ignore them, which is good, but if NetworkManager isn't getting any new nameservers to use, then you'll have to set them manually. Do you know the IPs of the nameservers you want to use? If so, why not just add them to the configuration of tun0?

My mistake, sorry, here is the correct output:

grep "\$NEW_RESOLVCONF" /etc/vpnc/vpnc-script
NEW_RESOLVCONF="$NEW_RESOLVCONF
NEW_RESOLVCONF="$NEW_RESOLVCONF
NEW_RESOLVCONF="$NEW_RESOLVCONF
echo "$NEW_RESOLVCONF" > /etc/resolv.conf
NEW_RESOLVCONF="$NEW_RESOLVCONF
NEW_RESOLVCONF="$NEW_RESOLVCONF
echo "$NEW_RESOLVCONF" | /sbin/resolvconf -a $TUNDEV



I didn't make any change in vpnc-script, that is the original one.

Yes I am sure, endpoint should push nameserver to me (I've used this way before centos update 7 - 7.1 and on another distro).
How to configure tun0 with nameservers, in /etc/sysconfig/network-scripts/ or something else?

Jyoung thank you for your answers, I hope that we are going to find soulutions.

[blink-link]

and when I've installed:

$ yum install NetworkManager-vpnc --enablerepo=epel

I've tried to connect via GUI it worked.
$ cat /etc/resolv.conf
# Generated by NetworkManager
search domain.local localdomain
nameserver 192.168.9.71
nameserver 192.168.9.70
nameserver 212.200.191.166
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 212.200.190.166

Here is from CLI:
$ vpnc /etc/vpnc/myVPN.conf
Enter username for vpn.myDOMAIN.com: username
Enter password for username@vpn.myDOMAIN.com:
VPNC started in background (pid: 4615)...
$ cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 212.200.191.166
nameserver 212.200.190.166

And routing is correct:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 600 0 0 wlp3s1
"public ip of vpn server" 192.168.1.1 255.255.255.255 UGH 0 0 0 wlp3s1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp3s1
192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s1

So, only vpnc does not change nameservers from CLI, that is very strange to me.

Any help for CLI?

[jyoung]

I've noticed that vpnc is interacting with NetworkManager differently now too in that I used to be able to run vpnc without NetworkManager being aware of anything. Now, NetworkManager knows that a new device is created and executes any dispatcher scripts for every VPN that I run. I understand the frustration.

Are you running this to start your VPN?

Code: Select all

sudo vpnc some_conf_file.conf

Or are you doing this?

Code: Select all

nmcli con up tun0

Assuming that NetworkManager is the "problem", you could have two scenarios. The first is when you only have one VPN that you connect to, making the script below neat to look at but otherwise worthless. The second, though, is when you have multiple VPNs.

In the first case, what if you try this:

Code: Select all

nmcli con modify tun0 ipv4.dns 8.8.8.8

In the second case, put this file in /etc/NetworkManager/dispatcher.d and name it whatever you'd like:

Code: Select all

vim /etc/NetworkManager/dispatcher.d/vpnc_updater

This is definitely more of a hack than a solution, but it highlights one of the nice features of NetworkManager's dispatcher. You can build on this if you'd like to do other things, like mount remote file shares, update your routing table with custom routes not pushed by the VPN endpoint, etc. I'd probably throw in a section that sets some variables based on the VPN profile name so that this can be used in multiple instances.

Code: Select all

#!/bin/bash
function update_name_resolution () {
   local ACTION=$1
   ## Update the below according to your VPN's settings.
   local NAMESERVER="8.8.8.8"

   for SERVER in "$NAMESERVER"; do
      if [[ "$ACTION" == "DOWN" ]]; then
         sed -i "/nameserver $SERVER/d" /etc/resolv.conf
      else
         sed -i "1inameserver $SERVER" /etc/resolv.conf
      fi
   done
}

## The check below makes sure that we're only taking action when a tun* device is created and when PROFILENAME is the most recently started vpnc process
if [[ "$1" == "tun"* ]]; then
   if [[ ! -z "$( pgrep -fan vpnc | grep -i PROFILENAME )" ]]; then
      case "$2" in
         up)
               update_name_resolution "UP"
               ;;
         down)
               update_name_resolution "DOWN"
               ;;
      esac
   fi
fi

[blink-link]

I've noticed that vpnc is interacting with NetworkManager differently now too in that I used to be able to run vpnc without NetworkManager being aware of anything. Now, NetworkManager knows that a new device is created and executes any dispatcher scripts for every VPN that I run. I understand the frustration.

Are you running this to start your VPN?

Code: Select all

sudo vpnc some_conf_file.conf

Or are you doing this?

Code: Select all

nmcli con up tun0

Assuming that NetworkManager is the "problem", you could have two scenarios. The first is when you only have one VPN that you connect to, making the script below neat to look at but otherwise worthless. The second, though, is when you have multiple VPNs.

In the first case, what if you try this:

Code: Select all

nmcli con modify tun0 ipv4.dns 8.8.8.8

In the second case, put this file in /etc/NetworkManager/dispatcher.d and name it whatever you'd like:

Code: Select all

vim /etc/NetworkManager/dispatcher.d/vpnc_updater

This is definitely more of a hack than a solution, but it highlights one of the nice features of NetworkManager's dispatcher. You can build on this if you'd like to do other things, like mount remote file shares, update your routing table with custom routes not pushed by the VPN endpoint, etc. I'd probably throw in a section that sets some variables based on the VPN profile name so that this can be used in multiple instances.

Code: Select all

#!/bin/bash
function update_name_resolution () {
   local ACTION=$1
   ## Update the below according to your VPN's settings.
   local NAMESERVER="8.8.8.8"

   for SERVER in "$NAMESERVER"; do
      if [[ "$ACTION" == "DOWN" ]]; then
         sed -i "/nameserver $SERVER/d" /etc/resolv.conf
      else
         sed -i "1inameserver $SERVER" /etc/resolv.conf
      fi
   done
}

## The check below makes sure that we're only taking action when a tun* device is created and when PROFILENAME is the most recently started vpnc process
if [[ "$1" == "tun"* ]]; then
   if [[ ! -z "$( pgrep -fan vpnc | grep -i PROFILENAME )" ]]; then
      case "$2" in
         up)
               update_name_resolution "UP"
               ;;
         down)
               update_name_resolution "DOWN"
               ;;
      esac
   fi
fi

Thank you Jeremy (jyoung) the first case is ok and it WORKS! Thank you very much. I've tried the second, but it didn't work, so I am going to test it again later.

Correct solution:

nmcli con modify tun0 ipv4.dns 192.168.9.71 ipv4.dns-search myVPNdomain.local

Thank you.