Is VPN kill switch rule strictly needed at Floating level?

[OPNenthu]

Regarding the rule discussed here: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html#step-11-add-a-kill-switch-optional

Does this strictly need to be a Floating rule in order to work or can it be added at the WAN interface level?  I'm assuming it's written here as a Floating rule in order to guarantee nothing overrides it, but is there another reason?

A related question: if an internal interface rule allows a packet (e.g. LAN -> WAN for some HTTPS traffic) does the packet automatically get forwarded out after NAT-ing, or does it get filtered a second time by WAN "out" rules?  I have some conflicting information about this.  ChatGPT claims that it only gets processed once at the origin interface (LAN), but in my testing I could see that the WAN "out" filter is being applied.

In case there is no outbound NAT (as in the case with IPv6 normally, not in the VPN case), does this change things?

[OPNenthu]

Potentially more AI misinformation (screenshot):

You cannot view this attachment.

It's claiming that WAN "out" rules only match when at Floating level.  Any truth, or complete garbage?

(Again, my very limited testing refutes this, but I don't trust my test.)

[Patrick M. Hausen]

NAT always happens before any filtering rules.

[OPNenthu]

Uff, yeah, I had forgotten that.

https://forum.opnsense.org/index.php?topic=36326.0

So taking NAT out of the picture, the questions left are:

1) Is WAN filtering (specifically WAN "out") guaranteed to happen on egress?  In other words, in the linked packet flow diagram above, does filtering happen again at step 11 or has the system already decided "this is good to go" in step 7.2 and lets it go out?

2) Do Floating rules get any special treatment here aside from processing order?

Thanks!

[keeka]

I may be wrong but I have feeling that was written when only floating rules provided an in/out selection. A single interface (WAN) out rule that matches on the tag should also work fine.

[OPNenthu]

Ah, interesting.  I starting using OPNsense at the tail end of 24.7 and WAN rule directionality was already present, IIRC.

So maybe it's not misinformation, just terribly outdated.

[keeka]

Ah, interesting.  I starting using OPNsense at the tail end of 24.7 and WAN rule directionality was already present, IIRC.

So maybe it's not misinformation, just terribly outdated.

In that case I may be mistaken as that is about the time I started using OPNsense regularly. I do recall some point in the past, only being able to select direction via floating rules. That may have been pfsense.

[OPNenthu]

I'm having a little trouble finding documentation to confirm that pf processes WAN filter rules (specifically WAN "out" rules) for traffic that originated and was already filtered on an internal interface.

I know from practice that it works because of this VPN kill switch rule, as one example, but also because in the past I've been able to use WAN "out" rules to block things like plain DNS and RFC1918 leaks on WAN.

I don't know why some AI sources contradict this.  I'm also confusing myself a bit because in the opposite direction (incoming connection) it's WAN that decides whether or not a packet is allowed and I don't think the receiving interface on LAN is consulted (?).

Appreciate if someone could set me straight on this.

[nero355]

I don't know why some AI sources contradict this.

Because their maintainers have been feeding them old outdated information probably...

[OPNenthu]

I'm looking for the current information, but struggling :)

I think none of the obvious sources (OPNsense docs, pfSense docs, OpenBSD pf manual, FreeBSD manual) explicitly state how this works.  The closest I've found so far is from the OpenBSD pf manual, but even that doesn't explicitly answer it.  You have to infer some things by reading between the lines.

https://www.openbsd.org/faq/pf/filter.html

Packet filtering is the selective passing or blocking of data packets as they pass through a network interface.

direction
    The direction the packet is moving on an interface, either in or out.

The part that I underlined, in combination with the fact that interface rules are directional, I **think** implies the following filter flow (NAT omitted):

Ingress:
remote client ---> [WAN]("in" rules) ---> [LAN]("out" rules) ---> local server

Egress:
local client ---> [LAN]("in" rules) ---> [WAN]("out" rules) ---> remote server

Once state is established, subsequent packets bypass the filters.

In most cases we don't use "out" filters in OPNsense, so those filter points can logically seem as though they don't exist.  (Maybe this is a source of confusion and why it's sometimes said that filtering only happens once, at the interface the packet comes in on?)

Then the reason the VPN kill switch works is because when the packet that would otherwise go the VPN gateway shows up on WAN, the rules there are evaluated because the flow doesn't match a state*.  Then, the WAN "out" rule sees the tag on the packet that was set from the VPN interface and blocks.

So, it must be filtering on all interfaces that the packet traverses, not just the interface the packet came in on.  Else this wouldn't work.

Is this all correct so far?


*not clear how floating vs. interface pf states (not rules) affect this.  Floating states are default in OPNsense, as they are also in OpenBSD's pf.

You cannot view this attachment.

pfSense is the opposite (defaults to interface bound states) and explains some potential VPN leakage problems.
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#interface-bound-states

Maybe at least the rules on the VPN interface should be manually set to interface-bound?

¯\_(ツ)_/¯

[keeka]

@OPNenthu interesting post as always.
I think my understanding is similar. Until you point out that default setting is for states to be recorded independent of interface. I had not considered this and I also wonder if this impacts effectiveness of out rules.
If a state has been established during ingress on one interface, does it mean a packet's not being examined on egress on a second interface by virtue of the existence of state? Would this impact for example flows that rely on tagging by one interface and subsequent treatment of that tag on another iface.
Do you think its the case that, if you rely on outbound rules, tagging etc, you should switch states to be bound to ifaces?
EDIT I have only just noticed there's also a 'state policy' dropdown for individual rules!