Project

General

Profile

Actions

Bug #13076

closed

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

Added by Marcos M about 2 years ago. Updated over 1 year ago.

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

100%

Estimated time:
Plus Target Version:
23.01
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 M about 2 years 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 M about 2 years ago

  • Description updated (diff)
Actions #3

Updated by Viktor Gurov about 2 years 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 about 2 years ago

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

Updated by Marcos M about 2 years 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 about 2 years ago

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

Updated by Georgiy Tyutyunnik almost 2 years 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 almost 2 years ago

  • Status changed from Feedback to New
Actions #9

Updated by Jim Pingle almost 2 years ago

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

Updated by Viktor Gurov almost 2 years ago

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

Updated by Marcos M almost 2 years 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 almost 2 years 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 almost 2 years ago

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

Updated by Viktor Gurov almost 2 years ago

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

Updated by Jim Pingle almost 2 years 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 almost 2 years ago

  • Plus Target Version changed from 22.09 to 22.11
Actions #17

Updated by aleksei prokofiev over 1 year ago

I've tested and looks like have the same issue. SG-3100 (22.05-RELEASE). When WAN1 goes down, IPsec keeps try to use old host IP from WAN1 even DynDNS updates correct new IP. Also tunnel shows established connection with old host IP. Restart the tunnel has no affect, only stop/start tunnel helps.

Actions #18

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 22.11 to 23.01
Actions #19

Updated by Jim Pingle over 1 year ago

  • Assignee set to Jim Pingle
Actions #20

Updated by Jim Pingle over 1 year ago

  • Status changed from New to In Progress

I see why this is happening, the gateway value being passed to rc.ipsec is coming through as a quoted string where the quotes are part of the string. Having rc.ipsec clean that up seems to fix it. Commit incoming.

Actions #21

Updated by Jim Pingle over 1 year ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #22

Updated by Marcos M over 1 year ago

  • Status changed from Feedback to Resolved

Tested on latest snap - now works correctly.

Actions

Also available in: Atom PDF