"Recent posts
#1
26.1, 26,4 Series / Re: KEA is still a mess IMHO
Last post by Patrick M. Hausen - Today at 08:01:56 AMQuote from: JamesFrisch on Today at 07:33:12 AMI can't say to NGINX:
My static /48 prefix is 2000:2000:2000::, my service is in the vlan 30, which has the prefix 2000:2000:2000:30:: so proxy pass to 2000:2000:2000:30:: and somewhere in there is my destination, go find it.
All my servers use SLAAC. The addresses are stable unless I change the MAC address of the server for some reason. I can then point Caddy (or NginX in your case) at these addresses. DHCPv6 is rarely needed.
#2
26.1, 26,4 Series / Re: KEA is still a mess IMHO
Last post by RES217AIII - Today at 07:59:36 AMI don't want to be misunderstood—I am far from being a networking expert. Rather, I am grappling with the very same issues regarding the implementation of fixed IPv6 assignments, network segmentation, and access control. In that sense, I used this thread as an opportunity to better understand—through discussion—how our specific problem might be solved without forcing the IPv6 structure into a straitjacket that runs counter to its fundamental design principles. Couldn't we simply assign a ULA to Nginx instead of relying on a static assignment via DHCPv6? In the IPv6 world, devices are capable of having—and indeed typically do have—more than one address: a GUA assigned via Router Advertisement to enable communication with the outside world, and a ULA for internal purposes, ensuring the device can be reliably located within the local network.
#3
26.1, 26,4 Series / Re: KEA is still a mess IMHO
Last post by Monviech (Cedrik) - Today at 07:56:52 AMEssentially with SLAAC (Router Advertisements) most devices should receive an EUI-64 based "management" IP address, that is stable (based on device MAC address) and static, which can be used for inbound connections.
So DHCPv6 IA_NA address is generally not that important.
As I said on github, the duid missing is a small bug right now that has been fixed in the PR I mentioned there.
So DHCPv6 IA_NA address is generally not that important.
As I said on github, the duid missing is a small bug right now that has been fixed in the PR I mentioned there.
#4
Virtual private networks / Re: Always On VPN (Wireguard) ...
Last post by keeka - Today at 07:39:55 AMNot sure where your issue lies but the way I have done this (for both openvpn and wireguard) is one destination NAT rule on the WAN, and another on the relevant lan interface. Both forwarding wireguard port to 127.0.0.1. I found that to be the most reliable way to get mobile/wifi roaming whilst only using WAN IP in any vpn client config. The WAN version of the port forward and fw rule filters src by my mobile provider's ASN.
#5
26.1, 26,4 Series / Re: KEA is still a mess IMHO
Last post by JamesFrisch - Today at 07:33:12 AMThat is a little bit off topic, because my issue is more about OPNsense offerin MAC based reservations, which according to some folks on github is against IPv6 philosophy. And because of that, they have not accounted for certain situations and you run into errors.
Maybe I am misunderstanding you, but IMHO your idea falls flat, because I only need static leases for services. And for that I need a static IPv6.
I can't say to NGINX:
My static /48 prefix is 2000:2000:2000::, my service is in the vlan 30, which has the prefix 2000:2000:2000:30:: so proxy pass to 2000:2000:2000:30:: and somewhere in there is my destination, go find it.
Maybe I am misunderstanding you, but IMHO your idea falls flat, because I only need static leases for services. And for that I need a static IPv6.
I can't say to NGINX:
My static /48 prefix is 2000:2000:2000::, my service is in the vlan 30, which has the prefix 2000:2000:2000:30:: so proxy pass to 2000:2000:2000:30:: and somewhere in there is my destination, go find it.
#6
Virtual private networks / Always On VPN (Wireguard) Mobi...
Last post by foss-johnny - Today at 06:27:01 AMHi all,
I'm having issues with an Always-On-VPN setup I'm trying to get working for mobile clients using Wireguard VPN.
My goal is to always leave the Wireguard VPN On for all mobile phones, and iand for them to roam between the internal wi-fi and their 5g connection, all traffic for the mobile client should route through the Opnsense firewall.
Here's the toplogy.
192.168.1.x = Internal Wireless Subnet
172.16.1.x = Wireguard Subnet
10.0.1.x = File server Subnet
Currently if the mobile phone is connected to the 5G connection, everything is working fine.
However, when the mobile phone is connected to internal wifi, and the Wireguard connection is sucessfully established, I try to connect apps (file server), and I receive a "TIME_WAIT:TIME_WAIT" message in the session logs.
After reviewing the firewall traffic logs I can see that the traffic is allowed and "pass" status.
However, when comparing a trace route from the mobile to the file server when on the wifi and wg connected, it does not hit the wireguard gateway first, instead I see * * * .. for each hop.
Does anyone have a configuration like this working properly or know how to resolve?
Thanks!
I'm having issues with an Always-On-VPN setup I'm trying to get working for mobile clients using Wireguard VPN.
My goal is to always leave the Wireguard VPN On for all mobile phones, and iand for them to roam between the internal wi-fi and their 5g connection, all traffic for the mobile client should route through the Opnsense firewall.
Here's the toplogy.
192.168.1.x = Internal Wireless Subnet
172.16.1.x = Wireguard Subnet
10.0.1.x = File server Subnet
Currently if the mobile phone is connected to the 5G connection, everything is working fine.
However, when the mobile phone is connected to internal wifi, and the Wireguard connection is sucessfully established, I try to connect apps (file server), and I receive a "TIME_WAIT:TIME_WAIT" message in the session logs.
After reviewing the firewall traffic logs I can see that the traffic is allowed and "pass" status.
However, when comparing a trace route from the mobile to the file server when on the wifi and wg connected, it does not hit the wireguard gateway first, instead I see * * * .. for each hop.
Does anyone have a configuration like this working properly or know how to resolve?
Thanks!
#7
26.1, 26,4 Series / Re: KEA is still a mess IMHO
Last post by RES217AIII - Today at 06:26:48 AMI do not believe KEA is the problem; rather, it is DHCPv6. Centralized address allocation runs counter to the design of IPv6, which is predicated on autonomous address assignment.
However, this presents a challenge for the network administrator who wishes to manage and structure their network in distinct zones.
One has two options: either continue using IPv4 for the internal network—retaining the familiar segmentation based on IP addresses—and restrict IPv6 usage solely to external traffic; or, structure the network not by IP addresses, but by interfaces (VLANs), groups, or segments. Given the immense number of potential addresses enabled by IPv6, one could theoretically assign each individual device its own interface with a unique address (via Prefix Delegation down to the host level).
Those who truly leverage IPv6 manage traffic at the boundaries of their network segments (via firewalls), rather than through the micromanagement of static leases.
However, this presents a challenge for the network administrator who wishes to manage and structure their network in distinct zones.
One has two options: either continue using IPv4 for the internal network—retaining the familiar segmentation based on IP addresses—and restrict IPv6 usage solely to external traffic; or, structure the network not by IP addresses, but by interfaces (VLANs), groups, or segments. Given the immense number of potential addresses enabled by IPv6, one could theoretically assign each individual device its own interface with a unique address (via Prefix Delegation down to the host level).
Those who truly leverage IPv6 manage traffic at the boundaries of their network segments (via firewalls), rather than through the micromanagement of static leases.
#8
26.1, 26,4 Series / Re: A firewalll rule pattern t...
Last post by Patrick M. Hausen - Today at 06:14:47 AMPlease post all details of the rules in question.
#9
Hardware and Performance / Re: 10GBASE-T RJ45 SFP+ Copper...
Last post by pfry - Today at 02:56:09 AMQuote from: BrandyWine on May 07, 2026, 08:00:26 PMIIRC, the ix in kernel tree lists specific models of hardware, much of it being Intel stuff.[...]
I wouldn't expect third-party Atom-based devices to have network interfaces with a vendor-locked NVM... but you never can tell. My one actual Intel 82599 (= x520) is not, but most (but not all) of my x710s are. So as you pointed out, a recommended device is a safe bet. Before Patrick chimes in, there's always fs.com for compatibles.
#10
26.1, 26,4 Series / A firewalll rule pattern that ...
Last post by opnseeker - Today at 02:47:05 AMI have an interface group with a rule that sends all internet traffic over a gateway ( can be the default or VPN ).
The above rule is setup with FirstMatch disabled so that I can have rules in individual interfaces that can override the gateway.
When I have a rule in one of the member interfaces to redirect traffic from a specific ip address over a different gateway with FirstMatch enabled, I expect the traffic from that specific ip address to be sent over the 2nd gateway while the rest use the first gateway (set in the group rule).
But it doesn't work. The traffic that matches the rule in the interface is rejected or blocked. Many times, traffic from the entire interface containing the override rule is blocked.
This seems to happen quite consistently. I have two instances with the above pattern and both have the same issue.
If the override rule blocks traffic instead of redirecting it over a different gateway, it seems to work as expected.
Is this the way it is supposed to work or is it a bug?
The above rule is setup with FirstMatch disabled so that I can have rules in individual interfaces that can override the gateway.
When I have a rule in one of the member interfaces to redirect traffic from a specific ip address over a different gateway with FirstMatch enabled, I expect the traffic from that specific ip address to be sent over the 2nd gateway while the rest use the first gateway (set in the group rule).
But it doesn't work. The traffic that matches the rule in the interface is rejected or blocked. Many times, traffic from the entire interface containing the override rule is blocked.
This seems to happen quite consistently. I have two instances with the above pattern and both have the same issue.
If the override rule blocks traffic instead of redirecting it over a different gateway, it seems to work as expected.
Is this the way it is supposed to work or is it a bug?
