Project

General

Profile

Bug #6263

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 3 years ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Category:
IPsec
Target version:
Start date:
04/25/2016
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:

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.

pfsense-bug-6263.diff (528 Bytes) pfsense-bug-6263.diff PJ Goodwin, 02/05/2018 05:41 PM

Associated revisions

Revision e9c04843 (diff)
Added by Renato Botelho 3 months ago

Fix #6263: Deduplicate encryption options on ipsec.conf

On a configuration with multiple P2, all encryption options from all P2
are added to ipsec.conf. The list could have duplicated itens when
multiple P2 use the same options. Deduplicate this list.

Revision c6220dcf (diff)
Added by Jim Pingle 3 days ago

IPsec swanctl conversion. Implements #9603

  • Converted IPsec configuration code from ipsec.conf ipsec/stroke style
    to swanctl.conf swanctl/vici style. Issue #9603
  • Split up much of the single large IPsec configuration function into
    multiple functions as appropriate.
  • Optimized code along the way, including reducing code duplication and
    finding ways to generalize functions to support future expansion.
  • For IKEv1 and IKEv2 with Split Connections enabled, P2 settings are
    properly respected for each individual P2, such as separate
    encryption algorithms. This method also fixes #6263
  • Corrected some cosmetic issues on status_ipsec.php, including changes
    that fix #8847
  • Added a "Conect Children" button to status_ipsec.php to bring up
    child SAs when a P1 is connected but P2s disconnected.
  • New GUI option under VPN > IPsec, Mobile Clients tab to enable RADIUS
    Accounting which was previously on by default. This is now disabled
    by default as RADIUS accounting data will be sent for every tunnel,
    not only mobile clients, and if the accounting data fails to reach
    the RADIUS server, tunnels may be disconnected.

Additional developer & advanced user notes:

  • For those who may have scripts which touched files in /var/etc/ipsec,
    note that the structure of this directory has changed to the new
    swanctl layout.
  • Any usage of /usr/local/sbin/ipsec or stroke must also be changed to
    /usr/local/sbin/swanctl and VICI. Note that some commands have no
    direct equivalents, but the same or better information is available
    in other ways.
  • IPsec start/stop/reload functions now use /usr/local/sbin/strongswanrc
  • IPsec-related functions were converged into ipsec.inc, removed from
    vpn.inc, and renamed from vpn_ipsec_<name> to ipsec_<name>

History

#1 Updated by Chris Buechler over 3 years ago

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

#2 Updated by Chris Buechler over 3 years ago

  • Target version changed from 2.3.2 to 2.4.0

#3 Updated by si lec about 3 years ago

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

#4 Updated by Jim Thompson almost 3 years ago

  • Assignee set to Matthew Smith

#5 Updated by Jim Thompson over 2 years ago

  • Assignee changed from Matthew Smith to Renato Botelho

#6 Updated by Cullen Trey over 2 years ago

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!

#7 Updated by Renato Botelho about 2 years ago

  • Target version changed from 2.4.0 to 2.4.1

#8 Updated by Jim Pingle about 2 years ago

  • Target version changed from 2.4.1 to 2.4.2

#9 Updated by Jim Pingle about 2 years ago

  • Target version changed from 2.4.2 to 2.4.3

#10 Updated by Jim Pingle almost 2 years ago

  • Target version changed from 2.4.3 to 2.4.4

#11 Updated by PJ Goodwin almost 2 years ago

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.

#12 Updated by PJ Goodwin almost 2 years ago

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.

#13 Updated by PJ Goodwin over 1 year ago

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.

#14 Updated by Jim Pingle about 1 year ago

  • Target version changed from 2.4.4 to 48

#15 Updated by Jim Pingle 9 months ago

  • Target version changed from 48 to 2.5.0

#16 Updated by Renato Botelho 3 months ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

#17 Updated by Jim Pingle 3 months ago

  • Status changed from Feedback to Resolved

This looks good to me, duplicate items are no longer present.

Also available in: Atom PDF