Messages

1

24.7 Production Series / Re: puzzled by the ISC/KEA DHCP direction

« on: October 03, 2024, 02:18:27 pm »

This topic was already referring to that PR in a way... The topic never stated that it wasn't possible to register static mappings.

2

24.7 Production Series / Re: puzzled by the ISC/KEA DHCP direction

« on: August 01, 2024, 02:58:54 pm »

Thanks a bunch for the reply.

Take the main DNS services Dnsmasq and Unbound..

I worked for Tucows and we used PowerDNS and DNSdist I am not too familiar with dnsmasq and Unbound, except that I am using pi-hole which uses dnsmasq. Btw, my pi-hole queries OPNsense for local resolution.

When it receives a SIGHUP, dnsmasq clears its cache and then re-loads /etc/hosts and /etc/ethers and any file given by --dhcp-hostsfile, --dhcp-hostsdir, --dhcp-optsfile, --dhcp-optsdir, --addn-hosts or --hostsdir. The DHCP lease change script is called for all existing DHCP leases. If --no-poll is set SIGHUP also re-reads /etc/resolv.conf. SIGHUP does NOT re-read the configuration file.

Well, in this case a re-read of the config file is not necessary. Since I am not too familiar with the 2 DNS servers you mentioned I thought the static leases are put into the config. But it seems other files can be read on SIGHUP.

So adding dns data from the DHCP should be hot-reloadable (via SIGHUP) according to the text above.

Unbound project is how old?

I don't think that it matters how old SW is. It's always possible to re-work core features when the market requires it. 30 years ago nobody was too concerned about having to restart a service. These days people expect easy config management, HA, and dynamic updates.
Old code does not necessarily mean dumb design. And if the design was fairly good, extending the code to support something like this shouldn't be too complicated.

Without a way to reload, a stop/start/restart will always be counter-productive with DNS servers.

!00% agree with you there. However, in a DNS cluster this should be less of an issue.

The import is automatic, but requires a restart of the DNS service when this static lease list is modified.

This certainly sucks. One can only hope that the DNS server will improve in that regard.

Business wise most likely not. Much of that world is hooked on Microsoft anyway.

I agree to disagree on those 2 points. (Although any further discussion on that part, I'd rather do with a few beers and in person.)

And if you look at how rigid DNS servers are built you quickly see that they have no need for much dynamic shenanigans however useful an invididual user might see this.

It all depends on the DNS server. As I mentioned before, PowerDNS and DNSdist to the rescue. ;-)

3

24.7 Production Series / Re: puzzled by the ISC/KEA DHCP direction

« on: August 01, 2024, 01:56:59 pm »

> If you edit static mappings and use DHCP registration in DNS services Unbound or Dnsmasq simply restart your DNS service at the earliest convenience to allow your new static lease(s) to be resolved by clients.

I know this is not an OPNsense issue, but I don't understand why these DNS servers don't support a reload of the config w/o restarting the service. There is no logical reason to require a restart to read a new config or add new dns entries these days.

> With Kea you can automate the lease creation as well so in theory you don't even have to open the GUI to do it compared to ISC which will likely remain a static PHP page without API.

This is great news. Is that static lease then added to the DNS? If not, does the DNS have an API to do that? In that case it doesn't matter whether one has to make 1 or 2 API calls. I will certainly use this feature when I migrate to KEA in the future (when ISC is removed or feature parity exists). I always hoped this was possible with ISC.

I still believe that registering DHCP leases (dynamic and static) into the DNS should be considered a basic feature (when looking at pretty much any router out there).

4

24.7 Production Series / Re: puzzled by the ISC/KEA DHCP direction

« on: July 29, 2024, 04:33:10 pm »

I still would appreciate if a dev could chime in. Am I so off base, asking for a feature that every router out there has?
The issue is that I remember that a dev mentioned that KEA might never reach feature parity with ISC.

I don't need this now. What I would kindly ask though is that before ISC is removed from OPNsense, a true replacement is available and working. And I do include registering DHCP hostnames in the DNS subsystem in this conversation.

5

24.7 Production Series / Re: puzzled by the ISC/KEA DHCP direction

« on: July 28, 2024, 10:34:14 pm »

I do understand that KEA is a bare DHCP server.

However, when I use an ASUS router or a fritzbox (or any router out there) and use the DHCP, the hostnames are registered and thus reachable via its DNS. I think I should be able to hope for the same functionality in OPNsense.

I seriously do not want to setup my own DHCP/DNS in my home network when it was working fine until now with ISC DHCP and unbound.

6

24.7 Production Series / Re: puzzled by the ISC/KEA DHCP direction

« on: July 28, 2024, 01:26:01 pm »

> there is no integration available in ISC DHCP / Kea and Unbound for this

What are you referring to? I was talking about multiple things. The discussion you referenced does not apply to any of them. Or at least I don't see the connection.

7

24.7 Production Series / puzzled by the ISC/KEA DHCP direction

« on: July 28, 2024, 01:05:09 pm »

In the release notes for 24.7, I found this:

ISC DHCP will no longer reload DNS services on static mapping edits. This is for feature parity with Kea DHCP and avoiding cross-service complications. If you expect your static mappings to show up in a DNS service please restart it manually.

