"Recent posts
#1
German - Deutsch / Re: Öffentlicher IPv6-Suffix ä...
Last post by drosophila - Today at 03:25:08 AMDas kommt mir irgendwie vor als könnte es sich nicht entscheiden, welches Interface das Richtige ist. Ist das eine komplett neue Konfiguration, oder wurden da evtl. mal die Interface-Assignments getauscht, so dass nun in einer aktuell nicht sichtbaren Konfigurationsstelle das falsche Interface steht, so dass es eine Race-Condition gibt? Kann man z.B. mal die beiden Interface-Assignments zwischen LAN und WAN tauschen (und natürlich die Kabel umstöpseln), um zu sehen, ob das Problem dann auch auftritt?
#2
Development and Code Review / Re: What is the status of KEA ...
Last post by drosophila - Today at 02:57:15 AMAlright, this has not been the final word. Instead I tested some more with appending a true zero. Doing so through the GUI seems to be impossible because it always escapes the escape character "\" into "\\" and therefore destroys the escaping, but from the config file itself it works with an appended "\u000". But for some reason this works only if at least one letter follows the true zero, otherwise KEA just ends there and doesn't send the zero at all. Adding any character(or multiple) makes it send the zero. Like this:
43 0e 2f 70 78 65 62 6f 6f 74 66 69 6c 65 00 56 ff 23 94
That translates to "/pxebootfile<zero>V", note how the length field now is 0e, correctly counting the length including the zero and the appended "V". This is handled correctly by both Realtek and nVidia, both end up requesting "/pxebootfile", which is correct. So is KEA wrong in not sending the final zero even though it correctly specifies the length? Did nVidia work off an outdated spec or did they simply commit the basic blunder of counting from zero instead of one? Does Realtek have a more stringent sanitizer that converts all non-ASCII characters into end-of-string?
Sadly, the "specification" in RFC4578 only says "The format and contents of these options are NOT defined by the PXE specification.", so this must be defined outside of an RFC.
IBM has a document here that lists "UINT8 bootfile[128]; Bootfile: Boot file name. Null terminated string." on page 50. So it seems like the error is indeed on KEAs part, but what about the difference in parameters (noted above: "file" vs. "BF")? Is there yet another spec that supersedes the 1999 IBM document?
So it seems there is one from uefi here. They don't want to let me look at their precious document through my secured browser, and I'm not willing to compromise my anonymity, especially not to satisfy some random sites self-importance. So my research ends here for now. Maybe I'll get back to it on someone elses computer, who doesn't care about security and privacy.
The final question is: does the GUI have some means to escape escape characters so that it does not escape escape characters? IOW: how do I get the "\" into the config file through the GUI without it being mangled into "\\"? So that the resulting config file reads:
43 0e 2f 70 78 65 62 6f 6f 74 66 69 6c 65 00 56 ff 23 94
That translates to "/pxebootfile<zero>V", note how the length field now is 0e, correctly counting the length including the zero and the appended "V". This is handled correctly by both Realtek and nVidia, both end up requesting "/pxebootfile", which is correct. So is KEA wrong in not sending the final zero even though it correctly specifies the length? Did nVidia work off an outdated spec or did they simply commit the basic blunder of counting from zero instead of one? Does Realtek have a more stringent sanitizer that converts all non-ASCII characters into end-of-string?
Sadly, the "specification" in RFC4578 only says "The format and contents of these options are NOT defined by the PXE specification.", so this must be defined outside of an RFC.
IBM has a document here that lists "UINT8 bootfile[128]; Bootfile: Boot file name. Null terminated string." on page 50. So it seems like the error is indeed on KEAs part, but what about the difference in parameters (noted above: "file" vs. "BF")? Is there yet another spec that supersedes the 1999 IBM document?
So it seems there is one from uefi here. They don't want to let me look at their precious document through my secured browser, and I'm not willing to compromise my anonymity, especially not to satisfy some random sites self-importance. So my research ends here for now. Maybe I'll get back to it on someone elses computer, who doesn't care about security and privacy.
The final question is: does the GUI have some means to escape escape characters so that it does not escape escape characters? IOW: how do I get the "\" into the config file through the GUI without it being mangled into "\\"? So that the resulting config file reads:
Code Select
"data": "\/pxebootfile\u0000V"Not relying on evil filesystem hacks is nice, but managing KEA through files while a perfectly capable GUI is there for everything else also detracts from maintainability. #3
Q-Feeds (Threat intelligence) / Re: Major upgrade Q-Feeds Thre...
Last post by Seimus - Today at 01:24:50 AMQuoteWhat filtering options would you actually use?
Anything missing in the IOC view?
Not sure if this is feasible but what about sorting based on country of origin? E.g Country from where the IoC originates.
QuoteIdeas for improving the OPNsense plugin?
Well, OPNsense has inbuilt RRD and other graph possible tooling, would it be possible under the condition its not resource heavy, to create graphs based on the events/IPs/ports/protocols?
Something similar for example as in
Lobby > Reporting > Health
Or
Firewall> Log Files > Overview?
This would still be local to the OPNsense, but would give the users more visual representation.
Regards,
S.
#4
Tutorials and FAQs / Re: Technitium DNS Server on O...
Last post by piepre - Today at 12:47:25 AMit is also possible to use the freebsd dotnet release:
Code Select
zfs create zroot/opt
zfs set mountpoint=/opt zroot/opt
cd /tmp
fetch https://github.com/sec/dotnet-core-freebsd-source-build/releases/download/10.0.103-vmr/dotnet-sdk-10.0.103-freebsd.14-x64.tar.gz
tar -zxf dotnet-sdk-10.0.103-freebsd.14-x64.tar.gz -C /opt/dotnet/
ln -s /opt/dotnet/dotnet /usr/local/bin/dotnet
fetch https://download.technitium.com/dns/DnsServerPortable.tar.gz
tar -zxf DnsServerPortable.tar.gz -C /opt/technitium/dns/
cd /opt/technitium/dns
./start.sh &
#5
Hardware and Performance / Re: Achieving sustained 25Gbps...
Last post by pfry - Today at 12:14:05 AMQuote from: VRBitman on May 01, 2026, 05:13:27 PM[...]My CPU is an i9[...]
If you don't mind saying, what hardware precisely (I believe the first "i9" was a Kaby Lake and the last a Raptor Lake)? Also, NIC and RAM.
#6
Virtual private networks / Re: Generating OpenVPN Client ...
Last post by cookiemonster - Today at 12:00:27 AMSome systems need the whole cert chain in a single file. Others need them separate ie. CA, intermediates if any, server + a separate file for the client. Checck documentation or iternet search for your system's OS needs.
Also posting the log of the failure would help to point in a more specific direction. With any sensitive info redacted.
Also posting the log of the failure would help to point in a more specific direction. With any sensitive info redacted.
#7
Tutorials and FAQs / Re: [How-To] NPTv6 with dynami...
Last post by OPNenthu - May 02, 2026, 11:31:35 PMSome thoughts:
For me this is an experiment to see if it helps with some specific issues (and to learn something new) but I don't plan to keep this configuration long term. The main problem is that if IPv4 is enabled then many web clients and browsers will prefer that over a ULA for egress, so IPv6 will almost never be used except as a fallback. I think there are ways to configure that on a per-client basis but I'm not going to try.
I think this method becomes more attractive in an IPv6 only network where the ULA route is the only one, because then you can have true independence from the ISP's delegation for internal networks and there is nothing competing with the ULA for priority. Still, it flies against the IPv6 design principle where everything is globally addressable and any kind of NAT (even just prefix translation) should not be needed. As already pointed out, addressability != reachability.
There are however a few annoyances that this attempts to work around and they mainly have to do with challenges associated with dynamic prefixes. Put bluntly, many ISPs are not following RIPE recommendations[1] for persistent /48 prefix assignments. Most of the below reasons stem from that fateful decision.
I think the most obvious reason is if you don't have enough /64 prefixes for your subnetting. If your ISP only delegates a /60 and you need more than 16 subnets (or 15+WAN, because in DHCPv6-PD the WAN interface consumes one) then you might consider using ULAs for additional subnets and translating them to one of the existing prefixes.
A second reason is because of firewalling challenges[2] related to dynamic GUAs. In some cases it's difficult to enforce boundaries using only the network aliases that OPNsense maintains. For example, you might be tempted to create an alias named "IPV6_INTERNET" and define it as 2000::/3, then use that in filters or policy routing. The problem is that your GUAs are included in that and (at least as of 26.1) you have no way to exclude your dynamic prefixes.
A third reason is because some particular quirks may affect you. My ISP gives me a long-lived prefix which persists even after modem reboots. The ISP also reboots the modem weekly for updates and network maintenance. This causes the prefix to become deprecated and clients should not use the same prefix again, by some unfortunate language[3] in section 3.5 of RFC 8981. The effect is that until/unless clients reset their network interfaces, SLAAC fails to generate new addresses which is particularly insidious if you rely on temporary addresses with IPv6 privacy extensions. If there's one thing I cannot abide, it's silent failure[4] of privacy related functions and in my recent testing NPTv6 does fix this.
All said however, I think NPTv6 for these use cases is still not the second, third, or even fourth best alternative. Before this is considered at all I would look at something like ndp-proxy-go[5] or the trick of borrowing an unused prefix from somewhere[6], if you can. Just beware that some ISPs (like mine) do Stupid ThingsTM with RAs (like advertising ULA routes) so the ndp-proxy is not recommended then.
I'll mention also this article[7] linked by @Javier® in case you are interested in a true NAT option, although the described solution is centric to the OpenBSD flavor of pf and would need some adaptation for OPNsense. This one still has the same problem of ULA priority as NPTv6, though.
NAT observations:
Regarding outbound NAT, in my testing I see that NPTv6 does not seem to interfere with it. I have a VPN interface with an attached gateway and traffic leaving that interface is NATed to the wireguard tunnel address. I think because the Outbound NAT / SNAT rules have higher precedence than the NTPv6 / binat rules in the pf ruleset those are overriding the NPTv6 rules:
You cannot view this attachment.
Finally, what about ingress? Well, for hosts behind the firewall I guess that NAT port forwards / DNAT should still work. I don't presently host anything and haven't tested it.
[1]: https://www.ripe.net/publications/docs/ripe-690/
[2]: https://github.com/opnsense/core/issues/7000
[3]: https://www.rfc-editor.org/rfc/rfc8981.pdf
[4]: https://forum.opnsense.org/index.php?topic=44435.0
[5]: https://forum.opnsense.org/index.php?topic=44071.0
[6]: https://forum.opnsense.org/index.php?topic=31374.msg151647#msg151647
[7]: https://eradman.com/posts/ipv6-strategy.html
For me this is an experiment to see if it helps with some specific issues (and to learn something new) but I don't plan to keep this configuration long term. The main problem is that if IPv4 is enabled then many web clients and browsers will prefer that over a ULA for egress, so IPv6 will almost never be used except as a fallback. I think there are ways to configure that on a per-client basis but I'm not going to try.
I think this method becomes more attractive in an IPv6 only network where the ULA route is the only one, because then you can have true independence from the ISP's delegation for internal networks and there is nothing competing with the ULA for priority. Still, it flies against the IPv6 design principle where everything is globally addressable and any kind of NAT (even just prefix translation) should not be needed. As already pointed out, addressability != reachability.
There are however a few annoyances that this attempts to work around and they mainly have to do with challenges associated with dynamic prefixes. Put bluntly, many ISPs are not following RIPE recommendations[1] for persistent /48 prefix assignments. Most of the below reasons stem from that fateful decision.
I think the most obvious reason is if you don't have enough /64 prefixes for your subnetting. If your ISP only delegates a /60 and you need more than 16 subnets (or 15+WAN, because in DHCPv6-PD the WAN interface consumes one) then you might consider using ULAs for additional subnets and translating them to one of the existing prefixes.
A second reason is because of firewalling challenges[2] related to dynamic GUAs. In some cases it's difficult to enforce boundaries using only the network aliases that OPNsense maintains. For example, you might be tempted to create an alias named "IPV6_INTERNET" and define it as 2000::/3, then use that in filters or policy routing. The problem is that your GUAs are included in that and (at least as of 26.1) you have no way to exclude your dynamic prefixes.
A third reason is because some particular quirks may affect you. My ISP gives me a long-lived prefix which persists even after modem reboots. The ISP also reboots the modem weekly for updates and network maintenance. This causes the prefix to become deprecated and clients should not use the same prefix again, by some unfortunate language[3] in section 3.5 of RFC 8981. The effect is that until/unless clients reset their network interfaces, SLAAC fails to generate new addresses which is particularly insidious if you rely on temporary addresses with IPv6 privacy extensions. If there's one thing I cannot abide, it's silent failure[4] of privacy related functions and in my recent testing NPTv6 does fix this.
All said however, I think NPTv6 for these use cases is still not the second, third, or even fourth best alternative. Before this is considered at all I would look at something like ndp-proxy-go[5] or the trick of borrowing an unused prefix from somewhere[6], if you can. Just beware that some ISPs (like mine) do Stupid ThingsTM with RAs (like advertising ULA routes) so the ndp-proxy is not recommended then.
I'll mention also this article[7] linked by @Javier® in case you are interested in a true NAT option, although the described solution is centric to the OpenBSD flavor of pf and would need some adaptation for OPNsense. This one still has the same problem of ULA priority as NPTv6, though.
NAT observations:
Regarding outbound NAT, in my testing I see that NPTv6 does not seem to interfere with it. I have a VPN interface with an attached gateway and traffic leaving that interface is NATed to the wireguard tunnel address. I think because the Outbound NAT / SNAT rules have higher precedence than the NTPv6 / binat rules in the pf ruleset those are overriding the NPTv6 rules:
You cannot view this attachment.
Code Select
root@firewall:~ # cat /tmp/rules.debug | grep nat
...
nat log on wg1 inet from any to any -> (wg1:0) port 1024:65535 # SNAT on WAN_VPN0
nat log on wg1 inet6 from any to any -> (wg1:0) port 1024:65535 # SNAT on WAN_VPN0 (IPv6)
...
binat log on igc1 inet6 from fd5a:xxxx:xxxx:1002::/64 -> (lo1:0)/64 # NPTv6 WAN<->VPN (/64)
Finally, what about ingress? Well, for hosts behind the firewall I guess that NAT port forwards / DNAT should still work. I don't presently host anything and haven't tested it.
[1]: https://www.ripe.net/publications/docs/ripe-690/
[2]: https://github.com/opnsense/core/issues/7000
[3]: https://www.rfc-editor.org/rfc/rfc8981.pdf
[4]: https://forum.opnsense.org/index.php?topic=44435.0
[5]: https://forum.opnsense.org/index.php?topic=44071.0
[6]: https://forum.opnsense.org/index.php?topic=31374.msg151647#msg151647
[7]: https://eradman.com/posts/ipv6-strategy.html
#8
Tutorials and FAQs / [How-To] NPTv6 with dynamic pr...
Last post by OPNenthu - May 02, 2026, 11:31:11 PMJust some notes on the configuration because I didn't find a tutorial here. Let me know if it exists and I'll link to it.
I'll give some thoughts about this in post #2.
If you're looking to set up IPv6 the right way, this is not it. Please go here instead.
---
(Tested on OPNsense 26.1.7_1-amd64)
The objective is to use static ULA /64 prefixes on internal interfaces (e.g. LAN) which are controlled by you and independent of the ISP, but which get translated on egress to a delegated prefix. The first 64 bits of the ULA get overwritten but the lower 64 (host) bits remain intact. This means if you use privacy extensions on a web client those temporary address host bits will be preserved.
This is how it might look in firewall logs:
You cannot view this attachment.
You need at least one internal interface tracking the delegated prefix from WAN. This is a required input to the NPTv6 rule so that it knows which external prefix to translate to. I think it's required that your ISP delegates at least a /60 so that one of the prefix IDs can be used for the tracking interface, but don't quote me on this. I don't know how you would track a /64 delegation and you unfortunately cannot have the NPTv6 rule just use whatever is assigned on WAN already (see Note 3 below).
You can reuse the same tracking interface in multiple NPTv6 rules, however.
You can also use a dedicated loopback as the tracking interface in case you don't already have one. In my testing the new 'Identity Association' (idassoc) mode works for this purpose though I guess you can also use 'Track Interface (legacy)' (track6). I haven't tried it. Take care to disable any automatic radvd configs that get created in that case.
1. Go to Interfaces->Devices->Loopback and add new device.
2. Go to Interfaces->Assignments and assign this device with a name.
3. Go to Interfaces->[name] and enable it.
- Leave the IPv4 config set to None.
- Change the IPv6 config to "Identity Association" and choose your WAN as the parent interface.
- Choose an available prefix ID and save.
Note 1: don't add any rules on this interface as it won't be passing traffic. It's just there to hold the prefix.
You cannot view this attachment.
Finally the NPTv6 rule itself:
1. Go to Firewall->NAT->NPTv6 and click the "+" button to add a new rule.
- Set "Interface" to WAN (this is the interface that the rule applies to for outbound translation)
- Set "Internal IPv6 prefix" to one of your ULA prefixes for an internal network.
- Leave "External IPv6 prefix" blank.
- Set "Track Interface" to the internal interface tracking the prefix, or the loopback we set up earlier.
- Save.
Repeat for additional ULA prefixes you need to translate.
Note 2: you don't need to specify the internal interface anywhere. NPTv6 cares only about prefixes.
Note 3: if you don't specify either a tracking interface or an external prefix for translation (which we don't use for dynamic prefixes), there is currently a validation bug that will not stop you from doing this and it will cause IPv6 services that you have listening on WAN (e.g. WireGuard tunnels) to break.
And that should be it. This is how it might look for several subnets getting translated to the same tracking interface's prefix:
You cannot view this attachment.
I'll give some thoughts about this in post #2.
If you're looking to set up IPv6 the right way, this is not it. Please go here instead.
---
(Tested on OPNsense 26.1.7_1-amd64)
The objective is to use static ULA /64 prefixes on internal interfaces (e.g. LAN) which are controlled by you and independent of the ISP, but which get translated on egress to a delegated prefix. The first 64 bits of the ULA get overwritten but the lower 64 (host) bits remain intact. This means if you use privacy extensions on a web client those temporary address host bits will be preserved.
This is how it might look in firewall logs:
You cannot view this attachment.
You need at least one internal interface tracking the delegated prefix from WAN. This is a required input to the NPTv6 rule so that it knows which external prefix to translate to. I think it's required that your ISP delegates at least a /60 so that one of the prefix IDs can be used for the tracking interface, but don't quote me on this. I don't know how you would track a /64 delegation and you unfortunately cannot have the NPTv6 rule just use whatever is assigned on WAN already (see Note 3 below).
You can reuse the same tracking interface in multiple NPTv6 rules, however.
You can also use a dedicated loopback as the tracking interface in case you don't already have one. In my testing the new 'Identity Association' (idassoc) mode works for this purpose though I guess you can also use 'Track Interface (legacy)' (track6). I haven't tried it. Take care to disable any automatic radvd configs that get created in that case.
1. Go to Interfaces->Devices->Loopback and add new device.
2. Go to Interfaces->Assignments and assign this device with a name.
3. Go to Interfaces->[name] and enable it.
- Leave the IPv4 config set to None.
- Change the IPv6 config to "Identity Association" and choose your WAN as the parent interface.
- Choose an available prefix ID and save.
Note 1: don't add any rules on this interface as it won't be passing traffic. It's just there to hold the prefix.
You cannot view this attachment.
Finally the NPTv6 rule itself:
1. Go to Firewall->NAT->NPTv6 and click the "+" button to add a new rule.
- Set "Interface" to WAN (this is the interface that the rule applies to for outbound translation)
- Set "Internal IPv6 prefix" to one of your ULA prefixes for an internal network.
- Leave "External IPv6 prefix" blank.
- Set "Track Interface" to the internal interface tracking the prefix, or the loopback we set up earlier.
- Save.
Repeat for additional ULA prefixes you need to translate.
Note 2: you don't need to specify the internal interface anywhere. NPTv6 cares only about prefixes.
Note 3: if you don't specify either a tracking interface or an external prefix for translation (which we don't use for dynamic prefixes), there is currently a validation bug that will not stop you from doing this and it will cause IPv6 services that you have listening on WAN (e.g. WireGuard tunnels) to break.
And that should be it. This is how it might look for several subnets getting translated to the same tracking interface's prefix:
You cannot view this attachment.
#9
Hardware and Performance / Re: Achieving sustained 25Gbps...
Last post by BrandyWine - May 02, 2026, 10:57:10 PM1st build a router and test speeds across interfaces. If you can build the 25Gb links.
After that, then you can install FW software.
After that, then you can install FW software.
#10
Virtual private networks / Generating OpenVPN Client Conn...
Last post by cybermailer84 - May 02, 2026, 09:40:41 PMHi,
i successfully configured openvpn server on opnsense and exported a client connection file.
With android and official openvpn app - importing and afterwards setting the username and password was successful - no problem.
With linux kubuntu importing the one-filer - i have problems connecting - it leads to tls handshake error.
Maybe it is my first time handling tls and never had that problem before.
Any tipps how to handle such a problem?
thx
i successfully configured openvpn server on opnsense and exported a client connection file.
With android and official openvpn app - importing and afterwards setting the username and password was successful - no problem.
With linux kubuntu importing the one-filer - i have problems connecting - it leads to tls handshake error.
Maybe it is my first time handling tls and never had that problem before.
Any tipps how to handle such a problem?
thx
