I am new to OPNsense. I am trying to copy the configuration I have been using for FreshTomato to OPNsense, but I can't seem to figure why I can't ping a device on a different LAN after adding the firewall rules for it unless I understand the rules wrong. Please see the attached pictures of my current setting.
I want to be able to access the device with the static IP address of 192.168.3.2, but I can't even ping it from my laptop with the dynamic IP address of 192.168.5.10. So I tried the reverse rule and tried pinging my laptop from the device and that didn't work either. Yet, I can access the internet from both devices, so I must be doing something correct.
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.
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.
Unless you configure it otherwise, the first rule that matches applies, and no rules after that matter.
Unless you configure it otherwise, the rules on a particular interface apply to traffic occuring on that interface. They do not apply to traffic on other interfaces.
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.
You may want to check the IP addresses, the routes and the firewall settings on the devices that you're using for the ping tests.
Quote from: defaultuserfoo on June 07, 2022, 12:38:36 AM
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.
Quote from: defaultuserfoo on June 07, 2022, 12:38:36 AM
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 (https://www.youtube.com/watch?v=kYFNa_zpeII) 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.
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?
Ah, this explains thing. (https://forum.opnsense.org/index.php?topic=28494.0) 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.
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
Sorry that is if you are using VLANs.
For physical interfaces, you need to create routes for each network, so that would be 192.168.2.0/24 to 192.168.2.1 (or IP of interface that maintains the network in question) and 192.168.5.0/24 to 192.168.5.1 and so on
Quote from: Ice_Drake1 on June 10, 2022, 02:54:34 AM
Quote from: defaultuserfoo on June 07, 2022, 12:38:36 AM
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.
Quote
Quote from: defaultuserfoo on June 07, 2022, 12:38:36 AM
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 (https://www.youtube.com/watch?v=kYFNa_zpeII) 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 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.
Quote from: Vilhonator on June 10, 2022, 07:01:53 PM
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.
Quote from: defaultuserfoo on June 11, 2022, 01:19:00 AM
Quote from: Ice_Drake1 on June 10, 2022, 02:54:34 AM
Quote from: defaultuserfoo on June 07, 2022, 12:38:36 AM
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.
Quote from: defaultuserfoo on June 11, 2022, 01:19:00 AM
Quote from: Ice_Drake1 on June 10, 2022, 02:54:34 AM
Quote from: defaultuserfoo on June 07, 2022, 12:38:36 AM
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 (https://www.youtube.com/watch?v=kYFNa_zpeII) 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.
Quote from: Ice_Drake1 on June 11, 2022, 02:55:39 AM
Quote from: Vilhonator on June 10, 2022, 07:01:53 PM
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.
It is possible that your Opnsense didn't create the routes (usually routers and firewalls will create routes automatically), I've had same issue as you do couple of times, and adding the routes manually usually fixed them.
You can check if routes are there, but usually when Ping fails to certain destination other than gateway, it is sign that you don't have working route going on
Quote from: Ice_Drake1 on June 11, 2022, 02:59:56 AM
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.
Yes, they do that, unless something is wrong.
Quote from: Ice_Drake1 on June 11, 2022, 03:16:57 AM
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.
Quote
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"?
Quote
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?
Quote from: defaultuserfoo on June 11, 2022, 01:02:15 PM
Quote from: Ice_Drake1 on June 11, 2022, 02:59:56 AM
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.
Yes, they do that, unless something is wrong.
Just to clarify.
Devices connected to same network (not same as same interface) will be able to communicate with eachother without issues unless you setup firewall rule, which prevents it or there's something wrong with routing.
Devices connected to different networks won't be able to communicate with each other even if you setup firewall rules, without having correct routes which usually is done by L3 switches, firewall or router automatically but not always.
The 3 first rows on IP address and subnet mask define network, as long as all those match, devices which begin with same IP and have same subnet mask are in same network.
192.168.0.0/16 is CIDR and allow you to create networks from 192.168.0.1 to 192.168.255.253 and that is required for VLANs which networks belong to that range.
You can for example setup LAN to use 192.168.0.1 IP, sign VLANs and setup routes, DNS and DHCP on a switch , and no one can access your firewall and you don't need firewall rules for it. Then only way to access firewall, is to physically connect to it and set static IP belonging to that network, using console or connecting keyboard and monitor to firewalls usb and video ports. That's what your ISP does, gateway your WAN connects to is either just unmanaged router or switch, or their remote management requires some form of authentication.
Above mentioned facts are also reason why you shouldn't connect your computer directly to the internet, as with private IP blocks, also public networks have unrestricted access to any device within the same network or CIDR (Not that I encourage to do so, but just scan your public IPs CIDR with nmap and you see what I mean. Depending where you are, it could be illegal as heck though)
Firewall rules do not prevent devices on the same network from communicating with each other. You'd have to use VLANs or other means to prevent that.
Quote from: defaultuserfoo on June 11, 2022, 10:53:07 PM
Firewall rules do not prevent devices on the same network from communicating with each other. You'd have to use VLANs or other means to prevent that.
Ah good point.
Firewalls won't allow or block communication per say, they pass, block or reject traffic which meets specific conditions. With right rules you are able to reject or block certain communications which use specific protocols and ports, but not communications which don't rely on protocols, ports AND meet the conditions of Default allow LAN to any rule or other rules which firewall passes.
The firewall doesn't get involved when devices are communicating directly with each other --- unless you connect everything to a hub perhaps (if you can still find one ...). In any case, it doesn't matter what the firewall rules are in that case.
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.
Quote from: defaultuserfoo on June 11, 2022, 01:17:59 PM
Quote from: Ice_Drake1 on June 11, 2022, 03:16:57 AM
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.
Quote from: defaultuserfoo on June 11, 2022, 01:17:59 PM
Quote
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.
Quote from: defaultuserfoo on June 11, 2022, 01:17:59 PM
Quote
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.
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.
Also if you have multiple routers and switches each connecting to different networks, then you need to check routes more carefully.
Things are simple when you have just a firewall to which switches are connected to, as soon as you add another router into it, things get more complicated because of routing, due to the fact that many manufacturers use default 192.168.1.0/24 network on their routers
Quote from: Vilhonator on June 24, 2022, 07:10:25 AM
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.
Quote from: Ice_Drake1 on June 24, 2022, 07:56:59 AM
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.
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.
Quote from: Vilhonator on June 24, 2022, 12:18:04 PM
Quote from: Ice_Drake1 on June 24, 2022, 07:56:59 AM
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?
Quote from: Vilhonator on June 24, 2022, 12:28:32 PM
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.
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.
Now if you don't mind searching for deals, you can check if there are cheap pre-owned NICS available.
I can recommend ones that have Intel I350 chip, Intel Ethernet I350-T4 (T4 means it has 4 ports) for example is around 250€ if you buy it brand new, so pre owned one wouldn't cost much over 150€, I350-T1 cards cost around 50-100€, so unless you need more than 2 ports, it's cheaper to just buy single port NIC. Only thing you have to check, which features and network protocols it supports, I would recommend ones with IEE 802.1Q (also known as VLAN tag) and Jumbo Frames, that way you know it's at least suitable for servers like NAS.
If your server has enough physical ports, you don't need VLANs, you can connect each port to different network and only downside would be, that server OS you use (like TrueNas) won't allow you to use DHCP on more than one port and you have to setup static IP manually and add those IPs to DHCP servers reserve list or choose IPs outside the DHCP pool range.
Only reason you would need to allow access from X network to all networks (or X IP to all networks) is to be able to do some diagnostics, access management and test that connections work.
Allowing server to access certain networks is done with VLANs or having multiple ethernet ports on the server
As for firewall rules.
You use firewall rules ONLY to allow access from network A to network B and blocking access from Network A to webgui, ssh or any remote management of the firewall, you won't be able to use firewall rules to block network A gaining access to devices in network A, for that the firewall on device in question (if it has any) would have to block the access or you would have to use switch with ACL (Allowed connections list) which blocks it.
You can use external DHCP servers though, if your firewalls LAN IP is 192.168.1.1 and has already working route 192.168.0.0/16. When you connect computer with 192.168.2.20 to LAN, you are able to access internet (if LAN firewall allows it).
Every rule that has LAN net as source and/or destination, is applied to any device connected to LAN port (it isn't bound to IP addresses), so you can setup external DHCP server with routes which gives different IP address to clients than LAN on firewall has. Don't know exactly how it's done because I have never done it, but I think that only requires routes or if it doesn't work out of the box.
It's easy to test, you can create virtual machine with IP 192.168.2.1, DHCP server which pool is 192.168.2.0/24 and routing, setup route where destination network of 192.168.0.0/16 to 192.168.1.1, go to OpnSense, add gateway 192.168.2.1 and create route where destination is 192.168.2.0/24 to 192.168.2.1 and see if it works.
Yes, it is possible to use opnsense firewall without DHCP function and you don't have to use even same IP range as opnsense has, it's possibly just more complicated to setup and requires quite a bit of routing
Oh and I use 192.168.1.1 etc as an example.
You can use any IP range which is reserved for private networks, 192.168.1.0/24 is just most common. https://www.ionos.com/help/server-cloud-infrastructure/private-network/private-ip-address-ranges/ <---- you can use any of ranges in question for private networks
Quote from: Vilhonator on June 25, 2022, 08:22:50 AM
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.
Quote from: Ice_Drake1 on June 25, 2022, 10:59:24 AM
Quote from: Vilhonator on June 25, 2022, 08:22:50 AM
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.
Check the model of network chip that server has, many of them have VLAN support. If you bought Workstation or server grade motherboard (AsrockPro, Asus Prime, Creator or WS and supermicro motherboards are ones I know are workstation and server motherboards) or actual server, their built in network chips do have VLAN support.
Nowadays pretty much any modern motherboard network chips have VLAN support
Also if you use intel motherboard which has ECC RAM support, then it definetly has network chip with vlan support.
All intel motherboards which support ECC ram are designed for servers and workstations