Bug #13230


Floating rules on VPN interfaces

Added by James Chambers about 1 month ago. Updated 24 days ago.

Not a Bug
Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


With floating rules on OpenVPN and WireGuard interfaces, matching traffic doesn’t seem to return with rules that pass traffic in the out direction. My VPN works as expected without a floating rule added (allowing pfSense to use its default pass rules for outbound traffic) but if I add a floating rule passing the IPs I want to pass or any traffic in the out direction it fails to return.

I only have a small block of IP that exit, so to get around the problem, rather than passing the block of IPs I want to allow and blocking everything else I’m blocking not (!) the block of IPs I want to exit so that I don’t have to create a pass rule.

I tried changing the state type to “Sloppy” but I still had the same issue.

Actions #1

Updated by Marcos Mendoza 28 days ago

  • Status changed from New to Feedback

More information is needed to understand the issue. Is this occurring with an OpenVPN Server or Client configuration on pfSense? What are the differences on /tmp/rules.debug between a working and non-working configuration?

Actions #2

Updated by Jim Pingle 27 days ago

  • Status changed from Feedback to Not a Bug

From the general description it sounds like when using rules on assigned VPN interfaces you get reply-to so traffic returns via the expected path, and when using floating rules (or the OpenVPN or WireGuard tabs) that breaks because they can't handle reply-to.

This is as expected and is not a bug, floating and group rules can't use reply-to.

If that's not the case we'll need a lot more information, starting with the /tmp/rules.debug entries that work and those that don't.

Actions #3

Updated by James Chambers 24 days ago

That’ll be my issue then, thanks. I did wonder if that was the case.


Also available in: Atom PDF