Recent posts

#1
26.1, 26,4 Series / Re: 26.1.6_2 - All traffic blo...
Last post by thormir84 - Today at 09:00:03 AM
With the latest updates (26.1.7 and 26.1.7_1) and leaving everything as it was originally, the problem has stopped occurring; i activated the Kea DHCP service, after deactivating and uninstalling ICS, and i corrected the 2 rules by putting '*' in the source port; now everything works as it should (moreover, i don't know how it used to work before and why I didn't notice it).

The rules in Destination NAT had already been set up and, from what i have seen doing some tests, they must exist otherwise nothing works.
I noticed that if i leave the Destination NAT rules active and deactivate the firewall ones or vice versa, the traffic is blocked, so i assume both must always be there.

In the Destination NAT rules, i also noticed that if i select the port as "https" and "http" instead of "Single host or Network" by entering "443" and "80", the traffic is blocked; i do not understand the logic.
#2
I can confirm on my template firewall instances, both BE and CE,
which I use to deploy for production environments for a new sub key or a CE user.

I ran through a few tests in the hopes this helps development.

OPNsense BE 26.4_6-amd64:
No issues editing a user with a heavily modified Dashboard
No issues adding a new user with a password.
No issues editing previous user, and new user passwords.

OPNsense CE 26.1.6-amd64:
No issues editing a user with a heavily modified Dashboard.
No issues adding a new user with a password.
No issues editing previous user, and new user passwords.

OPNsense CE 26.1.7_1-amd64 :::::::::::
Cannot edit user with a heavily modified Dashboard.
No issues adding a new user with similar privileges.
No issues editing the new user with no prior Dashboard..
After resetting the Dashboard of the trouble user, the user can be edited.

Workarounds to edit the original user:
Reset the dashboard of the trouble user, and proceed to edit the user.
Edit a fresh config and insert a new password created from the passwd utility.

The problem returns immediately:
When heavily modifying the dashboard, the problem returns.
The problem desists if the dashboard is left in a default reset state.

I miss when I could import just the dashboard config, and transplant just it across multiple sites.
I noticed that option disappeared in the Backup/Restore when we moved to the improved interface.

Also please keep the Track Interface v6 / ISC DHCP v4/v6 available as long as possible or
until the feature is reproduced in whatever is the 'improved' way to do it.
From a GUI perspective it shouldn't matter what the underlying OSS Technology is,
it doesn't look good if there are like 2 or 3 competing services, and the newer ones remove features
we build infrastructure with.

It works perfectly, especially with our local few internet providers.

I am better at IT than I am sales. It is really hard to sell an underappreciated intangible like this,
especially when I encourage my clients to purchase a 3-year subscription.
Like an insurance agent sells insurance, you never appreciate it until you need it.
Life gets harder with a rug moving under us.
If I need DHCP, I just need to find DHCP services, configure my scopes, leases, prefixes etc.
I shouldn't need to worry if it's ISC, DNSMasq, Kea, CoreDHCP, Dibbler, udhcpd, wide, etc.

I think CISCO only gives you one service and handles its own underlying service.
But don't think like Cisco, think better than them.

Thank you have a great week.

Love, A3
#3
German - Deutsch / Instabile IPv4 Verbindung als ...
Last post by markus.tobatz - Today at 07:25:37 AM
Ich betreibe einen Proxmox-Cluster (PVE 9.1) an einem Hetzner vSwitch. Der vSwitch stellt im VLAN 4000 ein IPv4 Subnetz bereit. Darauf soll eigentlich ein OPNsense HA Setup laufen. Ich habe das ganze mehrfach aufgesetzt, Firewall kontrolliert (und teilweise deaktiviert zum Test). Die MTU wird von Hetzner mit 1400 vorgegeben, die habe ich auch an allen Interfaces (Host und OPNsense) kontrolliert und gesetzt.

