NetExtender has stopped working since I updated to Leap 15 (a few days ago). It says it’s connected to the VPN and even displays bytes sent and received, however I am unable to access anything on the network (I cannot ping internal IP addresses). It worked fine on 42.3, but now I’m having this connectivity issue. I also tried uninstalling and reinstalling it, same problem. I also get no errors. I’m assuming this is the result of some network configuration change between 42.3 and 15.0. I have another computer I can connect on, so the problem is on my laptop, not the server.
When you’re connected, can you capture and post the IP details?
ip a
ip r
Also, when you activate the connection capture the output from
sudo tail -f /var/log/messages
or if using the systemd journalling do
sudo journalctl -f
BTW, with this being a proprietary product, you are probably best advised to get support from the vendor.
Thanks for the reply.
Result of ip a:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: p5p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 84:8f:69:b1:9f:4d brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 74:e5:0b:30:0c:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80::76e5:bff:fe30:c50/64 scope link noprefixroute
valid_lft forever preferred_lft forever
12: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 100
link/none
13: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 10.80.80.100 peer 192.0.2.1/32 scope global ppp0
valid_lft forever preferred_lft forever
ip r:
default via 192.168.1.1 dev wlan0 proto static metric 600
192.0.2.1 dev ppp0 proto kernel scope link src 10.80.80.100
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.2 metric 600
latest systemd journal entries:
Jul 06 23:16:23 xps baloo_file[2275]: QObject::connect: invalid null parameter
Jul 06 23:16:23 xps kdeinit5[2231]: QObject::connect: invalid null parameter
Jul 06 23:16:25 xps pppd[13191]: local IP address 10.80.80.100
Jul 06 23:16:25 xps pppd[13191]: remote IP address 192.0.2.1
Jul 06 23:16:25 xps NetworkManager[1551]: <info> [1530940585.1718] device (ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
Jul 06 23:16:25 xps NetworkManager[1551]: <info> [1530940585.1729] device (ppp0): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'external')
Jul 06 23:16:26 xps nscd[1300]: 1300 monitored file `/etc/resolv.conf` was deleted, removing watch
Jul 06 23:16:26 xps nscd[1300]: 1300 monitored file `/etc/resolv.conf` was created, adding watch
Jul 06 23:16:26 xps nscd[1300]: 1300 failed to add file watch `/etc/resolv.conf`: Permission denied
Jul 06 23:16:26 xps ip-up.d/sslvpnroute[13336]: Setting up DNS suffixes
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps pppd[13191]: Script /etc/ppp/ip-up finished (pid 13198), status = 0x0
So, it looks like there’s a problem with the permissions on resolv.conf.
I’d be curious if you run the following after your VPN is connected…
netfilter -f update
The above is being used to solve different situations where Network Manager is unable to configure DNS properly, could work in your case, too.
If it does owrk,
Pls submit a bug to https://bugzilla.opensuse.org including a link to this Forum thread.
TSU
Is there a package for this provided by openSUSE, or do I need to install it from source? I do not have this utility installed and zypper comes up empty.
The IP layer looks fine.
latest systemd journal entries:
Jul 06 23:16:26 xps nscd[1300]: 1300 monitored file `/etc/resolv.conf` was deleted, removing watch Jul 06 23:16:26 xps nscd[1300]: 1300 monitored file `/etc/resolv.conf` was created, adding watch Jul 06 23:16:26 xps nscd[1300]: 1300 failed to add file watch `/etc/resolv.conf`: Permission denied Jul 06 23:16:26 xps ip-up.d/sslvpnroute[13336]: Setting up DNS suffixesThe nscd (Name Server Cache) daemon is used to watch for changes in key config files, and flush the cache when needed. From the man page…
[QUOTE]The daemon will try to watch for changes in configuration files appropriate
for each database (e.g. /etc/passwd for the passwd database or /etc/hosts and
/etc/resolv.conf for the hosts database), and flush the cache when these are
changed.
However, I’m not sure where the problem comes from.
ls -l /etc/resolv.conf
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps ip-up[13200]: sh: /sbin/route: No such file or directory
Jul 06 23:16:26 xps pppd[13191]: Script /etc/ppp/ip-up finished (pid 13198), status = 0x0
The above errors are due to the fact the route command is missing. That can be cured by installing ‘net-tools-deprecated’
sudo zypper install net-tools-deprecated
So, it looks like there’s a problem with the permissions on resolv.conf.[/QUOTE]
No, that is a typo. It should be
netconfig -f update
I installed net-tools-deprecated (and rebooted), but it did not change the errors in the systemd journal. I’m still getting the
xps ip-up[13200]: sh: /sbin/route: No such file or directory
errors.
netconfig -f update
did not change anything either.
The permissions on resolv.conf are:
-rw-r--r-- 1 root users 866 Jul 7 01:40 /etc/resolv.conf
Would adding resolv.conf to the dialout group fix this problem, or would the permissions revert the next time it is updated?
Right. Actually, the openSUSE package puts route in
# whereis route
route: /usr/bin/route /bin/route
Easily fixed with a symbolic link though…
ln -s /bin/route /sbin/route
netconfig -f updatedid not change anything either.
No, I didn’t expect that to be relevant with respect to your issue.
The permissions on resolv.conf are:
-rw-r--r-- 1 root users 866 Jul 7 01:40 /etc/resolv.conf
Mine for reference
-rw-r--r-- 1 root root 830 Jul 7 16:30 /etc/resolv.conf
Sorry about the typo, and thx for posting the correction.
I’m speculating that the permissions issue is related to the fact that the error is reported only after connecting to a VPN in which case the vPN ordinarily would want to re-configure your DNS setting (to avoid name resolution leaking).
That potentially causes a permissions issue if the security context of the software used to set up the VPN is somehow running with normal User and not elevated permissions.
The command I suggested (and corrected) is supposed to support updating DNS configured using Network Manager.
I suppose although the following won’t fix your problem you could verify you don’t have any problems other than name resolution by running the following after your vpn is active
nslookup
server <vpn DNS IP address>
Followed by any FQDN you want to test. Ideally the name would be something resolvable only within your VPN but if your VPN connects to the Internet through a remote gateway you can also test Internet FQDN.
You can leave nslookup by typing
exit
Perhaps most to the point is solving your problem,
What software are you using… Are you configuring yourself in Network Manager, are you using software distributed by someone or are you setting up your VPN some other way?
TSU
The symbolic link fixed the problem. Also, the permissions on resolv.conf only lists the users group after I connect with the VPN. Prior to that, it lists root as the group owner. So, I suspect Tsu2’s speculation about not running with elevated permissions was the source of the problem and why the configuration was not done correctly. Interestingly though, NetExtender worked fine on 42.3 with none of these issues.
As expected. 
That’s really a build issue with the NextExtender software and should be reported to them as a bug. Also, they should really be migrating away from using the deprecated net-tools.
As Tony already asked, how do you invoke this VPN as a user?
It installed a desktop link in the applications menu. I just click on that and it opens up a GUI interface that I use to connect to the remote host. I’ll look into reporting the bug to them.
If you can launch it as a user (without any root credentials needed) then I assume that must run as root (via sudo), and with an entry in /etc/sudoers (configured when it is first installed perhaps).
I don’t see anything in the sudoers file that isn’t the default configuration.
And you don’t get prompted for root credentials at all when launching the NetExtender GUI? It is a user-run tool, but I wonder if when it was first installed it configured some ‘helper’ process to run as root on startup. I can only speculate here without having it installed of course.
I installed it from an rpm in zypper, so it was installed with root credentials, but no, I don’t need root credentials to run the GUI.
Now that I’ve read this SonicWall knowledge-base reference it is apparent that it relies on the pppd daemon running with root privileges, which makes sense since this daemon must create the necessary ppp0 interface, and change the routing tables needed to make this work. In order to achieve this, /usr/sbin/pppd permissions are likely configured with setuid root. This would the user-controlled GUI to launch the process in the required manner.
This can be checked with
ls -l /usr/sbin/pppd
With setuid root…
~> ls -l /usr/sbin/pppd
-rwsr-xr-x 1 root dialout 366984 Feb 20 12:51 /usr/sbin/pppd
Without setuid root…
~> ls -l /usr/sbin/pppd
-rwxr-xr-x 1 root dialout 366984 Feb 20 12:51 /usr/sbin/pppd