Messages

Ich bin immer wieder erstaunt, in welche Probleme man laufen kann, denn nach meiner Erfahrung macht eine OPNsense nach der Grundinstallation erstmal genau das, was man braucht, um mit ihr zu arbeiten, sprich WAN per DHCP und ein LAN mit DHCP und einer "allow all" Regel.

Wenn man weitere Netzwerke hinzufügt, egal ob LAN oder VLAN, muss man alle(!) Regeln selbst schreiben, weil per Voreinstellung nichts erlaubt ist. Dabei kommt es natürlich auf die Reihenfolge an und darauf, ob es "Quick" Regeln sind oder nicht.. Wenn also Hilfe zu Regeln gewünscht wird, ist ein Screenshot immer sehr hilfreich.

Auch sehr hilfreich ist es, Regeln erstmal mit Logging einzurichten, damit man im Firewall: Logging: Live View den Effekt sehen kann.

Just FYI:

At a site where an OPNsense is connected to the internet via a Telekom DSL router with LTE fallback, the fallback does not provide IPv6. In addition to the obvious problems with that, I found that unbound fails frequently with messages like

Code Select Expand

error: SERVFAIL <ocsp.edge.digicert.com. A IN>: exceeded the maximum number of sendsIt appears that unbound continues to contact nameservers via IPv6 even after repeated failures, not reverting to IPv4 automatically, thus impacting even IPv4 connectivity.

A quick hack to restore IPv4 connectivity completely is to set "do-ip6: no" in the "server:" section of unbound.conf and reload.

..., but everyone has to start somewhere when learning and forums are a means to learn

People here try to help the best they can given the questions they see.

The OPNsense UI provides inline help text. You can either press the i button near a configuration item or make all help text all visible all the time with the "full help" setting near the top right corner. The help text for "Static ARP" says exactly what it does. BTW, DHCP reservations do nothing to prevent ARP spoofing.

Unifi switches can use any vlan for their management network just like all other Unifi gear. The tricky bit is that one needs a switch port (ideally with PoE) configured to that vlan to adopt any new devices, i.e. untag outgoing traffic, tag incoming traffic with the management vlan.

You need to explain what role the Dream Machine has in your setup. By default it is a network controller, a router, DHCP server and a firewall and lots more. You need to turn off all features except the network controller app or you'll run the risk of services on OPNsense and Dream machine competing against each other.

Also, the OPNsense needs to be connected to one of the internal ports of the dream machine, not one of its WAN ports.

To avoid all of these problems, you may be better off with a Unifi CloudKey or just the Unifi Network Application running on a server instead of the Dream Machine.

Assuming you got that right, let's start with the fact that you didn't mention which VLAN is used for the management network of your unifi devices (the one they use to communicate with the network app). Assuming it is 1, the Unifi default, your OPNsense will never see any traffic on that network as it doesn't have an interface on it. Consequentially, your Unifi Switches and APs never get an answer from DHCP and fall back to their default 192.168.1.20.

In terms of debugging: Turn on logging of all your firewall rules and the default rules to see what your OPNsense sees and drops or allows. And, as mentioned by meyergru, OPNsense follows the philosophy of "deny by default", i.e. no traffic is accepted unless explicitly configured. In contrast, Unifi firewalls are "allow by default" if I remember correctly.

When creating a firewall alias and then deleting it later the alias still lives on in the drop down menu of the firewall diagnostics until a reboot. This is on 25.10.2

All there is is the log of the restarted procedure, after I made room in /var/log. The initial run stopped when trying to install suricata while /var/log/ was 100% full. But here it is anyway.

No, unfortunately not. When something fails I'm totally focussed on restoring functionality. I'll try to do better next time. Maybe it'll help to keep a history of logs of opnsense-update?

While updating from 25.10.1_2 to the latest release the update process stopped while updating suricata with "/var/log/suricata: filesystem full", or something along this line. Sorry, I forgot again to save the update log file. Anyway, as it turns out, the directory /var/log/suricata didn't even exist. But /var/log/resolver was eating up over 90% of the file system space, leaving no free space. So, I deleted all the crap, restarted the update and everything looks alright now.

I would like to kindly ask that the update procedure gets augmented with sanity checks to prevent out of memory conditions and possibly more stuff. You guys probably have a lot more ideas than me.

The more important bit to me however, is that unbound can fill up the entire /var/log filesystem because there doesn't seem to be proper log file rotation. For now I have deactivated query logging to gain some time before consuming all available disk space again.

