Messages

So just to be sure :

After logging into your OPNsense via SSH and after succesfull outcome of the procedure the file integrity of the system should be restored to safely enough reboot into the latest version ?

If so : NICE!!! :)

Yes, the opnsense-bootstrap script uninstalls all packages and re-installs them afresh.  You can select the major release branch to install, or can select snapshot mode to install from the latest development branch.  The process is pretty much automated and quite sleek.  :-)

The alternative would be to perform a fresh install, reformatting the drive.  I was about to do this, just as Franco pointed out to the opnsense-bootstrap handy tool.

Thank you for the suggestion to use opnsense-bootstrap.  It completed without any problems.  An update after it rebooted installed the following packages:

Code Select Expand

New packages to be INSTALLED:
        cpu-microcode-amd: 20251202
        cpu-microcode-rc: 1.0_2
        libpci: 3.14.0
        os-cpu-microcode-amd: 1.1
        pciids: 20251206
        x86info: 1.31.s03_1
The SoC on this box does not have any microcode applicable for it.  All seems to work fine now.

Thanks again for your help! :-)

I've upgraded in situ rather than re-install 26.1 and the upgrade completed.  There was a glitch and a warning, so I am not sure the upgrade went as intended.

The upgrade was stuck at this point for quite a few minutes:

Code Select Expand

[165/179] Reinstalling unbound-1.24.2...
===> Creating groups
Using existing group 'unbound'
===> Creating users
Using existing user 'unbound'
[165/179] Extracting unbound-1.24.2: .......... done
[166/179] Reinstalling wpa_supplicant-2.11_7...
[166/179] Extracting wpa_supplicant-2.11_7: .......... done
[167/179] Reinstalling x86info-1.31.s03_1...
[167/179] Extracting x86info-1.31.s03_1: ....... done
[168/179] Reinstalling os-cpu-microcode-amd-1.1...
[168/179] Extracting os-cpu-microcode-amd-1.1: .. done
Reloading firmware configurationPerhaps I should have waited longer before I entered Ctrl+c:

Code Select Expand

^C
Launching the init system...[169/179] Upgrading zip from 3.0_4 to 3.0_5...
[169/179] Extracting zip-3.0_5: .......... done
[170/179] Reinstalling zstd-1.5.7_1...
done.
Initializing...[170/179] Extracting zstd-1.5.7_1: .......... done
.......done.
[171/179] Reinstalling boost-libs-1.89.0_1...
[171/179] Extracting boost-libs-1.89.0_1: .......... done
[172/179] Reinstalling curl-8.17.0...
[172/179] Extracting curl-8.17.0: .......... done
[173/179] Reinstalling kea-3.0.2...
[173/179] Extracting kea-3.0.2: .......... done
[174/179] Upgrading php83-curl from 8.3.28 to 8.3.30...
[174/179] Extracting php83-curl-8.3.30: .......... done
[175/179] Reinstalling strongswan-6.0.3_1...
[175/179] Extracting strongswan-6.0.3_1: .......... done
[176/179] Reinstalling syslog-ng-4.10.2...
[176/179] Extracting syslog-ng-4.10.2: .......... done
[177/179] Upgrading opnsense from 25.7.11_9 to 26.1.1...
[177/179] Extracting opnsense-26.1.1: .......... done
configd not running? (check /var/run/configd.pid).
Resetting root shell
Updating /etc/shells
Unhooking from /etc/rc
Unhooking from /etc/rc.shutdown
[Snip ...]
There was also a warning as it was rebooting:

Code Select Expand

>>> Invoking start script 'freebsd'
Sync KEA DHCP config...done.
Starting kea.
INFO/keactrl: Starting /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf
INFO/keactrl: Starting /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf
Starting hostwatch.
error: the argument '--user <USER>' cannot be used multiple times

Usage: hostwatch [OPTIONS]

For more information, try '--help'.
/usr/local/etc/rc.d/hostwatch: WARNING: failed to start hostwatch
>>> Invoking start script 'syslog'
>>> Invoking start script 'carp'
>>> Invoking start script 'cron'
Starting Cron: OK


