HEADS UP: IPsec Changes
-
I just committed a significant set of IPsec changes which change IPsec in some fundamental ways. Some of which are not user-visible, others which are.
The most significant thing to watch out for is to ensure that assigned IPsec VTI interface names are updated appropriately on upgrade.
Highlights of changes:
- VTI changes
- VTI Interface name format has changed (again)
- Upgrade code will update assignments appropriately, but if the old names were hardcoded in custom/manual settings somewhere, users will need to adjust them appropriately.
- Interface names are now
ipsecYwhere Y is the P2reqidwhich is unique and constant - The
reqidinconfig.xmland for connection names is a low number (e.g.24) but when applied in the strongSwan configuration and interface it is5000+reqidso5024in this example- High enough to avoid conflicts with
reqidvalues dynamically allocated by strongSwan (See https://redmine.pfsense.org/issues/12155 ) - Low enough to not approach upper limits on FreeBSD interface names (max is
ipsec32767) or FreeBSD reqid values (16383)
- High enough to avoid conflicts with
- VTI Interface name format has changed (again)
- IPsec configuration
- Vast speed improvement when applying IPsec settings ( https://redmine.pfsense.org/issues/12026 )
- P1 information is shown when editing a P2, along with a link to the relevant P1
- Slight reorganization of some P1 and P2 sections
- IKE ID and reqid values are shown in the GUI in the tunnel list and when editing to assist in matching log and status information
- strongSwan configuration changes
- Changed internal connection names to a more easily identified pattern (
conXfor P1,conX_Yfor P2 when split,X=IKE ID,Y=reqid)- This means it's easy to always find the correct matching entry in
config.xmlwithout having to match in other ways. - Helps with issues such as https://redmine.pfsense.org/issues/11910
- This means it's easy to always find the correct matching entry in
- Added comments in
swanctl.conffor P1/P2 descriptions
- Changed internal connection names to a more easily identified pattern (
- IPsec status
- Vast speed improvement on IPsec status ( https://redmine.pfsense.org/issues/11951 )
- Fixed issues with P1 descriptions not matching properly ( https://redmine.pfsense.org/issues/11910 )
- Shows P2 descriptions where possible
- Shows disconnected P2 entries ( https://redmine.pfsense.org/issues/6275 )
- Shows count of both connected and disconnected P2s
- Improvements to connect/disconnect functionality
- Links to P1/P2 edit screens from status entries
- Status output is sorted
- Connect and disconnect buttons now use AJAX
- IPsec Widget
- Widget output redesigned to show better statistics and information
- Active and total counts for P1, P2, and Mobile leases
- Full listing of P1/P2 entries with AJAX connect/disconnect buttons ( https://redmine.pfsense.org/issues/2456 )
- Various other code optimizations and speed improvements in IPsec
This should make it into snapshots soon. If you have problems with IPsec on snapshots, please start a new thread to discuss and diagnose the issues.
- VTI changes
-
J jimp pinned this topic on
-
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp The widget, status and settings options seem to have gotten a bit of love like the wireguard UI by @cmcdonald brought into play and I sincerely hope some of those ideas/changes will get into other parts of IPSec and OpenVPN(!) as well, as those are really good and bring more overview and usability (e.g. interface assignment or quick editing ones!) But great job so far!
That said, on your status page screenshot: the first P2 entry (LAN to Missy LAN) - could it be that in the first P2 of any VPN there's always the MODP setting missing? All other P2s show it just fine. I just spotted the same on a few of our current 2.5.x deployments too and was always wondering if that's some limitation or just a UI bug?
-
@jegr said in HEADS UP: IPsec Changes:
That said, on your status page screenshot: the first P2 entry (LAN to Missy LAN) - could it be that in the first P2 of any VPN there's always the MODP setting missing? All other P2s show it just fine. I just spotted the same on a few of our current 2.5.x deployments too and was always wondering if that's some limitation or just a UI bug?
That fun quirk is a part of how IPsec works, not a bug. First P2 uses the MODP from IKE. Additional P2s or rekeys use the MODP from child SA. Comes up from time to time but not so much I've added it to the docs.
I could probably auto-fill that from the P1 but I'm not sure if that would be helpful since it's not technically correct and may confuse someone if they see the "wrong" value there.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp Huh! That's one of the times I'm glad to have asked as that has totally evaded me for years. Thanks for clarifying, always thought it to be a display/UI glitch as the phase was working anyways. Never thought much of it, but great thinking to add that to the docs, I'm sure there are quite a few who are thinking that being a bug! Big thumb up!
One little additional question: is that only for IKEv2? As for IKEv1 I remember all phases to show e.g. MODP_4096 etc. that was why I though of it being a bug in the first place?
