Messages

Now I'm nervous we've been wasting effort - we have several deployed systems where we've customised the rspamd plugin configuration to enable DKIM,as per this post:

https://forum.opnsense.org/index.php?topic=20280.msg270642#msg270642

 - is there a risk that configuration work will be lost on the next service/firewall restart?

Responses so far suggest nobody has this working via the plugin. While we're comfortable making Postfix work via conf it would seem that shouldn't be using a plugin on the firewall and we should have a separate VM to act as the relay for mail. Just to be clear what within the conf would be overwritten by updates to the firewall/plugin and why on reboot?

We have a scenario where an internal service sends with a domain that needs rewriting to one that the firewall relay can successfully deliver i.e.

mailbox1@internaldomain.net needs rewriting to mailbox1@correctdomain.com

Our initial research suggested that the Postfix plugin could achieve this with "Sender Canonical Rewriting" but found little documentation on how to correctly complete the fields. Posts elsewhere on this forum suggested we should format the original sender (entered into "Rewrite From") like this:

/mailbox1@internaldomain.net/i

and then the replacement address (entered into "Rewrite To") simply as:

mailbox1@correctdomain.com

However configured like this the sender address is not rewritten and the mail gets relayed with the original "From:" address and the headers do not contain the replacement address anywhere.

Is there any additional documentation on how to achieve the rewrite correctly?

NB the only entry in the logs referencing "canonical" is this: warning: regexp map /usr/local/etc/postfix/sendercanonical, line 1: ignoring unrecognized request but it is from a week ago, not repeated on subsequent service restarts nor when mail flows

All suggestions welcome!

Regards

Chris

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.