Messages

We're using Kea DHCP server.  The Valid Lifetime set on the Settings tab is sufficient for most of our subnets.  However, there are a couple subnets that require a shorter lease time.

Which Option code, if any, overrides the value set on the Settings tab?  There isn't a code that says "valid lifetime".  The closest I found is "renewal time [58]", but because this is a production router, I cannot do trial and error.  Is "renewal time [58]" the correct code to overrride default valid lifetime?

UPDATE:
The code I mentioned above is for IPv4.  I also need the correct code for IPv6.  Please and thanks.

kea claims to support per subnet valid-lifetime config option https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#shared-networks-in-dhcpv4, however isn't exposed in OPNsense UI, perhaps consider raising a new feature request ?

It's been requested before here -> https://github.com/opnsense/core/issues/7592

Thank you, yes i forget that step, working now....

OPNsense 26.1.5-amd64 openvpn client instance VPN: OpenVPN: Instances TLS static key = TLS auth only, is absent from UI

This breaks my NordVPN connections, with error of TLS handshake failure, as below

TLS Error: TLS handshake failed

The option, TLS static key = TLS auth only, is required for NordVPN connection to authenticate and get the tunnel UP

OPNsense 25.7.11_9-amd has the TLS static key = TLS auth only, and NordVPN tunnels come up just fine.

Seems like an oversight / bug to me...

When will it be fixed ?

Is there a mechanism to clean out v4 leases?

I believe there was some talk on the forum about adding such a feature to the KEA webGUI part of OPNsense :)

And printers for several decades now, use SSDP | Bonjour mDNS protocol to advertise their IP address and service information, and modern OS also learn from both SSDP and mDNS propagation advertisements, to dynamically learn printer IP address and service to connect to.

Which is horrible and luckily can be disabled via the webGUI of my printer to avoid unnecessary Multicast traffic ;)

And everything works just fine without it too! LOL!

Bonjour is inherent part of the Airprint protocol developed by apple, and is widely used my millions of users worldwide...the volume of mDNS traffic from Bonjour  is minuscule / insignificant, and if it was as 'horrible' as you claim, then apple, Microsoft and Linus  would have abandoned Airprint/mDNS support long ago...but they haven't, as it's been a huge overwhelming success! significantly simplifying adding a printer to a network for the masses...

For both devices that are always on, and devices that are intermittently on, but reconnect before lease affinity expires, zero need for dhcp reservations, it just works thanks to lease affinity.


And printers for several decades now, use SSDP | Bonjour mDNS protocol to advertise their IP address and service information, and modern OS also learn from both SSDP and mDNS propagation advertisements, to dynamically learn printer IP address and service to connect to.


Once the DHCP lease is assigned, it stays assigned ( reserved ) for the affinity lease period when devices are offline, and re-allocated when device connects, and re-allocated when DHCP renew event occurs..

The only time this would not work, is when the dhcp pool has insufficient number of leases, for the number of devices connecting to that particular L2 segment...or for device that do a DHCP release upon shutdown, i've only found one device that behaves this way...

kea dhcpv4 has the concept of lease affinity, which i use instead, so that returning dhcp clients can obtain the same IP lease, even after the lease has technically expired, but lease affinity not yet expired, it works great, and zero need to mess around with reserved DHCP leases...

Kea DHCPv4 Affinity lifetime is already exposed in OPNsense GUI

Defines in seconds for how long a returning client will be able to retrieve the same lease.

I have kea dhcpv4 lease time = 86400 seconds == 24 hours
and Kea DHCPv4 Affinity lifetime = 2592000 seconds == 30 days.

It was not removed, I just told you how you can have it.

Also, you can still use the legacy rules for as long as you like, they're not going anywhere for a while.

highlighted in yellow is the button that is removed in 26.x, your simply trying to dodge the question !

You can also see it at all times in the new release, just toggle the "Inspect" and the "Tree View" buttons. They are sticky too so a reload will always show all rules and folders.

why was the automatic generated rules expand button removed in 26.x ?

I wouldn't call it a regression because you don't need to see them all the time, and it improves performance a lot by only collecting them when "Inspect" is active.

I rather have a more response GUI for day to day operation than seeing everything all the time.

In prior release;

1. Could see the automatic generated rules "display" button all the time, so the automatic generated rules wasn't showed all the time, as you needed to click the automatic rules button for then to show in GUI, but this button has disappeared in 26.x, so the option is removed. It is a user interface regression for zero apparent benefit.

2. never had any performance issue what so ever.

Hi hharry

The new GUI for the firewall rules is unfortunately a bit confusing and will certainly need some further optimization. To see the automatic rules, simply click the 'Inspect' button.

Thanks, it is a definite GUI regression, in prior 25.7.11 release could see the automatic generated rules all the time, not in inspection mode.

LAB sand box test environment upgraded from 25.7.11 to 26.1_4-amd64, and now unable to view automatic rules in new firewall.

Under the old firewalls rules, can see all the automatic rules applied, i used the rules migration feature, and cannot view any of the automatic generated rules in the new firewall rules...

