Bug #13076
closed
Marking a gateway as down does not affect IPsec entries using gateway groups
100%
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%.
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.
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
Updated by Jim Pingle about 2 years ago
- Status changed from New to Pull Request Review
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.
Updated by Viktor Gurov about 2 years ago
- Status changed from Pull Request Review to Feedback
Updated by Georgiy Tyutyunnik about 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
Updated by Viktor Gurov almost 2 years ago
- Status changed from Feedback to New
Updated by Jim Pingle almost 2 years ago
- Status changed from New to Pull Request Review
Updated by Viktor Gurov almost 2 years ago
- Status changed from Pull Request Review to Feedback
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.
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 errordue 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
Updated by Jim Pingle almost 2 years ago
- Status changed from New to Pull Request Review
Updated by Viktor Gurov almost 2 years ago
- Status changed from Pull Request Review to Feedback
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.
Updated by Jim Pingle almost 2 years ago
- Plus Target Version changed from 22.09 to 22.11
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.
Updated by Jim Pingle over 1 year ago
- Plus Target Version changed from 22.11 to 23.01
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.
Updated by Jim Pingle over 1 year ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset f67c3ec2946594a3679f6016716712ce74dac9c5.
Updated by Marcos M over 1 year ago
- Status changed from Feedback to Resolved
Tested on latest snap - now works correctly.