Still IPSec Problems with 2.2.2
-
attached screen shots of pfsense and sonicwall
-
Last night around 7:30PM PST I removed one P2, so each tunnel (15) only has one P2 running and there are no issues even after P2 lifetime (86400) expired.
Which as confirmed 2.2.2 still has issues unfortunately with IPSec and multiple P2.
-
There was an issue with using the + button to create more P2s. Unconvinced the configuration upgrade code ever fixed that.
-
I didn't clone the first P2 to create the second P2, they were all manually created.
-
We are also having the same issues. This is driving us crazy.
With 2.1.5 we had absolutely no problems.
With 2.2.2 first everything looked ok so we updated like 2 weeks ago since 2.2 was
But after some time random tunnels stopped working. We get this problem with many tunnels (but not all of them).We have like 100+ Tunnels on some sites.
The issues almost only occur between pfsense firewalls, no matter if 2.2.2 or 2.2.1.
- Sometimes after phase2 lifetime ends (we default to 3600 seconds = 1hour) no data is passed through the new tunnel
- if the subnet-mask gets changed the sad will not be deleted (you need to completely destroy ipsec with restart daemon)
- sometimes the tunnel is only established from the other side
- sometimes random sa don't get reestablished, from 20 P2-SA between to sides we have 19 or 18 working.
- when chaning ikev1 to ikev2 the established SA must manually be stopped to restart we ikev2
- This happens no matter what settings. IKEv2, IKEv1, nothing is really stable.
- with ikev2 some phase2 settings don't work at all (having subnets like 192.168.1.0/24 <-> 192.168.2.0/24 + 192.168.1.1/32 <-> 192.168.3.1/32
- This sometimes also happens with single-P2-SA (single network to network) tunnels
- 2.2.1 looks more stable than 2.2.2, we have less issues with 2.2.1 sites
The frustrating thing is that it is not reproducable. Some sites work without issues. This after years of stable VPN.
Another frustrating thing is the Log output.
It either says nothing or tells too much and did not really help to detemine the reason for connection issues (new tunnel, wrong proposals, network mismatch).The bad is, that we cannot downgrade all systems since we went from 2.1.5 to 2.2.1 and after that to 2.2.2
-
I noticed one pfsense to fortigate tunnel did not exhibit the same problems where traffic stops flowing after lifetime expiration
After more in depth review of all settings (I've been at this for weeks now and getting exhausted)
I had P2 lifetime expiration set different between pfsense and fortigate
So…I changed settings:
All remote (sonicwalls & fortigates) P1 lifetime is 28800
All remote (sonicwalls & fortigates) P2 lifetime is 3600All pfsense P1 lifetime is 28800
All pfsense P2 lifetime is 86400Each tunnel has at least 2 P2 networks, some tunnels have 4 P2 networks
It's been stable, traffic continues to flow so far even after lifetime expiration on pfsense P1 or P2
Now the question...is this safe security practices?
I don't know, but I think I can live with it for the time being.
-
I noticed one pfsense to fortigate tunnel did not exhibit the same problems where traffic stops flowing after lifetime expiration
After more in depth review of all settings (I've been at this for weeks now and getting exhausted)
I had P2 lifetime expiration set different between pfsense and fortigate
So…I changed settings:
All remote (sonicwalls & fortigates) P1 lifetime is 28800
All remote (sonicwalls & fortigates) P2 lifetime is 3600All pfsense P1 lifetime is 28800
All pfsense P2 lifetime is 86400~~Each tunnel has at least 2 P2 networks, some tunnels have 4 P2 networks
It's been stable, traffic continues to flow so far even after lifetime expiration on pfsense P1 or P2Now the question…is this safe security practices?
I don't know, but I think I can live with it for the time being.~~
Doesn't work with the sonicwalls, oh well back to research again and disabling multiple P2 networks!
-
I didn't clone the first P2 to create the second P2, they were all manually created.
The reqids should be fine in that case. Seems they end up losing their unique reqids in this circumstance. If that's the case (check "ipsec statusall" for the reqid, it should be unique on every P2), that's this: https://redmine.pfsense.org/issues/4665
-
It appears strongswan 5.3.0 fixed something where setting the reqid explicitly is no longer required to work around other issues, and omitting reqid from ipsec.conf appears to work around the conflicting reqid problem. If you're on 2.2.2 already, gitsyncing to latest RELENG_2_2 is adequate to get those changes, or just comment out both instances of these lines in /etc/inc/vpn.inc:
if (!empty($reqids[$idx])) $ipsecfin .= "\treqid = " . $reqids[$idx] . "\n";
by changing it to:
//if (!empty($reqids[$idx])) //$ipsecfin .= "\treqid = " . $reqids[$idx] . "\n";
Matching this change:
https://github.com/pfsense/pfsense/commit/afd0c1f2c9c46eaa8e496e98bea8a8e0887d504fThen go to VPN>IPsec, click Save, and stop, then start strongswan. Or just reboot to be really sure everything previous is fully cleared out.
-
I can reproduce problem very quickly
P2 lifetime dropped to 300 seconds and when it expires, traffic stops
Oh well back to 2.1.5 because 2.2.x is not production ready from my experiences so far
I have been using 2.2.1 with no problems regarding Ipsec. when i upgraded to 2.2.2 i started having this issue with multiple P2 entries. I fell back to 2.2.1 and I am back up and running with no problems. just thought I would toss that out there.