I am a bit puzzled as to how the DHCP system is handled. The only feature that was missing for ISC DHCP to assign/remove static mappings via an API. (It's important when using Terraform and Ansible to deploy VMs.)

Then KEA came along with half of the features of ISC missing and without an upgrade path. I have at least 50 static mappings that I would have to manually enter in KEA, so this makes a migration not a happy one. Especially if you need features in ISC that are no available im KEA.

The fact that a reload is done when applying changes to static mappings is a basic feature. This should not be removed from ISC but added to KEA.

I wrote this post, because I do not understand the direction of development. It makes no sense to me.

DHCP is a crucial component of a Firewall/Router and it seems to me that not only the replacement is worse when it comes to features and usability, the "old" system is now made worse to be as bad as KEA.
Can someone please explain the logic of this?

8

General Discussion / Re: Idea for next version's codename

« on: May 03, 2024, 09:43:14 am »

Funny, it was tortoise at first, but I thought that turtle is a more common term. But I agree, turtoise is better.

9

General Discussion / Re: Idea for next version's codename

« on: May 03, 2024, 08:33:22 am »

They just came to mind when I saw the last 2 code names, because those 2 somehow escaped me. I really liked Restless Roadrunner.

10

General Discussion / Idea for next version's codename

« on: May 03, 2024, 06:32:06 am »

Tenacious Turtle
Tantalizing Tarantula
Timeless Tiger

Edit: Tenacious Tortoise

11

24.1 Legacy Series / Re: 24.1 - DHCP server moves to KEA - implications?

« on: January 29, 2024, 06:58:40 am »

There were no plans for migrating the existing DHCP data to Kea as far as I now.

This certainly is a deal breaker. I do have more than 50 DHCP Static Mappings on about 20 VLANs. I am not really inclined to recreate all of them manually.

12

Virtual private networks / Why is disfunctional gw always recreated when deleted?

« on: July 14, 2023, 07:52:46 pm »

I created a VPN client connection (OpenVPN for NordVPN) IPv4 only. Please note that NordVPN is just an example. It could be any OpenVPN client connection. It's just one I have access to.

I never created a gateway manually, but for some reason 2 gateways show up under System -> Gateways -> Single:

WAN_VPN_NORDVPN_VPNV4
WAN_VPN_NORDVPN_VPNV6



Both have set WAN_VPN_NordVPN as the interface.

Whenever I delete WAN_VPN_NORDVPN_VPNV6, it shows up again and is set as (active), even though I am not using IPv6 at all, and neither are any IPv6 addresses assigned. And the OpernVPN connection is IPv4 only.
Additionally the checkbox at the beginning of the line is gone.

There are so many things that make no sense:

Where are these gateways coming from? I rather set up the one I need manually (namely the IPv4 one WAN_VPN_NORDVPN_VPNV4).
Why is there a GW for IPv6 even though the NordVPN connection is setup as IPv4 only?
Why can't I delete a disfunctional gateway that has obviously no use at all.

I can just take it offline or didable it. But I want to know what is going on, because none of this makes sense to me.

Can someone please shed some light on this?

P.S.: Seeing that there hasn't been any replies, did I put my question in the wrong category or am I the only one who has ever seen this weird behavior?

13

High availability / Re: migrating from single FW/router to HA setup

« on: June 14, 2023, 05:00:52 am »

Thanks for the reply. I appreciate it.

1. You have to build another node with exact copy of interfaces as on first (exact means exact OPTx assignment, since OPTX definitions are used during the synchronization phase (copying the rules to second node).

I have no way to assign the interface IDs myself, since they are chosen automatically when creating an interface. There is no way to do that manually.

Unless a restore keeps the same assignments, this is impossible. Otherwise a backup and restore should do the trick.

2. Defining a new set of IP address on every pair of interfaces, defining CARP VIP on all interfaces with the IP address previously used on the single firewall interfaces (so yiu do not have to change Default gateways on the network nodes.

Here lies the issue. I have N (about 25) VLANs. This means I have to change 2xN interfaces and create N CARP VIP entries.

Then I have to change all firewall rules, because the FW now has to use the virtual interfaces, which are using new interface IDs.

I also use OpenVPN (out) and Wireguard (in/out). I certainly would have to figure out how to make this work as well.

3. Defining the High Availability on main and second node, and defining all the synchronization (XMLRPC Sync) you need. This will copy the chosen definitions  to the second node.

Yes, this should not be too complicated.

Thanks for the link, but I actually had read that one before I posted this topic.

Unfortunately all this is a moot conversation unless there is an answer to my first question.
I can't be the only one who has a cable modem, can I? Additionally, anyone who uses OPNsense is most likely using the modem in bridged mode, so someone should have an answer to my question.

14

General Discussion / Re: btop - install pkgs from FreeBSD repo?

« on: May 15, 2023, 10:06:33 pm »

I am sorry, but I think you misunderstood what I was doing. I did not install a dev env on my firewall.
I setup a FreeBSD 13.1 VM and installed the dev env there. Btw, this took about 15 minutes.
Then I compiled btop according to the README in the btop git repo. And there I ran into a few issues, because the STATIC=true option did not work, which is why I had to change the Makefile. Compiling btop took less than 30 seconds, so I have no idea why you are talking about hours.

Either way, for people who do not want to install gcc on their firewall, I created a binary that has the 2 libraries that come with gcc statically linkeed into btop.

I hope you understand now what I was doing and why.

15

General Discussion / Re: btop - install pkgs from FreeBSD repo?

« on: May 14, 2023, 08:16:02 pm »

If you compile it the way you do, you will have to install gcc on your firewall to meet the dependency requirements.

You actually have to tweak the Makefile and set a few env vars to create a binary that only has the libgcc and libstd++ statically linked. Otherwise you run into linker errors if you only try to set STATIC=true.

But this is why I provided a link to the compiled binary that works as is on the firewall.