Not respecting rules

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

Previous topic - Next topic
May 21, 2025, 11:02:48 PM Last Edit: May 21, 2025, 11:07:21 PM by jaggedbagel


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.

Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

 Apply the action immediately on match.

Isn't light blue the active color? Sigh, different themes...
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

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

If I remove all rules except the bottom one it still gets blocked with the auto generated rule.


May 22, 2025, 07:21:49 AM #7 Last Edit: May 22, 2025, 07:24:45 AM by undistio
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.