Messages

You don't note any details about your OPNsense settings. Do you have any firewall rules configured for VLAN4 interface? The DHCP is likely being assigned by the auto-generated rules, but if you didn't specify anything else, then no other traffic will flow,

And after having had to rebuild systems before...backup ASAP so you have your existing working config in case you cannot get it restart for some reason later. At least if you have to reinstall from scratch, you'll have all your work saved.

Save early...save often....

I think you're complicating the issue by trying to use the 'sequential' addresses you're using, and mixing masking.

A '.5' address with a /27 mask is going to assume that everything from .1 to .30 is part of the same subnet. Your masking and subnets are then overlapping. You'd probably be much better off using a different network range and  mask for your new interface.

Your options are: 1) choose a different network like 192.168.2.0 with whatever masking you want, or 2) need to go to 192.168.1.33/27 which would be the next valid IP to use with a /27 and keeping your 192.168.1.x addressing.

If you are trying to do a more complex setup, you need to have a better grasp of IP addressing and masking. Use an online calculator to show you valid addressing with each subnet mask. Something like https://dnsmadeeasy.com/support/subnet/

[.5 and .6.]

Assuming you are also using another /30, your 2 hosts should be .5 and .6. Broadcast address will be .7.
The .4 is the next available subnet.

Mesh is a different animal I was not considering. Sorry. Again the details fill out the picture.

More than likely your Orbi is going to control (or rather restrict) what you can do then. I am not familiar at all, so anyone who has mesh WiFi, or more specifically Orbi experience, would be better at answering.

Generally, mesh is implemented for end-user ease of use. Meaning that you can't really control what it does, or how it does it. My guess is that the 'guest' is controlled one of two ways: 1) you see the IP addresses assigned to your 'guest' vs. 'home' devices are different networks, and the device controls either routing or firewalling or 2) the devices are in the same 'network' IP space, but somehow firewalled/restricted from each other within the mesh AP (eg Orbi) itself. Either way, you will likely have little, if any, way of trying to influence or control how it is handling those.

This would pretty much make any firewall controls very difficult, if not impossible IMO....unless the Orbi does actually allow you to VLAN or tag traffic and create a trunk connection over the single ethernet link. There may some subnetting tricks that might give you a degree of traffic shaping control, but I think it will really take trial-and-error, or some response from someone who has experience or has done this. Otherwise you are going to be limited with the controls Orbi provides.

So 'dedicated interface' sounds like a single physical ethernet port on your OPNSense that you use for wireless. Then is that 2 separate access points: 1 for home and 1 for guest? Or does your access point support multiple SSIDs at the same time?

And 'traffic shaping' would really be firewall rules to restrict the traffic on Guest to only allow what you want, and restict other internal access.

Either way, multiple subnets on the same interface sounds like separate VLANs over a trunk to me. So then means that you need VLANs on the OPNSense firewall, separate Firewall rules for each segment, and a switch that supports VLANs.

Option with single interface sounds like this:

Firewall >>> 2 subnets/VLANs (trunk) >>> smartswitch >> Home AP VLAN/SSID
                                                                                         >> Guest AP VLAN/SSID

You could do without the VLANs if you have another physical ethernet interface from your firewall (OP is not specific) and can get a 'home run' from those interfaces to the APs. Each 'network' would be a physical interface rather than a VLAN. Still need separate Firewall rules for each.

Direct connect from Firewall to Access Points:

Firewall port 1 >>> Home WiFi >>> Home AP
Firewall port 2 >>> Guest WiFi >>> Guest AP


If you have 2 Firewall interfaces available, but need a switch between that and the APs, then also need a 'smartswitch' with VLANs on the switch, or 2 separate 'dumb' switches.

Firewall port 1 >>> Home WiFi >>> Switch 1 (or VLAN1 on smartswitch) >>> Home AP
Firewall port 2 >>> Guest WiFi >>> Switch 2 (or VLAN2 on smartswitch) >>> Guest AP

Finally, if the Access Points support multiple SSIDs, then could do any of these options, but then also need to trunk the multiple VLANs (SSIDs)  from a 'smartswitch' over the single link to the access points.

You need to think about physical connections first to define what you need to plan and configure for.

