"Recent posts
#1
25.7, 25.10 Legacy Series / Re: Android 16 and NDP cache
Last post by reinob - Today at 09:54:47 AMIt's been a while, and I have to say I didn't get to test the ndp-proxy.
But I can report that with my current workaround, things seem to be stable.
It's a python script which runs every minute which detects the GUAs associated with the MAC address of my phone and sets them to "permanent", while deleting/expiring any other GUA that is not currently associated with the phone.
By running this often enough, the ndp table is always accurate, as long as the phone doesn't randomly decided to change its IID — this has happened actually once, I don't know why/how (according to the documentation the IID should be stable for a given SSID, unless you activate the "randomize MAC" option, which I haven't).
I see that not only Motorola but also Fairphone has this issue (https://forum.fairphone.com/t/dns-over-tls-ipv6-issues-apps-dont-load-data-over-wifi/130519), so I'm hoping that the issue will gain some traction and be solved quickly.
BTW apparently Android, even if it doesn't support DHCPv6, does support getting a whole prefix (https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html, https://mailarchive.ietf.org/arch/msg/v6ops/Sq5TadeSsMQ-0uEWrdem3A1wDh0/#) which is weird but could be a solution. Unfortunately, this doesn't seem to be supported (yet) but RADVD or DNSMASQ.
But I can report that with my current workaround, things seem to be stable.
It's a python script which runs every minute which detects the GUAs associated with the MAC address of my phone and sets them to "permanent", while deleting/expiring any other GUA that is not currently associated with the phone.
By running this often enough, the ndp table is always accurate, as long as the phone doesn't randomly decided to change its IID — this has happened actually once, I don't know why/how (according to the documentation the IID should be stable for a given SSID, unless you activate the "randomize MAC" option, which I haven't).
I see that not only Motorola but also Fairphone has this issue (https://forum.fairphone.com/t/dns-over-tls-ipv6-issues-apps-dont-load-data-over-wifi/130519), so I'm hoping that the issue will gain some traction and be solved quickly.
BTW apparently Android, even if it doesn't support DHCPv6, does support getting a whole prefix (https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html, https://mailarchive.ietf.org/arch/msg/v6ops/Sq5TadeSsMQ-0uEWrdem3A1wDh0/#) which is weird but could be a solution. Unfortunately, this doesn't seem to be supported (yet) but RADVD or DNSMASQ.
#2
Intrusion Detection and Prevention / Re: Just converted from pfsens...
Last post by adgyhya - Today at 09:27:59 AMThat .LCK file means the rules DB is stuck in a locked/failed update state.
Quick fix:
Stop Suricata
Delete both files:
rm /usr/local/etc/suricata/rules/rules.sqlite*
Restart OPNsense IDS/IPS (or reboot)
Reapply config, then re-enable ET Open and update again
If it still auto-downloads, check Services → Intrusion Detection → Administration and disable auto rule updates temporarily.
The issue isn't the rules themselves—it's the locked SQLite DB blocking everything.bitlife online
Quick fix:
Stop Suricata
Delete both files:
rm /usr/local/etc/suricata/rules/rules.sqlite*
Restart OPNsense IDS/IPS (or reboot)
Reapply config, then re-enable ET Open and update again
If it still auto-downloads, check Services → Intrusion Detection → Administration and disable auto rule updates temporarily.
The issue isn't the rules themselves—it's the locked SQLite DB blocking everything.bitlife online
#3
Intrusion Detection and Prevention / Re: Update et open rules in ai...
Last post by adgyhya - Today at 09:26:14 AMYou've got a path and structure issue, not a rule problem.
Suricata on OPNsense expects rules inside a directory with a valid suricata.yaml reference, not a single file dropped randomly. Also your path has a typo: it should be /usr/local/etc/suricata/ (not suricate).bitlife
Quick fix:
Put your rules in: /usr/local/etc/suricata/rules/emerging-all.rules
Make sure suricata.yaml includes:
rule-files: - emerging-all.rules
Or better: use
suricata-update --local /path/to/emerging-all.rules
Then restart Suricata.
The error "no rules were loaded" usually means wrong path or rule-files not referenced, not that the rules themselves are invalid.
Suricata on OPNsense expects rules inside a directory with a valid suricata.yaml reference, not a single file dropped randomly. Also your path has a typo: it should be /usr/local/etc/suricata/ (not suricate).bitlife
Quick fix:
Put your rules in: /usr/local/etc/suricata/rules/emerging-all.rules
Make sure suricata.yaml includes:
rule-files: - emerging-all.rules
Or better: use
suricata-update --local /path/to/emerging-all.rules
Then restart Suricata.
The error "no rules were loaded" usually means wrong path or rule-files not referenced, not that the rules themselves are invalid.
#4
26.1, 26,4 Series / Re: OpenVPN - Via UDP no routi...
Last post by PotatoCarl - Today at 08:53:05 AMThe client - now comes the fun part - says connected. The VPN at the OpenVPN says -connected. The firewall protocol says - nothing.
I will try to reexport the client. Kind of strange as the local OpenVPN connection TCP is actually a copy of the one of UDP just with different peers, but who knows...
I will try to reexport the client. Kind of strange as the local OpenVPN connection TCP is actually a copy of the one of UDP just with different peers, but who knows...
#5
26.1, 26,4 Series / Question for Best Practice/Wir...
Last post by PotatoCarl - Today at 08:51:25 AMHi
I have successfully setup one Wireguard VPN. It works inside out network and outside. So Yay!
However, I copied this VPN to a second one, differences are: Different port, different IP range.
I cannot get this to work, i.e. my client does not show "handshake".
Few things:
- We have two WAN, so both Wireguard clients have 2 peers
- The WAN is coming via a fritz box and exposed host to the OPNSense port
- The different IP ranges are necessary as in our experience from time to time e.g. Hotels use the same internal IP range as we do, so no routing is possible. Therefore we have multiple VPN instances to make sure "one of them works"
I know, I know "I copied everything but..." usually means "but forgot something". I have checked mutiple times all settings (gateways, interfaces, rules, NAT, shaping, Wireguard) and cannot find a difference.
Basically I am asking where to look protocol wise to do debugging. Or any other tip if this is fundamentally wrong what I was thinking.
I have successfully setup one Wireguard VPN. It works inside out network and outside. So Yay!
However, I copied this VPN to a second one, differences are: Different port, different IP range.
I cannot get this to work, i.e. my client does not show "handshake".
Few things:
- We have two WAN, so both Wireguard clients have 2 peers
- The WAN is coming via a fritz box and exposed host to the OPNSense port
- The different IP ranges are necessary as in our experience from time to time e.g. Hotels use the same internal IP range as we do, so no routing is possible. Therefore we have multiple VPN instances to make sure "one of them works"
I know, I know "I copied everything but..." usually means "but forgot something". I have checked mutiple times all settings (gateways, interfaces, rules, NAT, shaping, Wireguard) and cannot find a difference.
Basically I am asking where to look protocol wise to do debugging. Or any other tip if this is fundamentally wrong what I was thinking.
#6
General Discussion / Re: Shaper queues and schedule...
Last post by keeka - Today at 07:51:19 AMThanks. I came across the thread in my search but skipped it because it appeared to be specific to IPv6. I now see it covers quite a lot more so I have this evening's reading sorted.
#7
26.1, 26,4 Series / Re: Why does this static ULA g...
Last post by OPNenthu - Today at 05:12:29 AMDoing some more reading and I think I'm starting to understand that this is to do with IPv6 mechanics.
The /128 address is not considered on-link for Neighbor Discovery by default, so the BSD kernel promotes it to loopback (I guess it always goes to 'lo0' regardless?) and makes that explicit in the routing table. (Side note: apparently some OSes effectively do the same thing but it's less obvious.)
So I'm not sure I gain any separation by using a dedicated loopback interface for redirects over just assigning a ULA VIP to the normal loopback.
The /128 address is not considered on-link for Neighbor Discovery by default, so the BSD kernel promotes it to loopback (I guess it always goes to 'lo0' regardless?) and makes that explicit in the routing table. (Side note: apparently some OSes effectively do the same thing but it's less obvious.)
So I'm not sure I gain any separation by using a dedicated loopback interface for redirects over just assigning a ULA VIP to the normal loopback.
#8
26.1, 26,4 Series / Why does this static ULA get i...
Last post by OPNenthu - Today at 02:54:33 AMMaybe someone can explain this to me:
I created a new loopback device (lo1) in Interfaces->Devices->Loopback for the sole purpose of using it as a redirect target in DNAT rules for internal services (e.g. DNS).
I assigned and enabled this interface, which I named "RDR," and I then assigned two IPs:
- 10.255.255.1/32
- fdff::1/128
These are not VIPs but static assignments on the interface.
As redirect targets for internal networks, these work fine so long as the associated firewall 'pass' rules are in place (or set to 'pass' in the DNAT rule itself).
I noticed something odd when I tried to use these IPs from the firewall host, however. This was getting blocked by the default deny rule:
And this was passing:
Now I know this has nothing to do with NAT- I was just testing if it works. It looks like the IPv4 case was being routed to the RDR interface and since there are no rules defined there it makes sense why this was blocked.
The IPv6 case didn't make any sense until I looked in the routing table and saw that the ULA address is installed as a host route on the default loopback (lo0) instead of lo1.
This difference was unexpected and my first thought was maybe it's a bug, but ChatGPT thinks it's a nuance of FreeBSD routing with IPv6. I figured best to get this clarified here. :)
I have two firewalls configured like this and both are showing the ULA on lo0 instead of lo1 in the routes.
You cannot view this attachment.
You cannot view this attachment.
I created a new loopback device (lo1) in Interfaces->Devices->Loopback for the sole purpose of using it as a redirect target in DNAT rules for internal services (e.g. DNS).
I assigned and enabled this interface, which I named "RDR," and I then assigned two IPs:
- 10.255.255.1/32
- fdff::1/128
These are not VIPs but static assignments on the interface.
As redirect targets for internal networks, these work fine so long as the associated firewall 'pass' rules are in place (or set to 'pass' in the DNAT rule itself).
I noticed something odd when I tried to use these IPs from the firewall host, however. This was getting blocked by the default deny rule:
Code Select
$ dig @10.255.255.1 opnsense.org
And this was passing:
Code Select
$ dig @fdff::1 opnsense.org
Now I know this has nothing to do with NAT- I was just testing if it works. It looks like the IPv4 case was being routed to the RDR interface and since there are no rules defined there it makes sense why this was blocked.
The IPv6 case didn't make any sense until I looked in the routing table and saw that the ULA address is installed as a host route on the default loopback (lo0) instead of lo1.
This difference was unexpected and my first thought was maybe it's a bug, but ChatGPT thinks it's a nuance of FreeBSD routing with IPv6. I figured best to get this clarified here. :)
I have two firewalls configured like this and both are showing the ULA on lo0 instead of lo1 in the routes.
You cannot view this attachment.
You cannot view this attachment.
#9
26.1, 26,4 Series / Re: Destination NAT - changes ...
Last post by lmoore - Today at 02:43:42 AMQuote from: swfchang on Today at 12:40:46 AMChanges made to the NAT rules were not updated in the Firewall Rules.
Perhaps you could show the NAT rules you've created/changed.
#10
General Discussion / Management port on transparent...
Last post by mantissa - Today at 02:36:05 AMThis has been problematic for me. I have a transparent bridge running IP4 and IP6. The bridge is on OPT1 and WAN. The IP4 address space is on the OPT1 interface 192.168.1.0/24. Traffic passes fine between OPT1 and the WAN. I cannot get a connection outbound from the bridge0 device to the outside world. This means I cannot get updates or add packages. I have been managing the bridge via the LAN interface on 192.168.10.1/24. I suspect this .10 address space is the problem. I have tried a few things and ended up locking myself out a couple of times so I am kind of hesitant to play around with settings until I know what is going on. How can I configure the device to it can communicate out the WAN and get updates?
