Messages

You should compare the DHCP Offer packets sent via ISC and KEA to find out of the options inside them match and if the clients receive all of the options they request. If they do, it should not have anything to do with DHCP itself.

You could use Wireshark on a client, or the Packet Capture feature in the OPNsense GUI.

With KEA, all clients receive both an IPv4 and an IPv6 address. However, the latter comes from ISC DHCPv6 and not from KEA. This shouldn't be a problem, because the main Wi-Fi subnet works with WiFi Call, but not the subnets that work with VLANs. From my understanding, everything should be fine as long as the clients have received their IP addresses successfully. So, you can be wrong.

So I suspect that KEA isn't embedded deep enough in the system yet, or that something is missing in the coding. But I have no idea about that, so I'll leave it to Franco and co.

Thanks for your helpful answers.

What do you mean with filtering some features?

DHCP is quite simple, it provides your clients with an IP address to use, as well as with DHCP options which specify certain resources (e.g., default gateway (router), dns server).

Did you set any specific DHCP option to enable Wifi calling?

No, I haven't configured anything special under KEA that could affect WiFi Call, that's the strange thing.

If it works fine with ISC and I've configured KEA correctly (which I have), then KEA must be filtering something or whatever. I just can't understand why KEA acts like this.

But generally, I agree with your statement that DHCP shouldn't filter anything, but rather handle the distribution of IP addresses.

But have you found out /why/ the Wifi calling did not work anymore?

That's the information that is needed to fix something and improve the new alternatives for everybody with the same issues.

No, i don't know why. Maybe KEA is filtering some Features. Also with DNSmasq WiFi Call doesn't work on all three WLAN-Subnets. On this point, it's very frustrating. I would like to continue to rely on OPNsense in the distant future, but if the DHCP alternatives don't work as smoothly as ISC currently does and ISC will no longer be available as a plugin at some point, things will look really bad.

I haven't had good experiences with either Kea or DNSmasq so far.

Recently, I noticed with Kea that WiFi Call only works on the first WiFi subnet of my Wi-Fi subnets (I have three). This is the parent interface. For the other two Wi-Fi subnets, I use VLANs that use the Wi-Fi parent interface.

After switching back to ISC, WiFi Call worked with all three Wi-Fi subnets. I understand that ISC is EOL and that security vulnerabilities will emerge over time, but ISC worked absolutely flawlessly for me, and I find it very unfortunate that it is no longer being developed.

A few words from me on the topic of DHCP. My introduction to OPNsense was ISC DHCP, which I've had very positive experiences with.

Today, however, I tried DNSmasq and was able to set up the appropriate domains, DHCP ranges, and DHCP options for my subnets following the OPNsense tutorial. A positive point is that the wired and wireless network devices (in different subnets) take too long for the DHCP process, whereas with ISC everything runs super quickly and smoothly.

I noticed, especially with my smartphone, that WiFi calling doesn't work with DNSmasq DHCP, but it does work with KEA and ISC DHCP. In general, I noticed that configuring DNSmasq is much more complex than with ISC und KEA and I have to agree with meyergru on that point.

Therefore, I seriously wonder whether ISC DHCP will continue to be usable despite its EOL status, albeit in the form of optional plugins? I also have the question of why HA will be mandatory for KEA DHCP in the future, or have I misunderstood something? Franco said that KEA DHCP is intended for medium to large companies, but why not simply leave HA optional so that regular users can also use KEA DHCP if they want?

In summary, the following question for @Franco:

1. Will ISC DHCP continue to be usable (via optional plugins) despite its EOL status?
2. Will KEA DHCP be usable for regular users even without HA?
3. DNSmasq is already active by default after a fresh installation of OPNsense. Will it be improved (and simplified) in the future?

Maybe post one of your public keys. That's not a problem, hence "public".

SSH-Access via Keys is now working! Thank you! :)

What's the output of

Code Select Expand

ssh -v <username>@<opnsense-ip>?

I'll watch it again tonight, thanks!

- generate a privat/public key pair with e.g. ssh-keygen
- place the public key in the user account via the OPNsense UI

That's essentially all. First step depends on your client. You don't still use Putty, do you? :-) Windows 10 and up come with native SSH.

Thank you. I created the keys and assigned them to the users. However, SHH login didn't work for me with these keys.

Check your system time. Make sure you allow access for SSH via key in emergency cases.

Hey franco,

do you have an easy to do tutorial for SSH-Access via Keys?

Allright, i have start a Feature Request on Github: https://github.com/opnsense/core/issues/8167

Interfaces-Widget on the Dashboard.

No, the subnets will not be sorted alphabetically on my OPNsense. The named LAN-Subnet is under the Management-LAN-Subnet.

On my OPNsense-Appliance are several Interfaces and my "problem" is, that die Interfaces are not sortet. The WAN-Interface is on the bottom, the LAN-Interface is on the top and my Management-LAN-Interface is under the LAN-Interface.

It would be very nice, if we can sort the Interfaces. I don't know about the possibility to code the Interface-Widget, but it would be awesome.

Hello Guys,

i want to deactivate the root-user (for security purposes) in Web-GUI und add a new user with admin privileges. Thats no problem, but via SSH-connection i can't access the default shell-login und can't get su-privileges.

Is it possible, to add the new user to wheel/su-users?

What is the CLI-Command to only remove a Patch?