I'd think that has to do with any firewall rules, and if they are set to log or not. From what I remember, the default is 'not' logged unless you turn it on. So you'd have to have a rule match, with logging for the rule 'on', to see it in the logs.

However, the Dell small form-factor business PCs are pretty darn quiet as well and if you put a quad Intel gigabit card in one of those (or or or two dual, according to your requirements) you have a higher spec machine with more up-to-date CPUs.

+1

I'm running exactly that. https://forum.opnsense.org/index.php?topic=13351.msg61385#msg61385

Confirmed a running 27W with a Kill-A-Watt meter. For the cost compared to anything micro/fanless I've seen with comparable specs will pay for a LOT of electricity.

So may not be your ultimate issue, but I fought with HOTPLUG events and Link state up/downs on my WAN interface for many weeks over the summer. No rhyme or reason. Sometimes days with no drops. Sometimes minutes. I tried everything, cables, ports on my cable gateway, even rebuilt my OPNsense box going from a laptop with one onboard and one USB NIC, to a Dell SFF with a dual-port Intel card. The USB just HAD to be the issue...The issue remained, even with the completely new hardware.

In the end, the issue had nothing to do with OPNSense at all. It was a failing Ethernet port on my cable gateway. Replaced with a new cable modem, and all problems disappeared.

Error free wIth the new cable modem.

Good.  Think you are getting closer then.

You do not need the bridge. At least I never have configured one.

Are VLAN10 and VLAN 20 trunked on the same physical connection, or different ports of your 4-port card? Looking at your image, vlan10 shows on igb1 and vlan20 shows on ibg2. I'd expect to see both of them on the same interface: igb1. Confirm this on your Interfaces > Assignments page.

Looking at my 'Interfaces' page as you snipped, all my VLANs are on the same interface: em0 in my case.

Re: firewall rules, it's been a while since my initial setup, but I think other than the auto-generated DHCP rules, that no other traffic is allowed. You'll need to start with an allow 'any' for each vlan network as you may have done. I later created explicit rules for 80, 443, etc, but keep the generic 'allow all' rule in the list, but disabled, in case I need to use it.

What is the config on the trunk port 1/0/52?

