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.
Same issue here. Please advice how to debug when theres no apparent error messages?
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.
openconnect's --juniper support appears to still work.
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.
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
*** Bug 1346394 has been marked as a duplicate of this bug. ***
Any updates on this? Thanks.
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.
Same problem here, both 23 and 24 are affected. Any news?
(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?
(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
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.
There seems to be a fix in upstream. Could this be implemented for fedora? https://bugzilla.kernel.org/attachment.cgi?id=222531&action=diff
(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
Seeing same behavior with same kernels F23/F24 using Dell Aventail Sonicwall VPN.
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.
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
The "echo" command in Jason's step 1 above also makes things work for the Aventail SonicWall VPN.
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.
*********** 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.
Yes, still a problem with 4.7.4-200.fc24.x86_64
Still a problem with 4.7.4-100.fc23.x86_64 as well.
For me this issue is resolved after upgrading PulseSecure Desktop client to latest (e.g 8.2 R5).
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.
Thank you, Jason. I have been suffering with Windows because I did not find this any sooner.
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.
*********** 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.
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.
both openconnect and the latest pulsesecure client work so I'm not going to bother to keep this open.
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.
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.