Project

General

Profile

Actions

Bug #13076

open

Marking a gateway as down does not affect IPsec entries using gateway groups

Added by Marcos Mendoza 2 months ago. Updated about 15 hours ago.

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

0%

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

Description

Tested on 22.05.a.20220419.0600 and 22.01.

Going into the gateway config and enabling Mark Gateway as Down will make the gateway show as Offline (Forced) under Status / Gateways, however dpinger is still running for it and the Loss column shows 0.0%.

Actions #1

Updated by Marcos Mendoza 2 months ago

  • Affected Version changed from 2.7.0 to 2.6.0

Restarting dpinger does not change the behavior - it still runs and packet loss stays at 0. Forcing it as down will also not affect an IPsec tunnel using a gateway group, hence the tunnel goes down and never re-establishes on the secondary WAN.

Actions #2

Updated by Marcos Mendoza 2 months ago

  • Description updated (diff)
Actions #3

Updated by Viktor Gurov 2 months ago

  • Assignee set to Viktor Gurov
  • Target version set to 2.7.0
  • Plus Target Version set to 22.05

Going into the gateway config and enabling Mark Gateway as Down will make the gateway show as Offline (Forced) under Status / Gateways, however dpinger is still running for it and the Loss column shows 0.0%.

This seems to be the correct behavior - to terminate dpinger process, gateway monitor must be disabled.

Forcing it as down will also not affect an IPsec tunnel using a gateway group, hence the tunnel goes down and never re-establishes on the secondary WAN.

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/731

Actions #4

Updated by Jim Pingle 2 months ago

  • Status changed from New to Pull Request Review
Actions #5

Updated by Marcos Mendoza 2 months ago

  • Subject changed from Marking a gateway as down does not stop dpinger to Marking a gateway as down does not affect IPsec entries using gateway groups

Updating the title to reflect the actual issue.

Actions #6

Updated by Viktor Gurov 2 months ago

  • Status changed from Pull Request Review to Feedback
Actions #7

Updated by Georgiy Tyutyunnik 2 months ago

Tested the issue against the version below:
22.05-DEVELOPMENT (amd64)
built on Fri Apr 22 06:22:18 UTC 2022
FreeBSD 12.3-STABLE

bug still present - neither logical nor physical downing of the tier1 gateway group member leads to the IPSec tunnel's reinitiation. Only manual reconnect restores connectivity via tier2 gateway

same symptoms on the version:
2.7.0-DEVELOPMENT (amd64)
built on Fri Apr 22 06:21:00 UTC 2022
FreeBSD 12.3-STABLE

Actions #8

Updated by Viktor Gurov 2 months ago

  • Status changed from Feedback to New
Actions #9

Updated by Jim Pingle 2 months ago

  • Status changed from New to Pull Request Review
Actions #10

Updated by Viktor Gurov 2 months ago

  • Status changed from Pull Request Review to Feedback
Actions #11

Updated by Marcos Mendoza 2 months ago

Tested on 22.05.a.20220426.1313.

On a VTI P2 with keepalive checked and the P1 using a gateway group, I marked the primary gateway as down and waited 10 minutes for the connection to re-establish. The remote side saw the IP change from dynamic DNS and tried to connect to the correct IP. The gateway group side responded with received NO_PROPOSAL_CHOSEN notify error due to it still listening on the old (now forced down) WAN CARP IP.

Apr 27 20:43:57     charon     36276     15[CFG] <38> looking for an IKEv2 config for 192.0.2.244...198.51.100.3
Apr 27 20:43:57     charon     36276     15[IKE] <38> no IKE config found for 192.0.2.244...198.51.100.3, sending NO_PROPOSAL_CHOSEN 
[...]
Apr 27 20:47:16     charon     36276     11[NET] <con2|40> sending packet: from 192.0.2.4[500] to 198.51.100.3[500] (464 bytes) 

Unfortunately this is still an issue.

Actions #12

Updated by Viktor Gurov about 2 months ago

  • Status changed from Feedback to New

Marcos Mendoza wrote in #note-11:

Tested on 22.05.a.20220426.1313.

On a VTI P2 with keepalive checked and the P1 using a gateway group, I marked the primary gateway as down and waited 10 minutes for the connection to re-establish. The remote side saw the IP change from dynamic DNS and tried to connect to the correct IP. The gateway group side responded with received NO_PROPOSAL_CHOSEN notify error due to it still listening on the old (now forced down) WAN CARP IP.
[...]

Unfortunately this is still an issue.

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/765

Actions #13

Updated by Jim Pingle about 2 months ago

  • Status changed from New to Pull Request Review
Actions #14

Updated by Viktor Gurov about 2 months ago

  • Status changed from Pull Request Review to Feedback
Actions #15

Updated by Jim Pingle 26 days ago

  • Status changed from Feedback to New
  • Assignee deleted (Viktor Gurov)
  • Plus Target Version changed from 22.05 to 22.09

This still isn't working properly. I marked a gateway as down and it has no effect on IPsec. The dynamic DNS entry changed as expected, but nothing in the IPsec logs suggested it tried to restart.

Actions #16

Updated by Jim Pingle about 15 hours ago

  • Plus Target Version changed from 22.09 to 22.11
Actions

Also available in: Atom PDF