OPNsense Forum

English Forums => General Discussion => Topic started by: t84a on April 12, 2025, 09:08:31 PM

Title: Blocking/Allowing InterInterface Traffic
Post by: t84a on April 12, 2025, 09:08:31 PM
I have 5 Interfaces
LAN 1 Private
LAN 2 Home
LAN 3 Cameras
PORT 4 Null
WAN 1
Wan 2

I want to block traffic from LANs 2 and 3 to the other LANs.  Is this the default?

I want to allow traffic from LAN 1 to the other LANs. I think Eric already answered this.

Thanks
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: viragomann on April 12, 2025, 10:04:55 PM
Out of the box, OPNsense only allows access to any on LAN (the internal LAN). On all other interfaces you need to add pass rules to allow traffic by yourself.
If you have added a pass rule to allow internet access (destination: any) this also allow access to the other subnets. The you need to block access to internal subnets with a block rule above of this.

Remember that the firewall rules are probed from the top to the bottom. If one matches it is applied and rules below are ignored then.

Best practice to block access to all local subnets is o create an alias with all RFC 1918 network ranges included, and use it in the block rule.
However, since this also will block possibly desired access to e.g. DNS or NTP on the interface IP, you need to add a pass rule for these services and put it above of the block RFC 1918 rule.

With a RFC 1918 alias your block rule will still be save if you change a subnet or add one in the future.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on April 12, 2025, 10:46:11 PM
You don't really need block rules if you allow more carefully. Here's my default set on my TEST interface:
Screenshot 2025-04-12 133549 OPN Test rules.png

You don't have to include all RFC1918 networks, just the ones you use (or plan to use).
Other appropriate names for the alias are "my_networks" or "private_networks".

The first rule allows access to anything but these private networks.
The second rule is added to allow access to DNS at the gateway for that network.

More granular inter-VLAN traffic can be allowed with more rules.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 03:34:20 PM
I'm still struggling with this. I set up the Private Network rule just as posted for LAN2 and I lost Internet and my smart devices went offline. What am I missing?
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 07, 2025, 04:22:12 PM
Maybe a dumb question to ask, but you did not specify how you configured your interfaces: Are LAN 1-3 bridged (and if so: correctly?) or are those different/disjoint subnets (i.e. "physical" VLANs)?

If they are "VLANs", each with a different subnet, you first have to create an "allow" all rule for them, because it will only be present fpr the first LAN. That way, you get internet access, but also access to any other (V)LAN. On the "low privilege" VLANs, you will have to insert a block rule with a target of the RFC1918 alias preceeding the "allow all" rule. This way, such a VLAN will not have access to any RFC1918 network - thus, your other VLANs.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 05:26:50 PM
Quote from: meyergru on May 07, 2025, 04:22:12 PMMaybe a dumb question to ask, but you did not specify how you configured your interfaces: Are LAN 1-3 bridged (and if so: correctly?) or are those different/disjoint subnets (i.e. "physical" VLANs)?

If they are "VLANs", each with a different subnet, you first have to create an "allow" all rule for them, because it will only be present fpr the first LAN. That way, you get internet access, but also access to any other (V)LAN. On the "low privilege" VLANs, you will have to insert a block rule with a target of the RFC1918 alias preceeding the "allow all" rule. This way, such a VLAN will not have access to any RFC1918 network - thus, your other VLANs.


Fantastic question.  I did not bridge my LANs.  They are not VLANs.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 07, 2025, 06:35:36 PM
I know that they are not VLANs, that is why I said "physical" VLANs. I subsume with that all (V)LAN interfaces that are set up correctly with non-overlapping RFC1918 IP ranges.

