LAN5 to LAN3 IP

Started by Ice_Drake1, June 06, 2022, 08:32:49 AM

Previous topic - Next topic
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 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.

June 10, 2022, 03:13:53 AM #4 Last Edit: June 10, 2022, 03:16:10 AM by Ice_Drake1
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?

June 10, 2022, 03:37:04 AM #5 Last Edit: June 10, 2022, 03:53:43 AM by Ice_Drake1
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.

June 10, 2022, 07:01:53 PM #6 Last Edit: June 10, 2022, 07:13:14 PM by Vilhonator
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

June 11, 2022, 01:19:00 AM #8 Last Edit: June 11, 2022, 01:32:54 AM by defaultuserfoo
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 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.

June 11, 2022, 03:16:57 AM #12 Last Edit: June 11, 2022, 03:19:03 AM by Ice_Drake1
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 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.