Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1359545 - [abrt] vpnc: lifetime_ike_process(): vpnc killed by SIGABRT
Summary: [abrt] vpnc: lifetime_ike_process(): vpnc killed by SIGABRT
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: vpnc
Version: 24
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christian Krause
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:85e50963bc1c0324aa69bb97127...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-24 23:56 UTC by Sam Bristow
Modified: 2017-08-08 15:51 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1171852
Environment:
Last Closed: 2017-08-08 15:51:02 UTC


Attachments (Terms of Use)

Description Sam Bristow 2016-07-24 23:56:13 UTC
The original bug report was closed as F22 is EOL however the issue is still present in a fully up-to-date version of Fedora 24.

+++ This bug was initially created as a clone of Bug #1171852 +++

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

--- Additional comment from David Klann on 2014-12-08 14:07:49 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:50 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:50 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:51 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:52 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:53 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:54 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:55 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:55 EST ---



--- Additional comment from David Klann on 2014-12-08 14:07:56 EST ---



--- Additional comment from Felix Schwarz on 2014-12-08 16:32:38 EST ---

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).

--- Additional comment from David Klann on 2014-12-08 16:46:46 EST ---

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!

--- Additional comment from Felix Schwarz on 2014-12-08 16:51:51 EST ---

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).

--- Additional comment from Felix Schwarz on 2014-12-13 06:34:22 EST ---

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.

--- Additional comment from Jeff Layton on 2015-06-26 14:18:36 EDT ---

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.

--- Additional comment from Jeff Layton on 2015-06-26 14:20:39 EDT ---

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.

--- Additional comment from Jeff Layton on 2015-06-26 14:21:25 EDT ---

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.

--- Additional comment from Felix Schwarz on 2015-06-26 15:26:28 EDT ---

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).

--- Additional comment from Jeff Layton on 2015-06-26 15:36:07 EDT ---

Agreed -- I'm certainly no IPsec expert. Hopefully he'll chime in sometime soon and we can get some review either way.

--- Additional comment from Jeff Layton on 2015-06-28 08:23:57 EDT ---

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

--- Additional comment from Jeff Layton on 2015-07-23 19:08:42 EDT ---

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?

--- Additional comment from Matteo Brancaleoni on 2015-08-03 06:47:33 EDT ---

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.

--- Additional comment from Jeff Layton on 2015-08-03 07:36:13 EDT ---

Sure:

    https://koji.fedoraproject.org/koji/taskinfo?taskID=10586702

--- Additional comment from Matteo Brancaleoni on 2015-08-03 08:52:11 EDT ---

works here, tested on two different fc22 installs (x86 and x86_64).
thanks :)

--- Additional comment from Jeff Layton on 2015-08-03 08:59:12 EDT ---

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".

--- Additional comment from Felix Schwarz on 2015-08-03 18:28:47 EDT ---

> 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?

--- Additional comment from Jeff Layton on 2015-08-03 18:34:10 EDT ---

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.

--- Additional comment from Charles Stempkovski on 2015-12-17 18:01:23 EST ---

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

--- Additional comment from Vincent Mialon on 2015-12-17 18:26:29 EST ---

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.

--- Additional comment from Charles Stempkovski on 2015-12-17 18:59:52 EST ---

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

--- Additional comment from Fedora End Of Life on 2016-07-19 08:29:24 EDT ---

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.

Comment 1 Fedora End Of Life 2017-07-25 22:01:13 UTC
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.

Comment 2 Fedora End Of Life 2017-08-08 15:51:02 UTC
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.


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