Description of problem: Attempting to follow instructions at http://www.justdailynotes.com/fortinet/linux/2014/11/24/Fortigate-IPSec-Linux-NetworkManager/ to set up VPNC to connect with fortigate firewall. journalctl --follow shows that the client successfully connects to the server, but the client immediately crashes with SIGABRT. VPNC client settings in NetworkManager are same as shown in the website example (above), with the exception that "IKE DH Group" is "DH Group 2", and PFS is "DH Group 2" also (this is how our VPN server is configured). Output from journalctl --follow (note that messages in /var/log/messages are somewhat misleading...): Dec 08 12:44:03 hostname NetworkManager[1021]: <info> Starting VPN service 'vpnc'... Dec 08 12:44:03 hostname NetworkManager[1021]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 15687 Dec 08 12:44:03 hostname NetworkManager[1021]: <info> VPN service 'vpnc' appeared; activating connections Dec 08 12:44:04 hostname NetworkManager[1021]: <info> VPN plugin state changed: starting (3) Dec 08 12:44:04 hostname NetworkManager[1021]: ** Message: vpnc started with pid 15691 Dec 08 12:44:04 hostname NetworkManager[1021]: <info> VPN connection 'metaswitch' (Connect) reply received. Dec 08 12:44:04 hostname NetworkManager[1021]: <info> (tun0): carrier is OFF Dec 08 12:44:04 hostname NetworkManager[1021]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 15) Dec 08 12:44:04 hostname NetworkManager[1021]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/14 Dec 08 12:44:04 hostname NetworkManager[1021]: <info> (tun0): No existing connection detected. Dec 08 12:44:04 hostname NetworkManager[1021]: <info> VPN connection 'metaswitch' (IP4 Config Get) reply received from old-style plugin. Dec 08 12:44:04 hostname NetworkManager[1021]: <info> VPN Gateway: [redacted] Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Tunnel Device: tun0 Dec 08 12:44:04 hostname NetworkManager[1021]: <info> IPv4 configuration: Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Internal Address: [legitimate but redacted] Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Internal Prefix: 32 Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Internal Point-to-Point Address: [legitimate but redacted] Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Maximum Segment Size (MSS): 0 Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Forbid Default Route: yes Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Internal DNS: [legitimate but redacted] Dec 08 12:44:04 hostname NetworkManager[1021]: <info> Internal DNS: [legitimate but redacted] Dec 08 12:44:04 hostname NetworkManager[1021]: <info> DNS Domain: '(none)' Dec 08 12:44:04 hostname NetworkManager[1021]: <info> No IPv6 configuration Dec 08 12:44:04 hostname NetworkManager[1021]: <info> (tun0): link connected Dec 08 12:44:04 hostname NetworkManager[1021]: <info> VPN connection 'metaswitch' (IP Config Get) complete. Dec 08 12:44:04 hostname NetworkManager[1021]: vpnc: vpnc.c:1208: lifetime_ike_process: Assertion `a->next->type == IKE_ATTRIB_LIFE_DURATION' failed. Version-Release number of selected component: vpnc-0.5.3-21.svn550.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: /usr/sbin/vpnc --non-inter --no-detach - crash_function: lifetime_ike_process executable: /usr/sbin/vpnc kernel: 3.17.4-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (2 frames) #4 lifetime_ike_process at vpnc.c:1208 #5 do_phase2_qm at vpnc.c:2795
Created attachment 965963 [details] File: backtrace
Created attachment 965964 [details] File: cgroup
Created attachment 965965 [details] File: core_backtrace
Created attachment 965966 [details] File: dso_list
Created attachment 965967 [details] File: environ
Created attachment 965968 [details] File: limits
Created attachment 965969 [details] File: maps
Created attachment 965970 [details] File: open_fds
Created attachment 965971 [details] File: proc_pid_status
Created attachment 965972 [details] File: var_log_messages
Thank you very much for your report. Just to be clear: Is this your first try using vpnc or did it work before with an older version? I assume this is an upstream bug. May I ask you to send a message on the vpnc-devel mailing list (https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel)? Unfortunately vpnc upstream is almost inactive so many missing features don't get the attention they should (given the popularity of ipsec) but posting to this list is still worth a try. We're shipping the latest svn trunk revision in Fedora (even though that doesn't mean much when it comes to vpnc) so everyone there should be able to reproduce the issue. It might be helpful to generate a debug log (using the '--debug 3' command line parameter).
Thanks for the quick response Felix. I sort of figured this was an upstream bug, but since ABRT prompted me to submit it ... This is the first time trying VPNC as a NetworkManager back-end. Since submitting this bug I've gotten the SVN sources just to be sure I could reproduce it from source. I've also enabled the debug flag in the config. Feel free to close this bug. I'll try posting to the vpnc-devel mailing list. Thanks again!
We can leave the bug open for a few days, just in case there are good news on the mailing list. Feel free to ping me if there is a good patch which we should integrate for Fedora (I'm subscribed for vpnc-devel but my free time is limited so I often skip mailing lists when reading email).
upstream discussion can be found here: http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2014-December/004143.html Workaround available via configuration, issue will be handled upstream.
Reopening this bug since there's been little activity upstream. I'll attach a patch in a minute that seems to fix this for me.
Created attachment 1043633 [details] patch -- skip parsing bogus responder lifetime payloads instead of asserting This patch seems to fix the problem for me, and seems like it ought to be safe. Instead of asserting when we hit a bogus responder lifetime payload, this just has it skip parsing it and move on. Given that the code already does that when the attribute format is bogus, this ought to be safe.
I've also sent this to the vpnc-devel mailing list, but if we could get this merged into all available shipping releases then that would also be helpful.
I'd like to see at least some (positive) response from a vpnc developer or at least someone else who has some in-depth knowledge about ipsec. In that case I'm in favor of adding the patch (ideally just updating to a newer svn revision).
Agreed -- I'm certainly no IPsec expert. Hopefully he'll chime in sometime soon and we can get some review either way.
In the meantime, I did run a couple of scratch builds with this patch for anyone who wants to help test it: epel7: http://koji.fedoraproject.org/koji/taskinfo?taskID=10234470 f22: http://koji.fedoraproject.org/koji/taskinfo?taskID=10234466
So far, I've been completely unable to get any response on the vpnc-devel mailing list. It's not terribly active, as best I can tell, and I'm unsure how to get any response from someone who has commit access to the tree. The last official release was in 2008, and the last commit to the SVN repo was over a year ago (May 2014). Felix, Do you have any idea of who has commit access to the repo so we can ask them directly to review this patch?
is possible to relaunch the scratch build in order to test the rpms? I'm experiencing the same issue, but built rpms have been deleted from koji.
Sure: https://koji.fedoraproject.org/koji/taskinfo?taskID=10586702
works here, tested on two different fc22 installs (x86 and x86_64). thanks :)
The ideal thing then would be to track down the posting to the vpnc-devel upstream mailing list and report the positive results there. Maybe if we get enough people doing so, the maintainer will merge the patch. Felix doesn't want to merge it into the Fedora package until upstream has merged it, but the pace of development there could best be described as "glacial".
> the pace of development there could best be described as "glacial". unfortunately I have to agree here. I'm a bit at a loss of what to do here: Obviously your changes are useful and help with some VPN servers. If vpnc wasn't a security-sensitive application I'd carry the extra patch without much hesitation. Christian: Maybe you can have add some guidance here?
Yeah. I completely understand not wanting to merge this patch until upstream does, especially since vpnc is security-sensitive. I also wouldn't mind hearing from someone who has more IPSec experience either. I do think this patch is reasonably harmless though, given that we ignore this payload when it's malformed in other ways. I'm just not sure what hailing frequency to use to get someone with commit access to the upstream repo to look at it.
Good day to you all, Did you ever get movement on this? The great and powerful Google directed me to your thread. I am a network administrator for a large service provider. We partner with Fortinet. Recently we had a customer migrate to our Fortigate security service. They use Ubuntu and Network Manager with the VPNc plug in. After migration to our firewall service from another service providers managed Fortigate firewall service, the only dial up clients that fail are the Linux users. My customer has working Windows, Android and Apple IOS clients on the same VPN to a Fortigate on Firmware 5.2.4. I have been working with my customer and Fortinet to resolve this. Fortinet took the stance that it is a client issue and not their problem. I would like to share some information I have. Fortinet starting in firewall firmware 5.0.8 and newer versions up to the current version are taking a more strict RFC enforcement. My hands on testing is with the vendor's software client for windows 10, the Apple IOS built in Cisco client and Ubuntu 14.04 TLS[the same version my client uses for their network] using network manager with the latest stable build of VPNc plugin. The other 2 clients work while the VPNc clients still fail to attach to Fortigates running firmware 5.0.8 and newer. The only working VPNc solution i could find with the current VPNc build was to down grade the firewall firmware to 5.0.7. I tested this and it does work. This resolves the problem with out a VPNc configuration or coding change. I am reluctant to downgrade the firewall firmware so far due to my other security concerns. If your Red Hat users are having problems, I have to assume the Fortigate is on one of the newer firmwares that were released over the last 18 months. My testing with old firmware did not crash VPNc. Thanks and looking for help, Charles Stempkovski
Hi Charles, We had the very same problem and we are running FortiOS 5.2.2. The only solution I found was the following package : ike.x86_64 : Shrew Soft VPN Client For Linux This provides the qikea client that sadly is not integrated in NetworkManager but at least Ipsec VPN works ! For the others not working Ipsec VPN plugins, Networkmanager-strongswan seems to be completely useless as nothing appears in the VPN creation wizard. Hope it will help.
Thank you Vincent With further searching i found the following url http://rolandtapken.de/blog/2015-06/how-connect-fortigate-ipsec-vpn-using-linux it is a walk through for 14.04 unbuntu and vpnc plugin vpnc-0.5.3r512. it is a walk through to manually patch it. I am about to attempt it now. If it fails i will try the Shrew soft client. Charles
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.