I use openvpn as VPN on top of a public WLAN connection with KDE network manager applet (now openSUSE 13.1, latest updates). This runs fine, but the throughput is bad compared to IPSec.
That’s why I tried to setup IPSec and, after years of trying, I finally succeeded. With two strange exceptions:
Openvpn does not ask for authentication to connect, but IPSec does. Annoying. How can I stop that? Both are system connections.
IPSec tunnel breaks down silently often. Not very private then, and you don’t easily notice the little yellow lock sign is gone. I see a time correlation to WLAN DHCP renewal, but I am not sure why this should have an impact on the VPN as long as the network parameters dont change. What I tested is that it has nothing to do with DPD (dead peer detection). Anyone knows what’s going on there and how to fix it?
IPSec tunnel breaks down silently often. Not very private then, and you don’t easily notice the little yellow lock sign is gone. I see a time correlation to WLAN DHCP renewal, but I am not sure why this should have an impact on the VPN as long as the network parameters dont change. What I tested is that it has nothing to do with DPD (dead peer detection). Anyone knows what’s going on there and how to fix it?
Examine /var/log/NetworkManager for messages relating to the VPN connection. Maybe that will help diagnose the cause.
I haven’t setup an IPsec VPN for a very long time, but if principles haven’t changed…
Prompting for credentials means that correct credentials aren’t being supplied by default. When I set up my tunnels, I had to exchange “secrets” in the form of certificates. Once those credentials are installed (or referenced) correctly, each endpoint should recognize and authenticate the other.
OpenVPN is an HTTP tunnel. In general, performance has been an issue with HTTP tunnels which many are still willing to overlook. “Real” VPNs (including but not limited to IPsec) function differently, they generally take slightly longer to initiate but perform better thereafter. The downside is that performance is related to locking up those resources continuously regardless whether there is any active traffic.
I don’t know why your VPN is unstable. Could be many causes, both under your control and not.
If performance and security are your objectives but don’t require the very high level of security IPsec provides, you can try something else.
this log file has no entries during that timeframe (although it usually does), but “journalctl -u NetworkManager --since=2014-05-26” shows basically the same (and more) info:
From here the public WLAN Guests and the VPN is active:
May 26 12:13:08 job2.job.de NetworkManager[1119]: <info> VPN plugin state changed: started (4)
Now the DHCPREQUEST for the public net got a DHCPACK:
May 26 13:05:26 job2.job.de NetworkManager[1119]: <info> (wlan0): DHCPv4 state changed bound -> renew
...
info of new but identical to previous ip config skipped
...
May 26 13:13:11 job2.job.de NetworkManager[1119]: VPNC started in foreground...
May 26 13:13:11 job2.job.de NetworkManager[1119]: <warn> VPN plugin failed: 1
May 26 13:13:11 job2.job.de NetworkManager[1119]: <info> VPN plugin state changed: stopped (6)
May 26 13:13:11 job2.job.de NetworkManager[1119]: <info> VPN plugin state change reason: 0
May 26 13:13:12 job2.job.de NetworkManager[1119]: <info> Policy set 'Guests' (wlan0) as default for IPv4 routing and DNS.
May 26 13:13:12 job2.job.de NetworkManager[1119]: <warn> error disconnecting VPN: Could not process the request because no VPN connection was active.
May 26 13:13:12 job2.job.de NetworkManager[1119]: <warn> (5) failed to find interface name for index
May 26 13:13:12 job2.job.de NetworkManager[1119]: nm_system_iface_flush_routes: assertion 'iface != NULL' failed
May 26 13:13:12 job2.job.de NetworkManager[1119]: <warn> (5) failed to find interface name for index
May 26 13:13:17 job2.job.de NetworkManager[1119]: <info> VPN service 'vpnc' disappeared
and that’s all.
I dont know why it says “VPNC started in foreground”. I did not start it at that time.
I dont know what “VPN plugin failed: 1” or “VPN plugin state change reason: 0” means.
My uneducated guess is, that the dhcp request unnecessarily overwrites vpn network infos and then restarts the vpn to repair the damage. This fails, because I am not around to (again unnecessarily) reauthenticate this.
thanks, that got me on track (and maybe fixed my problem - cannot test that now)! The IPSec credentials were correct. They are saved by the vpnc plugin. BUT changing global network settings requires authenticating to NetworkManager as root. And to avoid re-authentication on the next reconnect I have to tick a box in the connect dialog for NM to remember me. Now speculation starts again: I use fingerprint authentication but that dialog seems to remember only the empty password which then, obviously, cannot work. I now used the root password on connect once and no longer need to authenticate when starting the vpnc connection. I guess that will also allow the automatic reconnect to work when DHCP interferes, but I dont have the time now to wait for that.