IPSec issues after upgrading IPFire to core 72

General questions.
User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IPSec issues after upgrading IPFire to core 72

Post by trymes » September 9th, 2013, 1:01 pm

I can confirm that I have two different systems that have been rebooted since the upgrade to Core 72, and that both are working.

If you have performed a core update before, you can likely tell which updates you installed by checking the /var/log/pakfire/ directory. Each core update performed by Pakfire leaves a log there. For the record, it appears that OpenSwan was replaced by StrongSwan in Core Update 38, so if your install was pre-core-38, then you should see this announcement. It includes a link with instructions for modifying IPSec tunnels.

I was also going to suggest that you confirm that your advanced settings do not include the larger MODP types, as that can cause trouble if there is insufficient entropy, but Core 72 changed the defaults for MODP. You might want to double-check both sides' advanced settings to make sure that they match, though.

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IPSec issues after upgrading IPFire to core 72

Post by trymes » September 9th, 2013, 1:14 pm

Also: I checked one of my hosts, and the error about " unable to load 5 plugin features (5 due to unmet dependencies)" appears in my log, too, so that should not be your problem.

fkienker
Posts: 126
Joined: March 3rd, 2011, 4:59 pm

Re: IPSec issues after upgrading IPFire to core 72

Post by fkienker » September 16th, 2013, 2:35 pm

This issue is still not going away for me. One thing I have noticed - if left alone for about 30 minutes sometimes it will reconnect. I have to disable and reenable and wait and it may reconnect. Rebooting the firewalls has no effect. Logs show a continuous stream of these exchanges:

09:34:42 charon: 16[NET] received packet: from 71.81.25.250[4500] to 199.227.23.210[4500] (80 byt es)
09:34:42 charon: 16[ENC] parsed INFORMATIONAL request 29 [ ]
09:34:42 charon: 16[ENC] generating INFORMATIONAL response 29 [ ]
09:34:42 charon: 16[NET] sending packet: from 199.227.23.210[4500] to 71.81.25.250[4500] (80 byte s)

This is all happening using previously working configurations or new configurations with the default settings. Surely I can not be the only one having these issues.

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IPSec issues after upgrading IPFire to core 72

Post by trymes » September 16th, 2013, 3:03 pm

pangu wrote:I don't remember from which version I upgraded


Can you post the contents of your /var/log/pakfire directory?

pangu wrote:Funnily, when I use my correct whole "192.168.0.0/16" as LocalSubnet within my IPsec configuration the IPsec connection won't work (tried to reset it, restart it, also manually through /etc/init.d/ipsec restart). The log says connection established, but WebGUI shows a disconnected state, and pings won't work.[/url]


This is almost certainly because you have not changed the remote side's configuration.

pangu wrote:        ike=3des-sha-modp8192,3des-sha-modp6144,3des-sha-modp4096,3des-sha-modp3072,3des-sha-modp2048,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp8192,3des-md5-modp6144,3des-md5-modp4096,3des-md5-modp3072,3des-md5-modp2048,3des-md5-modp1536,3des-md5-modp1024
        esp=3des-sha1,3des-md5


There are some known issues with using high values of MODP groups if your hardware is not able to generate enough entropy. I would suggest that you remove the largest groups, perhaps anything over 3072, and see if some or all of your issues go away. Once you have everything up and running to your liking, you can then experiment with re-enabling them.

pangu wrote:Would it make sense, to tell my remoteSite to modify the IPsec tunnel settings, so we both use (192.168.0.0/16) as Subnet for my side, so the IPsec tunnel can be established correctly. And then restrict via Firewall the access to this tunnel to subnet 192.168.101.0/24 ?? If so, how would the Firewall rule look like in WebGUI ?


I would certainly suggest that this would be the best method to accomplish what you are trying to do. At the very least, my troubleshooting process would begin with eliminating the "non-standard" pieces of your configuration, seeing if that resolves your problem, and then adding things back in.

The firewall rule would likely require a custom rule entered via the CLI, or the new firewall interface, which is in beta. Using the new GUI, I imagine that you would create two rules, one of which allowed access from the remote subnet to the IP range you want to be accessible, and another just after it that blocked access to the whole subnet. That or two rules blocking the portions of the green subnet that you do not want to be accessible. I would suggest that you start by figuring out the IPSec problems, then move on to the firewall portion of the configuration.

fkienker: Is your configuration like Pangu's in that you are only configuring the tunnel for access to a portion of your green subnet?
Last edited by trymes on September 16th, 2013, 3:06 pm, edited 1 time in total.

fkienker
Posts: 126
Joined: March 3rd, 2011, 4:59 pm

Re: IPSec issues after upgrading IPFire to core 72

Post by fkienker » September 16th, 2013, 9:13 pm

No, I'm using: 192.168.21.0/255.255.255.0

Could this be the problem, using 255.255.255.0 notation instead of /24? In the past this has not been an issue.

