"Recent posts
#1
German - Deutsch / Re: Bootreihenfolge geändert n...
Last post by cottec - Today at 09:20:42 PMQuote from: Patrick M. Hausen on Today at 08:16:10 PMMach mal ntopng aus - das erzeugt ja noch mehr Last auf dem schon kaputten Datenträger.Stimmt, danke.
Gibts eigentlich auch nen Trick wie ich das WAN Gateway wiederbelebe?
Jedes mal wenn die Firewall jetzt "paniced" dann rebooted sie die Interfaces oder was auch immer und dann kriege ich keine IP mehr vom Modem...
Das Verhalten habe ich sonst nur gehabt, wenn ich das Modem neustarte und Opnsense nicht mitkriegt, dass das Interface down war.
Ultra nervig und ich muss jedes mal zig mal hin und her neustarten bis ich wieder Internet habe
Hilft das Log?
#2
26.1 Series / upgrade from 25.7.11_9 and IS...
Last post by jmcgee - Today at 09:10:28 PMI am still using the default from 5 years ago, ISC. Anything I should be aware of before upgrading to 26.1.
#3
25.1, 25.4 Series / Re: UDP6: M_MCAST is set in a ...
Last post by dfw3xam1n3r - Today at 09:07:48 PMDid you ever resolve this?
Quote from: undistio on May 22, 2025, 05:44:36 AMMy system log is getting flooded with the following message:
Severity:Notice | Process:kernel | UDP6: M_MCAST is set in a unicast packet.
1. What is likely to cause this?
2. How would I track down what is causing this?
3. Should I even bother?
#4
General Discussion / KEA DHCPv6 Leases not availabl...
Last post by jonny5 - Today at 08:57:01 PMCurrently still on 25.7.11_9 and have transitioned from ISC to KEA, and so far things are working okay.
With ISC, I could find all of my leases for DHCPv4 and DHCPv6, but with KEA, that does not seem accessible. I tried looking into "host discovery" / "host watch", but maybe it isn't built out in 25.7.x yet. Curious what we can expect to use "host discovery" for and if the data will be available via the API?
Are plans with KEA to allow us to see our DHCPv6 leases via API, both reserved and un-reserved?
With ISC, I could find all of my leases for DHCPv4 and DHCPv6, but with KEA, that does not seem accessible. I tried looking into "host discovery" / "host watch", but maybe it isn't built out in 25.7.x yet. Curious what we can expect to use "host discovery" for and if the data will be available via the API?
Are plans with KEA to allow us to see our DHCPv6 leases via API, both reserved and un-reserved?
#5
26.1 Series / Re: Suricata - Divert (IPS)
Last post by szix96 - Today at 08:56:11 PMQuote from: Ametite on Today at 04:11:12 PMQuote from: szix96 on Today at 03:07:59 PMHello,
sorry having a hard time understanding this DIVERT parameter.
So if i set FW rules to allow ports 443/80/5520 and then i create an additional FW rule with the same SRC/DST IP's then the 1ST rule would allow only the traffic on the ports defined and the second would send the traffic to the IPS?
or how is it possible to filter with DIVERT IPS?
as in the pic if i allow the 2 DIVERT rules?
Thank you all for the awesome work on this.
I think you confused protocol divert with Advanced Options -> divert to. Or I miss something..
Thank you, but i do not find it in the advanced settings in the FW rule just the protocol as divert.
edit: Found it in the new FW rules, so it is only available in the new rules, or is it also available in the legacy FW rules?
"To use the "Divert (IPS)" mode, you must use Firewall ‣ Rules [new] and create firewall rules that contain the "Divert-to" setting. Check the Rules manual for more information.
"
https://docs.opnsense.org/manual/ips.html
https://docs.opnsense.org/manual/firewall.html#divert-to
#6
Virtual private networks / Re: Hub-Spoke Wireguard VPN wo...
Last post by ala_nathaniel - Today at 08:42:59 PMPing and Trace Route
From TAC (Spoke) to HUB -
Pings:
10.1.0.1 (HUB LAN IP) from 10.2.0.1 (TAC LAN IP) via Shell = 100% Packet Loss
10.1.0.1 from 10.2.0.1 via GUI (Interface:Diagnostics:Ping) = 0% Packet Loss (Successful ping)
10.1.0.11 (DNS Server on HUB LAN) from 10.2.0.1 via Shell = 100% Packet Loss
10.1.0.11 from 10.2.0.1 via GUI = 0% Packet Loss
172.19.0.1 (HUB WG Interface) from 10.2.0.1 via Shell = 100% Packet Loss
172.19.0.1 from 10.2.0.1 via GUI = 0% Packet Loss
10.1.0.1 from 10.2.0.122 (TAC Client Workstation) = 0% Packet Loss
10.1.0.11 from 10.2.0.122 = 0% Packet Loss
172.19.0.1 from 10.20.122 = 0% Packet Loss
Traceroute:
10.1.0.1 (HUB LAN IP) from 10.2.0.1 via Shell = * * * for 10 hops (should never be more than 4 hops, so 10 should do it)
10.1.0.1 from 10.2.0.1 via GUI (Interface:Diagnostics:Traceroute) = Hop 1 is 172.19.0.1, Hop 2 is 10.1.0.1
10.1.0.11 from 10.2.0.1 via Shell = * * * for 10 hops
10.1.0.11 from 10.2.0.1 via GUI = Hop 1 is 172.19.0.1, Hop 2 is 10.1.0.11
172.19.0.1 from 10.2.0.1 via Shell = * * * for 10 hops
172.19.0.1 from 10.2.0.1 via GUI = Hop 1 is 172.19.0.1
10.1.0.1 from 10.2.0.122 = Hop 1 is 10.2.0.1, Hop 2 is 10.1.0.1
10.1.0.11 from 10.2.0.122 = Hop 1 is 10.2.0.1, Hop 2 is 172.19.0.1, Hop 3 is * * *, Hop 4 is 10.1.0.111
172.19.0.1 from 10.2.0.122 = Hop 1 is 10.2.0.1, Hop is 172.19.0.1
Interesting that from client to server, it drops the hop 3, which should be 10.1.0.1
From HUB to TAC -
Pings:
10.2.0.1 (TAC LAN IP) from 10.2.0.1 (HUB LAN IP) via Shell = 100% Packet Loss
10.2.0.1 from 10.1.0.1 via GUI = 0% Packet Loss (Successful ping)
10.2.0.50 (Printer on TAC LAN) from 10.2.0.1 via Shell = 100% Packet Loss
10.2.0.50 from 10.1.0.1 via GUI = 0% Packet Loss
172.19.0.2 (TAC WG Interface) from 10.1.0.1 via Shell = 100% Packet Loss
172.19.0.2 from 10.1.0.1 via GUI = 0% Packet Loss
10.2.0.1 from 10.1.0.11 (HUB DNS Server) = 0% Packet Loss
10.2.0.50 from 10.1.0.11 = 0% Packet Loss
172.19.0.2 from 10.1.0.11 = 0% Packet Loss
Traceroute:
10.2.0.1 (TAC LAN IP) from 10.1.0.1 via Shell = * * * for 10 hops (should never be more than 4 hops, so 10 should do it)
10.2.0.1 from 10.1.0.1 via GUI = Hop 1 is 172.19.0.2, Hop 2 is 10.2.0.1
10.2.0.50 from 10.1.0.1 via Shell = * * * for 10 hops
10.2.0.50 from 10.2.0.1 via GUI = Hop 1 is 172.19.0.2, Hop 2 is 10.1.0.50
172.19.0.2 from 10.1.0.1 via Shell = * * * for 10 hops
172.19.0.2 from 10.1.0.1 via GUI = Hop 1 is 172.19.0.2
10.2.0.1 from 10.2.0.11 = Hop 1 is 10.1.0.1, Hop 2 is 10.2.0.1
10.2.0.50 from 10.2.0.11 = Hop 1 is 10.1.0.1, Hop 2 is * * *, Hop 3 is 172.19.0.2, Hop 4 is 10.2.0.50
172.19.0.2 from 10.1.0.11 = Hop 1 is 10.1.0.1, Hop is 172.19.0.2
Again, interesting that the WG HUB IP is not showing. I will look more on the HUB firewall, as it does appear to be something on that end. Still not sure though, as GUI seems to send traffic fine. But that could be explained that GUI may now use a different process since update.
From TAC (Spoke) to HUB -
Pings:
10.1.0.1 (HUB LAN IP) from 10.2.0.1 (TAC LAN IP) via Shell = 100% Packet Loss
10.1.0.1 from 10.2.0.1 via GUI (Interface:Diagnostics:Ping) = 0% Packet Loss (Successful ping)
10.1.0.11 (DNS Server on HUB LAN) from 10.2.0.1 via Shell = 100% Packet Loss
10.1.0.11 from 10.2.0.1 via GUI = 0% Packet Loss
172.19.0.1 (HUB WG Interface) from 10.2.0.1 via Shell = 100% Packet Loss
172.19.0.1 from 10.2.0.1 via GUI = 0% Packet Loss
10.1.0.1 from 10.2.0.122 (TAC Client Workstation) = 0% Packet Loss
10.1.0.11 from 10.2.0.122 = 0% Packet Loss
172.19.0.1 from 10.20.122 = 0% Packet Loss
Traceroute:
10.1.0.1 (HUB LAN IP) from 10.2.0.1 via Shell = * * * for 10 hops (should never be more than 4 hops, so 10 should do it)
10.1.0.1 from 10.2.0.1 via GUI (Interface:Diagnostics:Traceroute) = Hop 1 is 172.19.0.1, Hop 2 is 10.1.0.1
10.1.0.11 from 10.2.0.1 via Shell = * * * for 10 hops
10.1.0.11 from 10.2.0.1 via GUI = Hop 1 is 172.19.0.1, Hop 2 is 10.1.0.11
172.19.0.1 from 10.2.0.1 via Shell = * * * for 10 hops
172.19.0.1 from 10.2.0.1 via GUI = Hop 1 is 172.19.0.1
10.1.0.1 from 10.2.0.122 = Hop 1 is 10.2.0.1, Hop 2 is 10.1.0.1
10.1.0.11 from 10.2.0.122 = Hop 1 is 10.2.0.1, Hop 2 is 172.19.0.1, Hop 3 is * * *, Hop 4 is 10.1.0.111
172.19.0.1 from 10.2.0.122 = Hop 1 is 10.2.0.1, Hop is 172.19.0.1
Interesting that from client to server, it drops the hop 3, which should be 10.1.0.1
From HUB to TAC -
Pings:
10.2.0.1 (TAC LAN IP) from 10.2.0.1 (HUB LAN IP) via Shell = 100% Packet Loss
10.2.0.1 from 10.1.0.1 via GUI = 0% Packet Loss (Successful ping)
10.2.0.50 (Printer on TAC LAN) from 10.2.0.1 via Shell = 100% Packet Loss
10.2.0.50 from 10.1.0.1 via GUI = 0% Packet Loss
172.19.0.2 (TAC WG Interface) from 10.1.0.1 via Shell = 100% Packet Loss
172.19.0.2 from 10.1.0.1 via GUI = 0% Packet Loss
10.2.0.1 from 10.1.0.11 (HUB DNS Server) = 0% Packet Loss
10.2.0.50 from 10.1.0.11 = 0% Packet Loss
172.19.0.2 from 10.1.0.11 = 0% Packet Loss
Traceroute:
10.2.0.1 (TAC LAN IP) from 10.1.0.1 via Shell = * * * for 10 hops (should never be more than 4 hops, so 10 should do it)
10.2.0.1 from 10.1.0.1 via GUI = Hop 1 is 172.19.0.2, Hop 2 is 10.2.0.1
10.2.0.50 from 10.1.0.1 via Shell = * * * for 10 hops
10.2.0.50 from 10.2.0.1 via GUI = Hop 1 is 172.19.0.2, Hop 2 is 10.1.0.50
172.19.0.2 from 10.1.0.1 via Shell = * * * for 10 hops
172.19.0.2 from 10.1.0.1 via GUI = Hop 1 is 172.19.0.2
10.2.0.1 from 10.2.0.11 = Hop 1 is 10.1.0.1, Hop 2 is 10.2.0.1
10.2.0.50 from 10.2.0.11 = Hop 1 is 10.1.0.1, Hop 2 is * * *, Hop 3 is 172.19.0.2, Hop 4 is 10.2.0.50
172.19.0.2 from 10.1.0.11 = Hop 1 is 10.1.0.1, Hop is 172.19.0.2
Again, interesting that the WG HUB IP is not showing. I will look more on the HUB firewall, as it does appear to be something on that end. Still not sure though, as GUI seems to send traffic fine. But that could be explained that GUI may now use a different process since update.
#7
German - Deutsch / Re: Bootreihenfolge geändert n...
Last post by Patrick M. Hausen - Today at 08:16:10 PMMach mal ntopng aus - das erzeugt ja noch mehr Last auf dem schon kaputten Datenträger.
#8
German - Deutsch / Re: Bootreihenfolge geändert n...
Last post by cottec - Today at 08:09:58 PMsuper, danke!
Ich warte dann mal auf die SSD...
Mittlerweile schmiert das Ding jede Stunde ab und ich kann nur noch neu starten wenn ich dabei über den Com Port verbunden bin.
Nach langem Drücken des An Aus Taster fängt er sich dann irgendwann mal wieder.
Ich warte dann mal auf die SSD...
Mittlerweile schmiert das Ding jede Stunde ab und ich kann nur noch neu starten wenn ich dabei über den Com Port verbunden bin.
Nach langem Drücken des An Aus Taster fängt er sich dann irgendwann mal wieder.
Code Select
Certificates generated /usr/local/share/ntopng/httpdocs/ssl/ntopng-cert.pem
Starting ntopng.
md5sum: invalid option -- q
usage: md5sum [-bctwz] [files ...]
usage: grep [-abcDEFGHhIiLlmnOopqRSsUVvwxz] [-A num] [-B num] [-C num]
[-e pattern] [-f file] [--binary-files=value] [--color=when]
[--context=num] [--directories=action] [--label] [--line-buffered]
[--null] [pattern] [file ...]
xargs: md5sum: terminated with signal 13; aborting
03/Feb/2026 20:05:35 [Ntop.cpp:4180] WARNING: Unable to find timezone: using UTC
03/Feb/2026 20:05:35 [Redis.cpp:172] Successfully connected to redis 127.0.0.1@0
03/Feb/2026 20:05:35 [Redis.cpp:172] Successfully connected to redis 127.0.0.1@0
03/Feb/2026 20:05:40 [boot.lua:23] [connectivity_utils.lua:64] WARNING: Connectivity check failed [Used https://github.com]
03/Feb/2026 20:05:40 [boot.lua:25] WARNING: No connectivity detected, ntopng will run in offline mode
03/Feb/2026 20:05:41 [Prefs.cpp:2677] ERROR: Too many interfaces (8): discarded lo0
03/Feb/2026 20:05:41 [Prefs.cpp:2681] ERROR: Hint: reset redis (redis-cli flushall) and then start ntopng again
03/Feb/2026 20:05:41 [Prefs.cpp:2677] ERROR: Too many interfaces (8): discarded igc0
03/Feb/2026 20:05:41 [Prefs.cpp:2681] ERROR: Hint: reset redis (redis-cli flushall) and then start ntopng again
03/Feb/2026 20:05:41 [NetworkInterface.cpp:3924] Cleanup interface dummy
03/Feb/2026 20:05:41 [Ntop.cpp:2692] Parent process is exiting (this is normal)
>>> Invoking start script 'syslog'
>>> Invoking start script 'ntopng'
ntopng already running? (pid=40735).
>>> Error in start script '50-ntopng'
>>> Invoking start script 'carp'
>>> Invoking start script 'cron'
Starting Cron: OK
>>> Invoking start script 'openvpn'
>>> Invoking start script 'sysctl'
Service `sysctl' has been restarted.
>>> Invoking start script 'beep'
Root file system: /dev/gpt/rootfs
Tue Feb 3 20:05:43 CET 2026
*** router.localdomain: OPNsense 26.1_4 (amd64) ***
HomeWireGuard (wg0) -> v4: 10.10.11.1/24
LAG (lagg0) -> v4: 10.10.100.1/24
LAN (igc0) -> v4: 10.10.10.1/24
MODEM (igc1) -> v4: 10.10.99.1/30
V_GUEST (vlan02) -> v4: 10.10.120.1/24
V_IOT (vlan01) -> v4: 10.10.110.1/24
WAN (pppoe0) ->
#9
German - Deutsch / Re: OPNsense hinter einer DS-l...
Last post by Patrick M. Hausen - Today at 07:57:21 PMAm Business-Anschluss bekommst du eine feste öffentliche IPv4-Adresse, aber dafür gar kein IPv6. 🤡
#10
26.1 Series / Re: Nothing happens when impor...
Last post by Toedels - Today at 07:56:15 PMThanks for your post. Had me fooled also :)
