Topics

[The Pledge of the Network Admin]

The Pledge of the Network Admin

This is my network.
It is mine,
or technically, my employer′s.
It is my responsibility,
and I care for it with all my heart.
There are many other networks a lot like mine,
but none are just like it.
I solemnly swear
that I will not mindlessly paste from HOWTOs.

-- Peter N.M. Hansteen, "The Book of PF, 4th Edition"

[Floating > Interface group > Interface]

OK, I just noticed a thing after upgrading to 26.1 and using the new rule interface. I suspect the issue was present in previous versions in the same manner, I just did not notice it.

So rule order watched from the highest level is:

Floating > Interface group > Interface

This is well documented and has not changed ever I could remember. And I use it more or less extensively to get a maintainable structure and a low number of rules.

Floating:



I really do think that blocking ICMP echo is silly, that it's the most important debug tool of all in IP, so I generally allow it, even when other traffic across the same interfaces is forbidden.

Interface groups:

I have one interface group "Internal" which is all my interfaces but WAN and the one to the DSL modems's management interface. I have another group named "Restricted" which is the same as "Internal" but without LAN. These are the interfaces for which I block any "cross talk". LAN after floating and groups applied has a final "allow all" rule just like the default setup.

These are the rules for the "Restricted" group:



This allows essential services to the respective firewall interface plus Internet access to arbitrary services but no access to any other local network. If you look closely you recognise that this set of rules does not yet prohibit e.g. SMTP out to the Internet. It's only "allow" rules, so the first three simply do not match and then the last two still allow DNS, NTP and SMTP outbound.

But I take care of that in the "Internal" group:



Since my LAN is generally "allow all" but I still want to restrict DNS, NTP and SMTP, the block rules for these go into the "Internal" group. Remember, that contains all "Restricted" interfaces plus LAN.

Result:

This works. I just verified by disabling all "Internal" rules - SMTP from a host on a restricted interface to the Internet is open. Enable again - SMTP blocked.

Fine.

My question is: why?

Why are the group rules for the "Internal" group applied before the rules for the "Restricted" group? As is obviously the case? And how can I guarantee a certain order of certain groups, because I want block before allow? Is it the metric system ... er ... alphabetical sorting?

Kind regards,
Patrick

Subject says it - I could not find any option that would do this.

Hi all,

after upgrade from 25.7.11_2 to 26.1r1 everything looked good at first. I did not yet try the rule migration but intended to wait for RC2 with all the fixes in that specific area.

Half an hour later Internet was down. SSH to the box still working, system quite sluggish, dashboard widgets failing to load.

A couple of hundred processes like this:

Code Select Expand

/usr/local/bin/php /usr/local/etc/rc.newwanipv6 pppoe0 force

"killall -9 php" made the system responsive again for a short while but the processes kept piling up.

Anything specific in the log I should look for?

With 25.7 running, this is the dhcp6d.conf:

Code Select Expand

