"Recent posts
#1
German - Deutsch / Re: Seltsamer Traffic OUT im W...
Last post by Monviech (Cedrik) - Today at 02:03:01 PMMach einfach einen Packet Capture auf allen interfaces (Interfaces -> Diagnostics -> Packet Capture), lass eine weile laufen (1 Minute), lade es herunter und mach es in Wireshark auf. Dann schaue was die meisten Pakete sind während nichts passiert.
#2
German - Deutsch / Seltsamer Traffic OUT im WAN
Last post by Jayfrog - Today at 01:56:20 PMHallöchen!
Ich bräuchte mal Hilfe, weil mir heute was komisches aufgefallen ist.
Gerade aktiv im Netz ist mein Home/Gaming-Server, der unter OPT1 läuft und auch mein Daily PC, unter LAN.
Weder der Server, noch mein Daily PC haben im moment den nötigen Traffic um rund 2MB an Traffic OUT vom WAN zu erklären.
Kommt das alles nur von den IPv6 ICMP Anfragen etc?
Danke!
Ich bräuchte mal Hilfe, weil mir heute was komisches aufgefallen ist.
Gerade aktiv im Netz ist mein Home/Gaming-Server, der unter OPT1 läuft und auch mein Daily PC, unter LAN.
Weder der Server, noch mein Daily PC haben im moment den nötigen Traffic um rund 2MB an Traffic OUT vom WAN zu erklären.
Kommt das alles nur von den IPv6 ICMP Anfragen etc?
Danke!
#3
26.1, 26,4 Series / Re: Upgrade from 26.1.4 to 26....
Last post by franco - Today at 01:14:20 PMThe scroll is fixed in 26.1.10, but since the update code is running on 26.1.9 it's still buffering jumpily.
Cheers,
Franco
Cheers,
Franco
#4
26.1, 26,4 Series / Re: Upgrade from 26.1.4 to 26....
Last post by nero355 - Today at 01:11:01 PM** UPDATE **
About this :
This was from 26.1.9 to 26.1.10 by the way!
About this :
Quote from: nero355 on June 14, 2026, 12:27:50 AMI will try to remember to do the next update with LibreWolfLibreWolf pretty much does the same thing that Pale Moon does and does not scroll, however I think Pale Moon does it a bit better because at least I can see the KERNEL UPDATE part before the Reboot happens :)
This was from 26.1.9 to 26.1.10 by the way!
#5
26.1, 26,4 Series / Degraded Speed Ghost
Last post by juicemain - Today at 12:53:50 PMAt a glance:
Internet connection speed:
1gig, usual speeds 940 mbps down / 940 mbps up
Temporary slowed speed state:
~700 mbps down / ~50 mbps up , (all pings/ latency stay generally consistent no degredation)
Triggers:
Multiple, the one I found for testing was playing the video game Overwatch while doing an Ookla speed test in a web browser
Temporary fixes:
Rebooting the router usually leads to a normal speed state most of the time, will revert eventually to the degraded speed state, which will eventually revert back to full speed overtime itself oscillating back and forth.
Degraded speed state DOES NOT occur on the ISP provided router solution, Calix U6 router.
----
Hardware:
Systems:
Lenovo ThinkCentre m720q tiny (original system)
Dell OptiPlex 7070 SFF (second system)
NICS:
ULANSeN Dual-Port PCIe card (Intel 82575/82576 chipset)
NICGIGA 4-port i350 card (Amazon white-label)
Genuine Dell I350-T4 (4-port, used in both m720q and 7070)
----
Timeline of troubleshooting steps taken:
(on Lenovo m720q tiny)
Multiple fresh installs of latest Opnsense
Disabled hardware offloading
Set tuneables
Observed pause frames and link flaps
Replaced original Ulansen 82575/82576 card with NICGIGA i350 4-port card
Tried multiple third-party PCIe risers
Isolated WAN/LAN port assignments on the multi-port cards
Removed internal wi-fi card
Scoured every possible BIOS setting in regards to PCIE slots and power management
Implemented FQ-CoDel traffic shaping
Isolated all network components down to PC -> m720q OPNSENSE router
Sourced genuine Dell I350-T4 with proper m720q low profile bracket
Checked ethernet cables
(on Dell Optiplex 7070 SFF)
Migrated to Dell Optiplex 7070 SFF with native PCIe slot
Retried all tunables
Installed and tested pfsense
Tested double NAT (7070 behind ISP router)
----
Synopsis:
This ghost persists across different hardware, OS, and configurations. I believe that I have isolated the issue either down to the PCIE bus / NIC itself, the Intel chipset igb drivers, and/or Freebsd itself. I am an amateur, and this is for a home network setup. If I'm missing anything glaring, please excuse. This has been my last resort to come to the forums for this issue. I'm sick of talking to an LLM. I'm sure this is usually a place for enterprise issues, but thank you in advance. You're my only hope lol. Any and all suggestions appreciated. Has anyone else ever had any issues like this when using a desktop PC as an opnsense machine? Is it recommended that I move on to dedicated hardware?
----
Next steps:
1. Ordered a realtek chipset nic to tryout different drivers
2. WIll move to Protectli hardware next with soldered nic instead of pcie nic.
Internet connection speed:
1gig, usual speeds 940 mbps down / 940 mbps up
Temporary slowed speed state:
~700 mbps down / ~50 mbps up , (all pings/ latency stay generally consistent no degredation)
Triggers:
Multiple, the one I found for testing was playing the video game Overwatch while doing an Ookla speed test in a web browser
Temporary fixes:
Rebooting the router usually leads to a normal speed state most of the time, will revert eventually to the degraded speed state, which will eventually revert back to full speed overtime itself oscillating back and forth.
Degraded speed state DOES NOT occur on the ISP provided router solution, Calix U6 router.
----
Hardware:
Systems:
Lenovo ThinkCentre m720q tiny (original system)
Dell OptiPlex 7070 SFF (second system)
NICS:
ULANSeN Dual-Port PCIe card (Intel 82575/82576 chipset)
NICGIGA 4-port i350 card (Amazon white-label)
Genuine Dell I350-T4 (4-port, used in both m720q and 7070)
----
Timeline of troubleshooting steps taken:
(on Lenovo m720q tiny)
Multiple fresh installs of latest Opnsense
Disabled hardware offloading
Set tuneables
Observed pause frames and link flaps
Replaced original Ulansen 82575/82576 card with NICGIGA i350 4-port card
Tried multiple third-party PCIe risers
Isolated WAN/LAN port assignments on the multi-port cards
Removed internal wi-fi card
Scoured every possible BIOS setting in regards to PCIE slots and power management
Implemented FQ-CoDel traffic shaping
Isolated all network components down to PC -> m720q OPNSENSE router
Sourced genuine Dell I350-T4 with proper m720q low profile bracket
Checked ethernet cables
(on Dell Optiplex 7070 SFF)
Migrated to Dell Optiplex 7070 SFF with native PCIe slot
Retried all tunables
Installed and tested pfsense
Tested double NAT (7070 behind ISP router)
----
Synopsis:
This ghost persists across different hardware, OS, and configurations. I believe that I have isolated the issue either down to the PCIE bus / NIC itself, the Intel chipset igb drivers, and/or Freebsd itself. I am an amateur, and this is for a home network setup. If I'm missing anything glaring, please excuse. This has been my last resort to come to the forums for this issue. I'm sick of talking to an LLM. I'm sure this is usually a place for enterprise issues, but thank you in advance. You're my only hope lol. Any and all suggestions appreciated. Has anyone else ever had any issues like this when using a desktop PC as an opnsense machine? Is it recommended that I move on to dedicated hardware?
----
Next steps:
1. Ordered a realtek chipset nic to tryout different drivers
2. WIll move to Protectli hardware next with soldered nic instead of pcie nic.
#6
26.1, 26,4 Series / WAN Interface speed duplex tro...
Last post by stumper - Today at 12:46:04 PMWAN Interface on my Protectli v1210 fails to negotiate speed/duplex correctly when ISP coax is connected to cable modem, but does negotiate properly (2500/fdx) when I disconnect the ISP coax.
I'm fairly certain this is an ISP issue, but would appreciate some advice on how to collect meaningful information to help with ISP tech support
Setup
- Cox 2Gbps Internet
- Motorola SB8611 cable modem
- Protectli V1210, 2 Intel® I226-V 2.5Gigabit Ethernet NIC ports, RJ-45
- OpnSense 26.1.9
Issue
- WAN Interface fails to autonegotiate to 2500 and fails to get WAN IP (same issue if I hard configure 2500-t)
- Same issue with either interface (igc0 or igc1)
- Same issue with multiple cables
- Same issue with two different cable modems (Motorola SB861))
- Removing the ISP coax from cable modem, then WAN interface negotiates properly and receives default IP (192.168.100.x) from cable modem
- Factory reset / default OpnSense does not resolve nor does CMOS reset on Protectli
- Replacing OpnSense firewall with an older Asuswrt router (gt-ax6000) and the WAN interface on the router does negotiate properly to 2500/fdx and obtain WAN IP
Questions
1. Are there any interface settings and/or tunable I can configure to resolve this
2. What cli command can I run to help diagnose this + information I should capture to bring to ISP, so I can avoid the "simple" questions (change the cable, reset the router, ...)
I'm fairly certain this is an ISP issue, but would appreciate some advice on how to collect meaningful information to help with ISP tech support
Setup
- Cox 2Gbps Internet
- Motorola SB8611 cable modem
- Protectli V1210, 2 Intel® I226-V 2.5Gigabit Ethernet NIC ports, RJ-45
- OpnSense 26.1.9
Issue
- WAN Interface fails to autonegotiate to 2500 and fails to get WAN IP (same issue if I hard configure 2500-t)
- Same issue with either interface (igc0 or igc1)
- Same issue with multiple cables
- Same issue with two different cable modems (Motorola SB861))
- Removing the ISP coax from cable modem, then WAN interface negotiates properly and receives default IP (192.168.100.x) from cable modem
- Factory reset / default OpnSense does not resolve nor does CMOS reset on Protectli
- Replacing OpnSense firewall with an older Asuswrt router (gt-ax6000) and the WAN interface on the router does negotiate properly to 2500/fdx and obtain WAN IP
Questions
1. Are there any interface settings and/or tunable I can configure to resolve this
2. What cli command can I run to help diagnose this + information I should capture to bring to ISP, so I can avoid the "simple" questions (change the cable, reset the router, ...)
#7
25.7, 25.10 Legacy Series / Re: Unable to get OPNsense Acm...
Last post by keeka - Today at 12:43:10 PMIt's also worth checking that the relevant known_hosts file (/var/etc/acme-client/sftp-config/known_hosts) is correct. IIRC this is done for you first time you test the ssh upload automation via the OPNsense web UI. If something subsequently changed on the remote side, you may need to delete the entry (in that file) and retest via the GUI or manually run ssh.
#8
General Discussion / Re: ARC RAM usage
Last post by nero355 - Today at 12:34:13 PMQuote from: Patrick M. Hausen on June 16, 2026, 02:22:40 PMIt appears to be totally different from what we both thought it should be : https://docs.freebsd.org/en/books/handbook/zfs/#zfs-advanced-tuningQuote from: nero355 on June 16, 2026, 02:01:43 PMIn theory ZFS should never use more than 50% of that IIRC so you should have nothing to worry about despite these values.That used to be a hard limit set in Linux because Linux memory management had difficulties flushing ARC in case of memory pressure.
In FreeBSD such a limit does not exist and ARC will happily use all available memory. This is not a problem. It will be freed if needed.
Quotevfs.zfs.arc.max starting with 13.x (vfs.zfs.arc_max for 12.x) - Upper size of the ARC./LearnedSomethingToday :)
The default is all RAM but 1 GB, or 5/8 of all RAM, whichever is more.
Use a lower value if the system runs any other daemons or processes that may require memory.
Adjust this value at runtime with sysctl(8) and set it in /boot/loader.conf or /etc/sysctl.conf.
#9
25.7, 25.10 Legacy Series / Re: Unable to get OPNsense Acm...
Last post by Sistally - Today at 12:24:42 PMA couple of things come to mind.
First, the SSH authentication is happening from OPNsense to the HAProxy VM, so the user and authorized key need to exist on the HAProxy side. The error:
Permission denied (publickey)
usually means one of the following:
the public key isn't in the correct user's ~/.ssh/authorized_keys
wrong username is being used in the automation action
incorrect permissions on .ssh or authorized_keys
the private key configured in OPNsense doesn't match the public key on HAProxy
SSH is refusing the login because of the user's shell or account configuration
I'd start by testing manually from the OPNsense shell:
using the same key that the ACME automation is configured to use. If that doesn't work manually, ACME won't work either.
As for the OPNsense side: you generally do not need a local OPNsense user named cert-bringer just to push certificates. The ACME plugin runs locally on OPNsense and can use a configured SSH key to authenticate to a remote system.
On the HAProxy VM, a setup like this is common:
Then place the public key in:
One other thing to check: if you've given the account a shell like /usr/sbin/nologin, OpenSSH may reject the session depending on how the automation executes commands. For troubleshooting, temporarily give it a normal shell (e.g. /bin/bash), verify key authentication works, then tighten things down afterward.
Could you post the exact ACME automation method you're using (Secure Copy, SSH command, HAProxy deploy script, etc.) and the full SSH error from the ACME log? That would make it much easier to pinpoint where the failure is occurring.
First, the SSH authentication is happening from OPNsense to the HAProxy VM, so the user and authorized key need to exist on the HAProxy side. The error:
Permission denied (publickey)
usually means one of the following:
the public key isn't in the correct user's ~/.ssh/authorized_keys
wrong username is being used in the automation action
incorrect permissions on .ssh or authorized_keys
the private key configured in OPNsense doesn't match the public key on HAProxy
SSH is refusing the login because of the user's shell or account configuration
I'd start by testing manually from the OPNsense shell:
Code Select
ssh cert-bringer@10.10.20.20using the same key that the ACME automation is configured to use. If that doesn't work manually, ACME won't work either.
As for the OPNsense side: you generally do not need a local OPNsense user named cert-bringer just to push certificates. The ACME plugin runs locally on OPNsense and can use a configured SSH key to authenticate to a remote system.
On the HAProxy VM, a setup like this is common:
Code Select
useradd -m cert-bringer
mkdir /home/cert-bringer/.ssh
chmod 700 /home/cert-bringer/.sshThen place the public key in:
Code Select
/home/cert-bringer/.ssh/authorized_keys
and set:Code Select
chmod 600 authorized_keys
chown -R cert-bringer:cert-bringer /home/cert-bringer/.sshOne other thing to check: if you've given the account a shell like /usr/sbin/nologin, OpenSSH may reject the session depending on how the automation executes commands. For troubleshooting, temporarily give it a normal shell (e.g. /bin/bash), verify key authentication works, then tighten things down afterward.
Could you post the exact ACME automation method you're using (Secure Copy, SSH command, HAProxy deploy script, etc.) and the full SSH error from the ACME log? That would make it much easier to pinpoint where the failure is occurring.
#10
26.1, 26,4 Series / Re: Been driving me mad STAFF ...
Last post by Orionrise - Today at 12:24:12 PMSolved — and it wasn't the igc driver after all.
Posting the resolution in case it helps anyone who finds this thread with the same signature (DNS to the gateway times out on one VLAN while external DNS and everything else works).
The root cause was my own firewall rules, not the hardware or the driver. My per-VLAN "block inter-VLAN" rule used the shared RFC1918 alias as its destination. Because RFC1918 includes the VLAN's own subnet, that block also matched the VLAN's gateway address — and in the live ruleset the "allow DNS to gateway" rule had ended up below the block. With quick/first-match evaluation, a DNS query to the gateway hit the RFC1918 block first and was silently dropped, so Unbound never saw it. DNS to 1.1.1.1 worked because 1.1.1.1 isn't in RFC1918 and matched a later pass rule. That's why it looked like a receive-path/driver issue — but DHCP, internet and the sibling VLAN all worked because none of them tripped that specific block.
What finally found it was reading the live generated ruleset over SSH rather than trusting the GUI order: pfctl -sr | grep -n vlan<id>. The block was clearly sitting ahead of the gateway-DNS allow there, even though the GUI looked fine (mixed classic + automation rules can display in a different order than they're generated).
Fix: I scoped the block to a bespoke per-VLAN alias that lists every internal subnet except that VLAN's own (so the gateway can never be caught by it), repointed the block rule at it, applied, and DNS to the gateway resolved immediately. Made this the standard on every VLAN so it's immune to rule-order drift.
Future note for anyone hitting this: if one VLAN can't reach its own gateway for DNS but everything else works, check whether your inter-VLAN block alias contains that VLAN's own subnet, and verify the real order with pfctl -sr, not just the GUI. Thanks to everyone who weighed in.
Posting the resolution in case it helps anyone who finds this thread with the same signature (DNS to the gateway times out on one VLAN while external DNS and everything else works).
The root cause was my own firewall rules, not the hardware or the driver. My per-VLAN "block inter-VLAN" rule used the shared RFC1918 alias as its destination. Because RFC1918 includes the VLAN's own subnet, that block also matched the VLAN's gateway address — and in the live ruleset the "allow DNS to gateway" rule had ended up below the block. With quick/first-match evaluation, a DNS query to the gateway hit the RFC1918 block first and was silently dropped, so Unbound never saw it. DNS to 1.1.1.1 worked because 1.1.1.1 isn't in RFC1918 and matched a later pass rule. That's why it looked like a receive-path/driver issue — but DHCP, internet and the sibling VLAN all worked because none of them tripped that specific block.
What finally found it was reading the live generated ruleset over SSH rather than trusting the GUI order: pfctl -sr | grep -n vlan<id>. The block was clearly sitting ahead of the gateway-DNS allow there, even though the GUI looked fine (mixed classic + automation rules can display in a different order than they're generated).
Fix: I scoped the block to a bespoke per-VLAN alias that lists every internal subnet except that VLAN's own (so the gateway can never be caught by it), repointed the block rule at it, applied, and DNS to the gateway resolved immediately. Made this the standard on every VLAN so it's immune to rule-order drift.
Future note for anyone hitting this: if one VLAN can't reach its own gateway for DNS but everything else works, check whether your inter-VLAN block alias contains that VLAN's own subnet, and verify the real order with pfctl -sr, not just the GUI. Thanks to everyone who weighed in.
