(https://preview.redd.it/not-respecting-rules-v0-p4snkqvwvr1f1.png?width=640&crop=smart&auto=webp&s=f12ede3e3f32fdf2b818e6e0854f6acad76d0941)
On one of my interfaces I have two rules one which allows traffic to a specific host and below that blocks all traffic to an alias. That alias includes the subnet that the afformentioned host is in, When I looks at the logs it shows the traffic is being blocked by the 2nd rule and I cannot figure out why.
I posted here: https://www.reddit.com/r/opnsense/comments/1kqhgy5/comment/mterkxy/?context=3 but still can't get it to work.
EDIT to add there is another rule not pictured that is an allow rule to all with a VPN gateway.
- Show the definition of the alias.
- Are you sure that it is this exact 2nd rule blocking? You said these were interface rules. There might be a floating rule of the same name/content that fires first. I say that because it looks like a standard rule to block inter-VLAN access. You can verify by disabling the rule and see if the traffic passes.
Apply the action immediately on match.
Isn't light blue the active color? Sigh, different themes...
Quote from: meyergru on May 21, 2025, 11:12:25 PM- Show the definition of the alias.
- Are you sure that it is this exact 2nd rule blocking? You said these were interface rules. There might be a floating rule of the same name/content that fires first. I say that because it looks like a standard rule to block inter-VLAN access. You can verify by disabling the rule and see if the traffic passes.
The block rule which contains the localnets alias does include the 10.0.0.0/25 subnet. I do know that it's that rule blocking the traffic based on the logs, but if I disable to block rule I still get denied by the auto generated Default deny / state violation rule
1st/last match is the bolt. yellow is typically 1st match. If themes change that...
Do you really need the block? What's the other rule that would allow traffic?
Edit: you just answered that. That block rule is useless.
Quote from: EricPerl on May 21, 2025, 11:28:05 PM1st/last match is the bolt. yellow is typically 1st match. If themes change that...
Do you really need the block? What's the other rule that would allow traffic?
Edit: you just answered that. That block rule is useless.
I don't see how the block rule is useless. There are 7 subnets in that alias that I'd prefer not to communicate. The full rules are in this screenshot(https://i.imgur.com/vLXu0BB.png)
If I remove all rules except the bottom one it still gets blocked with the auto generated rule.
Have you tried rebooting the firewall?
I find that sometimes - especially after messing with VLAN and interface assignments - some unexpected behavior can sometimes occur even after proper configuration and applying your changes - requiring a reboot to fix.
Quote from: undistio on May 22, 2025, 07:21:49 AMHave you tried rebooting the firewall?
I find that sometimes - especially after messing with VLAN and interface assignments - some unexpected behavior can sometimes occur even after proper configuration and applying your changes - requiring a reboot to fix.
Yes, I have. Issue still persists.
It seemed useless because there was not a more general allow rule below it (your OP appears to have been edited after I opened the topic).
The interface in question is 192.168.245.0/24? Is it a VPN interface?
From 192.168.245.2, you're trying to communicate with 10.0.0.39 (on some 10.0.0.0/24 interface)?
Quote from: EricPerl on May 22, 2025, 09:30:56 PMThe interface in question is 192.168.245.0/24? Is it a VPN interface?
From 192.168.245.2, you're trying to communicate with 10.0.0.39 (on some 10.0.0.0/24 interface)?
Yeah, the 2 subnets are 10.0.0.0/25 and 192.168.245.0/25. 192.168.245.0/25 is a VPN subnet that's local. It has a VPN gateway when the traffic goes out. Because of this I suspected there was some asymmetric routing, but I don't understand that either because the rule for the gateway is the last rule. Ultimately I'd like for 192.168.245.2 to be able to communicate with 10.0.0.39
I'm confused with your VPN setup. Can you explain?
Quote from: EricPerl on May 22, 2025, 11:00:27 PMI'm confused with your VPN setup. Can you explain?
Sure thing! 192.168.245.0/25 is for all intents and purposes a VPN VLAN. I have several internal clients that use that subnet. It hands out IPs via DHCP to clients on that VLAN. I also have a WAN_VPN interface. That acts as the gateway for access to the VPN provider. 10.0.0.0/25 is my LAN it does all the normal stuff, but that gateway is the through my ISP. Hopefully I explained it in a manner that's understandable.
/25 is unusual (not pointing at that as a cause).
Maybe it's a terminology issue but I'm still a little lost...
Did you follow a specific guide to set this up?
Then how does 192.168.245.0/25 fit in that guide?
When I was learning networking working for a voip company I was working with large blocks of public ips and advertising via BGP and it was always best to use the smallest subnet possible. That kind of stuck with me, even though it's silly.
I'll try to give an example to see if I can illustrate it better (don't think I followed a guide).
So say I've got a VM and I only want it to use a VPN for access to the internet, I add that to the VLAN and it gets an IP via DHCP on the 192.168.245.0/25 subnet. That client can now access the internet utilizing the VPN and it does not communicate with my LAN.
In this scenario I have such machine (rather service) that I do want to talk to my LAN. That's where the issue lies.
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 (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 (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:
vLXu0BB.png
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?