interface pppoe0 {
  send ia-na 2; # request stateful address
  send ia-pd 2; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 2 { };
id-assoc pd 2 {
  prefix ::/56 infinity;
};

I'm a bit puzzled by that "request domain-name-servers;" - is that hard coded? I could not find a way to disable it, anywhere and I certainly do not want any DNS servers, be it v4 or v6 from my ISP.

I isolated the logs for a single PID when the system was running 26.1r1:

Code Select Expand

root@opnsense:/var/log/system # grep 56100 *
latest.log:<29>1 2026-01-25T14:53:57+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="701"] Sending Solicit
latest.log:<27>1 2026-01-25T14:53:57+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="702"] transmit failed: Can't assign requested address
latest.log:<29>1 2026-01-25T14:53:58+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="705"] Sending Solicit
latest.log:<29>1 2026-01-25T14:53:59+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="721"] Sending Request
latest.log:<29>1 2026-01-25T14:53:59+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="722"] Received REPLY for REQUEST
latest.log:<29>1 2026-01-25T14:53:59+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="723"] failed to remove an address on pppoe0: Can't assign requested address
latest.log:<29>1 2026-01-25T14:53:59+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="724"] failed to update an address ::
latest.log:<29>1 2026-01-25T14:54:00+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="732"] Sending Solicit
latest.log:<29>1 2026-01-25T14:54:01+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="733"] Sending Request
latest.log:<29>1 2026-01-25T14:54:01+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="734"] Received REPLY for REQUEST
latest.log:<29>1 2026-01-25T14:54:01+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="735"] failed to remove an address on pppoe0: Can't assign requested address
latest.log:<29>1 2026-01-25T14:54:01+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="736"] failed to update an address ::
latest.log:<29>1 2026-01-25T14:54:02+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="741"] Sending Solicit
latest.log:<29>1 2026-01-25T14:54:03+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="744"] Sending Request
latest.log:<29>1 2026-01-25T14:54:06+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="746"] Received REPLY for REQUEST
latest.log:<29>1 2026-01-25T14:54:06+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="747"] failed to remove an address on pppoe0: Can't assign requested address
latest.log:<29>1 2026-01-25T14:54:06+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="748"] failed to update an address ::
latest.log:<29>1 2026-01-25T14:54:07+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="757"] Sending Solicit
latest.log:<29>1 2026-01-25T14:54:08+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="759"] Sending Request
latest.log:<29>1 2026-01-25T14:54:08+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="760"] Received REPLY for REQUEST
latest.log:<29>1 2026-01-25T14:54:08+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="761"] failed to remove an address on pppoe0: Can't assign requested address
latest.log:<29>1 2026-01-25T14:54:08+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="762"] failed to update an address ::
[...]
system_20260125.log:<29>1 2026-01-25T16:12:17+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="20634"] Sending Solicit
system_20260125.log:<29>1 2026-01-25T16:12:18+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="20640"] Sending Request
system_20260125.log:<29>1 2026-01-25T16:12:18+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="20641"] Received REPLY for REQUEST
system_20260125.log:<29>1 2026-01-25T16:12:18+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="20642"] failed to remove an address on pppoe0: Can't assign requested address
system_20260125.log:<29>1 2026-01-25T16:12:18+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="20643"] failed to update an address ::
system_20260125.log:<29>1 2026-01-25T16:12:19+01:00 opnsense.ettlingen.hausen.com dhcp6c 56100 - [meta sequenceId="20646"] Sending Solicit
root@opnsense:/var/log/system #

Kind regards,
Patrick

Frohe und gesegnete Weihnachten allen, die feiern.

Ruhige besinnliche Tage, Zeit für die, die euch wichtig sind, euch allen. Und ein gesundes und friedlicheres 2026 für alle.

Patrick

Hi all,

is anybody running NDP proxy in a high availability configuration? Anything special to consider?

WAN will be a flat Ethernet (vSwitch) with router advertisements and SLAAC.

TIA,
Patrick

Hi all,

I swapped a dying SSD for a new one, performed a fresh installation and imported a saved configuration.
Everything went smoothly - apart from GeoIP aliases.

It seems I can download neither from ipinfo nor from maxmind.

Any time I click on "Apply" this is the message I get:



Manually fetching the data with the exact URLs I place in the UI of course works.

Any ideas? Version is 25.7.7_4.

Thanks,
Patrick

Hi all,

I just moved one customer IPsec tunnel from old legacy framework to connections - all up and connected.

But this is an HA setup, the local endpoint for the tunnel is the CARP address, CARP is working and has been for years.
But the dashboard widget on the standby shows the tunnel as active (green) with the addition of "Phase2 disconnected".

This was not the case ans still isn't for connections that use the legacy method. For them the standby shows disconnected (red).

Any ideas? Thanks!
Patrick

Hi all,

so I finally found a capable Netflow consumer/visualiser to send data to - thanks to @9axqe for the discussion and some pointers. I finally settled on ElastiFlow. Their Docker based quickstart instructions worked great.

Now apparently OPNsense sends ifName and ifDescr in the flow data with both fields containing e.g. "pppoe0" or "vlan01" or "igb0" ... whatever.
It would of course be great of ifName would contain "pppoe0" and ifDescr "WAN" if that interface is assigned in that way.

But that is still perfectly fine, because ElastiFlow provides a simple method to map interface names like so:

Code Select Expand

