"Recent posts
#1
German - Deutsch / Re: Frage zu Zertifikaten und ...
Last post by Pete5 - Today at 09:10:58 AMQuote from: Patrick M. Hausen on December 30, 2024, 11:47:20 PMHAproxy ist unübersichtlich und ein Problem des Plugins ist, dass der maßgebliche Autor von der etablierten Terminologie von HAproxy abweicht und das ganze aufbaut wie viele Loadbalancer aus der kommerziellen Ecke - F5, Cisco, Kemp, ... - das Ganze behandeln.
Ich hab mir zugegebenermaßen nicht alle Details in diesem Thread angeguckt aber als generellen Hinweis:
Ich benutze für alle Dienste, die extern und intern erreichbar sein sollen, ausschließlich die externe IP-Adresse und FQDN. Nebst Letsencrypt-Zertifikat, natürlich. Also z.B. die Nextcloud heißt dann cloud.meinedomain.de - A und AAAA sind die WAN-Adresse meiner OPNsense und dort lauscht der Caddy und proxiet die Requests zum FreeBSD-Jail mit der Nextcloud.
Weshalb sollte ich für Zugriffe von "innen" eine andere IP-Adresse benutzen? Die Verbindung kommt zum LAN rein, dann ist "WAN address" eine lokale Adresse, also geht das an den Caddy. Da wird nix "erst mal raus zum Provider und dann wieder rein" geroutet. Jede Adresse, die für die Sense auf einem lokalen Interface liegt, ist gleichwertig. Und da ich auf LAN "allow LAN net to any" habe, geht das auch einfach so durch.
Keine NAT-Refelction, nix. Funktioniert einfach.
Es wäre einen winzigen Tick "optimaler", wenn cloud.meinedomain.de intern direkt auf den Server verweisen würde. Das würde den Proxy-Overhead sparen. Aber alle Server und die Sense sind hier intern mit 1G oder 10G veerknubbelt, also was soll das?
Pluspunkt: wenn es imtern funktioniert, weißt du, dass es auch extern funktioniert - und umgekehrt.
Das ist der Riesenvorteil eines Reverse-Proxy mit SSL-Terminierung im Proxy. Funktioniert von außen wie innen absolut identisch und es braucht keine NAT-Reflection oder anderes Gedöns.
Eine Verbindung von einem Client im "LAN" mit Ziel "WAN address" geht nicht "über das Internet". Nie. Berücksichtigen! 😉
Eine ähnliche Frage beschäftigt mich auch gerade, ich habe den Hinweis aus obigen post aufgenommen und dabei ist mir folgendes aufgefallen.
Auf meiner opnsense ist der ACME-Client und der caddy proxy eingerichtet, als lokalen DNS nutze ich unbound.
Caddy verteilt das Let's Encrypt Wildcard Zertifikat an die Dienste die in meinem Netz laufen, aber aus irgendeinem Grund nicht an alle. Z.B. habe ich 2 managed switche von DLink in meinem Netzwerk die ich über switch1.meinedomain.de und switch2.meinedomain.de anspreche.
Bei switch1 kommt eine https Verbindung zustande bei switch2 nicht obwohl die Subdomain und der Handler in caddy für beide switche genau gleich eingerichtet ist (außer der Upstream IP natürlich). Die Overrides in unbound sind so gesetzt dass die Dienste nach dem Muster subdomain.meinedomain.de an die öffentliche IP der WAN Schnittstelle weitergeleitet werden.
Und genauso verhält es sich auch mit anderen Diensten, bei manchen kommt eine ttps Verbindung zustande bei manchen nicht.
Hat jemand eine Idee woran das liegen könnte?
#2
26.7, 26.10 Series / Re: 26.7.7 — Security audit re...
Last post by franco - Today at 08:51:33 AMCorrect. In reality the class of security issues like GHSA-p683-f7x2-pm4p are for when someone can actually leverage a XSS against you as an admin (even if just "partial admin" but CVSS has no concept for this even though it wants to increase the scoring in that case which is rather nonsensical), in which case one can do more harm than modifying the firmware mirror to inject a command into the shell.
Suricata 8.0.8 dropped very late last night so we'll be releasing 27.6.8 with it this morning.
Cheers,
Franco
Suricata 8.0.8 dropped very late last night so we'll be releasing 27.6.8 with it this morning.
Cheers,
Franco
#3
26.1, 26.4 Legacy Series / Re: Unbound reporting stop wor...
Last post by Rick - Today at 07:52:33 AMI'm using OPNsense 26.7.7 with py313-numpy 2.4.6_1 on a system with an AMD Athlon 64 X2 5000+ (super old, but runs OPNsense great) and noticed this yesterday when I tried to enable Unbound logging.
Apparently this error happens because recent versions of NumPy are compiled to use features on newer hardware and the complied code chokes on older hardware. (Google: numpy illegal instruction) You can see the stack trace by running "python3 -v stats.py" I tracked the error to the following dynamic-link library:
/usr/local/lib/python3.13/site-packages/numpy/_core/_multiarray_umath.cpython-313.so
I worked around this by standing up a FreeBSD 15.1 VM (on my Linux Mint system), installing Python 3.13 and building NumPy for a generic system using the following command-line, and replacing the OPNsense ".so" above with the one generated (in the same location).
python3 -m pip install numpy -Csetup-args=-Dcpu-baseline="none" -Csetup-args=-Dcpu-dispatch="none"
Unbound logging is working now on my system.
Obviously this is just a workaround for the current version of NumPy.
Hope this helps.
- Rick
Apparently this error happens because recent versions of NumPy are compiled to use features on newer hardware and the complied code chokes on older hardware. (Google: numpy illegal instruction) You can see the stack trace by running "python3 -v stats.py" I tracked the error to the following dynamic-link library:
/usr/local/lib/python3.13/site-packages/numpy/_core/_multiarray_umath.cpython-313.so
I worked around this by standing up a FreeBSD 15.1 VM (on my Linux Mint system), installing Python 3.13 and building NumPy for a generic system using the following command-line, and replacing the OPNsense ".so" above with the one generated (in the same location).
python3 -m pip install numpy -Csetup-args=-Dcpu-baseline="none" -Csetup-args=-Dcpu-dispatch="none"
Unbound logging is working now on my system.
Obviously this is just a workaround for the current version of NumPy.
Hope this helps.
- Rick
#4
26.7, 26.10 Series / Re: Cert Based WIFI Authentica...
Last post by nicholaswkc - Today at 02:52:36 AMThanks for all the advises. I had install FreeRadius and configure it up.
#5
Zenarmor (Sensei) / Re: CPU spikes from Elasticsea...
Last post by mlenje - Today at 02:47:34 AMUpdate: it's the heartbeat, and 2.7.1 made it ~500x slower and runs it twice
I captured today's predicted heavy run at 14:15 (Monit: CPU 95.4% at 14:15:48). This answers the questions from my last post.
Periodical.log during the spike
I saved every version of the file from 14:13 to 14:23. Nothing unusual runs at the spike: scheduled-service-control, userenrich and aliases run every minute; check-remote-elastic and periodic-license-control run every 5 minutes (14:15 and 14:20); check-health ran at 14:14. So dashboard-cache and the per-minute scheduler aren't the cause. There are also no Elasticsearch transforms configured.
The cause: the ipdrstreamer-v2 heartbeat
grep 'heartbeat: collected' /usr/local/zenarmor/log/active/ipdrstreamer-v2*.log shows:
Before 2.7.1 (cli.log, triggered_by=agent, every 4h):
After 2.7.1, two collectors:
What this shows:
- The heartbeat collection went from ~0.4 seconds to 3.5-5 minutes in 2.7.1. During it, Elasticsearch runs the 30-day composite aggregation on conn_all (source IP x day, paged 1,000 buckets) from my last post, saturating 4+ cores.
- 2.7.1 adds a second collector inside ipdrstreamer that runs every 5 hours from ipdrstreamer's start time. That's the :15 / :20 cycle xpking and I see.
- The heavy runs are both collectors running in parallel: today the scheduler started at 14:14:38 and the agent-triggered one at 14:15:08. The agent's 4-hourly check only fires when 4+ hours have passed since the last heartbeat, which with the 5-hourly scheduler lines up once every 20 hours. All four agent-triggered runs match my four 90%+ CPU alerts exactly.
Questions for the Zenarmor team (@sy):
1. What changed in the 2.7.1 heartbeat that takes it from ~0.4 s to ~4 min? It now aggregates 30 days of conn data by source IP and day each time.
2. Is the second (5-hourly) collector in ipdrstreamer intended, and should it share a lock with the agent-triggered one so they can't run at the same time?
3. Can the heartbeat be made incremental, or its interval/lookback configured on Home licenses?
Setup: OPNsense 26.7, Zenarmor 2.7.1, local Elasticsearch 8.11.3, i7-3770 / 32 GB.
I captured today's predicted heavy run at 14:15 (Monit: CPU 95.4% at 14:15:48). This answers the questions from my last post.
Periodical.log during the spike
I saved every version of the file from 14:13 to 14:23. Nothing unusual runs at the spike: scheduled-service-control, userenrich and aliases run every minute; check-remote-elastic and periodic-license-control run every 5 minutes (14:15 and 14:20); check-health ran at 14:14. So dashboard-cache and the per-minute scheduler aren't the cause. There are also no Elasticsearch transforms configured.
The cause: the ipdrstreamer-v2 heartbeat
grep 'heartbeat: collected' /usr/local/zenarmor/log/active/ipdrstreamer-v2*.log shows:
Before 2.7.1 (cli.log, triggered_by=agent, every 4h):
Code Select
2026-10-25T22:51:54 heartbeat: collected took=405ms
2026-10-26T02:51:54 heartbeat: collected took=354ms
2026-10-26T06:51:54 heartbeat: collected took=416ms
After 2.7.1, two collectors:
Code Select
# ipdrstreamer's own scheduler, every 5h from its start (22:14:38 on Oct 26)
2026-10-28T23:18:10 heartbeat: collected took=3m32.228s
2026-10-29T04:18:02 heartbeat: collected took=3m24.436s
2026-10-29T09:18:05 heartbeat: collected took=3m26.881s
2026-10-29T14:19:27 heartbeat: collected took=4m49.409s
# agent-triggered (cli.log), fired only 4 times since the upgrade
2026-10-27T02:19:07 heartbeat: collected triggered_by=agent took=3m59.286s
2026-10-27T22:19:34 heartbeat: collected triggered_by=agent took=4m26.416s
2026-10-28T18:20:01 heartbeat: collected triggered_by=agent took=4m53.923s
2026-10-29T14:19:55 heartbeat: collected triggered_by=agent took=4m47.296s
What this shows:
- The heartbeat collection went from ~0.4 seconds to 3.5-5 minutes in 2.7.1. During it, Elasticsearch runs the 30-day composite aggregation on conn_all (source IP x day, paged 1,000 buckets) from my last post, saturating 4+ cores.
- 2.7.1 adds a second collector inside ipdrstreamer that runs every 5 hours from ipdrstreamer's start time. That's the :15 / :20 cycle xpking and I see.
- The heavy runs are both collectors running in parallel: today the scheduler started at 14:14:38 and the agent-triggered one at 14:15:08. The agent's 4-hourly check only fires when 4+ hours have passed since the last heartbeat, which with the 5-hourly scheduler lines up once every 20 hours. All four agent-triggered runs match my four 90%+ CPU alerts exactly.
Questions for the Zenarmor team (@sy):
1. What changed in the 2.7.1 heartbeat that takes it from ~0.4 s to ~4 min? It now aggregates 30 days of conn data by source IP and day each time.
2. Is the second (5-hourly) collector in ipdrstreamer intended, and should it share a lock with the agent-triggered one so they can't run at the same time?
3. Can the heartbeat be made incremental, or its interval/lookback configured on Home licenses?
Setup: OPNsense 26.7, Zenarmor 2.7.1, local Elasticsearch 8.11.3, i7-3770 / 32 GB.
#6
General Discussion / Two WAN trouble
Last post by nwabytes - October 29, 2026, 11:08:08 PMThese are all public ips anyway so i dont care to show them. Ive fought with this over and over end up going to the other freebsd firewall.
Main ip 170.10.188.14/30 the gateway is in the DC for this one 170.10.188.13. now my server network 167.224.195.232/29. I can use the internet with the main ip. but the NET29 network is pretty much dead. ive tried any rules i can think of. Ill post a screenshot of my firewall. Its got to be something pretty simple. 167.224.195.234 should be an active ip with directadmin on it.
Main ip 170.10.188.14/30 the gateway is in the DC for this one 170.10.188.13. now my server network 167.224.195.232/29. I can use the internet with the main ip. but the NET29 network is pretty much dead. ive tried any rules i can think of. Ill post a screenshot of my firewall. Its got to be something pretty simple. 167.224.195.234 should be an active ip with directadmin on it.
#7
26.7, 26.10 Series / Re: 26.7.7 — Security audit re...
Last post by Manfred.Knick - October 29, 2026, 09:44:40 PMAnd OPNsense Business Edition 26.10 is already safe against
e.g. GHSA-p683-f7x2-pm4p: c.f. Release Notes --> [3]
Enjoy
Manfred
e.g. GHSA-p683-f7x2-pm4p: c.f. Release Notes --> [3]
Enjoy
Manfred
#8
Hardware and Performance / Re: routing performance limite...
Last post by sternchen45 - October 29, 2026, 09:40:48 PMHello,
very long time but i managed to work on the topic.
The Windows-PC is now connected and linked with 2.5Gbps on the CRS310.
1) Tested Mac in the local subnet/same switch with iperf3 from/to Windows host. Result: 2.37Gbps.
2) Reverse: 2.37Gbps.
3) Tested Mac->OPNsense->Windows PC. Result: 1Gbps one process. With -P4 i reach 1.6-1.7Gbps.
4) Reverse:: 2.3Gbps.
5) Tested Mac->OPNsense->Mac. Similar as Mac->OPNsense->Windows, but -P4 stays at 1Gbps.
I made sure shapers, Suricata, Zen armor are off. Offloading features are off. CPU measured with top during the tests is at 0.1% user, 0.4% system.
The results very much point to the OPNsense. I just don't know what i should check.
Maybe from your experience you can suggest something?
very long time but i managed to work on the topic.
The Windows-PC is now connected and linked with 2.5Gbps on the CRS310.
1) Tested Mac in the local subnet/same switch with iperf3 from/to Windows host. Result: 2.37Gbps.
2) Reverse: 2.37Gbps.
3) Tested Mac->OPNsense->Windows PC. Result: 1Gbps one process. With -P4 i reach 1.6-1.7Gbps.
4) Reverse:: 2.3Gbps.
5) Tested Mac->OPNsense->Mac. Similar as Mac->OPNsense->Windows, but -P4 stays at 1Gbps.
I made sure shapers, Suricata, Zen armor are off. Offloading features are off. CPU measured with top during the tests is at 0.1% user, 0.4% system.
The results very much point to the OPNsense. I just don't know what i should check.
Maybe from your experience you can suggest something?
#9
High availability / Re: CARP update of backup fire...
Last post by babagoo - October 29, 2026, 08:52:08 PMThanks for the update Sergio. I will have to go a friend's to get a cable connection. It can't ping the default gateway (fe80::) or discovered neighbours. The firewall rule allows icmp to any destination.
I will keep using ipv4 in the mean time.
I will keep using ipv4 in the mean time.
#10
Zenarmor (Sensei) / Re: CPU spikes from Elasticsea...
Last post by mlenje - October 29, 2026, 08:05:52 PMThanks both. xpking's :20 every 5 hours matches my :15 every 5 hours, offset by our different upgrade times.
Periodical.log
On my box this file only ever holds the last minute (about 2 KB). Two samples, Oct 27 07:59 and Oct 29 11:56 (neither at a spike time), look identical:
checking mongodb...
checking mongodb done
dasboard-cache...
CLI dashboard-cache: Caching ...
CLI dashboard-cache: Cached ...
dashboard cache done
elastic-index-check...
elastic-index-check done
done
[2026-10-29T11:56:01][INFO][TEMP] Starting Zenarmor CRON for 2026-10-29 11:56:01
That's followed by Zenarmor's usual 18 internal Cron Check lines, with only scheduled-service-control, userenrich and aliases actually running (all OK). The mongodb / dashboard-cache / elastic-index-check block is always at the top with no timestamps, so it looks like a separate job that rewrites the file each time.
What Elasticsearch is doing during a spike
I logged Elasticsearch's task list and per-thread top every 30 seconds during the 23:15 run last night.
Before (23:13:37): idle. Load was 0.20, and Elasticsearch was running only its own health and monitoring tasks.
From 23:14:39, this search appears:
indices:data/read/search
indices[zenarmor_<id>_conn_all]
"query":{"range":{"start_time":{"gte":1790640000000,"lt":1793232000000}}}
"aggregations":{"daily":{"composite":{"size":1000,
"sources":[{"identity":{"terms":{"field":"ip_src_saddr.keyword"}}},
{"day":{"date_histogram":{"field":"start_time","calendar_interval":"day"}}}],
"after":{"identity":"<ip>","day":...}}}}
The range is Sep 29 to Oct 29 (UTC), exactly 30 days.
It's a composite aggregation by source IP × day, paged 1,000 buckets at a time.
The same query appears in 7 consecutive snapshots (about 3½ minutes), each with a different after key advancing through the source IPs. So it looks like one continuous pass through the whole result set.
At the peak (23:16:10): all 15 of the busiest threads in top -H were Elasticsearch's java, with 13 of them at about 30% each. No other process appeared.
Summary: every 5 hours at :15 since the 2.7.1 upgrade, a 30-day per-device daily aggregation on conn_all runs for about 4 minutes. Every 4th run is heavier (90%+ CPU). There was no such pattern in 11 weeks of CPU history before the upgrade.
Which task sends this query? Is it dashboard-cache? And are the interval or the 30-day window configurable? I'm capturing Periodical.log and the process connecting to port 9200 during my next predicted run at 14:15 today and will post the results.
Periodical.log
On my box this file only ever holds the last minute (about 2 KB). Two samples, Oct 27 07:59 and Oct 29 11:56 (neither at a spike time), look identical:
checking mongodb...
checking mongodb done
dasboard-cache...
CLI dashboard-cache: Caching ...
CLI dashboard-cache: Cached ...
dashboard cache done
elastic-index-check...
elastic-index-check done
done
[2026-10-29T11:56:01][INFO][TEMP] Starting Zenarmor CRON for 2026-10-29 11:56:01
That's followed by Zenarmor's usual 18 internal Cron Check lines, with only scheduled-service-control, userenrich and aliases actually running (all OK). The mongodb / dashboard-cache / elastic-index-check block is always at the top with no timestamps, so it looks like a separate job that rewrites the file each time.
What Elasticsearch is doing during a spike
I logged Elasticsearch's task list and per-thread top every 30 seconds during the 23:15 run last night.
Before (23:13:37): idle. Load was 0.20, and Elasticsearch was running only its own health and monitoring tasks.
From 23:14:39, this search appears:
indices:data/read/search
indices[zenarmor_<id>_conn_all]
"query":{"range":{"start_time":{"gte":1790640000000,"lt":1793232000000}}}
"aggregations":{"daily":{"composite":{"size":1000,
"sources":[{"identity":{"terms":{"field":"ip_src_saddr.keyword"}}},
{"day":{"date_histogram":{"field":"start_time","calendar_interval":"day"}}}],
"after":{"identity":"<ip>","day":...}}}}
The range is Sep 29 to Oct 29 (UTC), exactly 30 days.
It's a composite aggregation by source IP × day, paged 1,000 buckets at a time.
The same query appears in 7 consecutive snapshots (about 3½ minutes), each with a different after key advancing through the source IPs. So it looks like one continuous pass through the whole result set.
At the peak (23:16:10): all 15 of the busiest threads in top -H were Elasticsearch's java, with 13 of them at about 30% each. No other process appeared.
Summary: every 5 hours at :15 since the 2.7.1 upgrade, a 30-day per-device daily aggregation on conn_all runs for about 4 minutes. Every 4th run is heavier (90%+ CPU). There was no such pattern in 11 weeks of CPU history before the upgrade.
Which task sends this query? Is it dashboard-cache? And are the interval or the 30-day window configurable? I'm capturing Periodical.log and the process connecting to port 9200 during my next predicted run at 14:15 today and will post the results.
