Messages

Why using FW rules? Can't you simply configure the host with a fake gateway adress?
This way I am blocking a smart TV from WAN but granting LAN access. Moreover there is no need for the firewall to process anything.

While I appreciate the suggestion, its a bit of a digression from my question. I am aware that spoofing the gateway on the host stops it from accessing the firewall.

My practical uses of the firewall notwithstanding, in this case I'm asking from a purely theoretical standpoint. I have been told by others in the industry that Opnsense's firewalls are not reliable, or fully implemented. I don't rely on rhetoric, so I am testing it for myself as time allows. I'm trying to understand how the firewall works and push it a bit. This is purely a lab installation.

The problem is, most of the threads on this topic either remain unresolved, or are people suggesting workarounds to the problem presented, instead of explaining the problem or why it exists or presenting a direct resolution. 

Hello,

I don't see a spot on the forums for feature requests, so I will add it here. Apologies if it is in the wrong place.

As the subject implies:

I'm requesting an option in the web GUI on the schedule configuration page. I'm thinking something like a checkbox, to enable an option that resets states when a particular schedule takes effect.

I've seen a number of people requesting this on the forums, or something similar. There seems to be a lot of confusion as to why firewall rules aren't taking effect when the schedule becomes active. While I understand there is a good technical explanation, it is still understandable confusion. Especially for newer users.

The best workaround I can find is to create a cron script in the console to reset states on a schedule that happens to coincide with the respective firewall schedule. If this is the only way to reset states after a firewall schedule takes effect, then it is extremely inconvenient and probably beyond the abilities of the average user.

Having an option on the schedule page to reset states after a schedule rule becomes active seems like a fairly good solution.

Okay. I think I am starting to understand. The problem is the following:

Destination: WAN

Counterintuitively, this doesn't work for blocking LAN clients access to the WAN. I'm guessing because the packets originating from the LAN get translated at the firewall (as part of the NAT process). My understanding was that NAT only changes the "source" part of the packet, so I'm still not sure why specifying WAN addresses as the destination wouldn't work.

I created an alias with all of the local LAN addresses:

Alias: LOCAL_LANS
Networks: 192.168.1.0/24; 192.168.2.0/24; etc

Then I did the following:

Action: Block
Direction: In
Source: (Single Host) The blocked hosts LAN IP
Destination: (!INVERT)LOCAL_LANS
Port Range: Any to Any

This appears to work, but it is counterintuitive. I can understand why there are so many threads asking how to block clients from the internet via the firewall.

I guess my question is:

Why doesn't using WAN addresses as a destination in the firewall rule work? What is "WAN Addreses" used for, if not for packets marked with a destination on the WAN address?

Hello,

I'm trying to block a single host from the internet only (still have access to local LAN resources). It simply isn't working.

I've tried applying the rule to "floating" as well as the relevant LAN interface, but neither works.
I am resetting states after activating the rule, but it doesn't make a difference.

The rule I'm using is as follows:

Action: Block
Direction: In
Source: (Single Host) The blocked hosts LAN IP
Destination: WAN
Port Range: Any to Any

All other options are default. The rule is at the top of the list (below the auto generated rules).

I've also played around with a variety of other options, but literally nothing works. I've tried to use an Alias as well. Has the "block" feature been fully implemented yet in OPNsense, or is it a placeholder? I've never gotten a block rule to work on OPNsense before.

As I said, I am resetting states following rule activation.

Is there anything else I can try, or is this a known issue?

Thanks,
PW

Hello,

I have some questions about how OpnSense handles VLAN.

In the following example, I have a quad port device running OpenSense.
igb0 is WAN.
igb1 is trunk for all VLANS.

Lets assume the following VLANS configured:

VLAN 100 - Management - Parent: igb1
VLAN 200 - Workstations - Parent: igb1
VLAN 300 - IoT Stuff - Parent: igb1

• In this example, how can I select which VLAN is native to the trunk port (if someone physically plugs into the port). This is a theoretical question, since I would likely have a managed switch which would tag all packets on the trunck anyway, but I don't see an option for it in opnsense. Ideally, it would be the management LAN.
• Is there a way to ensure all packets traveling to the trunk port (igb1) are tagged? Or at least a way to configure opnsense to react as though all untagged packets are in a particular VLAN? I assume this would be related to the question above.
• Is there a way to configure the additional physical ports (igb2, igb3, etc) as access ports for VLANs defined above, which already have their parent port assigned to igb1. I don't see an option for this.

Thanks in advance.

Hmm.

I don't see that as an option in the Cron dropdown.

Is there a way to invert schedules? I had thought about using two rules: one to allow, based on a schedule, and then another to block based on the same schedule. The problem is I would have to create redundant schedules for each block and pas rule. Seems awkward.

What is the current recommended way to set up scheduled firewall rules for blocking specific clients from internet?

I've found a few threads on this forum, but they are quite old and trying the recommendations doesn't work entirely. For instance, simply setting a scheduled block rule in the floating rules is effective, but won't kill existing connections.

