Project

General

Profile

Actions
Copy link

Feature #14630

open

FRR script hook for clearing states on routing changes

Added by Christopher de Haas over 1 year ago. Updated about 1 year ago.

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

0%

Estimated time:
Plus Target Version:

Description

I have been chasing an issue of dropped traffic, and finally found the issue. A client is repeatedly sending traffic to a network on a remote router. When the local router is booting up, it sees this traffic and tries to send it over its default route. A state entry is created for this. Then, shortly after, FRR/OSPF gets routes from the remote router (which is where the traffic should go). This change means the traffic will flow through a different interface. However, the old state is not cleared on the local router, and the traffic does not take the correct path.

The state that has to be cleared is shown in firewall states as:

WAN udp public-ip:port (internal-ip:port) -> remote-site-device-ip:port SINGLE:NO_TRAFFIC 290.421K / 0 16.8MiB / 0 B

Manually clearing this state resolves the issue, but it immediately appears again after a reboot. I expect the same would be true if routes changes dynamically, making this a high impact issue.

FRR package version: 1.3 (latest)

Actions
Copy link
 #1

Updated by Jim Pingle over 1 year ago

  • Status changed from New to Not a Bug
  • Priority changed from High to Normal

There is no event or mechanism by which that situation could be identified and acted upon.

If it were a built-in WAN/gateway/assigned VPN then it may be covered by #855 but since the intended path is via FRR there is no pfSense event that could be triggered by that. And as far as I'm aware there isn't a mechanism built into FRR that would trigger a shell script or similar when forming a neighbor adjacency.

You could add floating outbound reject firewall rules to prevent the traffic from taking a path you do not want.

Actions
Copy link
 #2

Updated by Christopher de Haas over 1 year ago

Hi Jim,

Thanks for responding to this quickly, and thanks for the floating-rule idea. I get that it can help mitigate the problem, but as I see it, it does not solve it. Routing changes generally MUST clear the old state to take effect. It could just as easily be a routing change from one valid path to another.

I am not an expert on FRR, but it seems to me that the scripting described here might be a viable hook: https://docs.frrouting.org/en/latest/scripting.html

I also imagine a lower-level OS hook must be possible. The system routing table is changed, and that must be something applications can react to. Maybe something like the route monitor described here: https://man.freebsd.org/cgi/man.cgi?route

Without cleaning old states on routing changes, I don’t see how dynamic routing could ever be possible on pfSense.

Actions
Copy link
 #3

Updated by Jim Pingle over 1 year ago

  • Project changed from pfSense Plus to pfSense Packages
  • Category changed from Routing to FRR
  • Release Notes deleted (Default)

If such extensions were possible those would require developing new features to accommodate them, adding the new functionality with (for example) a daemon to monitor and act on route changes or extending the FRR package to add in custom scripting support. Both of which are significant undertakings and would require planning and development over time.

Of the two, adding custom scripting/event support to FRR looks like it would be easier for someone to develop.

It's still not a bug, however, those are potential features that are not yet available.

Actions
Copy link
 #4

Updated by Marcos M about 1 year ago

  • Project changed from pfSense Packages to pfSense
  • Category changed from FRR to Rules / NAT
  • Status changed from Not a Bug to Duplicate
  • Affected Plus Version deleted (23.05.1)
  • Release Notes set to Default

Though the behavior can be worked around in FRR specifically with a script hook, the issue itself is more general and affects other services. See #14059.

Actions
Copy link
 #5

Updated by Marcos M about 1 year ago

  • Is duplicate of Regression #14059: Old states are still used after a route change added
Actions
Copy link
 #6

Updated by Marcos M about 1 year ago

  • Tracker changed from Bug to Feature
  • Project changed from pfSense to pfSense Packages
  • Subject changed from State not cleared after routing change to FRR script hook for clearing states on routing changes
  • Category changed from Rules / NAT to FRR
  • Status changed from Duplicate to New
  • Release Notes deleted (Default)
  • Affected Architecture deleted (All)
Actions
Copy link

Also available in: Atom PDF