Messages

kea 2.6.3 supports DHCP lease affinity, but the configuration options haven't yet been exposed in OPNsense GUI

https://forum.opnsense.org/index.php?topic=48462.0

https://github.com/opnsense/core/issues/9094

In current OPNsense 25.7.1_1 release, manually editing the kea config file to add the options, are overwritten / removed when kea service is re-started ( from either OPNsense GUI or cli)...

Thanks for posting this. https://github.com/opnsense/core/issues/9094 is exactly what we would need to address the issue.

Basically, the good news is KEA does expose some tunables to make it behave like ISC with regard to lease recycling. The bad news is, opnsense doesn't expose any of that to the user via the web gui.

What I can picture though, is Kea more aggressively reusing addresses for which the lease has expired and handing them out to a different client.
I would make a protocol with tcpdump when you power on such a client after a couple of days to watch if that is what happens.

That's exactly what's going on. Same clients I've been using for years. I ran tcpdump and fed the pcap into wireshark to look at. KEA is just recycling addresses much more aggressively than ISC.

I don't see an option to change this behavior in the opnsense web gui, so I'd probably have to change something in the KEA conf file.

I'm not sure, but I think that the conf file would get overwritten by opnsense on boot/upgrade/config change, so I'd have to manually change the KEA conf file every time, unless there is a better way to do this? Ideally like a "free-form" "advanced options" that can get appended to the KEA Conf file via the opnsense web gui. I've seen opnsense do this for other things like OpenVPN settings.

Just switched everything over from using ISC DHCP to KEA DHCP. I noticed one annoyance.

Assume IPv4 only and a 1 hour DHCP lease for both ISC and KEA:

In ISC DHCP, If I have a host that I only turn on every few days or so, it will always get the same address from the pool.

In KEA DHCP, If I have a host that I only turn on every few days or so, it will get a different address from the pool.

So for example, if the reservation range is from .100 to .120, one day I may get .101, and another day I might get .100 if I didn't give out any IPs since the last time the machine was on.

I don't want to increase the lease time because I want the client to request a new lease frequently in case something changes.

ISC DHCP was much better about giving previous addresses out. I never exhaust the pool range, so it was pretty much similar to having static entries without needing to make static entries.

With ISC DHCP, I can have the machine off for weeks and still get the same dynamic IP address it gave me  a while back.

Is there any way to make KEA remember IP addresses better and behave like ISC in that regard?

[For people that have this issue:]

I figured it out. You were right franco, thanks. It was an invalid configuration that was allowed through the opnsense validator at some point in the past.

For people that have this issue: Check if you've assigned a static ip address to your wireguard interface. You would be able to see this under Interface->[Your wireguard interface].