I have the schedule and the alias' set up the way I want them, and they appear to work. The only quirk is terminating existing connections. Is there a trick I'm missing?

[out of the box]

Okay. Disregard.

Apparently Mikrotik switches currently have a bug out of the box where DHCP request packets are getting blocked/dropped on VLANs.

This is a new CSS610 switch, on version 2.12. I ended up fixing it by deep diving into their forums, finding a random semi-recent thread that mentioned a unpublished release candidate. I eventually got the switch updated to an RC of 2.13 and everything started working as expected.

I can see why Mikrotik devices are so divisive in their reception. I'm certainly put off by them after this.

Hello,

Has anyone used their OPNSense router with Mikrotik CSS switches (swOS)?

I have a very basic lab set up with a OPNSense box and a CSS-610-8G. Everything works exactly as I would expect, except when I get to VLANS. At that point everything completely stops working.

The lab OPNSense has two VLANS set up (100 and 200), with DHCP set up for each (192.168.100.1/24 and 192.168.200.1/24) respectively. I've set these up, assigned them to an interface (port 3), and plugged that interface into the switch (port 1).

I've added the two VLANs to the VLANS screen, and then chosen port 2 for 100 and port 3 for 200.

I would assume that if I plug a device into each one of these ports, I should get an address from the DHCP server of the respective pool. But I don't even get assigned an IP.

I'm not sure if I am missing something on the opnsense side of the mikrotik side.

Anyone have any suggestions?


Edit:

So upon further testing, it seems to be just the DHCP that is not working with the VLAN. If I assign the computer a static address within the range of the VLAN, and then plug it into the port assigned for that VLAN, everything works fine. 

1) I simply dont understand why pcengines switched away from i210 and use i211 in their higher numbered APUs (APU4, APU5, APU6, these are not even listed on pcengines.ch, the secrecy inner workings of this swiss company is  confusing as hell to me). As you all should be aware i211 is inferior to i210...

I don't understand a lot of your post, but I do understand human nature. Usually when a company/manufacturer makes a decision to downgrade a product, but give it a higher model number, the reason is usually always "money".

I would wager the i211 is cheaper to build.

That's kind of what I was afraid of.

I've replaced the cable, switch, and isolated the physical network down to a few devices and it has not resolved the dropouts. I've even changed the port (the device has 4).

When I started seeing threads about the i211 pop up, I assumed that was it. Especially since it wasn't happening on older BSD versions.

I'm starting to wonder if I have a bad QOTOM unit. Given the sketchy nature of the manufacturing on these things, I suppose it's possible.

To be honest, I probably wouldn't have noticed if we didn't have people working from home due to Covid. Lots of video conference calls getting interrupted. According to the logs, the dropouts happen 3 or 4 times a day, seemingly at random (no idea what triggers it). It flipflops for about 10-15 minutes then comes back up.

A lot of the time, this happens overnight, or during work hours. It is very possible someone could be having this issue and simply not noticing it. 

If you look through your system logs, you will see something like:

igb0: link state changed to DOWN

several times per day.

Then up and down a few more times. If this happened at a time when you weren't actively using your internet connection, you may not have noticed, or assumed it was a one-off.

I know there are a lot of priorities, but this seems like it should be a higher one.

This "glitch" effectively means the newer OPNSense versions cannot work reliability on many of the QOTOM/Protectli mini-computers that you can get off amazon/aliexpress that are very popular to run with PFSense/OPNSense. A majority of them use the i211 chipset.

I'm actually a little surprised more people aren't remarking on this. It makes me feel as though there is something unusual about my configuration. I suppose its possible most home/SOHO users may not notice dropouts several times a day.

> I think its Opnsense related, since the same hardware worked perfectly on PFsense.
Modify message

Qualified statements please: Which OPNsense and pfSense versions are we comparing? You are aware the two have different OS versions in production releases? ;)


Cheers,
Franco

Fair comment. The pfSense version was the latest stable. (2.4.5) pfSense doesn't post updates very often. Their stable branch is still on BSD 11 I think. They were on the verge of 2.5, but i'm not sure if that has been released yet. I lost interest in pfSense after finding out more about the organizations history.

Every Opnsense version I've tried has been BSD12.x. I ran 20.7 for a bit over a week then upgraded to 21.1.

The problem may lie with BSD12.

So 20.1 was working? That would point to a FreeBSD 12 issue, because 20.1 was FreeBSD 11 and 20.7 and 21.1 are FreeBSD 12.

I never used 20.1, so I'm not sure. I did use the latest stable of PFSense, and it was fine. I think its running FreeBSD 11, so you may be on to something.

I've been researching into it, and it seems lots of people are having trouble with the i211 network cards that come on the QOTOM computers.

I went into the BIOS last night and disabled "wake-on-lan" and all of the suspend/powersave features. We will see if that helps.

Edit: Question: Anyone having frequent dropouts with the i211 on BSD 11.x?