Messages

Downgrading to unbound 1.7.3 from 18.1 helps! So apparently there's a regression from 1.7.3 to 1.8.1 and up.

Used https://pkg.opnsense.org/FreeBSD:11:amd64/18.1/latest/All/unbound-1.7.3.txz and pkg add -f

Ok, this a lot badder: some 5 minutes after restart, the service will stop using the domain override, and try to resolve upstream.

A router pair with similar config still on 18.7.6 (unbound 1.8.1) doesn't show this problem so I tried that binary instead of the 1.8.2_2 version; no improvement.

I've been upgrading from 18.1.x to 18.7.9, and had some trouble with unbound not resolving some domain overrides after that. It would resolve some addresses from cache, and tried some from root servers. I had to edit and save a domain override unmodified to get unbound back to normal work.
This happened on two machines (master and slave).

There are some smartphones that will connect via wireless to one LAN or another, depending on app needs. Apparently, IOS phones may remember the old IP address, and sending out UDP broadcasts for quite some stuff (SMB, dropbox, spotify) using the old IP address (network A) on a LAN that has another network B.
Even if the iPhone is disconnected, about 4000 packets/s are still broadcasted, originating from the firewall's B network, but broadcasting A-sourced packets.
I have invented block rules
- for specific UDP ports
- for 255.255.255.255 destination
- for any packets that don't originate from that interface's network

Still, these broadcast storms from the firewall persist.
To stop the storm, I need to issue pfctl -d ; pfctl -e

I'm running out of ideas.

card/pfsync pair of opnsense, sometimes the master is the source of the broadcasts, sometimes the backup.

Anybody a clue for me?
Regards
Andreas

I got the very same problem, but the message just couldn't imagin which alias might be the faulty one.
I extended the message "Reserved protocol or service names may not be used" to include the name, and thus found out that 'sieve' and 'mysql' are forbidden.

I suggest extending that error message in upstream as well.

I had the same problem; couldn't update my 18.7.4 to .5 or .6 via GUI on one of two routers (carp pair). changelog was downloaded/unpacked successfully, but then things stopped. Connectivity to update site (pkg.opnsense) was fine.

I finally conducted the update via CLI successfully.

Yeah, already ditched os-bind for the old FreeBSD pkg.

For quite a while I had bind9 running on my firewalls (from FreeBsd repo), acting as secondary.
After Upgrade to 18.7, named was gone, and I installed os-bind, not immediately noticing the OpnSense configuration options so I went on configuring as usual.
Unfortunately, my configuration won't survive a reboot, and the config pages for bind are not sufficient to configure.
A free text "custom options" field as in unbound config or "advanced" as in dnsmasq would be very helpful.

Ok, I fixed this by specifying a dedicated IP.
IMHO the sticky option should be default on, since load balancer et al get confused if the same client is using different ips within the same session.

After upgrading to 17.x to 18.1.2, the outgoing NAT address translation doesn't work any more as expected.

I have outgoing nat configured to use the interface address on a CARP cluster, which used do use the physical ip address of each machine.
After the upgrade, outgoing traffic uses all VIF ip addresses randomly, making some sites' session handling nonfunctional.

That patch, apparently, included in 18.1, doesn't fix my issue.
Despite pass-rules on any carp traffic on the interface and as floating rule, the backup won't receive carp packets until I disable fw on the master.

Ich muß diesen Thread noch mal bumpen.
Auch nach Upgrade auf 18.1.2 immer noch das gleiche Problem: Am Backup kommen die CARP-Announcements am WAN-Interface nur an, wenn ich am Master die Firewall disable.

Floating Rules sind leer, anhängend die WAN-Rules mit meinen Versuchen CARP-Verkehr zu sehen.

Hab Bogon Filter testweise abgeschaltet. Hatte den unschönen Effekt daß nach Config neuladen auf dem Master alle VIFs wegwaren, ich mußte CARP disablen und enablen um ihn wieder zum Laufen zu bringen. Backup steht dauerhaft auf disabled, da CARP ja nicht funktionstüchtig ist....

Bogon Filter abschalten macht keinen Unterschied, weiterhin CARP Announcements nur bei pfctl -d auf dem Master.

Nach einem Update eines Firewall-Paars von 17.1.2 über 17.1.11 auf 17.7.6 funktioniert CARP auf dem WAN-Interface nicht mehr, da der Master zwar seine CARP-Announcements wie erwartet erzeugt, diese die Firewall aber nicht verlassen und der Backup daher meint übernehmen zu müssen.
Im Filterlog ist von CARP nichts zu sehen, die Pakete gehen aber sofort raus wenn die Firewall per pfctl -d abgeschaltet ist. ACCEPT-Rules helfen nicht.

Irgendein Hinweis wo das hängenbleiben kann?