Messages

As per previous poster, seems best to have an answer here as the most relevant result that turns up on <enter preferred search engine here>.

Following steps as above fails initially on rspamadm dkim_keygen with error "Too many options". While rspamdadm documentation (at time of writing) states the comamnd will produce two files, as indicated above, actually it produces only the the key file, outputting the txt (DNS entry) content to stdout. To get it to a shell add a redirect into the example command before the email.txt path. There are also typos in the previously posted instructions, and it doesn't cover the scenario of sending from subdomains, so will reproduce tested working version (OPNsense 26.1) below.

1. Install os-rspamd via web UI (if you already have it installed, disable it for now)

2. enable ssh and sudo as needed, access csh with root powers

3. Create folder for DKIM key

Code Select Expand

mkdir usr/local/etc/rspamd/dkim
4. Generate key

Code Select Expand

rspamadm dkim_keygen -d sub.yourdomain.tld -s email -k /usr/local/etc/rspamd/dkim/email.key -b 2048 > /usr/local/etc/rspamd/dkim/email.txt
5. Set proper owner and ACL for key file

Code Select Expand

chown rspamd:rspamd /usr/local/etc/rspamd/dkim/email.key
chmod 600 /usr/local/etc/rspamd/dkim/email.key
6. Disable clamav module (not sure this is required, but getting it working took so much trouble shooting that we made this change (and clamav should be called by postfix anyway?)

Code Select Expand

vi /usr/local/etc/rspamd/override.d/antivirus.conf

Code Select Expand

enabled = false;
7. Enable DKIM signing by creating the override file with the necessary settings

Code Select Expand

vi /usr/local/etc/rspamd/override.d/dkim_signing.conf

Code Select Expand

enabled = true;
sign_local = true; #send from known hosts and networks
auth_only = false; #send only from authenticated users
use_domain = envelope; #setting to from also worked for us but left at envelope in production
allow_hdrfrom_mismatch = false;
allow_username_mismatch = false;
use_esld = false; #needed if you are using a subdomain to send mail direct from a service e.g. nextcloud.example.com - esld will assume only the latter 2 parts are relevant and look for a domain that matches example.com and fail
use_redis = false; #in our case the keys were not loading to redis but rspamd dkim_signing module was treating it as the "source of truth" and failing to find the key

domain {
   sub.yourdomain.tld {
    selector = "email";
    path = "/usr/local/etc/rspamd/dkim/email.key";
     }
}
8. Test syntax and restart rspamd

Code Select Expand

rspamadm configtest

Code Select Expand

service rspamd restart
9. In web UI enable rspamd plugin and enable antispam in postfix

10. Test DKIM signing from CLI
Create a simple test email where the from address domain part has to match whatever you've used in the steps above

Code Select Expand

vi testmail.eml with content

Code Select Expand

From: john.doe@sub.yourdomain.tld
To: jim.doe@example.com
Subject: Test DKIM Signing

This is a test email for DKIM signing.
Then run

Code Select Expand

rspamc --pass-all -vvvv -i 10.0.3.10 -d jim.doe@example.com -F john.doe@sub.yourdomain.tld < testmail.emlIf signing is working properly then the response should include something like

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sub.yourdomain.tld;
        s=email; t=1784209642; h=from:from:reply-to:subject:subject:to:to:cc;
        bh=RYXvt0hMSt1DiETNsCX712grsTrzBedJQa3fPCnNtAO4=;
        b=bjKtJoFa31oH8afOzkrN+0Thoh84RyvokrSMdr+hcjtJ+aRdDlxR9ZoA

If at this stage you don't get DKIM signing, you can enable rspamd debug logs on a per module basis

Code Select Expand

vi /usr/local/etc/rspamd/logging.inc appending the line

Code Select Expand

debug_modules = ["dkim_signing"]; then restart rspamd and try the test again. Log is in /var/logs/rspamd/rspamd.log.

11. With a successful local test move to add the DNS TXT record for the appropriate (sub.) domain, using the content of the email.txt file you created earlier

Code Select Expand

cat /usr/local/etc/rspamd/dkim/email.txt. Some DNS services will require you to remove some or all of the " "'s used to split the record before letting you add it.

12. Now send a real email using your OPNsense mail relay, the key will be added and the mail should be delivered (to even that big mail provider who tries not to accept emails from small mail providers).

NB this was done on a server going into production so we may have done some steps during troubleshooting that we've overlooked in this write-up. Should get to test it on another project soon and will amend as needed.

Hope it helps someone, be nice to get added to rspamd plugin...

#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.