>>> Invoking start script 'openvpn'
>>> Invoking start script 'sysctl'
Service `sysctl' has been restarted.
>>> Invoking start script 'beep'
Root file system: zroot/ROOT/default
Sat Feb  7 12:36:06 GMT 2026

*** OPNsense.internal: OPNsense 26.1.1 (amd64) ***The hosts on the LAN were able to receive IPv4/6 addresses and these guys are running at present:

Code Select Expand

:~ # ps axf | grep watch
10243  -  Is     0:00.00 daemon: /usr/local/opnsense/scripts/kea/kea_prefix_watcher.py[10246] (daemon)
10246  -  S      0:01.09 /usr/local/bin/python3 /usr/local/opnsense/scripts/kea/kea_prefix_watcher.py /var/db/kea/kea-leases6.csv (python3.11)
72154  -  Is     0:00.00 daemon: /usr/local/opnsense/scripts/routes/gateway_watcher.php[72212] (daemon)
72212  -  S      1:04.51 /usr/local/bin/php /usr/local/opnsense/scripts/routes/gateway_watcher.php interface routes alarmGiven the above was the upgrade successful?  Is there anything I should take care of before I try to reboot?

I fixed the link.

Thank you for sharing your hard work.  Amazing write up!  :D

I have a permanent 48 and a different 64, from which I have allocated PDs/subnets to two separate LANs.  The LAN NICs are configured with a corresponding static 64 each.  I don't host public services, so some of your good advice won't be applicable to my setup.  Thanks again.

Any idea why on the KEA leases table GUI, IPv6 addresses leased to LAN devices showed up as belonging to the WAN interface until I rebooted the router?

Other than this little glitch, the KEA DHCPv4 and v6 services are both working faultlessly so far.

DHCPv6 works only for some clients - and sometimes, it is only being used to fetch DNS info, not IPs nor routes.

I was only testing Dnsmasq local address resolution for IPv4 - I had no IPv6 reserved addresses configured, only subnets for PD.  The DUID and/or MAC address of the client did not prove effective to allow local address resolution for IPv6 at all and for IPv4 it only worked some times.

Take a look at this for a more in-depth explanation and a remedy.

When I click on your link I don't arrive at the correct page.

A quick update on progress.

I had another go at configuring Dnsmasq.  DHCPv4 just works^(TM).  DHCPv6 does not work with the phones, but works with PCs.  There seems to be an issue related to the current phone firmware, which solicits via DHCPv6 an IPv6 address only at phone boot time and does not seek to renew it thereafter.  For some reason, the phones do not pick up an IPv6 address on this initial transaction with Dnsmasq and they end up with no IPv6 address at all - unless I have configured their firmware to use SLAAC.  I have set radvd to 'Assisted' and works fine with ISC and KEA.  I have not tried to configure RA on Dnsmasq itself.  I rebooted the phones with ISC DHCPv6 enabled (Dnsmasq disabled) in order for them to obtain an IPv6 address, then disabled ISC and enabled Dnsmasq to see what happens.  The Dnsmasq DHCPv6 does not recognise the IPv6 already allocated to the phones and continues to advertise different IPv6 addresses to them non-stop once a second flooding the logs.

The resolving of local domain names with Dnsmasq has been a hit & miss affair.  When I connect a host with a reserved IP address to the router, it obtains its address and its local domain name can then be resolved.  A few hours later I get NXDOMAIN responses from the router on port 53, while it resolves successfully the host's name on port 53053.  Restarting unbound didn't fix it.  This is not a major issue for my simple use case with less than two dozen hosts at any time and LAN servers/printers having reserved addresses anyway.  Perhaps setting lease renewal in more frequent intervals would address this local DNS issue, but given the above I decided to move on from Dnsmasq for now.

I then tried to set up KEA DHCPv4 and DHCPv6 with no DNS for local addresses. This was overall an easier and quicker setup than Dnsmasq for me.  DHCPv4 works reliably, leases are renewed regularly and more frequently than Dnsmasq.  KEA DHCPv6 has no problem allocating IPv6 addresses to the phones when they boot and extending their leases (every 20 minutes) on the same IPv6 addresses they obtained initially without fuss.

The only thing which caused some concern was the GUI table with all KEA DHCPv6 leases showed the phones' interface as WAN, instead of OPT1.  See attached screenshot, the top 4 entries show the phones connected on OPT1 NIC, but the GUI shows WAN interface instead.  Is this a parsing error, or something more critical?  After I rebooted the router the problem was gone.

PS. I removed some of the addresses to retain privacy.

Hi All,

I am trying to migrate from ISC DHCPv4 and DHCPv6 to Dnsmasq,  with only partial success so far.  I have followed the docs and example provided, but my understanding of Dnsmasq is rather poor and consequently the result is only partly working as intended.

1. When SIP phones are set with their own static IPv4 (no DHCPv4 solicitation) and also configured to obtain a stateful DHCPv6 address from the router, plus SLAAC, they fail to obtain an IPv6 address:

https://service.snom.com/display/wiki/HowTo+-+Networking+-+IPv6

The logs show a sequence of DHCPSOLICIT from the phones and DHCPADVERTISE from the router's interface, but eventually they time out and do not obtain any IPv6 address whatsoever.  Interestingly, other hosts receive IPv6 stateful addresses off the same router NIC, so far it is only the phones which fail to do so.  The ISC DHCPv6 had no problem serving the phones with an address from within the IPv6 range allocated to the router's NIC.

I still have Services > Router Advertisements enabled, rather than the Dnsmasq > General > Router advertisements, which is left disabled.  I understand this is the recommended approach, have I got this wrong?  Is there anything else I need to configure to have Dnsmasq working with IPv6 as ICS is able to do?

2. LAN clients receive the configured Dnsmasq host 'name.internal' as set in  Services > Dnsmasq > Hosts, but nslookup fails to resolve local domain names returning NXDOMAIN, while reverse lookups against the host's IP address return correctly the host name.  What could have I missed or misconfigured?

Grateful for any pointers.

You can update safely. ISC is still very much there in 25.1.7.

I updated last night and nothing broke for me.

Thanks, this will give me some (more) time to look into the alternatives.

Is there a migration guide from ISC to either KEA or dnsmasq, rather than configuring either of these alternatives to ISC afresh as described in the guide?  I consider my DHCP setup rather basic, but since I am not familiar with either KEA or dnsmasq it will take me time to look into pros & cons of either and walk through the documentation.

At least, can I update 25.1.6_4 to 25.1.7 and continue using ISC just as it is configured for now, or will it be removed by the new DHCP package(s) and leave me with a broken configuration?

Probably not directly related to gateways config, but I thought I should post this just in case.  I also received the same red coloured "Danger Unexpected error check log for details" pop up when I started an update to 24.7.12 earlier today.  The update completed a minute or so later and the system rebooted fine.  I can't find a php error.  The dpinger works and monitors the gateways, before and after the update, so I don't know why popped up.

Ok, after digging a little deeper I did a packet capture on the Apps on my Android phone RTP & STUN are being blocked and some DNS queries on port 53.

I experienced a problem with RTP failing due to packet size on releases newer than 24.7, something to do with how fragmentation is now being processed.  As a workaround I had to edit the VoIP phone and remove enough codecs from its configuration to allow packets to go through.  Perhaps your problem is related?

I'm on release 24.7.4_1 now, but the same RTP fragmentation problem remains.   :(

I noticed something with ping which I can't recall if it was the same on 24.7.  When I ping using IPv4 to check MTU size, it complains  about the packet size (unless I use sudo):

Code Select Expand

~ $ ping -4 -c 1 -D -s 1472 www.google.com
ping: packet size too large: 1472 > 56: Operation not permitted

However, no such problem with IPv6:

Code Select Expand

~ $ ping -6 -c 1 -D -s 1452 www.google.com
PING(1500=40+8+1452 bytes) 2001:XXXXXXXXXXX --> 2a00:1450:4009:81f::2004
1460 bytes from 2a00:1450:4009:81f::2004, icmp_seq=0 hlim=120 time=6.121 ms

--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.121/6.121/6.121/0.000 ms

Could someone please confirm if ping packet size is meant to have this constraint on IPv4 only, or if it is a result of the later releases?

Last time I used this setup a 4/5G modem the ISP provided CGNAT, so my suggestion would not work.  If you set keep alives from your network hopefully the VPN will not drop out.

Sorry, my mistake....the opnsense SHOULD see the public ip right? (didn't tried yet)...now the wan has a static ip4 ip, should i put PPPoE?

Place the modem in fully bridged mode and configure the opnsense WAN interface with IPv4 PPPoE, adding your login credentials at the "PPPoE configuration" section of the WAN interface page.

My problem is that I have 3 vpn of the same provide implemented and working with a fall-back logic.

You will need to replicate this VPN configuration at the opnsense router.  A bridged modem device would perform no routing.  A double NAT configuration could break many services, not just VPN.

I don't have access to EETV or any BT offering to compare notes, but have a look at these configurations to get you started:

https://forum.opnsense.org/index.php?topic=23064.0
https://www.draytek.co.uk/support/guides/vigor-2860-vdsl-setup

If you have access to a BT HomeHub and it is working as expected with EETV, then you can login into its GUI to find the required router settings, then use these on opnsense.