Messages

Unfortunately not. We reached out to the Desico Support and they confirmed that OPNsense is tracking the IP/MAC address combination resulting in the observed behavior.

They suggested to increase the DHCP lease time, but that didn't work because the clients only use that as a suggestion and have a max lease time themselves (2 months for macOS and iOS it looks like).

We ended up switching the VLAN (for a BYOD WLAN) with the long Voucher validity to a PSK WLAN, where the PSK gets rotated every few months.

The support also suggested to open an issue on Github since this is where the devs are more active than here. We didn't do that in the end since this was an edge case for us.

Hope this helps a little bit.

We had exactly the same problem with a new OPNsense setup. I settled with using the legacy Tunnel Settings.

Having the same worries, that the legacy Interface will be deprecated at some point, it would be great to have a Azure Basic SKU compatible proposal available in Connections.

Is there a reason why it was changed from the more flexible way of setting the parameters (encryption, hash, dh) seperatly to these predefined combinations?
Besides missing combinations, I personally find it more inconvenient to find the desired combination in that huge list of options.

Hi,

we have installed two DEC2770 in HA last week replacing Sophos XG Firewalls. There are two VLAN interfaces that require a captive portal with voucher authentication. That functionality was also ported to OPNsense.

We have reports that users need to re-authenticate every morning despite having idle timeout and hard timeout set to 0. Vouchers are valid and don't expire.

I have noticed that some MAC addresses have multiple sessions listed but with different IPs (dynamic leases, lease time 8h, Kea DHCP). There is one session for each day (per MAC) regarding "connected since".

Does OPNsense not check the MAC address regarding pre-existing authenticated session? It looks like it rather checks the IP. I can't immagine this to be true since it would render captive portal with DHCP kind of useless and grant any client pre-authenticated access that happens to get a still valid session IP.

Is that normal behaviour or am I missing something?