Eine vollständig eingerichtete OPNsense (mit Regeln, mit Outbound NAT, mit Wireguard und mit CARP IPs) funktioniert prinzipiell. Selbst das Failover funktioniert grundsätzlich. Aber es gibt ein Problem. Ich habe jetzt tatsächlich als allerletzten Test eine weitere OPNsense als VM nur installiert und überhaupt nicht konfiguriert (also wirklich überhaupt nicht konfiguriert, außer der WAN IP) und trotzdem hat sie das folgende Problem.

In einem festen Zeitabstand, ca. alle 160 Minuten, verliert die IP (egal ob CARP IP oder die IP der OPNsense selbst) die Verbindung für 1-5 Minuten. Sie ist dann weder von außen anzupingen, noch kommen die dahinterliegenden VMs ins Internet. Ich lasse von extern mehrere Monitorings (PING) darauf laufen und sehe regelmäßig die Unterbrechungen. Ich finde das Problem einfach nicht. Jetzt kommt das Kuriose: Wenn ich in Proxmox bspw. eine Debian VM aufsetze und auch diese nicht weiter konfiguriere außer ihr eine IP aus dem Subnetz zu geben, dann hat diese *kein* Problem. Wir haben jetzt also eine Debian VM und ein OPNsense, beide in Ausgangskonfiguration nur mit einer Subnetz-IP und nur eine von beiden Maschinen - die Debian-VM - funktioniert.

Hetzner hat dahingehend kein Problem und der Support findet auch nichts. Es stellt sich jetzt die Frage: Was macht OPNsense/FreeBSD also bei der Verwaltung einer einfachen IP anders als Debian? Und wie kann ich das Verhalten abstellen? Ich bin kurz davor, das ganze Setup komplett aufzulösen, weil es seit Wochen instabil läuft.

Hier mal die interfaces eines PVE-Hosts:
auto lo
iface lo inet loopback

auto enp1s0f0np0
iface enp1s0f0np0 inet static
        # public server address
        address <IPv4>/32
        # route to default gateway
        post-up ip route add 88.190.120.1 dev enp1s0f0np0 scope link
        post-up ip route add default via 88.190.120.1
        pre-down ip route del default via 88.190.120.1
        pre-down ip route del 88.190.120.1 dev enp1s0f0np0
iface enp1s0f0np0 inet6 static
        address <IPv6>/64
        gateway fe80::1

auto enp1s0f1np1
iface enp1s0f1np1 inet static
        # ceph cluster interface
        mtu 9000
        address 192.168.1.11/24

auto vlan4000
iface vlan4000 inet manual
        # public subnets on vswitch
        vlan-raw-device enp1s0f0np0
        vlan-id 4000
        mtu 1400
iface vlan4000 inet6 manual

auto vmbr4000
iface vmbr4000 inet manual
        # bridge for routing subnets
        bridge-ports vlan4000
        bridge-stp off
        bridge-fd 0
        mtu 1400
iface vmbr4000 inet6 manual

auto vlan4010
iface vlan4010 inet static
        # proxmox cluster traffic
        vlan-raw-device enp1s0f0np0
        vlan-id 4010
        mtu 1400
        address 10.0.0.11/24
#4
Since you are already way into hex anyway, why not send hex directly?

Its possible with the new options menu, just select hex.
#5
German - Deutsch / Re: Öffentlicher IPv6-Suffix ä...
Last post by drosophila - Today at 03:25:08 AM
Das kommt mir irgendwie vor als könnte es sich nicht entscheiden, welches Interface das Richtige ist. Ist das eine komplett neue Konfiguration, oder wurden da evtl. mal die Interface-Assignments getauscht, so dass nun in einer aktuell nicht sichtbaren Konfigurationsstelle das falsche Interface steht, so dass es eine Race-Condition gibt? Kann man z.B. mal die beiden Interface-Assignments zwischen LAN und WAN tauschen (und natürlich die Kabel umstöpseln), um zu sehen, ob das Problem dann auch auftritt?
#6
Alright, this has not been the final word. Instead I tested some more with appending a true zero. Doing so through the GUI seems to be impossible because it always escapes the escape character "\" into "\\" and therefore destroys the escaping, but from the config file itself it works with an appended "\u000". But for some reason this works only if at least one letter follows the true zero, otherwise KEA just ends there and doesn't send the zero at all. Adding any character(or multiple) makes it send the zero. Like this:

43 0e 2f 70 78 65 62 6f 6f 74 66 69 6c 65 00 56 ff 23 94
That translates to "/pxebootfile<zero>V", note how the length field now is 0e, correctly counting the length including the zero and the appended "V". This is handled correctly by both Realtek and nVidia, both end up requesting "/pxebootfile", which is correct. So is KEA wrong in not sending the final zero even though it correctly specifies the length? Did nVidia work off an outdated spec or did they simply commit the basic blunder of counting from zero instead of one? Does Realtek have a more stringent sanitizer that converts all non-ASCII characters into end-of-string?

Sadly, the "specification" in RFC4578 only says "The format and contents of these options are NOT defined by the PXE specification.", so this must be defined outside of an RFC.
IBM has a document here that lists "UINT8 bootfile[128];   Bootfile: Boot file name. Null terminated string." on page 50. So it seems like the error is indeed on KEAs part, but what about the difference in parameters (noted above: "file" vs. "BF")? Is there yet another spec that supersedes the 1999 IBM document?
So it seems there is one from uefi here. They don't want to let me look at their precious document through my secured browser, and I'm not willing to compromise my anonymity, especially not to satisfy some random sites self-importance. So my research ends here for now. Maybe I'll get back to it on someone elses computer, who doesn't care about security and privacy.

The final question is: does the GUI have some means to escape escape characters so that it does not escape escape characters? IOW: how do I get the "\" into the config file through the GUI without it being mangled into "\\"? So that the resulting config file reads: "data": "\/pxebootfile\u0000V"Not relying on evil filesystem hacks is nice, but managing KEA through files while a perfectly capable GUI is there for everything else also detracts from maintainability.
#7
QuoteWhat filtering options would you actually use?
Anything missing in the IOC view?

Not sure if this is feasible but what about sorting based on country of origin? E.g Country from where the IoC originates.


QuoteIdeas for improving the OPNsense plugin?

Well, OPNsense has inbuilt RRD and other graph possible tooling, would it be possible under the condition its not resource heavy, to create graphs based on the events/IPs/ports/protocols?

Something similar for example as in
Lobby > Reporting > Health
Or
Firewall> Log Files > Overview?

This would still be local to the OPNsense, but would give the users more visual representation.

Regards,
S.



#8
Tutorials and FAQs / Re: Technitium DNS Server on O...
Last post by piepre - Today at 12:47:25 AM
it is also possible to use the freebsd dotnet release:
zfs create zroot/opt
zfs set mountpoint=/opt zroot/opt
cd /tmp
fetch https://github.com/sec/dotnet-core-freebsd-source-build/releases/download/10.0.103-vmr/dotnet-sdk-10.0.103-freebsd.14-x64.tar.gz
tar -zxf dotnet-sdk-10.0.103-freebsd.14-x64.tar.gz -C /opt/dotnet/
ln -s /opt/dotnet/dotnet /usr/local/bin/dotnet
fetch https://download.technitium.com/dns/DnsServerPortable.tar.gz
tar -zxf DnsServerPortable.tar.gz -C /opt/technitium/dns/
cd /opt/technitium/dns
./start.sh &
#9
Hardware and Performance / Re: Achieving sustained 25Gbps...
Last post by pfry - Today at 12:14:05 AM
Quote from: VRBitman on May 01, 2026, 05:13:27 PM[...]My CPU is an i9[...]

If you don't mind saying, what hardware precisely (I believe the first "i9" was a Kaby Lake and the last a Raptor Lake)? Also, NIC and RAM.
#10
Some systems need the whole cert chain in a single file. Others need them separate ie. CA, intermediates if any, server + a separate file for the client. Checck documentation or iternet search for your system's OS needs.
Also posting the log of the failure would help to point in a more specific direction. With any sensitive info redacted.