For OPNS, under Interfaces > Assignments: Does your LAN show as 'vlan 10 on xxN' (being the VLAN subinterface on the physical interface? Or does your LAN show directly as being 'xxN' (physical interface)? Or do you have both entries?

Then should be showing as 'vlan 20 on xxN' for whatever your 2nd VLAN is.

From what I think I'm seeing is that you have both a LAN, and 'vlan10' (or your 'LAN') being defined. Essentially that looks like 2 'LANs' configured. Then you also have 2 sets of Firewall rules, one for Vlan10, and one for LAN (or what you are calling IGB1).


For my setup, under Interfaces > Assignments, I have
WAN is 'em1'
LAN is 'vlan 111 on em0'
IOT is 'vlan 222 on em0'
WiFi is 'vlan 333 on em0'
etc

On Cisco:
GhostVLAN 2 set as 'native vlan 2' on my trunk interface. No VLAN restrictions (ie. allowed VLANs) on the trunk
Define VLANs, 111, 222, 333, etc
Configure access switchports for VLANs 111, 222, etc


bpduguard does affect (block) additional MACs that may be on that connected port. That is meaning devices connected to a switch uplinked to a Cisco port with bpduguard enabled, will not work. This may or may not have been having an effect on your traffic issue.

The HP is likely not your issue. You don't list any kind of specifics, so hard to tell though what kind of capacity you are trying to support.

Yes VLANs can most certainy be trunked. I have 8 internal VLANs trunked over a single gig link from an HP dual-port card as the 'inside' of OPNSense.

Seeing your other post, you appear to be going to a Cisco switch. My setup is like this and no problems:

                                     [Intel gig dual port]
NetGear Modem >>> | OPNsense WAN    |
                                   |    -----------------       |
                                   | OPNsense 'inside' |  >>> 8 VLANs >>>> Cisco 2960

All 'inside' traffic VLANs are trunked across to the Catalyst. I found that this worked best:
- Define all the 'internal' segments as VLANs on OPNsense, so they are all 'tagged'.
- Define all your VLANs on Catalyst.
- On the Catalyst, also define an unused VLAN: I called mine GhostVLAN (VLAN2). Then on your Cisco trunk port, set that
   as the 'native VLAN'. This will keep all your VLANs tagged, so you don't have to worry about tagged and untagged traffic.
- Define your access ports as needed on the Catalyst.

This should work no problem.

["...my LAN is a 100MB ethernet to USB NIC Linksys USB100m dongle...]

I'm running OPNSense on a physical box, not virtual, so can't  help with, and would defer to others on that topic for setup and security concerns.

But, I think one of the keys to your issue could be this: "...my LAN is a 100MB ethernet to USB NIC Linksys USB100m dongle..." So first, that's a major performance limitation, and could also be a compatibility issue. You don't specify hardware, are you running on a laptop or desktop/PC? Do you have the option to go with a PCIE expansion card?

I did in fact run OPNSense on a laptop with a USB 2.0 Gigabit adapter (ASIX-based) for nearly 2 years. That was good up to USB 2.0 speeds, and enough for my 150Mbit connection. It works when it works, but when it doesn't, well, you get tired of fighting it. This past summer I switched to a small form factor PC with an old HP branded Intel chipset, dual-port Gigabit PCIE card HP NC360T. There are many old server-class cards for less than or around 20USD on Ebay. Search the posts here and you'll see many recommendations to go with Intel-based chipsets with the Free/HardenedBSD base of OPNSense. My new install has been error-free since going to the Intel-based card.

I can follow conceptually what you are trying to do, but not sure how your architecture will work, or why you are mixing untagged and tagged/VLANs, with the tagging requirement 'the switches must do that'.

What I can tell you is that you can trunk through multiple switches and use multiple SSIDs/VLANs on the UniFi WAPs. I have a Cisco Catalyst 2960 and an 8-port NetGear Smartswitch with 3 UniFi WAPs and 4 SSIDs/WLANs (and 4 wired VLANs). Everything has VLANs defined: OPNSense, switches, and the WAPs. I trunk from OPNSense to the Catalyst, to the NetGear with connected WAPs (for more Gigabit ports).

Links between your switches, and to the WAPs, must be 'trunked' or 'tagged' with all the VLANS that need to go across: on my NetGear, this means that all my wired and wireless VLANs are 'tagged' for the links between switches and to the WAPs. If you have VLANS 100 and 200 for SSIDs and 300 for wired LAN, then would need to tag 100 and 200 on your WAP ports, and all 3 of them where your switches connect. Your only 'untagged', or 'access' switchports would go to devices like your PCs.

You don't specify both a 'LAN/internal' wireless and guest (VLAN100) wireless on the WAPs, but assume you mean to do that. Again, my experience would be is that if you are 'tagging' one VLAN for guest, your need to tag all of them. Unless you've found something in the UniFi docs or forums that show how to mix tagged and untagged, not tagging everything IMO complicates it unneccessarily.

Question about setting/changing NUT parameters: Is there any way to specify the 'cable type'? NUT documentation for the 'apcsmart' driver says:

This driver expects to see a 940-0024C cable or a clone by default. You can switch to the 940-0095B dual-mode cable support with the 'cable=' definition described below.

https://networkupstools.org/docs/man/apcsmart.html

I have an older BP1400 (circa early 2000s Backups Pro) which I believe does expect the 940-0095B cable. I have that, and also ordered the noted 940-0024 cable, but I cannot get any communication. There may be other issues, but to me it seems trying to resolve the cable first makes the most sense. My serial/adapter should be good, as I am seeing this in the logs, so it is recognized: kernel: ugen0.2: <Prolific Technology Inc. USB-Serial Controller D> at usbus0

I tried setting 'cable=940-0095B' as an 'Argument', but still did not work. Neither does connecting using the noted 940-0024 cable, but I'm not sure if that pinning will work with the BP1400.

I had seen other more detailed posts and replies about the problems with users being able to set more extensive configuration parameters, and I understand the concerns. But, is there a work-around, or could there be a way to at least select the cable type?

Or am I missing something else entirely?
Thanks