Regression #11910
closed
IPsec status tunnel descriptions are incorrect
Added by Jim Pingle over 3 years ago.
Updated about 3 years ago.
Plus Target Version:
22.01
Description
Moving from internal Redmine since this affects CE and Plus and isn't hardware-dependent.
Original description:
I'm currently seeing wrong tunnel descriptions for site to site ipsec tunnels under 'status > ipsec'.
21.05-DEVELOPMENT (amd64)
built on Thu Apr 29 12:02:40 EDT 2021
FreeBSD 12.2-STABLE
Attached are images which indicate what I'm talking about.
I've seen this for at least a few weeks since I've been testing dev builds.
It survives reboots, and upgrades, and I see the wrong tunnel name with 'ipsec statusall' as well.
See NG 6284 for the attachments.
My note:
Probably something with the shift in numbering that Renato recently worked on (#11794). In the status output that cjl tunnel is "con8" which normally would be associated with the P1 that has an ikeid of 8, but the tunnel with an ikeid of 8 is Bob. So somehow it's not forming the expected connection numbers or it's not properly checking against the right reverse mapping when doing the status.
Files
- Related to Regression #11794: IPsec VTI interface names are not properly formed for more than 32 interfaces added
- Plus Target Version changed from 21.05 to 21.09
Renato said the fix for this will need to wait for the next release
Also seeing strangeness in the IPsec dashboard widget. Customer also reporting the active tunnel counts are incorrect in the widget but I can't duplicate that.
I can replicate the active tunnel count being incorrect, as well as incorrect status, by using P1s with the option "Gateway duplicates". See attached.
Notice on the status image, con1 should have a description of "SiteA-B-IPsec WAN2" and have a different number in the IPsec VTI range.
I saw this behaviour when adding a VTI phase 2 to a system which already had a mobile IPSec tunnel defined.
Both configured to carry 0.0.0.0/0. Something over-matching there potentially.
Saw this yesterday. Customer has the following:
3 P1s, 2 were IKEv1 and 1 was IKEv2
3 P2s, the 2 for the IKEv1 were tunnel mode, the IKEv2 was vti
The status page would show the VTI as always disconnected, but there would be a duplicate of one of the IKEv1 tunnels with the same name, but had the VTI tunnel's information other than the description. If you hit disconnect on the duplicate it would disappear into the ether. If you hit connect on the VTI tunnel the duplicate would re-appear.
Kris Phillips wrote:
Saw this yesterday. Customer has the following:
3 P1s, 2 were IKEv1 and 1 was IKEv2
3 P2s, the 2 for the IKEv1 were tunnel mode, the IKEv2 was vti
The status page would show the VTI as always disconnected, but there would be a duplicate of one of the IKEv1 tunnels with the same name, but had the VTI tunnel's information other than the description. If you hit disconnect on the duplicate it would disappear into the ether. If you hit connect on the VTI tunnel the duplicate would re-appear.
It's a smaller scenario than the one I was using to reproduce. Is it possible to share a sanitized version of this config with me?
Another scenario which may be related to whatever root cause this is:
While DPD is happening, i.e. waiting for the default 5 retransmits to finish, clicking Disconnect on IPsec status page does nothing.
Also in another setup, just having two VTI tunnels seems to do the same thing. See image attached.
- Tracker changed from Bug to Regression
- Status changed from New to Confirmed
- Priority changed from Normal to High
- Affected Version set to 2.5.2
Ran into this today as well. This seems to happen with multiple VTI tunnels or a mix of VTI and Tunnel mode. I don't believe I've ever seen this when all tunnels were tunnel mode.
- Has duplicate Bug #12123: 2.5.2 Ipsec Tunnel Status Dashboard Widget - Count of active tunnels, and Inactive tunnels is wrong added
- Assignee changed from Renato Botelho to Jim Pingle
To me, I have some ideas on how to address it.
I managed to reproduce it naturally on a system here and it looks like one way this is happening is due to vtimaps making a VTI with an ifnum of 1 for example which ends up with the resulting config being con1 and ipsec1 even though the ikeid is higher (e.g. 5), and the GUI gets confused because there is another non-VTI tunnel which is, for example, con100000 because it is actually ikeid 1.
I'm working on redoing how all of this is handled (ipsec config names, ikeid, reqid, VTI interface numbering) in a fundamental way which will fix this and several other issues at the same time.
- Status changed from Confirmed to In Progress
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
It seems this also prevents newly-added tunnels from coming up unless the VTI is disabled. Do we have an ETA on a fix yet?
Thank you!
Charles Hamilton wrote in #note-18:
It seems this also prevents newly-added tunnels from coming up unless the VTI is disabled. Do we have an ETA on a fix yet?
That should be fixed along with everything else in snapshots. Try it there.
That should be fixed along with everything else in snapshots. Try it there.
Confirmed! 21.09.a.20210806.0100 fixes the issue. Is there an official release date for 21.09 yet?
Thanks!
- File error1.PNG added
- File error2.PNG added
- File deleted (
error1.PNG)
- File deleted (
error2.PNG)
- Status changed from Feedback to Resolved
This is all working correctly now on current IPsec code.
- Plus Target Version changed from 21.09 to 22.01
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
