Messages

1) Zerotier is a plugin maintained by an external contributor. It may not have the perfect integration in terms of e.g. OpenVPN stability. It is a known issue. It also needs work in the core, but it is what it is.

https://github.com/opnsense/plugins/issues/239

2) Nobody "wants" unstable interfaces. How do you propose to lock them by default? How would a config migration from another hardware to a newer system work where interface names change? That's two of the challenges in making the experience less rocky in the future. Any help here is highly appreciated.


Cheers,
Franco

Those are reasonable responses, Franco; thank you. I didn't understand why that checkbox was there, because it seemed to me that interface assignments should be considered stable. Lesson learned; you can be sure I've locked them all now.

I don't know what checking that box does on the backend when you lock the interface and I'm not a PHP dev, so I can't offer any suggestions for how to lock one by default. I can say that I have a greater expectation of configuration stability through on-device upgrades and reboots than I would for migrations to dissimilar hardware, so if I were prioritizing development efforts, I'd look toward the former before worrying much about the latter. We deal in closed-source firewalls (one of which has a free home version that can be installed on off-the-shelf Intel hardware) at my day job, and I came to OPNsense by way of a solid 5-year run with pfSense. This is the first platform I've seen that didn't treat interface assignments as stable.

I know y'all are working hard, Franco, and I do appreciate it. Keep it up; it's a worthwhile effort.

Please lock your Zerotier interfaces and this will not happen. :)


Cheers,
Franco

1) Do I understand you to be saying that an unlocked ZeroTier interface can cause an OPNsense upgrade to remove all interface configuration and assignment?
2) In what use case would an administrator want unstable interfaces? Or, put another way, if it's possible for some operation to cause instability in the interface assignments, why not lock them by default?

Please lock your Zerotier interfaces in their respective interface settings (second checkbox). They are not to be considered stable interfaces. It can happen.


Cheers,
Franco

Frankly, if it was just ZeroTier, it'd be no big deal. Even breaking Suricata is something relatively trivial because it's "just" my home network, and nothing critical depends on IDS/IPS. Reassigning WAN+LAN and breaking Squid, though... that's huge, because it means I have no network.

Aaaand it garbled my Web Proxy settings (interfaces and access control network segments). Neat.

Suricata was down, too. I have it listening on all interfaces, and I had to remove and re-add the Public interface to get it to start. Presumably has something to do with having to reassign/reconfigure OPT1/Public.

Last night as I was going to bed, I fired off the update and reboot to 17.7.10 on my APU. I got up this morning to a down network. After dragging out the laptop and serial adapter, I found the firewall was up but had reverted all the interface assignments to defaults (re0 -> WAN; re1 -> LAN; re2 -> unconfigured) and had garbled the IP address scheme.

So we went from:

• re0 -> Public -> <private /24 network 0> (static/t6)
• re1 -> Private -> <private /24 network 1>(static/t6)
• re2 -> WAN -> DHCP(v6)
• zt* -> ZeroTier -> <private /24 network 2>

to:

• re0 -> WAN -> <private /24 network 1 from above> (static/t6)  :o
• re1 -> LAN -> unconfigured
• re2 -> unassigned -> unconfigured
• zt* -> unassigned -> unconfigured

Once I reassigned interfaces and reset the IP schemes, so far it looks like everything else is okay.
I don't have any idea what happened, but ain't nobody got time for that.  :P If there's an upgrade log somewhere y'all want me to open a Github issue against, point me to the path, and I'll get on it. Or if there's more specific information you'd like, I'll see what I can do.

I have an Atheros AR9280 PCI-e card in an APU, and have configured two virtual NICs in the GUI to use 802.11ng. Best I can tell from https://wiki.freebsd.org/WiFi80211n, there's a driver that supports 802.11g/ng on that card. OPNsense 17.7.9_8-amd64, though, is actually using 802.11b for the interfaces, though.

I'm very comfortable in a Linux environment, but FreeBSD is just unfamiliar enough to leave me floundering a bit. Any idea how I can confirm which driver is being loaded, and can I change that or confirm hardware support somehow?

---

EDIT:

Weird: Looks like manually setting the channel to one using 11ng forces the issue. Channel should auto-select ng when Standard is set that way, huh?

OPNsense 17.7.9_8-amd64

I asked this on IRC earlier, but didn't get a response after a few hours. I figured rather than keep reposting there, I'd put it here:

If I use a bridge interface (between, say, re1 and ath0_wlan1) to serve my private LAN, how can I replicate the various anti-lockout rules that get automatically created for the LAN interface? I think I've got the actual firewall rules right, but would like to be sure. I for sure would like a little direction about the NAT/port forward rule that gets created. I've created multiple new rules that mimic the behavior of the original anti-lockout rules on the wired interface, but would love to clean it up a little by either removing the original rules or redefining them and removing my additions.

TIA, etc. :)