Still IPSec Problems with 2.2.2

brumm

thank you - will my 2.2.2 configuration apply?
would be alot of work to manually configure all tunnels again.

regards
Martin

doktornotor

No, you cannot use 2.2.2 configuration. You can use the 2.0.1 one.

mkaishar

Same issues again, after lifetime expires, no traffic passing, forcing a disconnect/reconnect of ipsec enables traffic again.

anyone else having these issues?

brumm

i have even more problems. p2 only enables from one side (initiator/responder),
some p2 just do not activate automatically, manual identifier when using certificates.
rekeying problems, etc etc.

all in all absolutly unstable - ofcourse other side did not change - so it is not a problem of fortigate firewalls.

the 2.0.1 setup was now running well for years now.

regards
martin

mkaishar

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

cmb

@mkaishar:

I can reproduce problem very quickly

P2 lifetime dropped to 300 seconds and when it expires, traffic stops

Dropped lifetime on both ends or just one?

Could you share the IPsec portion of your config? Minus PSKs/certs is fine.

cmb

@brumm:

i have even more problems. p2 only enables from one side (initiator/responder),
some p2 just do not activate automatically, manual identifier when using certificates.
rekeying problems, etc etc.

Could you share the IPsec portion of your config? Minus PSKs/certs is fine.

mkaishar

@cmb:

@mkaishar:

I can reproduce problem very quickly

P2 lifetime dropped to 300 seconds and when it expires, traffic stops

Dropped lifetime on both ends or just one?

Could you share the IPsec portion of your config? Minus PSKs/certs is fine.

Both ends…sure I will put it together give me a little bit of time.

mkaishar

attached screen shots of pfsense and sonicwall

pfsense1.png_thumb

pfsense2.png_thumb

pfsense3.png_thumb

pfsense4.png_thumb

pfsense5.png_thumb

sonicwall1.png_thumb

sonicwall1a.png_thumb

sonicwall2.png_thumb

sonicwall3.png_thumb

sonicwall4.png_thumb

sonicwall5.png_thumb

sonicwall6.png_thumb

mkaishar

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.

doktornotor

There was an issue with using the + button to create more P2s. Unconvinced the configuration upgrade code ever fixed that.

mkaishar

I didn't clone the first P2 to create the second P2, they were all manually created.

tbo2k

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

mkaishar

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 3600

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

mkaishar

@mkaishar:

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 3600

All 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 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.~~

Doesn't work with the sonicwalls, oh well back to research again and disabling multiple P2 networks!

cmb

@mkaishar:

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

cmb

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/afd0c1f2c9c46eaa8e496e98bea8a8e0887d504f

Then go to VPN>IPsec, click Save, and stop, then start strongswan. Or just reboot to be really sure everything previous is fully cleared out.

jmesser

@mkaishar:

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.