Topics

I recently configured IPv6 on my NBN HFC connection in AU, early August with 20.7 version of OPNsense (not ever before this release).

This seems to cause dropouts after a number of hours and the most reliable way to get the connection back up has been to reboot OPNsense.  I've had more troubles with 20.7.1 and 20.7.2 than I've ever experienced over the life of OPNsense on the same hardware.  I started using OPNsense with version 15.1

I did also find that if I disabled or re-enabled any single firewall rule, it tended to drop the connection; reconnecting was a pain that was best fixed with a reboot!

It is also possible that my "installed" troubles may be partly related to an aging m.2 SSD drive; but I wouldn't be so sure, especially since I am now using a USB stick as a LiveCD working environment.

I am currently only using LiveCD setup  with auto-configuration and my saved config files.  When the PPP connection fails, the most reliable way to "quickly" get it back in service is to reboot, force the auto-configurator to run and then escape out (the no-so-secret way), manually restore my config in place (with original config and sshd keys intact after fixing permissions), then exiting from the shell and bypass extra config when the script continues.  Once I do this, I can get another good block of hours until the next PPP connection dropout and the dance has to begin again.

At one stage I did try to run the installer, but it took forever and didn't complete on the suspect m.2 SSD drive, so I won't try that again until I am sure the drive is good or a replacement is installed.

Being stuck on 20.7 doesn't otherwise seem to cause any grief, of course I would like it fully up to date, but getting an updated image doesn't seem to be an option at all (unless I build it myself) with OPNsense for point releases.  Not about to have that argument here.... but..... not super happy about that failing.

Any ideas how to best troubleshoot the problem, has anyone else suffered the same problems since implementing IPv6 (IPv4 was always good and it is still in use with IPv6 going over the IPv4 link).  IPv6 is experimental for the setup, but I don't want to remove it either; in time I expect to serve both IPv4 and IPv6 until some time in the future when IPv4 may be deprecated (if it ever is).  I am definitely not ready to transition away from IPv4 to IPv6 for anything production wise at this time, nor do I expect that to change any time in the near future.   I consider IPv6 a "bonus", but also something I don't want to have to give up on at this time.

I tried to setup a USB with the /conf directory tree on it using freebsd-usfs file system type, but the autoconfigurator seems to only work with msdos_fs, so I reformatted the USB to use vfat32and added  the /conf directory tree to it.

As the autoconfigurator option from USB boot (vga version) only wants to mount msdos_fs the sshd keys have incorrect permissions; I have to login to the console (usually a headless box) and adjust the permissions for the /conf/sshd/*key files to 600 and then manually start sshd.

I would have thought that a freebsd system should be able to read the freeebsd-ufs partition's /conf directory tree for use with the autoconfigurator.

Is there a better way to solve this so that the sshd key files have the appropriate permissions without needing to fix it with a login shell?  The autoconfigurator should adjust file permissions for the sshd keys...

It would also be good if the autoconfigurator could scan the devices and only present the one(s) that have a valid /conf directory and if only one valid device is found, then use it after a short delay without requiring any user action -- the machine could then be headless and keyboardless again.

I have some issues with 20.7.2 and am currently running 20.7 with my config via LiveCD method.

Obviously I would like to run 20.7.2 via LiveCD method, but there is no image available to do this.

How can I apply the updates to the image so that it becomes, in theory, 20.7.2 -- I am using the vga amd64 version.

When I registered for this forum, the registration form didn't have any limits of password size.  As I use a password manager that can create long and/or complex passwords, I registered with a long password.

The login screen has a 20 character limit, as does the change password screen; neither limit should be there.

If I adjust the field using developer options in my browser (setting the login password field to 99 charcaters), then my password is okay -- if I add an extra character or remove one, then the login fails.  So it seems clear to me that the 20 character password setting should be removed to allow anybody to have an extra long password if they so desire.

Please remove the 20 character limits in the login as well as for the change password forms of this forum.