"Recent posts
#91
Hardware and Performance / Re: CPU recommendations for gi...
Last post by jim1985 - February 03, 2026, 12:05:50 PMQuote from: Stormscape on February 03, 2026, 11:59:00 AMFor what it's worth, the i5-8500 in my Optiplex 3060 I use for OPNsense easily handles my 2100/200 connection. I usually peak at around 2.40 for CPU usage when downloading. Now granted I'm not doing any sort of IDS, but hopefully that should give you a good idea of what to pick.
Thanks for your reply. I take it that your connection is PPPoE as well?
From what I understand, it is PPPoE that can be the problem & it requires a pretty decent single core clock speed as the PPPoE implementation in FreeBSD is not multithreaded yet
#92
Hardware and Performance / Re: CPU recommendations for gi...
Last post by Stormscape - February 03, 2026, 11:59:00 AMFor what it's worth, the i5-8500 in my Optiplex 3060 I use for OPNsense easily handles my 2100/200 connection. I usually peak at around 2.40 for CPU usage when downloading. Now granted I'm not doing any sort of IDS, but hopefully that should give you a good idea of what to pick.
#93
26.1 Series / Re: The upgrade was aborted du...
Last post by eric_zrgoq14k - February 03, 2026, 11:41:54 AMThis was the output:
sh -x /usr/local/etc/rc.syshook upgrade
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
+ REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem
+ SYSDIR=/usr/local/etc/rc.syshook.d
+ SYSLEVEL=upgrade
+ shift
+ [ -z upgrade ]
+ [ ! -d /usr/local/etc/rc.syshook.d/upgrade ]
+ find -s /usr/local/etc/rc.syshook.d/upgrade -type f}
+ SYSHOOKS='/usr/local/etc/rc.syshook.d/upgrade/10-sanity.sh
/usr/local/etc/rc.syshook.d/upgrade/20-isc-dhcp-plugin.sh
/usr/local/etc/rc.syshook.d/upgrade/90-cleanup.sh'
+ RETURN=0
+ SYSHOOK=upgrade/10-sanity.sh
+ SYSHOOK=10-sanity.sh
+ SYSNAME=sanity.sh
+ echo $'>>> Invoking upgrade script \'sanity.sh\''
>>> Invoking upgrade script 'sanity.sh'
+ /usr/local/etc/rc.syshook.d/upgrade/10-sanity.sh
Passed all upgrade tests.
+ SYSHOOK=upgrade/20-isc-dhcp-plugin.sh
+ SYSHOOK=20-isc-dhcp-plugin.sh
+ SYSNAME=isc-dhcp-plugin.sh
+ echo $'>>> Invoking upgrade script \'isc-dhcp-plugin.sh\''
>>> Invoking upgrade script 'isc-dhcp-plugin.sh'
+ /usr/local/etc/rc.syshook.d/upgrade/20-isc-dhcp-plugin.sh
Skipping already installed legacy ISC-DHCP plugin...
+ SYSHOOK=upgrade/90-cleanup.sh
+ SYSHOOK=90-cleanup.sh
+ SYSNAME=cleanup.sh
+ echo $'>>> Invoking upgrade script \'cleanup.sh\''
>>> Invoking upgrade script 'cleanup.sh'
+ /usr/local/etc/rc.syshook.d/upgrade/90-cleanup.sh
+ exit 0
Cheers, Eric
sh -x /usr/local/etc/rc.syshook upgrade
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
+ REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem
+ SYSDIR=/usr/local/etc/rc.syshook.d
+ SYSLEVEL=upgrade
+ shift
+ [ -z upgrade ]
+ [ ! -d /usr/local/etc/rc.syshook.d/upgrade ]
+ find -s /usr/local/etc/rc.syshook.d/upgrade -type f}
+ SYSHOOKS='/usr/local/etc/rc.syshook.d/upgrade/10-sanity.sh
/usr/local/etc/rc.syshook.d/upgrade/20-isc-dhcp-plugin.sh
/usr/local/etc/rc.syshook.d/upgrade/90-cleanup.sh'
+ RETURN=0
+ SYSHOOK=upgrade/10-sanity.sh
+ SYSHOOK=10-sanity.sh
+ SYSNAME=sanity.sh
+ echo $'>>> Invoking upgrade script \'sanity.sh\''
>>> Invoking upgrade script 'sanity.sh'
+ /usr/local/etc/rc.syshook.d/upgrade/10-sanity.sh
Passed all upgrade tests.
+ SYSHOOK=upgrade/20-isc-dhcp-plugin.sh
+ SYSHOOK=20-isc-dhcp-plugin.sh
+ SYSNAME=isc-dhcp-plugin.sh
+ echo $'>>> Invoking upgrade script \'isc-dhcp-plugin.sh\''
>>> Invoking upgrade script 'isc-dhcp-plugin.sh'
+ /usr/local/etc/rc.syshook.d/upgrade/20-isc-dhcp-plugin.sh
Skipping already installed legacy ISC-DHCP plugin...
+ SYSHOOK=upgrade/90-cleanup.sh
+ SYSHOOK=90-cleanup.sh
+ SYSNAME=cleanup.sh
+ echo $'>>> Invoking upgrade script \'cleanup.sh\''
>>> Invoking upgrade script 'cleanup.sh'
+ /usr/local/etc/rc.syshook.d/upgrade/90-cleanup.sh
+ exit 0
Cheers, Eric
#94
Hardware and Performance / CPU recommendations for gigabi...
Last post by jim1985 - February 03, 2026, 11:27:52 AMHi all,
I have recently upgraded my PPPoE FTTP to 1000 / 110
Previously I was on a 550 / 50 connection.
I am using an old HP T730 thin client with an AMD RX-427BB CPU & an Intel I350-T4 NIC. This handled my previous connection speed quite fine, but I think the CPU is struggling to keep up with my new gigabit downstream bandwidth.
Speed tests vary between ~700Mbps down & 850Mbps down, but more often than not are on the lower end of that range.
I am also running Zenarmor. I don't currently have any VLANs set up.
One of the 4 NIC ports is the PPPoE WAN input, the others are bridged for my LAN.
Am I right in thinking that the AMD RX-427BB is now the bottleneck in my setup & if so, what CPU should I be looking to upgrade to?
I've been looking at changing to a Lenovo m720q or possibly the 920q, but I see that they are available with intel i3, i5 & i7 processor options.
Any advice on what I should go for would be greatly appreciated, thanks.
I'm based in the UK, just in case that has a bearing on any recommendations
I have recently upgraded my PPPoE FTTP to 1000 / 110
Previously I was on a 550 / 50 connection.
I am using an old HP T730 thin client with an AMD RX-427BB CPU & an Intel I350-T4 NIC. This handled my previous connection speed quite fine, but I think the CPU is struggling to keep up with my new gigabit downstream bandwidth.
Speed tests vary between ~700Mbps down & 850Mbps down, but more often than not are on the lower end of that range.
I am also running Zenarmor. I don't currently have any VLANs set up.
One of the 4 NIC ports is the PPPoE WAN input, the others are bridged for my LAN.
Am I right in thinking that the AMD RX-427BB is now the bottleneck in my setup & if so, what CPU should I be looking to upgrade to?
I've been looking at changing to a Lenovo m720q or possibly the 920q, but I see that they are available with intel i3, i5 & i7 processor options.
Any advice on what I should go for would be greatly appreciated, thanks.
I'm based in the UK, just in case that has a bearing on any recommendations
#95
German - Deutsch / Re: 26.1.4 Wireguard funktioni...
Last post by Zapad - February 03, 2026, 11:11:47 AMja, habe ich.
Ich habe Fritzbox mit exposed host und Bridged, gesamt 4 IP 2x ip4 und 2 ip6.
habe 2 Gateway Gruppen mit Ausfall Option, aber kein Richtlinien basiertes Routing für wireguard.
ddns läuft über Exposed Host, und darüber greife ich auf Wireguard.
Habe jetzt weiter expirementiert es läuft in 2 Versionen:
1x Status Typ > kein, Zustandrichtlinie > Standard
1x Status Typ > Status behalten, Zustandrichtlinie > Interface
mit anderen Optionen läuft es nicht.
Ich habe Fritzbox mit exposed host und Bridged, gesamt 4 IP 2x ip4 und 2 ip6.
habe 2 Gateway Gruppen mit Ausfall Option, aber kein Richtlinien basiertes Routing für wireguard.
ddns läuft über Exposed Host, und darüber greife ich auf Wireguard.
Habe jetzt weiter expirementiert es läuft in 2 Versionen:
1x Status Typ > kein, Zustandrichtlinie > Standard
1x Status Typ > Status behalten, Zustandrichtlinie > Interface
mit anderen Optionen läuft es nicht.
#96
Tutorials and FAQs / Re: [HOWTO] Reach your ONT or ...
Last post by meyergru - February 03, 2026, 10:46:12 AMplaceholder
#97
Tutorials and FAQs / Re: [HOWTO] Reach your ONT or ...
Last post by meyergru - February 03, 2026, 10:46:04 AMAs outlined by @Maurice, there is yet another way to keep RFC1918 IPs from leaking outside your WAN gateway - thereby eliminating the need for "out" block rules or exceptions for that.
You can define NULL routes for RFC1918 and ULA ranges like so:
You cannot view this attachment.
Note, however the warning on that page:
Why that works:
You create routes that use your localhost interface(s), i.e. they end on your OpnSense itself, so packets using them will never exit via the default gateway. However, you cannot set priorities on these system routes. This is not neccessary for as long as any rules for your local interfaces are more specific than these.
As an example, say your LAN is configured to use 192.168.4.1/24. When you look at the routing table, 192.168.4.0/24 is more specific than 192.168.0.0/16 and thus will have a higher implicit priority.
Caveat: This scheme would severely break if you ever created an interface that covers the whole of one of these NULL routes, e.g.: 10.0.0.0/8. It only works for as long as your interfaces are using less general subnets.
You can define NULL routes for RFC1918 and ULA ranges like so:
You cannot view this attachment.
Note, however the warning on that page:
QuoteDo not enter static routes for networks assigned on any interface of this firewall. Static routes are only used for networks reachable via a different router, and not reachable via your default gateway.
Why that works:
You create routes that use your localhost interface(s), i.e. they end on your OpnSense itself, so packets using them will never exit via the default gateway. However, you cannot set priorities on these system routes. This is not neccessary for as long as any rules for your local interfaces are more specific than these.
As an example, say your LAN is configured to use 192.168.4.1/24. When you look at the routing table, 192.168.4.0/24 is more specific than 192.168.0.0/16 and thus will have a higher implicit priority.
Caveat: This scheme would severely break if you ever created an interface that covers the whole of one of these NULL routes, e.g.: 10.0.0.0/8. It only works for as long as your interfaces are using less general subnets.
#98
Tutorials and FAQs / Re: [HOWTO] Reach your ONT or ...
Last post by meyergru - February 03, 2026, 10:45:55 AMThe first (pass) rule discussed above will look like this:
You cannot view this attachment.
The second (block) rule is this and it has to be placed after the pass rule:
You cannot view this attachment.
The alternative method uses just a single block rule with a modified alias instead of the two rules:
You cannot view this attachment.
and no advanced options (i.e. no explicit disable-reply-to):
You cannot view this attachment.
You cannot view this attachment.
The second (block) rule is this and it has to be placed after the pass rule:
You cannot view this attachment.
The alternative method uses just a single block rule with a modified alias instead of the two rules:
You cannot view this attachment.
and no advanced options (i.e. no explicit disable-reply-to):
You cannot view this attachment.
#99
Tutorials and FAQs / Re: [HOWTO] Reach your ONT or ...
Last post by meyergru - February 03, 2026, 10:45:45 AMComplex Case: WAN interface = ONT interface
This is when your WAN interface is the same as the management interface (often via DHCP).
You must assign a second IP in addition to the DHCP address, using a Virtual IP.
Now for the question on how to block WAN traffic for RFC1918 destinations.
Apparent solution: Use an "out" firewall rule to block all RFC1918 traffic, but create exceptions for your ONT network.
Code Select
Allow "out" quick from any to 192.168.100.0/24
Block "out" quick from any to RFC1918
This will pass outbound packets, but replies may not return unless Disable reply-to is enabled, because the resulting rules in /tmp/rules.debug would show:
Quotepass in quick on igc3 reply-to ( igc3 100.87.0.1 ) inet from {any} to {192.168.100.0/24} keep state # Allow ONT access
block out log quick on igc3 reply-to ( igc3 100.87.0.1 ) inet from {any} to $RFC1918 # Never expose internal IPs
Correct approach: Enable Disable reply-to in the advanced rule options for both allow and block rules:
Code Select
Allow "out" quick from any to 192.168.100.0/24 with disable reply-to
Block "out" quick from any to RFC1918 with disable reply-to
Another method: exclude the ONT network from the RFC1918 block.
Note: You cannot use an exception in the RFC1918 alias. You must manually list all subnets except the ONT subnet. On the other hand, you need no "disable-reply-to" in your (single) rule.
Example alias "RFC1918_WITHOUT_ONT":
Code Select
10.0.0.0/8
172.16.0.0/12
192.168.0.0/18
192.168.64.0/19
192.168.96.0/22
192.168.101.0/24
192.168.102.0/23
192.168.104.0/21
192.168.112.0/20
192.168.128.0/17
Them use the new alias in your block rule:
Code Select
Block "out" quick from any to RFC1918_WITHOUT_ONT
Actual steps with screendumps
So, to configure for the complex case, first create the virtual IP:
You cannot view this attachment.
Do not forget the outbound NAT rule (you cannot use "Interface address" for the NAT address because of the virtual IP):
You cannot view this attachment.
Again, you can use either hybrid or manual mode for this.
Also, unlike in the easy case, you cannot use "ONT net" with a virtual IP in your client access rule:
You cannot view this attachment.
#100
Tutorials and FAQs / [HOWTO] Reach your ONT or mode...
Last post by meyergru - February 03, 2026, 10:45:35 AMOPNsense – Accessing ONT / Modem Management Interfaces (Complete Guide)
I know that there are existing guides to do this, like this, yet those threads have become quite cluttered.
This guide does not want to take away from these efforts, rather expand them for a complex edge case that warrants a new guide, so here goes:
Basic Requirements
First off, there are some basic requirements for this to work:
In what follows, I assume 192.168.100.1 is the ONT management IP and 192.168.100.2/24 is the OPNsense interface IP. Adjust as needed for your setup.
Important warning: Some providers (e.g., Deutsche Glasfaser) block your internet access for a few minutes if they detect traffic to RFC1918 or BOGON IPs outside your networks.
You cannot simply block RFC1918 on the WAN interface because it violates requirement a).
I like to have an "out" rule on the WAN interface to suppress traffic to RFC1918 destinations, but that is not so easy sometimes...
Two Main Cases
You have two separate cases if you want to enable ONT (or modem) access:
Easy Case: WAN interface ≠ ONT interface
You have the actual WAN interface on a separate interface than your ONT.
This applies if your WAN uses either a VLAN, PPPoE, or both.
In this case, you can assign the ONT interface to the management subnet, because the interface is not being used otherwise.
So, you simply configure the ONT interface like this:
You cannot view this attachment.
This is the outbound NAT rule (you can use it via manual or hybrid NAT):
You cannot view this attachment.
Now for the question on how to block WAN traffic for RFC1918 destinations - this is easy in this case, because the rule applies to WAN only (and not to ONT):
You cannot view this attachment.
And lastly, the firewall rule to allow management clients to access your ONT (in case your LAN does not have an "allow any" rule):
You cannot view this attachment.
I know that there are existing guides to do this, like this, yet those threads have become quite cluttered.
This guide does not want to take away from these efforts, rather expand them for a complex edge case that warrants a new guide, so here goes:
Basic Requirements
First off, there are some basic requirements for this to work:
- You must not block RFC1918 IPs on the OPNsense interface connected to the ONT for obvious reasons.
- Your ONT's (or modem's) management IP must be outside of any of your local networks, including remote VPN sites. This is why you should never use some well-known network ranges that ONTs often use (also covered here).
- Some ONTs shut off management access once they establish internet access (i.e., O5 state). Nokia ONTs only react to ARP, but neither ICMP nor IP access works once connected on the fiber side.
- You most probably need outbound NAT to access the ONT because it is statically configured and does not have a default gateway. By using NAT, the translated IP the ONT sees lies inside its own local network, so it can respond correctly. You could theoretically install a route via OPNsense instead, but that does not work for all ONTs. Outbound NAT is the more general solution.
- You need a firewall rule allowing access from your management client(s) to your ONT's management IP.
In what follows, I assume 192.168.100.1 is the ONT management IP and 192.168.100.2/24 is the OPNsense interface IP. Adjust as needed for your setup.
Important warning: Some providers (e.g., Deutsche Glasfaser) block your internet access for a few minutes if they detect traffic to RFC1918 or BOGON IPs outside your networks.
- This can happen if devices (Fritzboxes, IoT devices) attempt to reach hardcoded RFC1918 IPs that are not local.
- Such traffic goes out via your ISP router and triggers provider protections.
You cannot simply block RFC1918 on the WAN interface because it violates requirement a).
I like to have an "out" rule on the WAN interface to suppress traffic to RFC1918 destinations, but that is not so easy sometimes...
Two Main Cases
You have two separate cases if you want to enable ONT (or modem) access:
Easy Case: WAN interface ≠ ONT interface
You have the actual WAN interface on a separate interface than your ONT.
This applies if your WAN uses either a VLAN, PPPoE, or both.
In this case, you can assign the ONT interface to the management subnet, because the interface is not being used otherwise.
So, you simply configure the ONT interface like this:
You cannot view this attachment.
This is the outbound NAT rule (you can use it via manual or hybrid NAT):
You cannot view this attachment.
Now for the question on how to block WAN traffic for RFC1918 destinations - this is easy in this case, because the rule applies to WAN only (and not to ONT):
You cannot view this attachment.
And lastly, the firewall rule to allow management clients to access your ONT (in case your LAN does not have an "allow any" rule):
You cannot view this attachment.
