Project

General

Profile

Actions

Regression #14059

closed

Old states are still used after a route change

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

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Rules / NAT
Target version:
-
Start date:
Due date:
% Done:

0%

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

Description

It's possible for traffic meant to be sent over an IPsec policy tunnel to instead go out of the WAN. This can happen when for example:
  • The relevant child SA has not yet been installed.
  • The tunnel is currently disabled.
  • The IPsec service is stopped.

When this happens, states are created on the WAN. In the following example, lagg0.6 is the WAN. The top two states were created when there was an outage with the tunnel, and the bottom two states' age closely match the firewall's uptime.

all udp 10.102.242.3:5060 <- 10.103.242.116:5060       NO_TRAFFIC:SINGLE
   age 05:29:11, expires in 00:02:24, 2899:0 pkts, 1096243:0 bytes, rule 128
   id: b198066400000000 creatorid: d0dc7a29 gateway: 0.0.0.0
   origif: lagg0.10
all udp 198.51.100.234:21991 (10.103.242.116:5060) -> 10.102.242.3:5060       SINGLE:NO_TRAFFIC
   age 05:29:11, expires in 00:02:24, 2852:0 pkts, 1078191:0 bytes, rule 74
   id: b298066400000000 creatorid: d0dc7a29 gateway: 198.51.100.233
   origif: lagg0.6

all udp 10.102.242.3:5060 <- 10.103.242.117:5060       NO_TRAFFIC:SINGLE
   age 21:06:18, expires in 00:02:28, 16580:0 pkts, 3820099:0 bytes, rule 128
   id: dd08f46300000000 creatorid: d0dc7a29 gateway: 0.0.0.0
   origif: lagg0.10
all udp 198.51.100.234:57200 (10.103.242.117:5060) -> 10.102.242.3:5060       SINGLE:NO_TRAFFIC
   age 21:06:18, expires in 00:02:28, 16519:0 pkts, 3806685:0 bytes, rule 74
   id: de08f46300000000 creatorid: d0dc7a29 gateway: 198.51.100.233
   origif: lagg0.6

In 22.05 once the relevant child SA is installed, the firewall correctly replaces the states and sends the traffic through the tunnel.

In 23.01, the states remain active on WAN regardless of the child SA being installed afterwards. While the bad states exist and the child SA is installed, running a packet capture on enc0 shows the traffic makes it into the interface, but is not actually sent through the tunnel. To work around the issue, the following floating rule may be created:

Action: Block | Quick: Checked | Interface: <select all WAN interfaces> | Direction: out | Address Family: IPv4 | Protocol: Any | Source: Any | Destination: 10.0.0.0/8 (or the relevant subnet)

With this rule in place, states are prevented from being created on the WAN, and hence traffic flows correctly once the child SA is installed.

Actions #1

Updated by Chris Linstruth almost 2 years ago

I believe the change that makes this a problem where it wasn't before is that states are now created on interface "all".

Actions #2

Updated by Jim Pingle almost 2 years ago

That sort of leakage has always been a problem without rules to ensure it doesn't escape. The old states sort of masked it but it really only worked by luck (and not for all types of traffic).

IMO there may not be anything actionable here other than encouraging people to use proper rules to prevent leaks.

We could maybe come up with some automatic rules to disallow egress of traffic matching P2 selectors out WAN but that could get tricky fast.

Actions #3

Updated by Jim Pingle almost 2 years ago

  • Priority changed from High to Normal
Actions #4

Updated by Marcos M over 1 year ago

This state behavior can affect other VPN types, not only IPsec.

Edit: e.g. https://www.reddit.com/r/PFSENSE/comments/187hhkz/states_issue_with_3cx_and_yealink_phones_over/

Actions #5

Updated by Marcos M about 1 year ago

  • Subject changed from Traffic may not be sent through IPsec tunnels even after the child SA is installed to Old states are still used after a route change
  • Category changed from IPsec to Rules / NAT
  • Affected Architecture All added
Actions #6

Updated by Marcos M about 1 year ago

  • Has duplicate Feature #14630: FRR script hook for clearing states on routing changes added
Actions #7

Updated by Marcos M about 1 year ago

  • Status changed from New to Not a Bug

Related: https://redmine.pfsense.org/issues/14630, https://redmine.pfsense.org/issues/15140

It seems like some sort of route change event queue would need to be maintained (either in userspace or in pf directly) which would trigger the clearing of related states. Even so, there there may be other issues that present themselves (e.g. unintended behavior, race conditions); additionally some setups may want prefer one behavior over the other. Correcting the behavior with rules seems preferable to doing all of that.

Actions

Also available in: Atom PDF