Bug 1343091 - Juniper VPN doesn't pass traffic after update to kernel 4.5.5
Summary: Juniper VPN doesn't pass traffic after update to kernel 4.5.5
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1346394 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-06 13:24 UTC by Andy Wang
Modified: 2017-08-08 14:46 UTC (History)
23 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-08 14:46:19 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 121131 0 None None None 2016-07-06 13:43:05 UTC

Description Andy Wang 2016-06-06 13:24:34 UTC
Description of problem:
Juniper VPN stops working after 

Version-Release number of selected component (if applicable):
kernel-4.5.5-201.fc23.x86_64

How reproducible:
Always

Steps to Reproduce:
1. boot to 4.5.5-201
2. launch juniper vpn


Actual results:
ip address is assigned and tun0 interface is properly created but no traffic is passed

Expected results:
expected to work

Additional info:
I haven't checked if openconnect works yet, and I see no obvious errors or logging of any kind.  Reverting to kernel-4.4.9-300.fc23.x86_64 works fine.

Comment 1 Kristjan Kullerkann 2016-06-09 07:19:00 UTC
Same issue here.
Please advice how to debug when theres no apparent error messages?

Comment 2 Monty Walls 2016-06-10 22:18:00 UTC
From the outside, it looks like a regression on: https://bugzilla.redhat.com/show_bug.cgi?id=1204512. 

Falling back to 4.4.9-300 works, and the ip route from the working session matches the ip route from the non-working session.  tun0 is passing 0 packets.

Comment 3 Andy Wang 2016-06-12 12:57:51 UTC
openconnect's --juniper support appears to still work.

Comment 4 Vitor 2016-06-19 06:30:12 UTC
I started seeing this too on 4.5.x kernels. A few additional details:

1. This page has a good overview of this vpn client:

   http://mad-scientist.us/juniper.html

I don't use any java or other script but run the client binary "ncsvc" directly, to this is about the 32 bit binary.

2. The tunnel interface and routing table are set-up by the 32-bit binary "ncsvc". On the surface everything is set up fine: tunnel interface, routes, dns, and so on. But no packet can go through the tunnel interface "tun0", as per a simple tcpdump monitoring, when running a 4.5.x kernel. With the most recent 4.4.x it works fine.

3. Every time a 4.5.x kernel is booted, the (only) tip in ncsvc.log of something possibly amiss is the consistent message

   "ncsvc[p3661.t3661] adapter.warn Bad ip packet len 48 - should be 0 (adapter.cpp:184)"

That's a bit cryptic to me, but allowed me to find this very similar scenario:

   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/677343

4. Unfortunately, openconnect might not be an alternative option to the proprietary juniper client because many institutions use two-factor auth or other intermediate auth methods that not always play well with openconnect.

Comment 5 Miguel Costa 2016-06-20 13:25:08 UTC
same here, after upgrading to 4.5 no traffic goes through tun0 and ncsvc outputs "adapter.warn Bad ip packet len 48 - should be 0 (adapter.cpp:184)", falling back to 4.4 works

Comment 6 Yaroslav 2016-06-20 15:17:57 UTC
*** Bug 1346394 has been marked as a duplicate of this bug. ***

Comment 7 Yaroslav 2016-06-29 14:03:03 UTC
Any updates on this? Thanks.

Comment 8 Peter van Hooft 2016-07-03 10:10:46 UTC
I have exactly the same problem but then with Dell Sonicwall Aventail.
The correct routes are assigned to tun0, and I see DNS going out to it, but no answer is ever received. I also can't ping hosts by ip address on the other side of the tunnel.

Comment 9 fixmetal 2016-07-04 21:12:54 UTC
Same problem here, both 23 and 24 are affected. Any news?

