Bug 1204512 - kernel 3.19.1-201.fc21.i686+PAE breaks Juniper VPN's.
Summary: kernel 3.19.1-201.fc21.i686+PAE breaks Juniper VPN's.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 21
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: fedora-kernel-networking
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1205104 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-22 20:08 UTC by Monty Walls
Modified: 2015-03-31 21:49 UTC (History)
11 users (show)

Fixed In Version: kernel-3.19.3-200.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-31 21:49:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 90901 0 None None None Never

Description Monty Walls 2015-03-22 20:08:54 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build Identifier: 

Upgrade to kernel 3.19.1-201 and Juniper VPN no longer passes packets.
Juniper VPN: Network Connect version 7.4.13-build 32697.
Downgrade to kernel 3.18.9-200 and Juniper VPN works.


Reproducible: Always

Steps to Reproduce:
1. Install Juniper Network Connect 7.4 to connect to VPN.
2. Boot to kernel-3.19.1-201.
3. Connect to VPN, which works, now no packets pass.
Actual Results:  
NO PACKETS through the VPN.  No ping, no traceroute, no ssh....

Expected Results:  
ssh <redhat enterprise server> should give me ssh signon prompts and banner page.
ping should show transit times.

Had to fall back to previous kernel.

Comment 1 Kurt Bechstein 2015-03-23 03:31:06 UTC
I am also experiencing on the x86_64 version of the kernel as well.  It seems that the tun interface simply doesn't pass traffic once it is brought up.

Comment 2 Josh Boyer 2015-03-23 12:26:05 UTC
What kind of VPN connection is this?  Can you provide more details on the modules and setup?

Comment 3 Kurt Bechstein 2015-03-23 14:22:51 UTC
At least in my case, I am accessing a Juniper SA SSL VPN.  It has a web interface that you log into and then run a client called Network Connect that runs a java application that setups of the VPN tunnel from there.  

The tun interface seems to get brought up with no issues, but when trying to access anything that should be reachable via the tun interface nothing works.  If I reboot and boot into any previous kernel it works just fine, in that I can reach anything that should be reachable via the tunnel.  Local networking to my own lan seems unaffected, it is merely the tunnel interface that is having the issue.  Let me know if I can provide better information.

