Messages

OPNsense 25.1.10 aarch64 packages and sets released.

OPNsense 25.1.9 aarch64 packages and sets released. Includes hotfix 25.1.9_2.

OPNsense 25.1.8 aarch64 packages and sets released. Includes hotfix 25.1.8_1.

After a successful handshake, the remote peer remembers the IP address and port of your local peer. It keeps sending packets to this address / port until you connect from a different address / port.

OPNsense 25.1.7 aarch64 packages and sets released. Includes hotfix 25.1.7_2.

[Update 2025-05-26]
Hotfix 25.1.7_4 released.

If you have a public IPv4 subnet (like a /28) and not just a single address, you can balance outbound NAT connections across multiple addresses. That's especially useful if you have many clients.

The 'Pool Options' setting specifies how connections are balanced.

Cheers
Maurice

IPv6 over PPPoE uses Router Advertisements and / or DHCPv6 for addresses, prefixes, DNS and other information. PPP itself (IPV6CP to be specific) is only used for setting up the link (which seems to work according to your log).

So you should take a look at the DHCPv6 logs and the WAN interface information.

If your ISP uses neither SLAAC nor DHCPv6 for assigning a WAN address, you can use the "Optional prefix ID" setting to generate a WAN address from the delegated prefix.

Cheers
Maurice

Got it. So currently, dnsmasq can't do downstream PD at all (correct?) and Kea can't handle dynamic prefixes?

ISC it is. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

Cheers
Maurice

I gave Kea a try by replicating my ISC DHCPv6 configuration.

ISC (works): PD range from ::80:0:0:0:0 to ::f0:0:0:0:0, PD size 60.
Kea (new): Prefix ::80:0:0:0:0, prefix length 57, delegated length 60.

But Kea doesn't merge the range and instead literally leases 0:0:0:80::/60 to 0:0:0:f0::/60.

Any hints appreciated.

Cheers
Maurice

OPNsense 25.1.6 aarch64 packages and sets released. Includes hotfix 25.1.6_2.

[Update 2025-05-10]
Hotfix 25.1.6_4 released.

Other states do indeed get killed on failback. I tested this with an SSH session which gets reset when the primary WAN goes up again.

The default route successfully fails back to the primary WAN. WireGuard doesn't seem to be bothered though.

There is no firewall rule which allows incoming connections to the affected wg instance. Also, the secondary WAN is an LTE connection and the ISP blocks all inbound connections anyways.

Unfortunately, doesn't work for me for WireGuard. It still sticks to the secondary WAN despite the primary WAN going up again. Only restarting WireGuard forces it to fail back to the primary.

Probably not a firewall issue, but a WireGuard issue?

Not using gateway groups, but default gateway switching.

Just to make sure it's actually a WAN issue (not a LAN issue), I'd try a ping test from OPNsense itself. Source address: LAN interface address, destination address: something on the Internet. This won't work without ndproxy, but doesn't depend on a client in the LAN.

I made sure the interfaces are not in promiscuous mode when testing (no packet capture running).

Are you only testing with physical Intel NICs? So far, I've done all my testing with VMs. Maybe the driver plays a role in this... ND offloading? Just a guess.

I did build ndproxy 3.2.1402000_2 and os-ndproxy 1.1 and can't reproduce the behaviour. It just works, without enabling promiscuous mode, joining a multicast group or enabling promiscuous mode for multicast packets (allmulti).

Did you try a ping from OPNsense itself, setting the source address to the LAN interface address (2003:a:1704:XXXX:XXXX:eaff:fe01:3db4)?

Cheers
Maurice

Code Select Expand

hn0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: LAN (lan)
        options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
        ether 00:15:5d:d2:76:3c
        inet6 fe80::215:5dff:fed2:763c%hn0 prefixlen 64 scopeid 0x5
        inet6 fd01:2345:6789:abcd::a prefixlen 64
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=121<PERFORMNUD,AUTO_LINKLOCAL,NO_DAD>

hn1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: WAN (wan)
        options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
        ether 00:15:5d:d2:76:87
        inet6 fe80::215:5dff:fed2:7687%hn1 prefixlen 64 scopeid 0x6
        inet6 fd01:2345:6789:abcd:215:5dff:fed2:7687 prefixlen 64 autoconf pltime 14400 vltime 86400
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

WireGuard is essentially stateless and there are no "clients" and "servers", just peers. As long as you don't explicitly disable the WG instances at the remote sites, they're always up. Any traffic directed towards the allowed IPs configured at the remote WG instances will be sent through the tunnels. It doesn't matter whether a WG client on your local site is running or not.

Cheers
Maurice