"Recent posts
#21
25.7, 25.10 Series / Re: Unwanted route that keeps ...
Last post by Patrick M. Hausen - December 06, 2025, 04:43:15 PMInterface configuration for LAN - did you set a gateway there? Don't.
If you need static routes pointing to that other firewall, add it as a gateway in System > Gateways and add the static routes as necessary.
If you need static routes pointing to that other firewall, add it as a gateway in System > Gateways and add the static routes as necessary.
#22
Tutorials and FAQs / Re: OPNsense aarch64 firmware ...
Last post by Maurice - December 06, 2025, 04:40:52 PMHaving some build issues with 25.7.9 after switching to my own fork of opnsense/core in 25.7.8. Stand by, I'll figure it out.
@franco No opnsense-update 25.7.9 with removed "pin" feature? Patching that locally on my build system is a bit of a pita...
@franco No opnsense-update 25.7.9 with removed "pin" feature? Patching that locally on my build system is a bit of a pita...
#23
25.7, 25.10 Series / Re: Unwanted route that keeps ...
Last post by abenaou - December 06, 2025, 04:40:34 PMQuote from: Patrick M. Hausen on December 05, 2025, 08:54:18 PMUGHS - that route is static. It's configured somewhere. Do you have configured a gateway on vlan0.6? Remove that.Thanks for your answer.
Where should I look? I checked :
System -> Routes -> configuration
And there is no such a route, in fact the page is empty.
I even downloaded the configuration file and did and nothing came up:
Code Select
grep -rni 10.99.200.180 myroute-20251206083945.xmlWhere should I check?
Thanks
#24
25.7, 25.10 Series / Re: GeoIP with ipinfo stopped ...
Last post by reincoder - December 06, 2025, 03:56:23 PMHi,
We were slowly migrating to a different cloud storage service over a period of time. We have rolled back the system migration entirely.
We have been doing incremental migration throughout the process, and thanks to the post and the only message we received on the support portal, we discovered reliance on the URI header metadata. This was not a hard transition, which has been rolled back, and further investigation will be conducted in the next few days.
During this transition, thanks to this post, we found out that the Content-Disposition header was no longer included in the final download response. This header was optional, but OpnSense relies on it to detect the filename or file type. We have been doing the slow rollout for several weeks, and this was the first issue we received.
The file itself has not changed; it's still a .csv.gz gzip file, but because the header is missing, some scripts may incorrectly treat it as a ZIP instead of a GZIP file. We have rolled back our entire deployment to our previous storage service.
We will investigate closely in the coming days. Thank you for understanding.
— Abdullah | DevRel, IPinfo
We were slowly migrating to a different cloud storage service over a period of time. We have rolled back the system migration entirely.
We have been doing incremental migration throughout the process, and thanks to the post and the only message we received on the support portal, we discovered reliance on the URI header metadata. This was not a hard transition, which has been rolled back, and further investigation will be conducted in the next few days.
During this transition, thanks to this post, we found out that the Content-Disposition header was no longer included in the final download response. This header was optional, but OpnSense relies on it to detect the filename or file type. We have been doing the slow rollout for several weeks, and this was the first issue we received.
The file itself has not changed; it's still a .csv.gz gzip file, but because the header is missing, some scripts may incorrectly treat it as a ZIP instead of a GZIP file. We have rolled back our entire deployment to our previous storage service.
We will investigate closely in the coming days. Thank you for understanding.
— Abdullah | DevRel, IPinfo
#25
Tutorials and FAQs / Re: ndp-proxy-go: Proxy ISP pr...
Last post by Monviech (Cedrik) - December 06, 2025, 03:51:36 PMExperimental PPPoE support is in 25.7.9.
The last feature I added is PF table (firewall alias) support to help with the network segmentation for highly dynamic setups.
It will most likely hit 25.7.10.
With that the proxy should be complete for now, I personally do not miss any feature when using it, it just worksTM and is quite possibly the leading most complete implementation to fix IPv6 for many setups.
I would call it generic since you can chain the proxy over multiple routers. You dont even need DHCPv6-PD anymore, this proxy handles dynamic IPv6 so gracefully that you won't believe it.
https://github.com/opnsense/docs/commit/5bb5fca5c67ac9162c8f76d6261ca6cc90f34076
The last feature I added is PF table (firewall alias) support to help with the network segmentation for highly dynamic setups.
It will most likely hit 25.7.10.
With that the proxy should be complete for now, I personally do not miss any feature when using it, it just worksTM and is quite possibly the leading most complete implementation to fix IPv6 for many setups.
I would call it generic since you can chain the proxy over multiple routers. You dont even need DHCPv6-PD anymore, this proxy handles dynamic IPv6 so gracefully that you won't believe it.
https://github.com/opnsense/docs/commit/5bb5fca5c67ac9162c8f76d6261ca6cc90f34076
#26
25.7, 25.10 Series / Re: 25.7.9: pkg exited on sign...
Last post by kozistan - December 06, 2025, 03:46:42 PMUnderstood. What I did is set the remaining tunables and reboot, but this did not fix the issue.
Then I removed SunnyValley from the active repos and reset the pkg state:
After that I reinstalled pkg using pkg-static:
So I downgraded pkg and
Does this mean there is something wrong with the pkg 2.4.2 version on this hardware/setup?
Code Select
vm.pmap.pcid_enabled="0"
hw.ibrs_disable="0"
vm.pmap.pti="1"Then I removed SunnyValley from the active repos and reset the pkg state:
Code Select
mv /usr/local/etc/pkg/repos/SunnyValley.conf /usr/local/etc/pkg/repos/SunnyValley.conf.DISABLED
rm -rf /var/cache/pkg/*
rm -f /var/db/pkg/*.sqliteAfter that I reinstalled pkg using pkg-static:
Code Select
/usr/local/sbin/pkg-static install -f pkg # installed pkg-2.3.1_1So I downgraded pkg and
Code Select
pkg update -f now runs cleanly and no longer faults.Does this mean there is something wrong with the pkg 2.4.2 version on this hardware/setup?
#27
General Discussion / Re: Unbound strange behavior
Last post by ricksense - December 06, 2025, 02:00:53 PMQuote from: Patrick M. Hausen on December 06, 2025, 11:57:37 AMIn general it doesn't. I run it at multiple offices and an entire data centre with that setting and no problems at all.
Something about your configuration must be unusual. Still pondering what that might be. Did you change the interfaces setting for Unbound, possibly? Something in private networks?
I read about another user on Reddit who is dealing with the same issue as mine. Anyway, I've never complained about OPNsense, but I have already run across a couple of problems with the last version.
#28
25.7, 25.10 Series / Re: 25.7.9: pkg exited on sign...
Last post by meyergru - December 06, 2025, 01:09:26 PMASPM is your smallest problem. That is neither the first nor the only thing in point 23. You need to use the os-microcode-intel plugin and the tuneables from the linked posting in point 23 with your Alder Lake CPU.
You also do not need to add anything to any files, just use the web UI to enter the tuneables and reboot afterwards.
You also do not need to add anything to any files, just use the web UI to enter the tuneables and reboot afterwards.
#29
General Discussion / Re: Seeking advice for first G...
Last post by meyergru - December 06, 2025, 12:59:06 PMThere are lots of problems with those rules.
First, you have to ask yourself what you want to achieve by separating out a guest VLAN.
Usually, this is used to protect your "valuable assets" in your main LAN from anyone who may just use your internet connection. In order to do this, you should have rules in place to protect your LAN from the guest VLAN.
Your rules show an attempt to further regulate the traffic originating from your guest network. This is debatable at best and your rules do not provide that, either. The way you currently do it would keep most guests from browsing anything at all, because current browsers use DoT on port 853, which you do not allow. On the other hand, because you allow port 443, anybody could use DNS via DoH, so you do not block external DNS requests effectively.
Before I go on to show what is wrong with your rules, I tell you what mine are:
1. I have floating rules to allow traffic that I need to allow basic network functions for all local networks - that includes the guest VLAN.
Those would be DNS (53/UDP) and NTP (123/UDP). I also allow access to specific resources there, like a printer on my IoT VLAN.
2. In the VLAN-specific rules, I have one rule to allow any to any, like the default LAN rule. This will allow guest clients to access anything on the internet. Why? Frankly, because you cannot effectively regulate traffic, there anyway. The only thing you have to do there is a block rule to an alias "RFC1918", which has to be placed before the "allow any" rule, in order to keep guests from accessing your local networks.
That is about it.
Now for your rules:
- Allow DHCP Port 67/UDP: This rule is unneccesary AFAIR, because that is allowed in the "Automatically generated rules" already. Delete it.
- Allow DNS Port 53: Only needed with UDP and should beplace in floating rules for all local network interfaces. Move it there.
- Block External DNS Port 53: Why would you? These days, browsers mostly do DoT or DoH, anyway. As long as you do not block that, either, this is fruitless. If you want to block it: This is very complex and frankly, at your current level, you would not succeed in doing it. Leave it be, delete the rule.
- Block access to firewall management: Since this rule comes before the next rules, it would block anything after it, like "Allow NTP", so it is misplaced. If at all, you should move it further down in the list. Then again, it is not needed at all, because there already is an implicit "block all" rule at the end of the list. Rule of thumb: order matters! Delete it.
- Block access to private/internal networks. Yes, keep it.
- Allow Inbound Connection Ports 80-443: Problem here is, you allow not only ports 80 and 443 ofr HTTP and HTTPS, but anything in between, including NTP (123) and many others. If you really want ports 80 and 443 only, you need either two rules or a "Port" alias for web traffic consisting of port 80 and 443. I would say, delete the rule and replace it by an "allow any" rule.
- Allow Outbound traffic Port 443-80: You never need to have a firewall rule for outbound directions (with only a few exceptions), even less so for an existing inbound rule. The responses to allowed traffic are always allowed. Delete it.
- Allow NTP Port 123: Move the rule to floating.
First, you have to ask yourself what you want to achieve by separating out a guest VLAN.
Usually, this is used to protect your "valuable assets" in your main LAN from anyone who may just use your internet connection. In order to do this, you should have rules in place to protect your LAN from the guest VLAN.
Your rules show an attempt to further regulate the traffic originating from your guest network. This is debatable at best and your rules do not provide that, either. The way you currently do it would keep most guests from browsing anything at all, because current browsers use DoT on port 853, which you do not allow. On the other hand, because you allow port 443, anybody could use DNS via DoH, so you do not block external DNS requests effectively.
Before I go on to show what is wrong with your rules, I tell you what mine are:
1. I have floating rules to allow traffic that I need to allow basic network functions for all local networks - that includes the guest VLAN.
Those would be DNS (53/UDP) and NTP (123/UDP). I also allow access to specific resources there, like a printer on my IoT VLAN.
2. In the VLAN-specific rules, I have one rule to allow any to any, like the default LAN rule. This will allow guest clients to access anything on the internet. Why? Frankly, because you cannot effectively regulate traffic, there anyway. The only thing you have to do there is a block rule to an alias "RFC1918", which has to be placed before the "allow any" rule, in order to keep guests from accessing your local networks.
That is about it.
Now for your rules:
- Allow DHCP Port 67/UDP: This rule is unneccesary AFAIR, because that is allowed in the "Automatically generated rules" already. Delete it.
- Allow DNS Port 53: Only needed with UDP and should beplace in floating rules for all local network interfaces. Move it there.
- Block External DNS Port 53: Why would you? These days, browsers mostly do DoT or DoH, anyway. As long as you do not block that, either, this is fruitless. If you want to block it: This is very complex and frankly, at your current level, you would not succeed in doing it. Leave it be, delete the rule.
- Block access to firewall management: Since this rule comes before the next rules, it would block anything after it, like "Allow NTP", so it is misplaced. If at all, you should move it further down in the list. Then again, it is not needed at all, because there already is an implicit "block all" rule at the end of the list. Rule of thumb: order matters! Delete it.
- Block access to private/internal networks. Yes, keep it.
- Allow Inbound Connection Ports 80-443: Problem here is, you allow not only ports 80 and 443 ofr HTTP and HTTPS, but anything in between, including NTP (123) and many others. If you really want ports 80 and 443 only, you need either two rules or a "Port" alias for web traffic consisting of port 80 and 443. I would say, delete the rule and replace it by an "allow any" rule.
- Allow Outbound traffic Port 443-80: You never need to have a firewall rule for outbound directions (with only a few exceptions), even less so for an existing inbound rule. The responses to allowed traffic are always allowed. Delete it.
- Allow NTP Port 123: Move the rule to floating.
#30
General Discussion / Re: Unbound strange behavior
Last post by Patrick M. Hausen - December 06, 2025, 11:57:37 AMIn general it doesn't. I run it at multiple offices and an entire data centre with that setting and no problems at all.
Something about your configuration must be unusual. Still pondering what that might be. Did you change the interfaces setting for Unbound, possibly? Something in private networks?
Something about your configuration must be unusual. Still pondering what that might be. Did you change the interfaces setting for Unbound, possibly? Something in private networks?
