Messages

#metoo

Code Select Expand


set hint.agp.0.disabled=1
set hint.agp.1.disabled=1
set hint.agp.2.disabled=1
set hint.agp.3.disabled=1
boot


can get you running from the loader shell probably (on most setups, agp.0 should be enough).

Worked for me on my test (home) setup but with the added gotcha of having to access it blind, as for some reason the (very small cheap) monitor is blank during the boot menu stage (works before and after). Very careful one-finger typing got me there eventually  ;D

In case of power outage when I'm not available to restore it, is there a way to add these settings to apply every boot?

Probably obvious to most but for those like me who backed their head on it a bit before the light dawned, if your Nextcloud instance is internal to the firewall you're backing up it won't work unless you add a DNS override for the URL of your Nextcloud. In this case the internal Nextcloud was also behind reverse proxy so the override was URL -> proxy IP, but I'm assuming a direct to NC internal IP would also work where it's a direct port forward.

You can set automatic retention in Nextcloud using Flow and the Retention app. You create 2 tags, name them anything but for example opnsense-backup and opnsense-backupdelete. Tag your target  folder with the first of the tags. Then in Flow create an automated tagging flow, with:

When file is changed; File system tag; is tagged with (that tag you tagged the target folder with); tag with (the other tag you created above)

Then add a File retention rule that uses the second tag you created, set your preferred retention time and you're done.

Files that end up in the target folder will automatically be tagged with the second tag and then the retention rule will be applied in due time.

Awesome, that fixed it :)

Just spending some time investigating this issue and noting that many (most, all?) of the files on the affected system are date stamped "Jul 13" - is it possible the upgrade completed as such but failed to mark itself as complete?

Anybody any ideas how to solve this issue?

From the fetch start:

Code Select Expand

Fetching packages-19.7-OpenSSL-amd64.tar: .+ mkdir -p /var/cache/opnsense-update/70569
+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/70569/packages-19.7-OpenSSL-amd64.tar.sig https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/sets/packages-19.7-OpenSSL-amd64.tar.sig
.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/70569/packages-19.7-OpenSSL-amd64.tar https://pkg.opnsense.org/FreeBSD:11:amd64/19.1/sets/packages-19.7-OpenSSL-amd64.tar
...+ [ -n -V ]
+ opnsense-verify -q /var/cache/opnsense-update/70569/packages-19.7-OpenSSL-amd64.tar
+ echo ' done'
done
+ [ '' '=' -b ]
+ [ '' '=' -k ]
+ [ '' '=' -k ]
+ [ -n '' -a -z -u ]
+ [ -p '=' -P -a -z -u ]
+ [ -p '=' -p -a -n -u ]
+ echo -n 'Extracting packages-19.7-OpenSSL-amd64.tar...'
Extracting packages-19.7-OpenSSL-amd64.tar...+ rm -rf /var/cache/opnsense-update/.sets.pending/packages-19.7
+ mkdir -p /var/cache/opnsense-update/.sets.pending/packages-19.7
+ pkg-static clean -qya
Segmentation fault (core dumped)


Running pkg-static manually, with no switches/commands also returns a segfault. This may be related to the health check returning the error

Code Select Expand

/usr/local/lib/libpkg.so.4: version LIBPKG_1.4 required by /usr/local/sbin/pkg not defined?

Hi

Trying to upgrade to 19.7 from 19.1.10_1. Having unlocked the upgrade I get web UI output of

Code Select Expand

***GOT REQUEST TO UPGRADE***
Fetching packages-19.7-OpenSSL-amd64.tar: ... done
Extracting packages-19.7-OpenSSL-amd64.tar...***DONE***


and CLI output of:

Code Select Expand

Proceed with this action? [19.7/y/N]: 19.7

Fetching packages-19.7-OpenSSL-amd64.tar: ... done
Extracting packages-19.7-OpenSSL-amd64.tar...Segmentation fault (core dumped)

*** OPNsense.ourpack.eu: OPNsense 19.1.10_1 (amd64/OpenSSL) ***



Locating the downloaded file and manually running tar -xf successfully extracts the contents.

Any ideas?

Ok, I may have resolved this one. A combination of using Disable Reauth on the phase 1 and limiting the encryption options on the phase 2s to a single option has reduced renegotiation times to the point that monitoring services are no longer (normally) triggered. Still get the occasional blip but that's much better than all tunnels every X hours!

We've got a setup with several offices, with VPNs between each site (fixed IPs, dedicated FTTP) which are used among other things for monitoring kit on each site from a central server. We're noticing that when the VPN lifetime expires the tunnel drops and then there's an odd delay before it re-establishes. For most purposes it wouldn't be an issue but the disconnect is long enough to make the monitoring send a bunch of alerts - and can disrupt inter-site backups.

Lifetimes are set at 28800 seconds for phase 1 and 2 at each end.

Are there any settings we could tweak to cause the renegotiation to take less time?

That option works better when you don't administrate a lot of firewalls. Unique password per install is a lot of passwords to remember.

As in the fix on the firewall we are having a similar issue on is switch gateway in WAN interface settings to auto, then back to manual. Though of course this might be a completely different issue to yours!

You have a password manager that differentiates between the password on a page v. a password on a site? I don't think mine can do that.

For interest, why would you need to store the VHID password at all - if it's available in plain text in the UI, like the IPSEC PSK, can't you just cut and paste between the firewalls?

When creating or editing a Virtual IP (Firewall -> Virtual IP -> Settings) the Gateway and Virtual IP Password boxes are seen as the firewall user/password boxes respectively, and the password manager (via FF66 and earlier) auto-completes them. Could this be changed so that doesn't happen?

Should the VHID password even be treated as something that needs hiding? I'm guessing that if it's not called/defined as "password" that it won't be seen as one.

No further detail yet (not sure where to look) but we're seeing this issue flip-flop depending on changes made.

Scenario:
central office firewall with multiple internal subnets and public IPs. Single gateway (ISP "true" fibre router).

adding a new rule (LAN/SSN certainly, not observed with WAN rules - but it's not an everytime thing) and routing in one direction stops; changing the WAN gateway to auto and then back to manual gets everything back working.