192.168.1.1:
  11:
    ifName: LAN
    internal: true

The IP address is the address of the Netflow sender, the first number is the ifIndex which is identical for both Netflow and SNMP, and then you can change arbitrary fields so the interface name in the ElastiFlow dashboards is "LAN" instead of  "vlan01" by the example above.

Great.

Now after I created entries for all my interfaces there is one single ifName for which OPNsense sends flow records to ElastiFlow and that is named - oddly - "index: 0".

What real interface on the OPNsense system is this? So I can adjust the displayed name to something reasonable.

Mind you, this is data sent from OPNsense to ElastiFlow with an interface name that is literally "index: 0" if I am not grossly mistaken. And I just wonder what precisely that data is - yes, there are flows if I filter for "index: 0". But nothing that obviously matches a real interface.

I can send anyone a single flow record in JSON showing that weird ifName field. I just do not want to post that data publicly where it will be indexed by search engines etc. Only IP addresses and DNS names in there, but still.

Thanks,
Patrick

Hi all,

I am currently toying with ElastiFlow pumping netflow data from OPNsense into the tool. I take great care manually adding overrides for all my internal servers to Unbound so I have A and PTR records for everything.

What puzzled me was that in ElastiFlow OPNsense shows as "opnsense" while all other devices are "something.internal.domain.com".


I have in the configuration:

• Register DHCP Static Mappings


• Do not register IPv6 Link-Local addresses


• Do not register system A/AAAA records

And then a manual override: opnsense.internal.domain.com --> 192.168.1.1

Which ends up in host_entries.conf like this:

Code Select Expand

root@opnsense:/var/unbound # grep opnsense host_entries.conf
local-data-ptr: "192.168.1.1 opnsense.internal.domain.com"
local-data: "opnsense.internal.domain.com  IN A 192.168.1.1"


Yet, when I query the system from outside, this happens:

Code Select Expand

root@flow:~# dig -x 192.168.1.1

[...]
;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 10 IN PTR opnsense.
1.1.168.192.in-addr.arpa. 10 IN PTR opnsense.internal.domain.com.
[...]

Why is that first entry there and how can I get rid of it? There should never be multiple PTR records for a single IP address, IMHO.


Thanks,
Patrick

[February 2026:]

Hi all,

Scrutiny is a nice and lean HDD and SSD monitoring solution relying on smartmontools to gather health data. In case of SSDs and OPNsense most importantly the "Percentage Used" (NVMe) or "Percentage Used Endurance Indicator" (SATA) values.

This post does not cover how to install and run Scrutiny - you need a dedicated Linux system for that in addition to OPNsense. The recommended way is to simply start it in Docker.

The installation in OPNsense is done in a way which does not interfere with OPNsense configuration or updates.

February 2026: The project was recently taken over by GitHub user "Starosdev" who added many fixes and improvements including monitoring of ZFS pools. I extended these instructions to include the new repository and the new ZFS pool metrics.

Scrutiny GitHub repo


1. Install smartmontools

The easiest way is to install the os-smart plugin from System > Firmware > Plugins

2. Install the Scrutiny binaries for FreeBSD

As root on OPNsense do:

Code Select Expand

cd /root
fetch https://github.com/Starosdev/scrutiny/releases/download/v1.19.2/scrutiny-collector-metrics-freebsd-amd64
fetch https://github.com/Starosdev/scrutiny/releases/download/v1.19.2/scrutiny-collector-zfs-freebsd-amd64
chmod 755 scrutiny-collector-*
3. Create a wrapper shell script

Use an editor to create /root/run-scrutiny.sh with this content:

Code Select Expand

#!/bin/sh

cd /root

./scrutiny-collector-metrics-freebsd-amd64 run --api-endpoint "https://scrutiny.mydomain.com" --host-id "OPNsense" --log-file "scrutiny-collector-metrics.log" >/dev/null 2>&1
./scrutiny-collector-zfs-freebsd-amd64 run --api-endpoint "https://scrutiny.mydomain.com" --host-id "OPNsense" --log-file "scrutiny-collector-zfs.log" >/dev/null 2>&1

Adjust the api-endpoint and host-id for your environment.

Make it executable:

Code Select Expand

