Messages

I recently a small CLI tool I wrote for a client migration to help move ISC DHCP static mappings to Kea reservations using the OPNsense config.xml, as there's currently no way to export IPv6 static mappings via web interface.

I've open sourced it on github (should have releases for Linux, Windows, Mac).

It supports both IPv4 and IPv6 static mappings (including DUID, hostname, domain search, description). I originally wrote it mainly to handle DHCPv6 static reservations, since there isn't currently a GUI export/import path for those.

It's safe by default (reads the input config and writes to a new output file so you can review before importing) and only migrates static reservations, not pools or options.

This is very much a v1 community tool, so please test (pref in a lab) first and take a backup/snapshot before importing. If anyone wants to try it and provide feedback or edge cases, I'd really appreciate it.

See the Github README for command line usage.

• Leave kea disabled for now
• Create the relevant IPv4 and IPv6 subnets in kea
• Download the config (from system settings in GUI)
• Use scan option first to see what will change
• Use the convert option to create a new xml config
• Restore the new config from OPNsense gui
• Check the kea settings everything imported
• Disable isc and enable kea

Tested with 25.7.11:
ISC-DHCP to Kea Migration Tool

This does not work for me by the simple fact that one of my WANs has a /29 subnet. I do not know why your script looks at WANs. Why does it?

Anyway, I had a wind storm, and the multiple power outages caused my old installation that still relied on ISC to become too corrupt to boot. I decided to reinstall, and the drive was good enough to get the config from. Much to my chagrin, nothing was getting addressed with the newly booted system, so I added another network connection to my workstation and manually logged in to the OPNsense install by IP and discovered no ISC. I installed them as plugins, then exported my static leases by csv as others pointed out here, thanks for that folks! I learned how to set up KEA, imported my static DHCP mappings from csv, killed ISC, and started KEA, and it works fine now. I had been wanting to try KEA, and I missed that ISC was going away. In essence, I managed to get my system out of the ditch it was in due to my not paying attention to timelines and changes coming, and it's functioning again, and it will be much easier to reinstall now with KEA. I uninstalled the ISC plugins and removed the dhcpd stuff from the config and loaded it.

I went with three columns. With the firewall PIE chart, if you click on any part of the PIE, a live log for that interface will open in an external tab. The letters to the left of the PIE can be toggled on and off to show or not show on the pie by clicking.

I think I will try three columns. At first, I forgot to lock the layout as it is unlocked at first login after the update, at least for me it was.

 I still do not quite know what to make of the new dashboard so I am feeling it out whether I want to or not. How many columns wide seems to work best for all of you? I have 5 but..... something still doesn't look right.

Edit, I attached an AVIF with three columns.

Still not sure what the deal is with recent kernels and older Intel NICS.

Replaced the motherboard with an identical unit, the 82574L when being assigned to something does the same thing with the same errors and simply will not work. I did not even try to assign the 82579LM on the new board.

I put a quad Broadcom gigabit NIC in a PCIe slot and assigned my two WANs, LAN and WLAN to the four interfaces, works perfectly now so really, a non-Intel NIC solved this.

Right now I am focusing on why the throughput between the WAN and the LAN and WLAN is so slow in the download direction with a twist. I ran iperf3 from a Linux client to a known server iperf3 -c la.speedtest.clouvider.net -p 5209 -P 20 and got this:
[SUM]   0.00-10.00  sec   620 MBytes   520 Mbits/sec  1837             sender
[SUM]   0.00-10.02  sec   607 MBytes   509 Mbits/sec                  receiver

It's a 500/500 fiber connection.

Now running speedtest-cli from that same linux client I get:
Download: 3.40 Mbit/s
Testing upload speed...
Upload: 383.22 Mbit/s

Web browsing and file downloading reflect the speedtest results. The same happens over WLAN.

The 82574L nic that doesn't work anymore doesn't seem to return by reverting.

Not as important but I had to boot the machine to a gparted live image to clean up the drives by wiping the partition tables before the installer would let me install.

I just updated from the previous version.

The Intel NIC that IS working, sort of, an 82579LM, is assigned to LAN, and through it I get full upload bandwidth but download bandwidth is a trickle. Doing a speed test from within the firewall itself in and out of the WAN has no performance issues. That one is a Broadcom NIC.

To sum up, after updating, the 82579LM works well in the upload direction and the 82574L doesn't work at all. I did try reverting the kernel but no change so I brought it back up to date.

I tried reverting the kernel and no change. I did substitute a USB NIC for the down NIC and it has the same lesser download bandwidth but the upload is full 500 mbs I pay for. I ran speedtest-cli within OPNsense and I still get 500/500. I inadvertently bought another motherboard last weekend from eBay without realizing that I already had this one in an older Intel server. I had a Mini-ITX firewall crap out on me last Tuesday morning, both the motherboard and power supply went.

Just for the fun of it, I moved a 347 MB file to the OPNsense machine via SFTP  and then moved it back and it only took a few seconds either way so the one working Intel NIC is not the bottleneck itself.

After applying the 24.1.5_3 and subsequent reboot, my Intel 82574L nic no longer works. The second intel nic uses a different chip and works fine.

root@thor:~ # dmesg | grep em1
em1: <Intel(R) Gigabit CT 82574L> port 0x2000-0x201f mem 0xc1a00000-0xc1a1ffff,0xc1a20000-0xc1a23fff irq 16 at device 0.0 on pci2
em1: EEPROM V2.1-0
em1: Using 1024 TX descriptors and 1024 RX descriptors
em1: Using 2 RX queues 2 TX queues
em1: Using MSI-X interrupts with 3 vectors
em1: Ethernet address: 00:1e:67:19:4d:3c
em1: netmap queues/slots: TX 2/1024, RX 2/1024
em1: link state changed to UP
em1: link state changed to DOWN
em1: Disabling TSO for 10/100 Ethernet.
em1: link state changed to UP
em1: link state changed to DOWN
em1: Disabling TSO for 10/100 Ethernet.
em1: link state changed to UP
em1: link state changed to DOWN

It repeats from there.

Yes, when it goes down the first time and it begins to reboot it stops and does the kernel update then reboots and starts the package update and reboots. Tells me how major of an upgrade this is.

 This update takes a while so if it seems like it's taking a long time, it is but there is nothing wrong. Don't reset or anything, just wait.

You did the right thing.

PHP 8 has had some things changed and not all third party software seems to be ready.


Cheers,
Franco

The 3rd party plugin is no longer available in recent versions anyway. Once I removed those two pieces I haven't had any surprises.

Looks like PHPmailer doesn't fully support PHP 8 yet. Bummer.


Cheers,
Franco

But do we really need it with the config backup mailer gone?

Was I right to remove it? The backup mailer became defunct because your team had questions about security. I see the php mailer and os-mail-backup as residual because once it became defunct with an os upgrade, there was no way to remove it through the gui. If I had downgraded, removed the plugin and then upgraded again at that time I am sure none of this would have happened unless you know better.

My config file no longer has that defunct plugin so if I did a clean install with the new config I doubt the php mailer and the os-mail-backup would ever be installed. I will find out on Saturday as I am building a fanless machine that is in a 1U case that has heatpipe and a huge heat sink on one side. Because of the heat sink it can only take a mini-itx. EPCY 3000 series are in my future. With these cases the power can't be over 95 watts.