What I want to rule out is that you tried to configure all interfaces equally like some newbies then wondering why nothing works. So, if you have different subnets on your LANs like described here (https://forum.opnsense.org/index.php?topic=47099.0), you only have to do it as I explained above. If that does not work, show your interface configurations and your firewall rules.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 07, 2025, 08:03:11 PM
The primary troubleshooting tool is the FW live view. Filter down to an interface or source or destination based on what you are trying to do.
Check that the live view matches your expectations.
If you have issues interpreting the displayed info, screenshot it.

Of course, the above is predicated on logging being enabled on the rules (and in FW settings for some of the default rules).

Alias content:
Screenshot 2025-05-07 110126.png
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 08:15:52 PM
Quote from: meyergru on May 07, 2025, 06:35:36 PMI know that they are not VLANs, that is why I said "physical" VLANs. I subsume with that all (V)LAN interfaces that are set up correctly with non-overlapping RFC1918 IP ranges.

What I want to rule out is that you tried to configure all interfaces equally like some newbies then wondering why nothing works. So, if you have different subnets on your LANs like described here (https://forum.opnsense.org/index.php?topic=47099.0), you only have to do it as I explained above. If that does not work, show your interface configurations and your firewall rules.

Sorry, I meant that I do not use VLANS.  I originally set up all the interfaces to have this rule.  I had no problems but I don't think that I am preventing LAN2 and LAN3 from accessing LAN1 or each other. 

I'll have to work on this: "Do not use 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.88.0/24, 192.168.100.0/24 or 192.168.178.0/24 for your (V)LAN subnets."

Thanks
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 08:24:19 PM
Quote from: EricPerl on May 07, 2025, 08:03:11 PMThe primary troubleshooting tool is the FW live view. Filter down to an interface or source or destination based on what you are trying to do.
Check that the live view matches your expectations.
If you have issues interpreting the displayed info, screenshot it.

Of course, the above is predicated on logging being enabled on the rules (and in FW settings for some of the default rules).

Alias content:
Screenshot 2025-05-07 110126.png

Blocking a camera in my crawlspace:
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 07, 2025, 09:00:34 PM
That fw block may be due to state violations or because you have no outbound NAT. Judging from the varying destination ports with always the same source port, this looks like return traffic. Have you tried connecting anything else to that network and to make outbound internet connections, say, HTTP traffic?
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 09:10:52 PM
Quote from: meyergru on May 07, 2025, 09:00:34 PMThat fw block may be due to state violations or because you have no outbound NAT. Judging from the varying destination ports with always the same source port, this looks like return traffic. Have you tried connecting anything else to that network and to make outbound internet connections, say, HTTP traffic?

When I connect using my phone. Port 3
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 07, 2025, 09:15:47 PM
So it seems any outbound traffic gets blocked. Of course, the blocked traffic would not be allowed be the actual fw rule you presented, because it is for another interface. You did set up outbound NAT and you got the part about non-overlapping RFC1918 ranges?

It sure looks like you did the NAT and firewall rules correct, so it must be something that would be obvious, but you did not set up.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 09:17:22 PM
Quote from: meyergru on May 07, 2025, 09:15:47 PMSo it seems any outbound traffic gets blocked. Of course, the blocked traffic would not be allowed be the actual fw rule you presented, because it is for another interface. You did set up outbound NAT?
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 07, 2025, 09:46:30 PM
Do the clients get their IPs and netmasks plus DNS server via DHCP? Your phone being connected via WiFi does not show if it has an IP/netmask or if it can resolve DNS.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 09:58:01 PM
Quote from: meyergru on May 07, 2025, 09:46:30 PMDo the clients get their IPs and netmasks plus DNS server via DHCP? Your phone being connected via WiFi does not show if it has an IP/netmask or if it can resolve DNS.

Yes
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 07, 2025, 10:10:27 PM
If that is true, I don't know what could be wrong. You say:

a. The interfaces are set up correctly with an IP and an RFC1918 network/netmask. None of these ranges overlap. You did. not  block bogons or RFC1928.
b. The clients are configured via DHCP and they get an IP in the correct range with the correct netmasks and gateway and you have verified them to get these.
c. They also can resolve names via DNS (which is strange considering the same firewall rule is used to DNS access and outbound traffic).
d. NAT is set to automatic, which should be just fine, unless your routing is broken because of wrong gateways or netmasks.
e. Outbound firewall rules "allow all" are in place. There are no overriides in the floating rules.

Yet no external IP can be reached, effectively no rules seem to match, which is why the default deny all rule blocks traffic.

I would go over each and every of these settings again, if I were you, because something does not add up.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 07, 2025, 10:25:05 PM
This thread is not focused (1 interface, then another). We might want to concentrate on one use case, fix it, then move on to the next.

A few observations:
O1: The OP indicated 2 WAN interfaces. Multi-WAN is its own can of worms. Is it currently used?
O2: The rule in post #8 does not have logging enabled. it won't show up in logs.
O3: The screenshot in post #11 looks like accessing the Wi-Fi hotspot of the camera. Is that the case?
If your phone is connected to it, what's surprising here? It's entirely between the camera and the phone, isolated from everything.
O5: This kind of FW output is difficult to interpret without context. You should know what the local IP maps to (a camera?).
The destination seems to be an AWS EC2 node. Is there a website you can connect to to view what your camera is streaming?
How was this setup? Reply traffic would imply a Port Forward from your FW to the camera. Does that exist?
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 07, 2025, 10:42:55 PM
1 have 3 interfaces.  LAN1 I want full access to LAN2 and LAN3.  LAN2 and LAN3 should be set up identically so they can access the internet only and specifically not be able to access LAN 1.

O1. I have 2 WAN ports but only one connected.  I have T Mobile as a backup provider but it's metered so I don't want to connect it until I figure out WAN Failover.  In Untangle, it was simple and automatic.
O2. I enable logging by clicking on it i and Apply.  It resets.  Why?  I have no idea.  You had me enable logging before. Post #9 shows blocking.
O3. Not a hotspot, an access point connected to OPNSense.  That access point is wired to Port 3.
O5. I'm not sure that matters.  When I connect to LAN2 or LAN3 from my PC, I get no internet access unless I put in a rule for Pass All.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 07, 2025, 11:29:14 PM
OK, let's sort out outbound first on either LAN2 or LAN3, then reproduce on the other.

If you can, let's keep the Wireless AP out of the loop for now. We can add it when wired works.

It looks like you've established that a pass all works. That's something.
OTOH, it doesn't match your requirements (you want Internet only). Let's fix that.
That's precisely what the 2 rules in reply #2 should achieve.
Is the alias you use similar to the one I showed in reply #7?

If you still have issues, show the resulting rules from your side, for the interface you choose to fix first.
A screenshot from the interfaces > overview can't hurt either (you can blank out the public IPs). We can double-check IP ranges.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: cookiemonster on May 08, 2025, 12:20:59 AM
I suggest if you don't mind me intervening, to clear one or two steps behind. To basics. (Sorry Eric to interfere)
meyergry has tried but the responses have only implied an answer. Not that clear that those basics are correct.
I'm referring to each interface being setup as we expect it. Has a valid range and dhcp setup.
OP - can you confirm the IP ranges of each interface (that would save having to show screenshots). And that each has dhcp setup, and DNS enabled also on each.
Thinking is that the right rules will be set as per the latest suggestion from EricPerl but they won't be of much use if these settings aren't yet correct.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 08, 2025, 01:34:58 AM
I interfere here and there too. No issues with me. With many of us in different time zones, I don't mind when someone takes over. I'm about done for a while...
I was hopeful wrt IP ranges and DHCP because of this:
Quote from: t84a on May 07, 2025, 10:42:55 PM...
O5. I'm not sure that matters.  When I connect to LAN2 or LAN3 from my PC, I get no internet access unless I put in a rule for Pass All.
In all fairness, I asked for a screenshot because one recent "long" threads ended with an erroneous /16 and the OP didn't know it was wrong...
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 08, 2025, 02:24:41 AM
DHCP. DNS Servers are left blank.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 08, 2025, 02:27:36 AM
Interface Overview
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 08, 2025, 04:05:30 AM
Nothing jumps at me on the IPv4 front, apart maybe from routes on WAN. I expected to find one entry for the local subnet, but it's probably in the collapsed part.
Is there any significance to the IP we see there?

I have no direct experience with IPv6.
Given the existence of "Prefer IPv4 even if OPv6 is available" in settings, I assume the default is IPv6.
It would be a shame to troubleshoot v4 if v6 is used.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 08, 2025, 07:26:28 AM
This is no "interfering" and I don't mind: I am at a loss to what causes this and you are correct in questioning the basics here (as I did as well). Any ideas are welcome.

1. I think we focus on internet connectivity on all three LANs before blocking any inter-VLAN traffic. But we have been shown two firewall rules only, one allowing all traffic and an RFC1918 alias, which seems to be unused?

2. The WAN and Loopback routes are collapsed and those look strange to me: The default route 108.166.149.2 is not the gateway 173.20.240.1. Yet, with LAN1 reported working, it seems to work.

3. IPv6 seems unconfigured apart from link-local IPs, but could be a problem anyway, it should be deactivated completely, also in the interfaces global settings. The "Prefer IPv4 even if OPv6 is available" should be set in this case.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: cookiemonster on May 08, 2025, 12:24:49 PM
thanks chaps.
- ipv6 - maybe "IPv6 Configuration Type" is set to something other than "none" in each interface. If ipv6 not used, it should be changed to "none".
- Gateway != default route : I wonder if gateway priorities have been set, after all this seems a partially-setup multiWAN set. Odd nonetheless.
So in sum, agree with a topsy turvy as we call them in England, an odd set of settings.
So my humble opinion, if the OP wants an educational exercise why it does what it does, this might be long haul.
If instead wants to make it functional, I suggest to the OP to start from scratch with the as you say, focusing in inter-interface and desired internet access, leaving multiWAN well alone from it, IPV4 only.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 08, 2025, 02:32:04 PM
I really appreciate everyone's help.  I guess I can take some small comfort that there's something bigger going on.  I set it back to Pass All and everything works.  I disabled the other WAN interface first to see if that would fix it and it did not.  Maybe if I get some time, I'll put the Untangle hardware back on and reinstall OPNSense on my Protecli box and start over although my configuration is really just out of the box settings.  Thanks again for all your help.

If anything pops up and you want more screenshots, please post.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 08, 2025, 02:57:11 PM
Just a thought. Does a log exist that tracks every change that I made to any configuration?
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 08, 2025, 03:12:50 PM
You can compare the differences between any of your last configurations yia System: Configuration: History.

What do you mean by "I set it back to Pass All and everything works."? You only showed one firewall rule to that extent here (https://forum.opnsense.org/index.php?msg=236749). We were chasing ghosts here if that was not the only rule and you did not have internet access with that.

If it was not the only manual rule on that interface, then please show all interface rules. As I wrote, your first goal should be to enable internet access from all interfaces, then block specific inter-VLAN traffic without losing internet access.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 08, 2025, 03:28:34 PM
Quote from: meyergru on May 08, 2025, 03:12:50 PMYou can compare the differences between any of your last configurations yia System: Configuration: History.

What do you mean by "I set it back to Pass All and everything works."? You only showed one firewall rule to that extent here (https://forum.opnsense.org/index.php?msg=236749). We were chasing ghosts here if that was not the only rule and you did not have internet access with that.

If it was not the only manual rule on that interface, then please show all interface rules. As I wrote, your first goal should be to enable internet access from all interfaces, then block specific inter-VLAN traffic without losing internet access.


On Port 3. The experiment in this thread was with Port 3-Cameras.

I have Pass All on all 3 LAN interfaces now.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 08, 2025, 07:25:55 PM
Here's my understanding of where we stand.
OP has Internet connectivity when using the "Pass all" rule.

Reply #8
Quote from: t84a on May 07, 2025, 08:15:52 PM...
Sorry, I meant that I do not use VLANS.  I originally set up all the interfaces to have this rule.  I had no problems but I don't think that I am preventing LAN2 and LAN3 from accessing LAN1 or each other. 
...
Edit: This rule refers to the pass all rule attached.

Also reply #18
Quote from: t84a on May 07, 2025, 10:42:55 PMO5. I'm not sure that matters.  When I connect to LAN2 or LAN3 from my PC, I get no internet access unless I put in a rule for Pass All.

The OP is correct in that first quote that a pass all rule also gives access to other private VLANs, which is not what he wants (all the way to OP).

I gave him the way I set this up (allow all but private, allow DNS at GW).
OP seems unable to reproduce. That is still outstanding.
OP has never shown his version of these rules...

I concur with disabling IPv6 for now.
Restarting fresh could also eliminate leftover gremlins (for example that weird IP in the routes on WAN, but we could also clean this up more surgically).

Am I missing anything?
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 08, 2025, 08:17:02 PM
Probably, the OP messed up the VLAN blocking rules. Since he never showed them in context with the "allow all rules", we cannot tell.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 08, 2025, 08:46:02 PM
If you use the "allow all but private" mechanism, block rules are not needed, thus eliminating the need to order rules properly.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 08, 2025, 09:02:16 PM
For your given rules in posting #2 to not work, it suffices to use a DNS server IP on another than the test network (say, on the first LAN ip or not the gateway itself, e.g. a pi-hole or something, i.e. 192.168.x.y where y != 1 or where x is not in the same subnet as the client).

If you then do not know how to diagnose that, you will not have DNS and thus "no internet":

1. I never saw the actuall firewall rules.
1. I never saw a ping/traceroute to 8.8.8.8.
3. I never saw the DHCP configuration.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 08, 2025, 09:44:09 PM
Update.  Here's the solutio. Thanks to EricPerl.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: Jansie on May 08, 2025, 11:11:22 PM
I have like a same question @viragomann says by default inter vlan traffic is blocked, but my opnsense out of the box allows all inter vlan traffic. Does someone have a clue where to look? Only if i make a rule like LAn to Management with block, it stops working. But in my opinion by default inter vlan traffic should be blocked.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: Patrick M. Hausen on May 08, 2025, 11:18:08 PM
By default only the LAN interface has an "allow all" rule configured. When you create a new (VLAN) interface it comes with no rules so everything is blocked. That's the default and that is why people make statements like "by default inter VLAN traffic is blocked".

If you copy your LAN rule over to that VLAN, then of course you permitting *everything* including inter VLAN traffic but that is your decision and your action which cause this.

Create your rules appropriately. A firewall is a policy enforcement device. It does whatever you tell it to.


VLAN 100 in, destination "any" means "any". Make that "! private networks" instead and you do not allow inter VLAN traffic. How should OPNsense guess which policy you want to implement?
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 08, 2025, 11:42:07 PM
Quote from: t84a on May 08, 2025, 09:44:09 PMUpdate.  Here's the solution thanks to the HomeNetworkGuy:

FWIW, this is EXACTLY the same as in reply #3 on this thread...
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: Patrick M. Hausen on May 08, 2025, 11:46:26 PM
Quote from: EricPerl on May 08, 2025, 11:42:07 PMFWIW, this is EXACTLY the same as in reply #3 on this thread...

#2 - this one:

https://forum.opnsense.org/index.php?topic=46812.msg234831#msg234831

Yeah. Youtube ... 🙄
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: EricPerl on May 09, 2025, 12:04:27 AM
Opening the 1st page of the thread to compare the rules and typing the wrong number... 🤷�♂️
I guess I should take a break.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 09, 2025, 12:47:21 AM
Quote from: EricPerl on May 08, 2025, 11:42:07 PM
Quote from: t84a on May 08, 2025, 09:44:09 PMUpdate.  Here's the solution thanks to the HomeNetworkGuy:

FWIW, this is EXACTLY the same as in reply #3 on this thread...

Crap.  You are 100% right.  I probably tried it but did it wrong.  So to correct myself:  Thanks to ERIC for the solution!!
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: meyergru on May 09, 2025, 12:56:29 AM
I can't even... sigh.
Title: Re: Blocking/Allowing InterInterface Traffic
Post by: t84a on May 09, 2025, 01:24:08 AM
Post 41 was from my phone. To be clear, I'm positive I tried Eric's recommendation.

I restored a backup from the beginning of April and started over. Instead of coming back to this thread, I went from scratch.

I'm not sure what was jacked up. My apologies to Eric. He's helped me on every one of my topics.