And there's one more thing: While investigating I saw that the /var/log filesystem is mounted twice:

Code Select Expand

root@firewall:~ # df -h
Filesystem                  Size    Used  Avail Capacity  Mounted on
zroot/ROOT/default          221G    1.6G    219G    1%    /
devfs                        1.0K      0B    1.0K    0%    /dev
/dev/gpt/efifs              256M    864K    255M    0%    /boot/efi
zroot                        219G    96K    219G    0%    /zroot
zroot/tmp                    219G    96K    219G    0%    /tmp
zroot/var/audit              219G    96K    219G    0%    /var/audit
zroot/usr/home              219G    96K    219G    0%    /usr/home
zroot/var/log                220G    311M    219G    0%    /var/log
zroot/var/crash              219G    96K    219G    0%    /var/crash
zroot/var/tmp                219G    96K    219G    0%    /var/tmp
zroot/usr/src                219G    96K    219G    0%    /usr/src
zroot/var/mail              219G    136K    219G    0%    /var/mail
zroot/usr/ports              219G    96K    219G    0%    /usr/ports
tmpfs                        2.0G    2.6M    2.0G    0%    /var/log
tmpfs                        1.2G    3.0M    1.2G    0%    /tmp
tmpfs                        1.2G    152K    1.2G    0%    /var/lib/php/tmp
devfs                        1.0K      0B    1.0K    0%    /var/dhcpd/dev
devfs                        1.0K      0B    1.0K    0%    /var/unbound/dev
/usr/local/lib/python3.11    221G    1.6G    219G    1%    /var/unbound/usr/local/lib/python3.11
/lib                        221G    1.6G    219G    1%    /var/unbound/lib
root@firewall:~ #
I know what it means and I know that it works fine, but why is /var/log not unmounted before mounting tmpfs in its place?

On a side note, I had lots of TLS Handshake timeouts with fontawsome.com in the last 2 days (Firefox 140). Luckily, they can be blocked without defects to the site using noscript ...

Thanks guys, your discussion adds valuable information that helped me get my setup running (finally). But while experimenting with the settings I noticed something:

At a site with limited upload capacity, traffic from one network needs to be de-prioritised when other traffic is present. So, I added an upload pipe with the full nominal bandwidth to the ISP, added two weighted queues and the rules (great to have interface pairs in rules!). Generally, everything works as expected. Occasionally however, I get DNS resolution failures on the hi-prio networks while the low-prio network is uploading at full speed. This has not been observed before using traffic shaping. I'm not 100% sure what is going on. Shifting queue weights doesn't seem to do much to solve the issue. Latest test is to lower the pipe bandwidth to a few Mbits below the nominal bandwidth because the connection is via VDSL and the actual bandwidth is fluctuating somewhat. I'm guessing that physical bandwidth below pipe bandwidth may mess with the scheduling.

Since the DNS timeouts occur only sporadically, I can't be sure if this really fixes the issue. Has anyone else seen this and is there a know solution?

If the ISP's Combo router provides a way for the customer to add routes, you don't have to do double NAT. Define the networks your OPNsense should handle, add the OPNsense as router for these networks to the Combo router's routing table. Then, add the necessary firewall rules to the WAN of your OPNsense and turn off NAT on it. Now, only the ISP router does NAT.

IPv6 doesn't need NAT. Just make sure the ISP router can delegate a prefix to OPNsense.

Ok, I see. It's a community plugin after all. Thanks for the info and please keep the porting effort up.

B.t.w. Is there a way to switch the repository for this plugin?

I'm currently experimenting with the NDP proxy go and I have to say that this is an invaluable tool if you want to use an existing segmented network behind a LTE/5G router because carriers only hand out /64 prefixes. That said, I would love to use the automatic aliases as documented in the OPNsense Help, but I can't find the settings in the UI. Is this a problem with my OPNsense 25.10.1_2-amd64 + os-ndp-proxy-go 1.0 (says 0.1 in the changelog) installation or is a problem with the OPNsense docs? After all, the ndp-proxy website doesn't mention aliases.

@mooh These firewall rules have nothing to do with the default route in the routing table.

I agree, it doesn't change the kernel routing. Thanks to your response I now understand the question better, so please ignore my comment.

Have you looked into the Firewall:Settings:Advanced:"Disable force gateway" setting? By default OPNsense creates a default policy route for traffic originating from the FW itself.