Comment 4 Monty Walls 2015-03-23 17:24:30 UTC
all IP's have been edited to remove sensitive information:
$ ip route
default via AAA.BBB.253.169 dev tun0  scope link  metric 1
default via AAA.BBB.236.1 dev wlp2s0  proto static  metric 1024
1.1.1.1 via AAA.BBB.253.169 dev tun0  scope link  metric 1
1.1.1.1 via AAA.BBB.236.1 dev wlp2s0  proto dhcp  metric 10
CCC.DDD.32.18 via AAA.BBB.236.1 dev wlp2s0  metric 1
AAA.BBB.236.0/22 via AAA.BBB.253.169 dev tun0  scope link  metric 1
AAA.BBB.236.0/22 dev wlp2s0  scope link  metric 10
AAA.BBB.236.1 dev wlp2s0  scope link  metric 1
$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         AAA.BBB.253.169 0.0.0.0         UG        0 0          0 tun0
0.0.0.0         AAA.BBB.236.1   0.0.0.0         UG        0 0          0 wlp2s0
1.1.1.1         AAA.BBB.253.169 255.255.255.255 UGH       0 0          0 tun0
1.1.1.1         AAA.BBB.236.1   255.255.255.255 UGH       0 0          0 wlp2s0
CCC.DDD.32.18   AAA.BBB.236.1   255.255.255.255 UGH       0 0          0 wlp2s0
AAA.BBB.236.0   AAA.BBB.253.169 255.255.252.0   UG        0 0          0 tun0
AAA.BBB.236.0   0.0.0.0         255.255.252.0   U         0 0          0 wlp2s0
AAA.BBB.236.1   0.0.0.0         255.255.255.255 UH        0 0          0 wlp2s0
$ lsmod
Module                  Size  Used by
tun                    26473  2 
rfcomm                 62101  14 
btusb                  31648  0 
bnep                   18829  2 
bluetooth             434574  32 bnep,btusb,rfcomm
ip6t_REJECT            12553  2 
nf_reject_ipv6         13125  1 ip6t_REJECT
xt_physdev             12523  1 
nf_conntrack_ipv6      18282  3 
nf_defrag_ipv6         26172  1 nf_conntrack_ipv6
br_netfilter           17499  1 xt_physdev
bridge                 96190  1 br_netfilter
ip6table_filter        12711  1 
stp                    12756  1 bridge
llc                    13645  2 stp,bridge
ip6_tables             17635  1 ip6table_filter
nf_conntrack_ipv4      14192  2 
nf_defrag_ipv4         12601  1 nf_conntrack_ipv4
xt_conntrack           12664  5 
nf_conntrack           86843  3 xt_conntrack,nf_conntrack_ipv4,nf_conntrack_ipv6
fuse                   84615  5 
arc4                   12536  2 
snd_hda_codec_hdmi     46611  1 
iwldvm                223666  0 
snd_hda_codec_conexant    18496  1 
snd_hda_codec_generic    61719  1 snd_hda_codec_conexant
mac80211              597522  1 iwldvm
snd_hda_intel          29328  4 
coretemp               13201  0 
kvm_intel             137650  0 
snd_hda_controller     29714  1 snd_hda_intel
kvm                   413976  1 kvm_intel
iwlwifi               122426  1 iwldvm
snd_hda_codec         112992  5 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
iTCO_wdt               13256  0 
iTCO_vendor_support    13243  1 iTCO_wdt
cfg80211              461788  3 iwlwifi,mac80211,iwldvm
snd_hwdep              13232  1 snd_hda_codec
snd_seq                55888  0 
crc32_pclmul           12987  0 
crc32c_intel           12796  0 
snd_seq_device         14093  1 snd_seq
i2c_i801               17729  0 
serio_raw              13210  0 
snd_pcm                93964  4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller
intel_ips              18019  0 
thinkpad_acpi          71968  1 
wmi                    18372  0 
snd_timer              23814  2 snd_pcm,snd_seq
snd                    63701  19 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,thinkpad_acpi,snd_seq_device
tpm_tis                18174  0 
mei_me                 19035  0 
tpm                    33912  1 tpm_tis
rfkill                 20934  5 cfg80211,thinkpad_acpi,bluetooth
mei                    71332  1 mei_me
soundcore              14128  2 snd,snd_hda_codec
lpc_ich                16877  0 
mfd_core               13022  1 lpc_ich
acpi_cpufreq           18841  1 
nfsd                  257066  1 
auth_rpcgss            52402  1 nfsd
nfs_acl                12653  1 nfsd
lockd                  77643  1 nfsd
grace                  12892  2 nfsd,lockd
sunrpc                269087  7 nfsd,auth_rpcgss,lockd,nfs_acl
binfmt_misc            17691  1 
i915                  931607  7 
i2c_algo_bit           13058  1 i915
drm_kms_helper         99065  1 i915
e1000e                207172  0 
drm                   259616  4 i915,drm_kms_helper
ptp                    18646  1 e1000e
pps_core               18587  1 ptp
video                  19334  1 i915
$
$ ifconfig -a
enp0s25: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether f0:de:f1:2a:e3:3d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf2500000-f2520000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 140  bytes 21154 (20.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 140  bytes 21154 (20.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
        inet AAA.BBB.253.169  netmask 255.255.255.255  destination AAA.BBB.253.169
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 60 (60.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet AAA.BBB.237.234  netmask 255.255.252.0  broadcast AAA.BBB.239.255
        ether 58:94:6b:3a:5a:88  txqueuelen 1000  (Ethernet)
        RX packets 884  bytes 504134 (492.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 516  bytes 99383 (97.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$$$$$
Note: I've compared these output with the same outputs from a working session and the outputs match.  So the tunnel & route assignment are normally working prior to the last kernel.

Comment 5 Josh Boyer 2015-03-24 16:34:43 UTC
*** Bug 1205104 has been marked as a duplicate of this bug. ***

Comment 6 Josh Boyer 2015-03-24 16:41:35 UTC
I've started a scratch build with the fix pointed to in the upstream bug.  Please test this kernel once it finished building and let me know if it resolves the issue for you.

http://koji.fedoraproject.org/koji/taskinfo?taskID=9311606

Comment 7 Kurt Bechstein 2015-03-24 19:33:41 UTC
I was able to install the newly built x86_64 kernel and I was able to use the VPN as before.  It definitely fixed the issue for me.

Comment 8 Kristjan Kullerkann 2015-03-24 20:40:19 UTC
Confirm as fixed with x86_64 kernel.

Comment 9 Josh Boyer 2015-03-24 22:49:20 UTC
Thanks for testing everyone.  I'll get this added to Fedora git.

Comment 10 rob glazer 2015-03-25 16:19:18 UTC
I have tested the new kernel 3.19.2.201 build with the fix and it did not work with juniper 7.4R11, which works with kernel 3.18.9-200.

These are the steps I followed to install the 3.19.2.201 kernel (first time attempting this, please let me know if this is not the correct process and I will try again):

yum install https://kojipkgs.fedoraproject.org/packages/kernel/3.19.2/201.fc21/x86_64/kernel-3.19.2-201.fc21.x86_64.rpm https://kojipkgs.fedoraproject.org/packages/kernel/3.19.2/201.fc21/x86_64/kernel-core-3.19.2-201.fc21.x86_64.rpm https://kojipkgs.fedoraproject.org/packages/kernel/3.19.2/201.fc21/x86_64/kernel-modules-3.19.2-201.fc21.x86_64.rpm https://kojipkgs.fedoraproject.org/packages/kernel/3.19.2/201.fc21/x86_64/kernel-modules-extra-3.19.2-201.fc21.x86_64.rpm

after rebooting uname -r displayed 3.19.2.201

ran juniper: connected, correctly assigned IP, no traffic allowed.

ipconfig -a showed tun0 RX packets 0 and TX packets 1

this is the same as kernel 3.19.1.201

thank you.

Comment 11 Josh Boyer 2015-03-25 16:23:11 UTC
3.19.2-201 doesn't have the patch in it.  It is expected to fail in this specific case.  The Fedora updates system will leave a link to the update that contains the fix for this issue in this bug.

Comment 12 rob glazer 2015-03-25 16:40:25 UTC
I have downloaded the patched rpms and installed - works correctly - kernel 3.19.2-201.bz1204512.fc21.x86_64

Thank you for your help.

Comment 13 Fedora Update System 2015-03-27 12:27:56 UTC
kernel-3.19.3-200.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kernel-3.19.3-200.fc21

Comment 14 Fedora Update System 2015-03-29 04:46:44 UTC
Package kernel-3.19.3-200.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.19.3-200.fc21'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4887/kernel-3.19.3-200.fc21
then log in and leave karma (feedback).

Comment 15 Fedora Update System 2015-03-31 21:49:58 UTC
kernel-3.19.3-200.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


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