Messages

Okay, well I'm in AU, so changing to my ISP isn't an option for you; but perhaps another ISP would be happy to help or you can convince them why you need to be off CGNAT?

Thanks, whom is your ISP?  Mine is now doing CGNAT, but not for me and I get some of my clients to request to be taken off CGNAT without any trouble -- they just tell the ISP that they require a proper static IP address for support reasons.

I've got a /60, with the IDs from 0 to 15, that still gives 16x /64 to play with.

btw I am a "partner / agent" for my ISP, so.... if you want to explore changing ISP as an option, I am sure you'll be able to avoid CGNAT.  Perhaps private message me.

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.

Line 317 (unless it is done by line 314), creates the sshd directory if it doesn't exist, so perhaps still no need to check if it exists?

Line 322 has a couple of errors, it won't work as far as I can tell.

After taking away the dash before the f for -type, you still get this problem:

Code Select Expand


# for FILE in "$(find /conf/sshd -type f -name '*key')";do ls "${FILE}";echo;done
ls: /conf/sshd/ssh_host_rsa_key
/conf/sshd/ssh_host_ecdsa_key
/conf/sshd/ssh_host_ed25519_key: No such file or directory


You will need to remove the double quotes.

This works:

Code Select Expand


# for FILE in $(find /conf/sshd -type f -name '*key');do ls "${FILE}";echo;done
/conf/sshd/ssh_host_rsa_key

/conf/sshd/ssh_host_ecdsa_key

/conf/sshd/ssh_host_ed25519_key


The above is testing....

This is the code replacement I think is needed if you want to include just the sshd directory, but you will still need to test for the existence of the directory:

Code Select Expand


find /conf/sshd -name '*key' -print0|xargs -0r chmod 600


And for what it's worth, if we want verbose-ness to show exactly what was changed and how, then add -vv with chmod

Code Select Expand


find /conf/sshd -name '*key' -print0|xargs -0r chmod -vv 600


I believe this would work too for the keys:

find /conf -name '*key' -print0|xargs -0r chmod 600

As we always have the /conf directory at that time, there is no need to check for sshd directory or to process each found file separately -- it's only a minor change, but it's neater I think.  What's more, if no files are found then xargs won't run chmod at all.

I understand, but the point releases don't seem too frequent.  And having a new image built for each one could be handy for further testing by the masses.

Thanks.

The reason I come across this is that upgrades have become a problem for me of late.

This time I had a completely unbootable system, but the m.2 SATA SSD in place was able to be used to fetch the config and run LiveCD environment.  Then I tried the installer and it took forever adding a partition.  Eventually I rebooted and cleaned the internal disk and am now running just with LiveCD environment until I can check out the SSD which seems to be giving people grief with older installed systems like mine is now.

It would be handy to have smarttools and/or other diagnostics included to help check the health of disks.

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.

I upgraded, first upgrade with any issues.... original installation version was 15.1

Until this upgrade, I never had any issues with upgrading whatsoever.

This time, after the "reboot" and any number of reboots from the GUI the Internet would not connect.

I ended up pulling the power plug on my OPNsense box and then power cycling the modem (HFC NBN connection in AU), when it was fully ready, then I re-plugged in the OPNsense box and it seems to have run a migration script (looking at a backup config taken immediately afterwards).

This gave me normal Internet access again.

It would seem that doing a reboot via the GUI some how doesn't do a full power cycle and then the migration script doesn't run.  Doing the full power cycle enabled the migration script [1] to kick in.

[1] /usr/local/opnsense/mvc/script/run_migrations.php