Messages

I have an opnsense firewall (business edition) which utilizes plugins for postfix and rspamd. We sometimes receive spam mails, originating from different mail servers (sending SMTP), which are however from the same second level domain.

Example:
Spam sending SMTP server 1 has fqdn and also PTR entry: xyz.spamfreak.com
Spam sending SMTP server 2 has fqdn and also PTR entry: abc.asd.spamfreak.com

Is there a way to use a wildcard approach to block all and any communication with hosts having a PTR entry in DNS, that matches spamfreak.com at the end?
So it should block *.spamfreak.com but also *.*.spamfreak.com.

Hello there

It seems that HAproxy does not at all react to whatever changes i make.
I want to put a single backend host into maintenance mode or through what ever means is achievable, that this host is no longer accessible from the outside, so I can run maintenance tasks.

If I set that host into maintenance mode, the website it hosts is still accessible from WAN. If I change the IP address of the backend server to another non existant address, that freakin web page is still loading from WAN.
It doesn't matter what I do, even restart HA proxy, I am totally unable to restrict that access.
HAproxy seems badly broken to me...
Anybody else?

Cheers

warning: TLS library problem: error:14094416

what if you add

Code Select Expand

smtp_tls_CAfile = $smtpd_tls_CAfile
also then

That worked, thanks :-)

I adjusted my main.cf as follows and had to uncomment the default "smtp_tls_CAfile = /etc/ssl/cert.pem":

#smtp_tls_CAfile = /etc/ssl/cert.pem
smtp_tls_CAfile = /usr/local/etc/postfix/ca_opn.pem
smtp_tls_cert_file = /usr/local/etc/postfix/cert_opn.pem
smtp_tls_key_file = /usr/local/etc/postfix/cert_opn.pem

Afterwards, I have enabled the following setting: System / Settings / General / Store intermediate
This adds all locally administered intermediate CAs to the /etc/ssl/cert.pem.
This way I could revert the change made to the smtp_tls_CAfile.
Is there a more selective way to add intermediate CAs to the cert.pem file?
It added now ofc also the "Fake LE Intermediate X1" intermediate CA, which I rather would not have in the cert.pem, or is it safe?

My last question would be, how I would make my manual main.cf adjustments update safe? :)

Thanks

@mimugmail
I did ask and they sent me the following, generic info, although i asked for postfix explicitly (in German).
The OPNsense is utilizing a Let's Encrypt certificate.

___
Für die IncaMail-Kommunikation benötigt ein Server:

- Ein gültiges X.509 Zertifikat einer anerkannten Certification Authority (CA)

- Wichtig: Nur gültige Zertifikate einer anerkannten Zertifizierungsstelle werden akzeptiert, u.a. alle Zertifikate von europäischen und nordamerikanischen Zertifizierungsstellen (CA - certificate authority) welche in der Trust-Liste von Mozilla aufgeführt sind (https://wiki.mozilla.org/CA/Included_Certificates). Ein selfsigned Zertifikat können wir leider nicht anerkennen



Serverconfig:

- Installieren Sie auf dem Inbound oder Empfangs- Connector das gültige Zertifikat

- Ebenfalls auf dem Outbound oder Sende- Connector. Dort ist es wichtig, dass das Zertifikat in der Client Role präsentiert wird.

- Die Zertifikatskette sollte in der  Reihenfolge - Client - Intermediate - Root Zertifikat - präsentiert werden.

- Aktivieren Sie  "Transport Layer Security" (TLS) and "Mutual Authentication"

- Stellen Sie sicher, dass "Client Certificate Authentication" aktiviert ist



Einstellungen beim Routing:

Dort können Sie hinterlegen, dass alles was an *.incamail.ch geht weitergereicht wird an gw1.incamail.com und gw2.incamail.com (sofern Sie zwei Empfangsserver angeben können). Falls nur ein Empfangsserver angegeben werden kann, nehmen Sie bitte im.post.ch (dieser verteilt die Nachrichten dann an gw1.incamail.com und gw2.incamail.com).



Optional können Sie auch ein E-Mail-Gateway dazwischen einsetzen, welches zwischen den Mailserver und dem IncaMail-Dienst geschaltet ist.

Da die Transportverschlüsselung erst ab dem Gateway erfolgt, muss eine hinreichend sichere Transportverschlüsselung zwischen Gateway und Mailserver gewährleistet sein.

Statt auf dem Mailserver können Sie In diesem Fall das oben genannte Zertifikat auf dem Gateway installieren und dort STARTTLS in SMTP-Kommunikation über Port 25 sowie die Unterstützung von Mutual Authentication einschalten.

Weiter ist es wichtig, dass das SwissSign-Rootzertifikat des IncaMail-Serverzertifikats in Ihrem Truststore enthalten ist, Nachrichten mit HTML-Anhängen nicht gefiltert werden und der IncaMail-Server nicht gesperrt ist (ev. Eintrag in Whitelist).

Well, that was based on the already existing entry in the main.cf:

smtpd_tls_cert_file = /usr/local/etc/postfix/cert_opn.pem

I added those two lines after that variable definition, which didn't work.
I did add then the explict path like this:

smtp_tls_cert_file = /usr/local/etc/postfix/cert_opn.pem
smtp_tls_key_file = /usr/local/etc/postfix/cert_opn.pem

With that I get the followinmg error in postfix log:
warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:ssl/record/rec_layer_s3.c:1621:SSL alert number 46:

And it still doesn't work...

Thanks for the links @doktornotor

Your feedback helped me to find a post on github with the spot on topic:
https://github.com/opnsense/plugins/issues/3274

For testing, I added the following two lines, as mentioned ind the above psot, to the main.cf:

smtp_tls_cert_file = $smtpd_tls_cert_file
smtp_tls_key_file = $smtpd_tls_cert_file

Unfortunately, that didn't help.
Are the variable names even correct?

Hello there

I'm using OPNsense with the Postfix plugin as a mail gateway.
We have a secure mail provider here in Switzerland called IncaMail.
They require us to have our MTA provide a client certificate to their receiving MTA when we send mails to them.
You can easily check it by sending a mail to mta@check.incamail.ch, which sends back its findings about receiving and sending capabilities of your own MTA, the OPNsense in that case, of course.

The first part of the answer, which is sending from the OPNsense to the MTA of check.incamail.ch, tells me that there is no client certificate.

The second part is the other way around, where MTA from check.incamail.ch is sending a mail to the OPNsense, which works as it should.

How can I provide a client certificate to the MTA of check.incamail.ch?

I've read, that enabling "smtpd_tls_ask_ccert = yes" should not be used in general, as it could break legitimate mail transfer with sendmail MTAs.

Would there be a solution around "smtp_tls_policy_maps"?
If yes, how should that policy map look like and how can I tell OPNsense to use it, as it probably is a bad idea to directly modify postfix main.cf

Thanks for any hint :)