chmod 755 /root/run-scrutiny.sh
4. Create a symlink to activate it as a daily periodic job

Code Select Expand

cd /usr/local/etc/periodic/daily
ln -s /root/run-scrutiny.sh scrutiny
5. Result

The stats will be updated every night at 3 am and in my case look like this:



Clicking on the drive entry shows you all SMART attributes concerning the drive health in detail:



So I know that I have used up 5% of the drive's guaranteed write endurance, for example.

---
Done - enjoy.
Patrick

Code Select Expand

root@opnsense:/var/log/kea # ps awwux | grep kea
root    23264   0.0  0.3   51808  22872  -  S    16:12     0:00.12 /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf
root     8097   0.0  0.0   13744   2460  0  S+   16:20     0:00.00 grep kea

Nothing unusual in the logfile, either, but:



State in the service settings identical to the widget. All "red".

Kind regards,
Patrick

Hi!

After upgrading our 4 systems with a business subscription all are working well but I cannot see them in OPNcentral at all. Re-creating and reconfiguring an API key for one of the manages systems did not change anything.

All systems including the one running OPNcentral are on 25.4.

Where shall I look for clues?

Thanks!
Patrick

The configuration contains manual overwrites, these may interfere with the settings configured here.

I definitely have not made any manual changes in config files so how can I find out what this message is referring to?

Thanks,
Patrick

Hi all,

24.7.9 --> 24.7.11_2

Tunnel to a Sophos appliance claims to be up, but no traffic is passing in at least one direction. We have 3 phase 2 SAs and it seems that the problem occurs whenever there's a rekey happening. All hints welcome.

Thanks and kind regards,
Patrick

I have this pair of firewalls and a link local address as a CARP VIP for my DMZ. Also the router advertisement service is enabled on that interface as "unmanaged", because I rely on SLAAC throughout. See screen shots for the CARP and RA configuration, please.

The CARP state looks good - one node is master, the other one backup for all addresses on all interfaces.

Unexpectedly my Ubuntu server in that DMZ receives and uses two default routes - and with the node link-local address instead of the CARP address as the gateway. Is this intentional?

Code Select Expand

::/0                           fe80::f690:eaff:fe00:6506  UGDAe 1024 9     0 eth0
::/0                           fe80::f690:eaff:fe00:6500  UGDAe 1024 1     0 eth0

The generated radvd.conf looks identical on both nodes:

Code Select Expand

# Generated RADVD config for manual assignment on opt2
interface vlan0.15 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
prefix 2a00:b580:a000:4000::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
};
};

Shouldn't the configured CARP address as source appear somewhere in the config?

Kind regards and thanks in advance,
Patrick

Hallo zusammen,

die DG grast gerade das Wohngebiet meines Kollegen zwecks Erschließung ab und verteilt fleißig Prospekte.

Leider fehlt sowohl in dem Hochglanzteil als auch in den AGB jede Definition, wie sie denn nun IP liefern. Den verschiedenen Threads hier entnehme ich, dass es auf jeden Fall IPv6 gibt, möglicherweise nur PD - was ja aber kein Problem wäre.

Die interessantere Frage aber ist:

- gibt es eine öffentliche fixe IPv4-Adresse?
- wenn nein, gibt es zumindest eine öffentliche dynamische IPv4-Adresse?
- gibt es ein fixes IPv6-Prefix?

Eigener Router (Sense) am ONT scheint ja wenigstens offiziell supportet zu werden. Würde dem Kollegen dann eine Fritzbox 7510 hinter der Sense für die DECT-Telefone empfehlen. Schon witzig, dass heutzutage eine Fritzbox die beste Telefonanlage für einen Privathaushalt oder ein kleines Büro ist. Das Gigaset-Zeug oder Yealink ist eine dermaßene Zumutung ... hatten wir ja schon  ;)

Danke für Hinweise, Grüße
Patrick

Hallo, nachdem hier ja einige Spezialisten für SIP unterwegs sind, und der Anlass für das Problem tatsächlich der Einbau einer OPNsense ist, versuche ich es erst einmal hier.

