Feature #14630
open
FRR script hook for clearing states on routing changes
Added by Christopher de Haas over 1 year ago.
Updated 12 months ago.
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)
- 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.
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.
- 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.
- 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.
- Is duplicate of Regression #14059: Old states are still used after a route change added
- 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)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by