Another IPSEC log message which seems more ominous: "charon: received NO_PROPOSAL_CHOSEN notify error". According to the strongSwan documentation this means the tunnel will never try to be established and the current issues with no connection is to be expected.

fkienker
Posts: 126
Joined: March 3rd, 2011, 4:59 pm

Re: IPSec issues after upgrading IPFire to core 72

Post by fkienker » September 16th, 2013, 9:30 pm

FYI: I do use pre-shared keys with my IPSEC setups. This may not be what is typical for IPSEC setups as lots of folks use certificates instead.

Another potential source of the problem - from my IPSEC log:
"charon: Unable to establish a IKEv2 PSK - MAC mismatchd"

Googleing on this message produced this hit:

"I also faced same kind of issue often.
The issue might exists in identification payload coming from strongswan2 ,which differs from identification configured in Strongswan1"

This *suggests* the issues may be coming from the recent updates to strongSwan.

What is the most aggravating about all of this is sometimes I can get it connect with the current configurations. It may stay connected for up to 72 hours, then drops the connection and again refuses to reconnect.

fkienker
Posts: 126
Joined: March 3rd, 2011, 4:59 pm

Re: IPSec issues after upgrading IPFire to core 72

Post by fkienker » September 19th, 2013, 3:34 pm

Since I've stabilized my IPSEC issues (at least for the moment), I'm going to close this out with the following comments:

* Something went "haywire" during the upgrade process from 71 to 72 on MULTIPLE systems.
* By changing the submask from "255.255.255.0" to "/24" and saving it the configuration file may have been changed JUST ENOUGH to fix the problem. Maybe the "rewriting" process of the configuration settings was the key but I'll never know for sure.
* rebooting the affected firewalls after making these configuration changes SIGNIFICANTLY improved the stability of the IPSEC.
* FYI: "restart" is the only setting which should be used - "clear" just leaves a dead tunnel when it disconnects.

Overall, I've been pleased with IPFire's performance but this has been a very painful experience. More "beta testing" on my part I might have avoided all of this. I surely will no longer assume it is safe to just update systems and not worry about bad things happening.

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IPSec issues after upgrading IPFire to core 72

Post by trymes » September 19th, 2013, 4:05 pm

As a counterpoint, we had been experiencing issues where tunnels would periodically refuse to pass traffic, often in the morning. Of 22 different tunnels, 2-5 would require a restart of the connection in any given week. Changing the DPD setting to 'Hold" instead of "Restart" seems to have cleared this up, but more time is needed to confirm that the issue does not come back.

After digging around, it seems that, given the standard Kernel settings, there is minimal difference between Clear and Hold, as the default settings have the items that would normally cleared pre-cached, and they are thus not cleared.

IPFire uses StrongSWAN, but FWIW, OpenSWAN recommends that you use "Hold" for Statically defined tunnels and "Restart" for Dynamically defined tunnels. See this link.

Tom

PS: When all else fails and I am experiencing an IPSec problem, I generally delete the tunnel from both ends, and recreate it using different Local/RemoteIDs. That process has worked well in the past when I could not explain why something was not working.
Last edited by trymes on September 23rd, 2015, 3:34 pm, edited 1 time in total.

fkienker
Posts: 126
Joined: March 3rd, 2011, 4:59 pm

Re: IPSec issues after upgrading IPFire to core 72

Post by fkienker » September 19th, 2013, 5:42 pm

Your postscript was a HUGE hint! I've been using the same ID's so I didn't have to update all of our documentation for the VPN setups. You may have pointed me to the final solution and I'm going to try this asap!

But I fail to understand why deleting and then re-adding the tunnel information doesn't work - something I had tried repeatedly without success. This seems to indicate there is something not quite right "under the hood". Some settings are being left even after the tunnel setup information is deleted which isn't good.

In the mean time, till we sorted out the IPSEC issues, the most problematic client firewalls have been switched to OpenVPN. The setup isn't not particularly hard but it seems there is a performance hit and getting it configured into the QoS seems problematic. It seems "sloppy" to me especially in networks with multiple net-to-net connections but it connects quickly and does the job.

Best regards,
Fred
Last edited by fkienker on September 20th, 2013, 2:55 pm, edited 1 time in total.

User avatar
trymes
Posts: 663
Joined: February 9th, 2011, 4:10 pm
Location: New England, USA

Re: IPSec issues after upgrading IPFire to core 72

Post by trymes » September 19th, 2013, 6:45 pm

That suggestion has worked for me through many different firewall distros, so it's not unique to ipfire; glad I could help!

When ipfire upgraded to StrongSwan v5, I experienced issues with adding new tunnels, and filed this bug: https://bugzilla.ipfire.org/show_bug.cgi?id=10339 , which fixed the issue. However, nothing has changed for deleting a tunnel, and it could be that something is being left in memory, as you can see in my notes on the bug report.

As for OpenVPN, I have heard many suggest that it works well, but it always seems less "professional-grade" to me. That may be an unfair accusation, but it is an accurate reflection of my general impression.

Good luck,

Tom

Post Reply