Hello there

I have following task at hand:
An internal mail sending machine (LAN zone) has a non changeable email sender address in this form: machine@otheraddress.com
That machine however needs to send mails to external address with this from address: machine@address.com

In order to achieve that I thought that "Sender Canonical Rewriting is the necessary feature and configured this:

Rewrite From:   /machine@otheraddress.com/i
Rewrite To:   machine@address.com

My expectation would be, that any outbound mail sending (from LAN to WAN) with a sender address of "machine@otheraddress.com" should now get rewritten to "machine@address.com".
Well, it's not working...

What am I doing wrong?

Thanks for a hint  ;)

Best
Juri

Does it work when you assign an alias in the port, where that alias consists of that port range in question?
An I assume you have defined as protocol either tcp or udp, right?

Did you reboot inbetween?

Yay, I finally can replace then my FireHOL List 3 with List 1, without having to create a super complicated firewall rule set.

Thanks @AdSchellevis  :)

Hi szurubooru

Lol, you're right, you said its LAN only. I shouldn't try to answer blog posts late in the night ;)

Why would you define in DHCP your OPNsense-DHCP-only as a gateway for clients? It is no gateway, so better use your real internet gateway.

Did you set any additional DHCP options or just vanilla?

In case the OPNsense interferes during your RDP session, try to disconnect the OPNsense interface, once your client got its DHCP address.
This way you can eventually see if your clients DHCP config is the issue or the OPNsense itself.

You are still using public IPs in your LAN. What's the reason behind that?

@Franco
That was no offence, just a feedback  :)

I am quite new to OPNsense and would be willing to assist in curating that info, but am not sure if I'm ready for it, since I'm an OPNsense user only since a few weeks.

But back to the point: I think it would be already of great help, if near the top of the update notice, a sticky note says: IMPORTANT: Please consult open bugs list, prior to updating.

There should be a link to github bug tracker.

That what probably already suffice, what do you think?

I agree with Ricardo.
There should be a "known issues" section with update infos.
I also ran into the syslog-ng issue, just to find out it was known, but nobody actually cared to tell others, that this happening.

How about a dynamic update info when pressing the update button, that contains that "known issue" section?

Knowingly letting people run into an issue that's known and hoping for them to find a solution on the forums seems to be quite a poor solution...

Cheers
Juri

Well, your LAN IP range is using public IP adresses, which is a baaaad idea, unless you own those addresses, which I doubt.

Are you sure youre using a correct subnet mask? I would recommend to compare the mask from your DHCP server with your manual IP setup.

Disabling WAN firewall... Are you serious?
I can only hope that on your WAN comes another LAN. In that case, you probably are blocking private IP adresses on the WAN interface and should disable that setting found under Interfaces / WAN.