Comment 10 Josh Boyer 2016-07-04 22:21:03 UTC
(In reply to fixmetal from comment #9)
> Same problem here, both 23 and 24 are affected. Any news?

Does this still happen with 4.6.3 on f24?

Comment 11 Miguel Costa 2016-07-05 02:12:36 UTC
(In reply to Josh Boyer from comment #10)
> (In reply to fixmetal from comment #9)
> > Same problem here, both 23 and 24 are affected. Any news?
> 
> Does this still happen with 4.6.3 on f24?

yes

Comment 12 Michael Wills 2016-07-07 13:47:48 UTC
Please let me know if I can provide any additional information as I'm having the same issue.

Tested:  

Kernel versions:  4.5.7-200, 4.5.7-202 on fc23     4.6.3 on fc24  
Adapters:  Same behavior with both wired [Intel e1000e]  and wireless [Qualcomm Atheros ath10k_pci])

Client:  Using msjnc's Perl wrapper for NetworkConnect

Behavior:  No packets are passed through the tunnel interface (tun0). However the interface is brought up and the routing is added. Disabling firewalld and adjusting the routing has no effect on usability.

Currently using 4.4.9-300 too as a workaround.

Comment 13 Kristjan Kullerkann 2016-07-12 19:06:13 UTC
There seems to be a fix in upstream. Could this be implemented for fedora?

https://bugzilla.kernel.org/attachment.cgi?id=222531&action=diff

Comment 14 Josh Boyer 2016-07-12 19:28:24 UTC
(In reply to Kristjan Kullerkann from comment #13)
> There seems to be a fix in upstream. Could this be implemented for fedora?
> 
> https://bugzilla.kernel.org/attachment.cgi?id=222531&action=diff

Not yet.  They're still actually discussing it upstream.

http://marc.info/?l=linux-netdev&m=146824838121564&w=2

Comment 15 Clay Haapala 2016-07-20 13:23:49 UTC
Seeing same behavior with same kernels F23/F24 using Dell Aventail Sonicwall VPN.

Comment 16 Jason Elwell 2016-07-27 20:06:56 UTC
Same issue here.  Using 4.4.9-300.fc23.x86_64 as a backup to get it working again.  (yes, I've upgraded to F24, but using an F23 kernel)

To reiterate, the network plumbing looks right, tun0 comes up, and the appropriate routes get applied, but no traffic flows.

If there is anything of use I can supply, please let me know.

Comment 17 Jason Elwell 2016-07-27 20:34:41 UTC
After reading https://bugzilla.kernel.org/show_bug.cgi?id=121131, this can be worked around, at least for Juniper gear.  The steps are as follows:

1. As root:
   echo 0 > /proc/sys/net/ipv6/conf/default/router_solicitations
2. Establish VPN, which should now work properly.

I can live with that... 

But, after a quick test, it _appears_ that disabling IPv6 altogether, also, makes things work.  YMMV Again, as root:
    echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Comment 18 Clay Haapala 2016-08-04 01:10:24 UTC
The "echo" command in Jason's step 1 above also makes things work for the Aventail SonicWall VPN.

Comment 19 Peter van Hooft 2016-08-15 04:02:58 UTC
The 'echo 0 > /proc/sys/net/ipv6/conf/default/router_solicitations' trick works for Dell Sonicwall Aventail as well. Note that my ISP provides native IPv6.

Comment 20 Laura Abbott 2016-09-23 19:29:18 UTC
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

Comment 21 Andy Wang 2016-09-24 03:48:22 UTC
Yes, still a problem with 4.7.4-200.fc24.x86_64

Comment 22 Peter van Hooft 2016-09-27 19:15:44 UTC
Still a problem with 4.7.4-100.fc23.x86_64 as well.

Comment 23 Kristjan Kullerkann 2016-09-30 05:32:38 UTC
For me this issue is resolved after upgrading PulseSecure Desktop client to latest (e.g 8.2 R5).

Comment 24 rafael hinojosa palmer 2016-10-31 16:54:28 UTC
The problem still in kernel 4.7.9-200, Arch have a same problem, and ins this wiki show the same problem for the ncsvc since kernel 4.5 to 4.8.

Comment 25 rafael hinojosa palmer 2016-10-31 16:54:45 UTC
The problem still in kernel 4.7.9-200, Arch have a same problem, and ins this wiki show the same problem for the ncsvc since kernel 4.5 to 4.8.

Comment 26 Jose Mendoza 2016-11-04 21:44:14 UTC
Thank you, Jason. 
I have been suffering with Windows because I did not find this any sooner.

Comment 27 Jose Mendoza 2016-11-04 21:55:46 UTC
for the record, This started happening for me on Fedora 24 gnome 3 kernel 4.7.6-200 and was last running 4.8.4-200.fc24.x86_64.

Comment 28 Justin M. Forbes 2017-04-11 14:44:39 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs.

Fedora 25 has now been rebased to 4.10.9-100.fc24.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.

If you experience different issues, please open a new bug report for those.

Comment 29 Fedora End Of Life 2017-07-25 21:01:20 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 30 Andy Wang 2017-07-27 03:33:39 UTC
both openconnect and the latest pulsesecure client work so I'm not going to bother to keep this open.

Comment 31 Clay Haapala 2017-08-07 19:11:42 UTC
SSL VPN clients such as Aventail/SonicWall still fail to pass traffic on Fedora 26, 4.11.10 kernel. (Note that connections appear successful.)

The hack:
echo 0 > /proc/sys/net/ipv6/conf/default/router_solicitations
still allows the VPN client to pass traffic.

Comment 32 Fedora End Of Life 2017-08-08 14:46:19 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.