Bug #6263
closed
Encryption options for every P2 on a given P1 are written to each P2 individually inside ipsec.conf with multiple P2 entries + split conn entries
Added by Jim Pingle over 8 years ago.
Updated over 4 years ago.
Description
When multiple Phase 2 entries exist, the encryption options for every P2 inside a given P1 are added to every split connection entries (IKEv1 or IKEv2 with split connections active)
For example, with three P2 entries all set for AES256-GCM-128, ipsec.conf has this in each conn entry:
esp = aes256gcm128,aes256gcm128,aes256gcm128!
The same identical option is written on each connection.
If different options are used for P2s within the same tunnel, all of them are written to each P2. So each split conn entry contains all possible P2 algorithms for any P2 on the P1, not just the selected algorithm for that specific P2 entry.
Files
- Target version changed from 2.3.1 to 2.3.2
- Affected Version changed from 2.3 to All
always been that way (well, w/strongswan, >=2.2.0). Doesn't hurt anything, not worth risking at this stage for 2.3.1.
- Target version changed from 2.3.2 to 2.4.0
might be always been that way but this is very painful... all other brand do support this properly.
I just start using pfSense and this bug cause me quite a lot of trouble. You really need to fix this
- Assignee set to Matthew Smith
- Assignee changed from Matthew Smith to Renato Botelho
Hi,
we had problems with one of our IPSecs. Sometimes it can connect, sometimes not. After a reboot of pfsense, pfsense can mostly connect.
When I read about this bug, I disabled all P2 entries except one. Now it always works...
Could it really be, that the entry with the same encryption multiple times (esp = aes256gcm128,aes256gcm128,aes256gcm128!) is making problems with the remote site? In our setup, only we establish the ipsec connection.
We be greate to see this fixed, as it can not do anything good.
thanks for your work!
- Target version changed from 2.4.0 to 2.4.1
- Target version changed from 2.4.1 to 2.4.2
- Target version changed from 2.4.2 to 2.4.3
- Target version changed from 2.4.3 to 2.4.4
Ran into this bug as well, though it appears to break things if you have too many phase 2 entries. After a certain number (currently appears to be around 85 or 90) phase 2 networks, things start becoming flakey. Sometimes the phase 2 entries at the bottom will work, and other times they don't.
If I modify the /var/etc/ipsec.conf file to make the esp config entries just have the single entry for the last few phase 2 sections, all the networks work / are stable.
If you need any additional info on our setup, let me know.
If someone can point me in the direction of what file creates the ipsec.conf file, I can take a look at it and see if I can figure out a fix. I'm going to try to get time to search for the file myself, but not sure when I'll be able to take a look.
thanks.
Looked into this and the attached patch appears to fix the issue in 2.4.2. The comparable change also corrected a 2.3.1 version.
It simply resets the $ealgoESPsp2arr variable for each phase2 entry.
I didn't look into it but it's possible that $ealgoAHsp2arr may need to be reset at the appropriate point as well. I don't have a setup that uses that so I didn't look into it.
PJ Goodwin wrote:
Looked into this and the attached patch appears to fix the issue in 2.4.2. The comparable change also corrected a 2.3.1 version.
It simply resets the $ealgoESPsp2arr variable for each phase2 entry.
I didn't look into it but it's possible that $ealgoAHsp2arr may need to be reset at the appropriate point as well. I don't have a setup that uses that so I didn't look into it.
Same fix corrected the issue on version 2.4.3, though the section moved to line 1264.
pj.
- Target version changed from 2.4.4 to 48
- Target version changed from 48 to 2.5.0
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
- Status changed from Feedback to Resolved
This looks good to me, duplicate items are no longer present.
Nice to see that this issue got resolved.
Nevertheless, I'm wondering if the changes could be backported to the branches RELENG_2_4_5 & RELENG_2_4_4? The changeset was only applied to master but those changes got reworked in the context of #9603. It would be really nice to see this patched in one of the next releases, otherwise people have to wait for 2.5/3.0.
Thanks in advance for your effort.
- Status changed from Resolved to Feedback
- Target version changed from 2.5.0 to 2.4.5
I've cherry-picked it to 2.4.5
- Status changed from Feedback to Resolved
Renato Botelho wrote:
I've cherry-picked it to 2.4.5
tested on 2.4.5.a.20200107.1903
works as expected
Also available in: Atom
PDF