Messages

If your server needs access to different networks and you want to restrict access from certain computers, that's easy thing to solve.

If you want to avoid having to buy expensive multiport server NIC, check if it's current one supports IEE 802.1Q (That's standard VLAN Tag support), setup a VLANs on the switch and on the server and that's it.

Downside to that is, you need to setup VLANs (if you haven't) which isn't that hard but it is alot of work.

Yeah, troubleshooting VLANs is even more of a pain. I had an issue where I forgot to place a VLAN to a trunk port. It causes a particular untagged port at the other end has no connection to its DHCP server. I spend hours trying to figure why that is the case. I eventually realize that I was looking at the wrong place.

I used to setup the server as VM with three separate ethernet ports - one for each network. Now that I replaced that server with a physical one. I only have one port. Since I don't think I can setup that port as VLAN trunk, I end up giving that server special network access to the other devices on the other networks.

Make sense. However, I never manage to figure out how the routing is handled and its syntax. I managed to get the job done with the firewall rules.

Following the approach of setting up the gateway for each network, how would I go about setting up only one device with a particular IP address like 192.168.2.10 to be able to access 192.168.5.0/24 and certain devices on other network like 192.168.4.10 and 192.168.4.50? I was able to handle this easily with firewall rules.

If 192.168.2.10 is LAN3 and 192.168.5.0/24 is LAN 5, you can set 192.168.2.10 to be able to access to LAN 5 by going to LAN5 firewall rules, creating block rule where direction is in, source is LAN3 net and destination is LAN5 net. Move the new block rule above default allow all rule.

Then create an host alias, type in 192.168.2.10 and go back to LAN5 rules, this time create pass rule, where direction is in, source is Alias you created and destination is LAN5 net, move the pass rule above block rule and test if it works. Now only 192.168.2.10 should be only IP that can access LAN5 and you need to do same thing for each network except LAN3.

Firewall applies rules based on order, by default order is from top to bottom, so any block rule should be above allow any to LAN rule, and any "allow specific IP" above block rule which contains range of IP or network where IP lies.

Do keep in mind that x net is not bound to IPs, so with this set of rules, you are able to access LAN5 on any computer on LAN2 as long as it's IP is 192.168.2.10, for more specific protection (like MAC address filtering) you will need a switch which has MAC address ACL support.

I already figured out the proper firewall rules for that. My question was asking about the other approach that @defaultuserfoo mentions. I don't think you can do something like that without firewall rules, am I right?

If you don't need access from your computer to all networks, I would recommend to leave 1 LAN port for management and use VLANS on other LAN port, this way you can allow LAN management to have access to all VLANs, and all you have to do, is just connect your computer to Management LAN whenever you need access to it.

Think it as this way, to make networks as secure as possible, gaining access to different networks would have to require you to physically connect computer to right network, not just allow specific IP, since IPs can be changed and MAC addresses can be cloned.

Good point. I didn't think of other computers mimicking specific IP and MAC addresses, but this is assuming that others know how you setup your network. Nonetheless, I will see if I can do that. Got quite a complicated setup already. I placed different types of devices on different networks. A server needs to gain access to certain devices on those different networks. While I can place all the devices together, I don't trust the other devices on the other network so they are placed on a separate network completely isolated from the other networks.

I did test this and defaultuserfoo is correct. You don't need rules to allow access to devices between same network because firewall doesn't block communication within same networks.

Way you allow communication between 2 different networks, is by creating routes.

If you have LAN 5 with IP range of 192.168.5.0/24 and LAN 3 with 192.168.3.0/24, reason why you can't ping devices in different  LAN, is because they are in different network.

All you need to do, is add either LAN 5 or 3 interface to gateways and create a route where destination is 192.168.0.0/16 and gateway is IP of either one of LAN you have added as gateway.

Allow any to LAN default rule will allow all traffic to any network, so if you are unable to ping, it's due to gateway misconfiguration or you are missing a route.

Make sense. However, I never manage to figure out how the routing is handled and its syntax. I managed to get the job done with the firewall rules.

Following the approach of setting up the gateway for each network, how would I go about setting up only one device with a particular IP address like 192.168.2.10 to be able to access 192.168.5.0/24 and certain devices on other network like 192.168.4.10 and 192.168.4.50? I was able to handle this easily with firewall rules.

I tried to follow your discussion, but your network diagram and the conversation completely got me confused. Basically, the fact that IN are all traffics coming into the OPNsense firewall and OUT are all traffics coming out of the OPNsense follows the same convention as Windows Firewall and PiHole.

It's not a network diagram, it's a diagram of a router.  I don't know what a PiHole is or does, and Windows never seemed to actually have something that could actually be called a firewall.

Pi-Hole is a DNS server with a sole purpose of ad blocking. It is not very effective on Youtube, but it helps reduce network activities especially on mobile devices.

Windows does have a firewall. It is called Windows Defender. By default, it blocks hardly anything in network profile other than public.

About your topic, the person answered your question correctly. "The "inbound/outbound" distinction is strictly from the firewall's point of view."

But I would bet that you are confused with what that answer means.

He also said: "Well, a machine on the guest network sends a packet to a machine on the LAN network. That packet goes in to the firewall on the guest interface and out of the firewall on the LAN interface ..."

Maybe I'm confused, but doesn't that mean that OUT means "going out of the firewall"?

That is correct. It does mean "going out of the firewall". Not taking VLAN trunk into account, all routers must have at least two interfaces. Communication must go in one interface and out another.

For simplicity explanation of IN and OUT, picture your firewall having only one input and one output. Which interface is input and which interface is output will depend on which interface is initiating the connection. So if I am pinging 192.168.3.2 from my laptop (192.168.5.10), my interface at my laptop is input and the interface at 192.168.3.2 is output. On other hand, if I am pinging 192.168.5.10 from my device, my interface at my laptop is output and the interface at the device is input.

This explanation is omitting that these packets must go through the firewall.  That means they go IN to the firewall and come OUT of it.

That is a crucial distinction, see here: https://forum.opnsense.org/index.php?topic=28447.msg138240#msg138240


> Quote from: defaultuserfoo on May 23, 2022, 01:07:49 pm
>
> An outbound rule on the LAN interface that blocks everything from <group> /would block traffic coming out of the firewall before the traffic could enter the LAN interface and go out of the LAN interface/.
>
> Exactly.


This distinction is crucial in that it does matter where the outgoing traffic is coming from, the particular interface or the firewall, i. e. possibly coming from any interface (i. e. out of the firewall).  --- The point is that you need not put many IN rules on all interfaces to prevent traffic going to some interfaces because you can place a single OUT rule blocking traffic from all the very interfaces that are in a particular interface group.  That's because the traffic you want to block doesn't come out of the interface you put the rule on (going to devices connected to them) but out of the firewall (possibly coming from many other interfaces).  (The problem is that you might need many interface groups to achieve what you want.)

There is also traffic going to the firewallwall and traffic coming from the firewall.  The diagram in the other thread is supposed to show that.

Or am I confused?

That is correct. They do need to go IN to the firewall and come OUT of it. Otherwise, how do devices on different networks communicate with each other? There must be a merging point where the different networks connect. The firewall rule at your router determines whether they can communicate with each other or not.

Your diagram is confusing indeed. Conceptually, I would divide the firewall into two parts. One firewall is placed between all LANs. You control this firewall through firewall rules. OPNsense divides this firewall up by interfaces for better management. If you are using a different firmware like Tomato, all of these firewall rules are merged together.

Another firewall is placed between LANs and WAN. Port forwarding is part of that firewall.

Well, after spending three days to transfer all the Tomato firmware router settings to OPNsense and troubleshooting, I finally got almost everything back to normal as before except for certain Nginx settings.

In the progress, I found that I DO need LAN to LAN rule in order to get all my devices on the same network to communicate with each other. After troubleshooting a bit, I was able to settle with LAN to Gateway rule instead. I think it is because there are multiple routers and switches and VLAN switches involved.

It is a VM. I ran it on top of Proxmox VE. I can reserve a bit more memory and space, but I think I can live with 2 GB of memory, 4 GB of ZFS, and 6 GB of swap. I didn't check the hard drive requirement before installing OPNsense though. How does OPNsense even use that much space? So far, I have all my necessary router settings copied over to OPNsense. Currently, I only used 900 MB of memory, 900 MB hard drive space of ZFS and 0 MB of swap.

After struggling with shifting the ZFS partition upward with commands, I eventually boot it up with Magic Partition and shift the partition that way.

After starting with a fresh DVD installation of OPNsense, I noticed that the default partition setup is quite annoying to work with. See attached swap partition for details.

Out of 10 GB hard drive space, 8 GB is automatically allocated for swap and placed in front of the main ZFS partition while only 2 GB is allocated for it. Thus, I can't update my firmware without allocating more hard space to ZFS partition, which I can't unless I move the swap partition down and shrink it.

While I figure out how to remove the swap partition, I can't figure out how to move ZFS partition up.

If you configure the direction of the rule from IN to OUT, OUT means traffic that goes into OPNsense.  OUT does not mean traffic that goes out of the interface to something that is plugged into it, and it does not mean traffic that comes out of OPNsense into the interface.  Traffic coming out of OPNsense goes IN to the interface.

Initially, I thought I understand it wrong, but I just finish watching this video tutorial and I discover that I understand this correctly. IN are all traffics coming into the OPNsense firewall and OUT are all traffics coming out of the OPNsense. By default, everything IN are blocked and everything OUT are passed. Thus, you would mainly need IN rules. The time you would need an OUT rule is when you need to filter packets going out of the firewall.

Not long ago I was told on this forum that OUT means traffic going out of the interface into OPNsense, as opposed to going out of OPNsense.  I do not know which version is true.  Since there can be multiple interfaces through which traffic can go out of OPNsense, the first version makes sense while the other version doesn't.  Otherwise you would have to be able to specify multiple interfaces OUT of which traffic is supposed to go out of OPNsense when creating a rule for the OUT direction.

And what about traffic going IN to OPNsense and traffic coming OUT of OPNsense?  How would you create rules for that?

See here: https://forum.opnsense.org/index.php?topic=28447.msg138236#msg138236

I tried to follow your discussion, but your network diagram and the conversation completely got me confused. Basically, the fact that IN are all traffics coming into the OPNsense firewall and OUT are all traffics coming out of the OPNsense follows the same convention as Windows Firewall and PiHole.

About your topic, the person answered your question correctly. "The "inbound/outbound" distinction is strictly from the firewall's point of view."

But I would bet that you are confused with what that answer means. For simplicity explanation of IN and OUT, picture your firewall having only one input and one output. Which interface is input and which interface is output will depend on which interface is initiating the connection. So if I am pinging 192.168.3.2 from my laptop (192.168.5.10), my interface at my laptop is input and the interface at 192.168.3.2 is output. On other hand, if I am pinging 192.168.5.10 from my device, my interface at my laptop is output and the interface at the device is input.

Moving the rule isn't the solution.  What you call "WAN rule" would allow access from addresses in the address range of the particular LAN to anywhere, and you don't need an extra rule to allow access to a particular device somewhere after that rule.

That is not correct. I restrict that rule to WAN Gateway. It would mean all other traffics that won't match the other rules will automatically to be passed to WAN interface out to the internet.

Sorry, I think I have missed the restriction to the gateway because the screenshot was too wide to show in the browser window.

So it would seem that you have rules which allow everything to anywhere on the same LAN (which is ineffective because devices on the same network will communicate directly with each other); after that, you force all traffic from the LAN through the WAN_DHCP gateway, and it the last rule, you're trying to allow everything to everywhere from a particular IP address.  The last rule is also ineffective because the 2nd rule already matches.  So yes, when you switch the 2nd and 3rd rule, it would make a difference.  And you can delete the first rule.

Oh, really? Devices on the same network will communicate directly with each other? I was using the same two devices for all my testing and I thought I would need that rule for them to communicate.

You need to create routes to be able to allow traffic from 2 different networks to communicate with eachother.

First add your LAN IP 192.168.1.1 to gateways.

After that create rule where network is 192.168.0.0/16 and gateway is 192.168.1.1 (or whatever is LAN IP of any LAN interface your opnsense has. IP MUST BE LAN gateway in use and within same same IP block.)

Voïla, now all traffic between IPs 192.168.0.1 - 192.168.255.254 goes to 192.168.1.1 (or whichever LAN interface you use as route gateway) and can talk with eachother.

Basic network stuff. Deviceses which belong to different networks can't communicate with eachother

Well, I am configuring my OPNsense to be the gateway for both LANs. To be more precise, it is the gateway for all 4 LANs, so I don't need a gateway for that. The person in the tutorial video did the same thing. He was able to get communication working between the two LANs.

I think I figure out the issue now. It wasn't a bug issue, because I tried to revert back and reimage to multiple older versions up to OPNsense 21.7.1. So I tried packet sniffing and found that the packet send from 192.168.3.2 is received at 192.168.5.10, but the content of those packets is missing a response section. So the problem must be coming from either OS or OS firewall, not OPNsense related.

Ah, this explains thing. Others are having firewall issue as well with version 22.1.8. Sadly, it isn't working as expected for 22.1.7. Guess I will have to check in from time to time to figure out the working stable version for it.

Yeah, I was right. It is strange indeed. Looking at the log, it shows that OPNsense allow that traffic to pass through, but it never reaches its destination. Why?!

I can ping that device (192.168.5.10) from OPNsense (192.168.3.1 and 192.168.5.1) directly, but not from 192.168.3.2?

Moving the rule isn't the solution.  What you call "WAN rule" would allow access from addresses in the address range of the particular LAN to anywhere, and you don't need an extra rule to allow access to a particular device somewhere after that rule.

That is not correct. I restrict that rule to WAN Gateway. It would mean all other traffics that won't match the other rules will automatically to be passed to WAN interface out to the internet.

If you configure the direction of the rule from IN to OUT, OUT means traffic that goes into OPNsense.  OUT does not mean traffic that goes out of the interface to something that is plugged into it, and it does not mean traffic that comes out of OPNsense into the interface.  Traffic coming out of OPNsense goes IN to the interface.

Initially, I thought I understand it wrong, but I just finish watching this video tutorial and I discover that I understand this correctly. IN are all traffics coming into the OPNsense firewall and OUT are all traffics coming out of the OPNsense. By default, everything IN are blocked and everything OUT are passed. Thus, you would mainly need IN rules. The time you would need an OUT rule is when you need to filter packets going out of the firewall.

Oh, I found my problem now. I have the rule order wrong. I need to move the rule up before WAN rule. Doing so allows me to be able to ping 192.168.3.2 from my laptop. Strangely, applying the same solution on LAN3 doesn't fix the problem though. I still can't ping my laptop from my device. Very strange.