Howto view automatic generated rules in new firewall rules ?

kea 3.0.2 supports DHCP options

https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#standard-dhcpv4-options
https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#dhcpv4-private-options
https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#dhcpv4-vendor-specific-options

OPNsense GUI has not been developed to make options configuration for kea

i can confirm the OP's point here, i as able to re-create the issue in LAB, can clearly see the received PPPoE servers MRU = 1472, however whilst OPNsense LCP ack's the PPPoE servers MRU,  OPNsense then just defaults to a PPPoE interface MTU = 1492


Below can clearly see the PPPoE servers LCP advertised MRU = 1472, which OPNsesne LCP acks.

PPPoE server MAC address in below tcpdump == 00:0c:29:2a:de:ad

OPNsense PPPoE client interface MAC address == 00:0c:29:55:0d:8a

Code Select Expand

root@OPNsense_LAB:~ # tcpdump -nevi vmx0
tcpdump: listening on vmx0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:05:48.180841 00:0c:29:55:0d:8a > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 36: PPPoE PADI [Host-Uniq 0x40517C3B00F8FFFF] [Service-Name]
08:05:48.201268 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE D (0x8863), length 74: PPPoE PADO [AC-Name "VYOS03"] [Service-Name] [AC-Cookie 0x7A9041E0E45617BFDABF9F34EF35229B4B7E454C99D2D63C] [Host-Uniq 0x40517C3B00F8FFFF]
08:05:48.201293 00:0c:29:55:0d:8a > 00:0c:29:2a:de:ad, ethertype PPPoE D (0x8863), length 74: PPPoE PADR [Host-Uniq 0x40517C3B00F8FFFF] [AC-Cookie 0x7A9041E0E45617BFDABF9F34EF35229B4B7E454C99D2D63C] [AC-Name "VYOS03"] [Service-Name]
08:05:48.221657 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE D (0x8863), length 60: PPPoE PADS [ses 0x180] [AC-Name "VYOS03"] [Service-Name] [Host-Uniq 0x40517C3B00F8FFFF]
08:05:48.221879 00:0c:29:55:0d:8a > 00:0c:29:2a:de:ad, ethertype PPPoE S (0x8864), length 36: PPPoE  [ses 0x180] LCP (0xc021), length 16: LCP, Conf-Request (0x01), id 1, length 16
        encoded length 14 (=Option(s) length 10)
          MRU Option (0x01), length 4: 1492
          Magic-Num Option (0x05), length 6: 0xcb840b5a
08:05:48.221932 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE S (0x8864), length 60: PPPoE  [ses 0x180] LCP (0xc021), length 21: LCP, Conf-Request (0x01), id 137, length 21
        encoded length 19 (=Option(s) length 15)
          Auth-Prot Option (0x03), length 5: CHAP, MD5
          MRU Option (0x01), length 4: 1472
          Magic-Num Option (0x05), length 6: 0x5a0802f3
08:05:48.222042 00:0c:29:55:0d:8a > 00:0c:29:2a:de:ad, ethertype PPPoE S (0x8864), length 41: PPPoE  [ses 0x180] LCP (0xc021), length 21: LCP, Conf-Ack (0x02), id 137, length 21
        encoded length 19 (=Option(s) length 15)
          Auth-Prot Option (0x03), length 5: CHAP, MD5
          MRU Option (0x01), length 4: 1472
          Magic-Num Option (0x05), length 6: 0x5a0802f3
08:05:48.242128 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE S (0x8864), length 60: PPPoE  [ses 0x180] LCP (0xc021), length 16: LCP, Conf-Ack (0x02), id 1, length 16
        encoded length 14 (=Option(s) length 10)
          MRU Option (0x01), length 4: 1492
          Magic-Num Option (0x05), length 6: 0xcb840b5a



Operationally the PPPoE interface MTU on OPNsense still defaults to 1492, despite LCP ack'ing the remote PPPoE servers MRU = 1472

Code Select Expand

root@OPNsense_LAB:~ # ifconfig
pppoe1: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN (wan)
        options=0
        inet 192.168.40.1 --> 192.168.40.254 netmask 0xffffffff
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


OPNsense not handling any vlan's in above example!, all vlan handling performed in ESXi vSwitch port groups...

Most vendors consider such behavior as a clear and repeatable defect, needing fixing !

Kea is a relatively new introduction to opnsense, i'm not sure why kea-dhcp-ddns hasn't been implemented, but kea supports it...over here -> https://kea.readthedocs.io/en/kea-3.0.1/arm/ddns.html, nor do i know if it's already on the opnsense roadmap....as this question had been requested before, but closed without implementation...

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

You'll likely get push back for native kea ddns support, along the lines to use unbound DNS, for the DDNS component...

AFAIK, the dashboard gateways widget is meant to display the gateway IP address being monitored.

You should check in Interfaces: Overview for the gateway ip address...also check in System: Gateways: Configuration, ideally your Monitor address should = interface gateway address.

If the widget still reporting incorrect interface gateway IP address, you could also try deleting the dashboard gateway widget, then re-adding it to see if it clears up....