Project

General

Profile

Actions

Bug #13723

open

dpinger doesn't renew Gateway Monitoring IP address for IPsec VTi after changing IPsec VTi subnet

Added by Azamat Khakimyanov about 2 months ago. Updated 12 days ago.

Status:
Confirmed
Priority:
Normal
Category:
Gateway Monitoring
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

Tested on 22.05

Steps to reproduce:
1. Create Routed IPsec with IPv6 addresses as a Local and Remote. In my case I used unique local address: fc00:248:250::1 and fc00:248:250::2
2. assign IPsec as an Interface and check that gateway being added and /Status/Gateways shows this gateway as Online
3. (it doesn't matter if IPsec is Down or Up) change IPsec VTi subnet. I just used fc00:248:2::1 and fc00:248:2::2 and apply these changes

so
1. Status/Interfaces shows that IPsec Vti gets correct IPs as an Interface IP and as a Gateway IP
2. Status/Routing/Gateways shows correct new IPs as a Gateway and as Monitor IP
3. Status/IPsec shows that IPsec is UP and running
4. Diagnostics/Ping I can ping new remote IP with IPsec Vti as a Source (and I see new IP as a Source)
5. in Diagnostics/Packet Capture I can capture my ICMP requests/replies

BUT
1. Status/Gateways still shows 'old' IP:fc00:248:250::2 as a Monitor IP BUT shows correct Gateway IP:fc00:248:2::2 ('gateways_status.png')
2. running Packet Capture on IPsec and on IPsec VTi shows that dpinger just stops sending ICMP requests for this gateway. And there are no dpinger messages in Gateway log about old or new gateway IP. Last message in System log was 'Saved IPsec tunnel Phase 2 configuration.'
3. dpinger is still monitoring all other gateways and /Status/Services shows that dpinger is active.

- Restarting IPsec or running Filter Reload don't help.
- Restarting dpinger fixes this issue immediately.

I saw the same issue
- when I used IPv4 addresses
- on latest 23.01-DEV (built on Mon Dec 05 06:05:03 UTC 2022)

The only strange thing I found is that both local and remote IPsec peers had the same IPv6 Link Local addresses on IPsec VTIs and in System log I saw
Dec 5 10:19:07 kernel ipsec1: manual intervention required
Dec 5 10:19:07 kernel ipsec1: DAD complete for fe80:8::7059:569:3b47:5e5f - duplicate found
Dec 5 10:19:07 kernel ipsec1: DAD detected duplicate IPv6 address fe80:8::7059:569:3b47:5e5f: NS in/out/loopback=0/1/0, NA in=1

For assigned IPsec VTIs when both IPsec peers are latest 23.01-DEV, LL IPv6 addresses are the same on both peers too.


Files

gateways_status.png (42.6 KB) gateways_status.png Azamat Khakimyanov, 12/05/2022 05:24 AM

Related issues

Related to Feature #13362: Update dynamic gateway consumers when their interface is renamedNewReid Linnemann

Actions
Actions #1

Updated by Reid Linnemann about 2 months ago

  • Assignee set to Reid Linnemann
Actions #2

Updated by Reid Linnemann about 2 months ago

This might be related to #13362, there seems to be some missing functionality for updating gateways when VTI interfaces or tunnels change.

Actions #3

Updated by Reid Linnemann about 1 month ago

  • Related to Feature #13362: Update dynamic gateway consumers when their interface is renamed added
Actions #4

Updated by Danilo Zrenjanin 12 days ago

  • Status changed from New to Confirmed

I can confirm this behavior on the 22.05 and 23.01 Beta versions.

I tried to remove the VTI interfaces before changing the IPv6 local remote address in Phase 2, but that didn't help.

Yes, restarting dpinger deamon fixes the issue.

Actions

Also available in: Atom PDF