Ask Your Question
0

Juniper VPN connection does not work after upgrade to Fedora21

asked 2014-12-22 08:12:55 -0500

NicolaC gravatar image

I've updated my laptop to fedora a few days aog, using fedup. Everything went very well, except that I can no longer connect to a Juniper VPN server using the command line. I used the technique described in http://www.scc.kit.edu/scc/net/juniper-vpn/linux/ which has worked wonderfully in both Fedora19 and Fedora20. What happens is that the connection is briefly established, but after a few seconds the notification "Connection 'tun0' deactivated" appears on the NetworkManager icon and the connection is broken. The tun0 interface appears briefly in ifconfig, and then is gone. Apart from that, everything else in NetworkManager seems to be OK (no problems in detecting or connecting to WiFi networks).

A "systemctl status NetworkManager" shows the following:

Dec 21 14:08:31 localhost.localdomain NetworkManager[771]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
Dec 21 14:08:31 localhost.localdomain NetworkManager[771]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
Dec 21 14:08:31 localhost.localdomain NetworkManager[771]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Dec 21 14:08:31 localhost.localdomain NetworkManager[771]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
Dec 21 14:08:31 localhost.localdomain NetworkManager[771]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Dec 21 14:08:31 localhost.localdomain NetworkManager[771]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Dec 21 14:08:31 localhost.localdomain NetworkManager[771]: <info> Activation (tun0) successful, device activated.
Dec 21 14:08:36 localhost.localdomain NetworkManager[771]: <info> (tun0): device state change: activated -> unmanaged (reason 'removed') [100 10 36]
Dec 21 14:08:36 localhost.localdomain NetworkManager[771]: <info> (tun0): deactivating device (reason 'removed') [36]

while the connection log (ncsvc.log) shows

20141221150952.37463 ncsvc[p9893.t9893] rmon.info adding a conflicting route with a lower metric to 192.168.0.0/255.255.255.0 gw 161.72.13.14 metric 1 (routemon.cpp:861)
20141221150952.37589 ncsvc[p9893.t9893] rmon.info adding route to 0.0.0.0/0.0.0.0 with gw 161.72.13.14, metric 1, if_id 0 (routemon.cpp:872)
20141221150952.37622 ncsvc[p9893.t9893] session.info added route to dest = 0.0.0.0, mask = 0.0.0.0 (session.cpp:1336)
20141221150952.37644 ncsvc[p9893.t9893] session.info route count = 1 (session.cpp:1340)
20141221150952.37801 ncsvc[p9893.t9893] rmon.info system routes:  (routemon.cpp:257)
20141221150952.37826 ncsvc[p9893.t9893] rmon.info 0.0.0.0/0.0.0.0 gw 161.72.13.14 via 0x00000018 metric 1 (routemon.cpp:1864)
20141221150952.37849 ncsvc[p9893.t9893] rmon.info 0.0.0.0/0.0.0.0 gw 192.168.0.1 via 0x004C5255 metric 1024 (routemon.cpp:1864)
20141221150952.37871 ncsvc[p9893.t9893] rmon.info 161.72.1.27/255.255.255.255 gw 192.168.0.1 via 0x4E494E47 metric 1 (routemon.cpp:1864)
20141221150952.37892 ...
(more)
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
1

answered 2014-12-23 10:42:45 -0500

Andousto gravatar image

updated 2014-12-23 11:25:43 -0500

"20141221150957.46935 ncsvc[p9893.t9893] rmon.error Unauthorized new route to 161.72.13.0/0.0.0.0 has been added (conflicts with our route to 0.0.0.0), disconnecting (routemon.cpp:582)"

I'm having the same issue. I've tracked it down to the route monitor. Something Fedora 21 is automatically entering what it thinks is the correct route, the route monitor is picking it up, and killing the connection.

EDIT: Figured it out. You need to exclude Network Manager from touching the created interface. In /etc/NetworkManager/NetworkManger.conf:

[main] plugins=ifcfg-rh,keyfile

[keyfile] unmanaged-devices=interface-name:tun0

edit flag offensive delete link more

Comments

Wonderful! This indeed did the trick. Thanks a lot!

NicolaC gravatar imageNicolaC ( 2014-12-27 00:02:03 -0500 )edit

Did the trick for me too! thanks :)

fatdunky gravatar imagefatdunky ( 2018-01-06 06:16:37 -0500 )edit
0

answered 2015-02-03 02:53:13 -0500

Uosef gravatar image

su iptables --flush iptables -A POSTROUTING -o tun0 -j MASQUERADE -t nat iptables -A FORWARD -i tun0 -o wlp6s0 -m state --state RELATED,ESTABLISHED -j RETURN iptables -A FORWARD -i wlp6s0 -o tun0 -m state --state INVALID -j DROP iptables -A FORWARD -i wlp6s0 -o tun0 -j RETURN

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2014-12-22 08:12:55 -0500

Seen: 1,804 times

Last updated: Feb 03 '15