Gegeben ist ein Vodafone Kabelanschluss mit Fritzbox vom Provider und Telefonie. Ich hatte ja vor einiger Zeit schon mal mit euch die Szenarien durchgespielt von wegen Bridge Mode, eigenes Kabelmodem, etc. pp.

Wir haben dann den sinnvollen Hinweis beherzigt, die OPNsense hinter die Fritzbox zu hängen. Zunächst ohne doppeltes NAT mit einer statischen Route in der Fritzbox. Das Management-Netz für das Unifi-Geraffel haben wir ebenfalls "draußen" gelassen und einfach zwei neue VLANs in Unifi angelegt und auf getrennte phys. Ports der OPNsense gepatcht. Ihr könnt mir glauben, dass wir diesen Teil im Griff haben  ;)

/16er Netze weil der liebe Kollege ein Einfamilienhaus hat und seine Heimautomatisierung etwas eskaliert. Das war auch der Grund für die OPNsense und getrennte Netze etc. pp. Will sagen, es ist wahrscheinlich, dass 254 Adressen nicht ausreichen werden.

NAT auf der OPNsense wie gesagt aus!

Code Select Expand

                                               ▲                                               
                                               │                                               
                                               │                                               
                                               │ Uplink                                       
                                               │                                               
                                               │                                               
                                      ┌────────────────┐                                       
                                      │                │                                       
                                      │                │                                       
                                      │    Fritzbox    │                                       
                                      │                │                                       
                                      │                │                                       
                                      └────────────────┘                                       
                                               │                                               
                                               │ 192.168.90.1                                 
                                               │                    Unifi VLAN: Default (1)   
                                               │                    Netzwerk:   192.168.90.0/24
                                               │                                               
                                               │ 192.168.90.2                                 
                                               │                                               
                                      ┌────── WAN ─────┐                                       
                                      │                │                                       
                                      │                │                                       
──────────────────────────────────── LAN   OPNsense   IOT ─────────────────────────────────────
                                      │                │                                       
Unifi VLAN: LAN (16)                  │                │ Unifi VLAN: IOT (17)                 
Netzwerk:   172.16.0.0/16             └────────────────┘ Netzwerk:   172.17.0.0/16             
DHCP Range: 172.16.1.0-172.16.255.254                    DHCP Range: 172.17.10.0-172.16.255.254

Auf der Fritzbox haben wir dann eine einzige statische Route angelegt, siehe Bild:



Und jetzt kommts: wenn diese Route aktiv ist, funktioniert die Telefonie nicht. Man ruft an, Signalisierung klappt, aber keine Sprachübertragung. Das Telefon ist ein Gigaset DECT-Telefon an der Fritzbox. Es ist also lokal kein SIP im Spiel.

Schaut man in der Fritzbox in das Log unter Telefonie > Eigene Rufnummern > Sprachübertragung, dann sieht ein Anruf so aus:



Was ist das für eine IP-Adresse 172.17.8.97? Die existiert in unserem Netz nicht! Bildet so eine Fritzbox die DECT-Telefonie auf nicht dokumentierte private IP-Adressen ab, die sie intern für ... was eigentlich ??? ... verwendet?

Bin diesbezüglich sehr verwirrt. Weiß da jemand was?

Deaktiviert man die Route in der Fritzbox, funktioniert es sofort wieder. Was zur Hölle?

Ein möglicher Workaround ist natürlich, auf dem WAN der OPNsense dann doch NAT zu machen. Oder ein anderes Netz zu wählen? Gibt's da irgendwo eine Doku? Hätte ich die Garantie, dass es mit irgendwas aus 10/8 dauerhaft funktioniert?

Danke im Voraus und Grüße
Patrick

Hi all,

if I want to copy "distro" to "/usr/local/sbin/distro" like so:

Code Select Expand

distro:/usr/local/sbin/distro


is there a way to specify that the file should be installed mode 755?

Thanks!
Patrick

Hi all,

wasn't there a release when wg0 became verboten and interfaces needed to start with wg1? I remember I renumbered all interfaces on all my firewalls via XML edit back then.

Now I just configured a new system with a single tunnel, added an instance and a peer and *boom* - wg0.
So what's the current (and hopefully future) state of affairs?

Thanks,
Patrick