4

At work we have to use Dell's SonicWall NetExtender software to connect to the company VPN. Some people use Windows and contractors (like myself), use whatever, which in my case is Manjaro (Arch-based) Linux. The issue is that I seem to be the only who can not connect via the client or CLI. What happens is the connection just hangs forever at Connecting to tunnel.

Diagnostic outputs:

netExtender log:

08/31/2017 10:01:32.792 [connect warn 4847] SSL_get_peer_certificate: err= (success?) self signed certificate in certificate chain 08/31/2017 10:01:32.793 [general notice 4847] Connected. 08/31/2017 10:01:32.793 [general notice 4847] Logging in... 08/31/2017 10:01:32.886 [general notice 4847] Login successful. 08/31/2017 10:01:32.928 [general error 4847] Version header not found 08/31/2017 10:01:32.928 [epc info 4847] Server don't support EPC check. Just pass EPC check 08/31/2017 10:01:33.047 [general notice 4847] SSL Connection is ready 08/31/2017 10:01:34.049 [general info 4847] Using new PPP frame encoding mechanism 08/31/2017 10:01:34.050 [general info 4847] Using PPP async mode (chosen by server) 08/31/2017 10:01:34.050 [general info 4847] Connecting tunnel...

It stays this way without errors or timeouts for however long I let it run.

journalctl -u NetworkManager seems to have no useful output for ppp, or anything related.

journalctl -b --no-pager | grep pppd:

aug 31 10:01:34 daniel-pc pppd[4893]: pppd 2.4.7 started by daniel, uid 1000 aug 31 10:01:34 daniel-pc pppd[4893]: Using interface ppp0 aug 31 10:01:34 daniel-pc pppd[4893]: Connect: ppp0 <--> /dev/pts/1 aug 31 10:01:34 daniel-pc pppd[4893]: Cannot determine ethernet address for proxy ARP aug 31 10:01:34 daniel-pc pppd[4893]: local IP address <local ip> aug 31 10:01:34 daniel-pc pppd[4893]: remote IP address <remote ip> aug 31 10:19:46 daniel-pc pppd[4893]: Modem hangup aug 31 10:19:46 daniel-pc pppd[4893]: Connect time 18.2 minutes. aug 31 10:19:46 daniel-pc pppd[4893]: Sent 80 bytes, received 0 bytes. aug 31 10:19:46 daniel-pc pppd[4893]: Connection terminated. aug 31 10:19:46 daniel-pc pppd[4893]: Exit.

The happens once I terminate the netExtender process. The same process worked previously on a previous installment of the same OS and Windows also, which is why I suspect an issue elsewhere.

Output of uname -a: Linux daniel-pc 4.9.44-1-MANJARO #1 SMP PREEMPT Thu Aug 17 08:23:52 UTC 2017 x86_64 GNU/Linux

Improve this question
2
  • I'm also experiencing this with my university, also with a self-signed certificate. My logs are essentially identical. I'm running 4.9.47-1-MANJARO. Commented Sep 6, 2017 at 13:41
  • I had the same issue after upgrading from Fedora 28 to 29. Reinstalled netExtender; fixed. Commented Nov 2, 2018 at 8:59

3 Answers 3

Reset to default
5

After trying several different methods of fixing, none working, I finally came across a forum post on the Gentoo forums about the same issue. It seems that the issue is that some files are named incorrectly and so a symbolic link needs to be created in order to successfully connect. Link to thread.

To create a symbolic link to connect with NetExtender successfully you need to:

cd /etc/ppp/ip-up.d ln -s sslvpnroute sslvpnroute.sh

This should allow you to get past the Connecting to tunnel... part. Once connected, NetExtender will create a file called sslvpnroutecleanup. You also need to link this file, so

cd /etc/ppp/ip-down.d ln -s sslvpnroutecleanup sslvpnroutecleanup.sh

Note, you can only do that once you're successfully connected to the route. These steps fixed the issue for me.

Improve this answer
1
  • Interesting. NetExtender doesn't clean up /etc/resolv.conf or systemd-resolved, so I'd been trying to do that in /etc/ppp/ip-down.d — and finding that this happened to me whenever my script didn't get run from ip-down.d, which seemed to be most of the time. Those symlinks shouldn't really be required, as any executable in ip-*.d should be running: it seems run-parts is being blocked, and instead of ensuring it does run, Dell has opted to make their own half-baked solution. Commented Mar 24, 2022 at 10:24
3

When NetExtender is installed, it patches ppp configuration files. The patches are distribution specific. When ppp is updated by the distribution, the original configuration is restored. After that, NetExtender stops working exactly with those symptoms (stopping at Connecting tunnel...). The solution is to reinstall NetExtender.

Improve this answer
2
  • 1
    Not related to the original issue, but thank you for the clarification. NE does some funky stuff on Linux. Some pretty poor design choices by them on external package use. Commented May 6, 2018 at 18:39
  • I corrected my response. It's the file contents, not the permissions. I concur w.r.t. the design choices. Why could not SonicWall open source the OS interaction code and let distros adapt and improve it? Commented May 8, 2018 at 16:05
2

I had the same Problem, but got it running on my Manjaro Linux. Here is my approach to solve the problem.

I installed the AUR package editing the PKGBUILD using the comment from liviucmg. This got me the endless "Connecting tunnel" issue after installing the package.

Then I downloaded Netexender Package from the Sonicwall Demo-Site, unpacked it, ran the installer as root with following command:

# ./install --force-install

and since then the Netextender GUI worked fine.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.