If you go to this page and press save without making ANY changes, opnsense will yell at you with an error message. Make the fix (in my case, don't assign a static ip address), then press save, apply the changes, and then restart wireguard. The routes will now get propagated.

I feel like the page should not have had "Static IPv4" as a drop down option if it's a wireguard interface.

Is there anything in opnsense that could find invalid configuration entries like that in the future? I did a health check previous to this and that said everything looked good.

I suspect it's related to commits on:

https://github.com/opnsense/core/issues/7304

Routes are no longer being propagated in Wireguard since the update. Statically adding the routes is a workaround, but there is a bug in opnsense:

Configuration:

Code Select Expand


root@router:~ # cat /usr/local/etc/wireguard/wg1.conf
####################################################
# Interface settings, not used by `wg`             #
# Only used for reference and detection of changes #
# in the configuration                             #
####################################################
# Address =  192.168.10.2/24
# DNS =
# MTU =
# disableroutes = 0
# gateway =

[Interface]
PrivateKey = ...
ListenPort = ...

[Peer]
# friendly_name = ...
PublicKey = ...
PresharedKey = ...
Endpoint = ...:...
AllowedIPs = 192.168.10.1/32,192.168.20.1/24


I can successfully ping the remote "Wireguard transfer net IP"

Code Select Expand


root@router:~ # ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=60.482 ms
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=28.849 ms
^C
--- 192.168.10.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.849/44.666/60.482/15.817 ms


I can't ping the remote network

Code Select Expand


root@router:~ # ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
^C
--- 192.168.20.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss


The remote network is not showing up in the routing table even though its in the "Allowed IPs"

Code Select Expand


root@router:~ # netstat -rn|grep wg1
192.168.10.0/24    link#15            U           wg1


Manually adding the remote network as a static route to the wireguard interface

Code Select Expand


root@router:~ # route add -net 192.168.20.1/24 -interface wg1
add net 192.168.20.1: gateway wg1


Confirming it's there

Code Select Expand


root@router:~ # netstat -rn|grep wg1
192.168.20.0/24    link#15            US          wg1
192.168.10.0/24    link#15            U           wg1


Now I can ping the remote network as it's getting routed through the wireguard interface

Code Select Expand


root@router:~ # ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1): 56 data bytes
64 bytes from 192.168.20.1: icmp_seq=0 ttl=64 time=29.310 ms
64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=30.184 ms
^C
--- 192.168.20.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.310/29.747/30.184/0.437 ms


I would love a better workaround for this until it's fixed as I don't want to be manually adding static routes.

Seeing the same issue here. WG site to site worked fine until I upgraded.

Code Select Expand

# opnsense-revert -r 24.1.4 opnsense

does not fix it.

I noticed that the OS routing table is not showing any of the allowed IPs I have under the Site to Site peer. I can successfully ping the remote "Wireguard transfer net IP" when I SSH into the router but that's about it.

"Disable routes" is Unchecked and I've rebooted multiple times.

I looked at `/usr/local/etc/wireguard/*.conf` and everything looks good.

Performing a traceroute on the router, I can see that the issue is that because the routes from the "Allowed IPs" are not getting propagated to the OS the packets are exiting the WAN / default gateway interface instead of going to the wireguard interface.

Anything under Wireguard->Peers->Allowed IPs should be showing up when I do a `netstat -rn` on the router, correct? I think there was a regression introduced and that's the bug.

I just found this post and figured it would be helpful to people here who are watching it for any updates / progress.

For people who are doing MAC spoofing, the port flapping was caused by a bug that was introduced in 22.1.2.

It's been fixed as of this commit thanks to Franco:

https://github.com/opnsense/core/commit/d19cd6cdbf4da581f71e5483b279f82fb4396bec

[EDIT:]

I changed:

Code Select Expand

if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif, $ifconfig_details))) {

to

Code Select Expand

if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif))) {

and that fixed it as it used $interface with legacy_interface_details() in get_interface_mac() because $ifconfig_details is null.

Wow, I can't believe mac spoofing has been broken that long and nobody complained! I guess nobody uses that feature.

EDIT:

Saw your commit here:

https://github.com/opnsense/core/commit/d19cd6cdbf4da581f71e5483b279f82fb4396bec

Thanks.

Code Select Expand

    /*
     * Don't try to reapply the spoofed MAC if it's already applied.
     * When ifconfig link is used, it cycles the interface down/up,
     * which triggers the interface config again, which attempts to
     * spoof the MAC again which cycles the link again...
     */
    if (!empty($wancfg['spoofmac']) && strcasecmp($wancfg['spoofmac'], get_interface_mac($realhwif, $ifconfig_details))) {
        mwexecf('/sbin/ifconfig %s link %s', [$realhwif, $wancfg['spoofmac']]);
    }

I believe this is the code that keeps calling ifconfig and cycling the interface up and down. New logic was added in the conditional that broke this check:

https://github.com/opnsense/core/commit/13388839e7e

Even the comment above it describes the issue that is popping up.

I tried a few different versions and discovered that it works on 22.1.1. I believe it's one of these two commits that broke mac spoofing:

https://github.com/opnsense/core/commit/13388839e7e
https://github.com/opnsense/core/commit/84cd38adb558

My bet is on the former since it specifically has to do with mac spoofing.

I'm using the latest opnsense (21.7) and I have a Deciso DEC850 and decided to try out specifying a custom MAC on the WAN port.

When I do this, the WAN port flaps. The interface goes up then down, then up, then down. It continues to do this until I remove the MAC spoof and then it starts working normally again.

Has anyone ever seen this issue before?

I installed the intel-em-kmod package / driver from FreeBSD but no luck, it still flaps.

I would be curious if someone who has a DEC800 series router could try to specify a custom MAC address on igb0 and let me know if it flaps.

I am running the latest Opnsense and decided to run zpool upgrade. Here was the result:

root@router:~ # zpool upgrade zroot
This system supports ZFS pool feature flags.

Enabled the following features on 'zroot':
  userobj_accounting
  encryption
  project_quota
  allocation_classes
  resilver_defer
  bookmark_v2
  redaction_bookmarks
  redacted_datasets
  bookmark_written
  log_spacemap
  livelist
  device_rebuild
  zstd_compress
  draid

Pool 'zroot' has the bootfs property set, you might need to update
the boot code. See gptzfsboot and loader.efi for details.

Is there anything I need to do, or can I reboot? I am worried that I'm going to brick my opnsense install by not updating "the boot code".

Well, this is news to us too so we asked Insyde what this is all about. I'll report back as soon as we know.


Cheers,
Franco

Did Insyde get back to you guys?