Not respecting rules

Started by jaggedbagel, May 21, 2025, 11:02:48 PM

Previous topic - Next topic
Also, I don't think I actually followed this, but this is basically my setup https://docs.opnsense.org/manual/how-tos/wireguard-client-mullvad.html

Isn't what you want to achieve closer to this, based on reply #14?
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
Some hosts go through VPN, some don't.
Although instead of using an alias, you want machines in a VLAN to go through the VPN?

And one of these machines also needs local inter-VLAN?

Quote from: EricPerl on May 23, 2025, 03:53:03 AMIsn't what you want to achieve closer to this, based on reply #14?
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
Some hosts go through VPN, some don't.
Although instead of using an alias, you want machines in a VLAN to go through the VPN?

And one of these machines also needs local inter-VLAN?

Yes, I want the machines in the VLAN to go through the VPN. The solution you posted would work, but I think my ruleset would get quite a bit more complex

So for the case at hand, this is regular inter-VLAN. VPN is not used.
It's just that the source interface is isolating a set of machines that should go through the VPN provider to access the internet.

When I see this:
You cannot view this attachment.
Assuming it corresponds to rules on the interface of the source, it should be straightforward.
There are no floating rules (otherwise a line would appear below the automated ones).

Traffic should enter the source interface and exit the destination interface, both of which should show in live view when logging is consistently enabled.
In terms of troubleshooting, you might want to set a description for the rules...

NAT Port forward could take precedence though, but I don't see how it could end up with a default deny on the source interface. Do you have such rules?
As you attempt communication, can you show how that block manifests itself in the live view?