Messages

1

General Discussion / Simple: How to assign two IP Subnets to one interface?

« on: October 25, 2021, 05:12:39 pm »

Hello and sorry for the newbie question!
I have to be a jack of all trades, and thus master of none.
Judging from the forum search and google, everyone and their dog seems to do multi-WAN these days. Yet no one seems to want two /24 on one physical router port.

Current scenario:
Typical plain SoHo setup with 1 WAN interface that has 1 public IP that is NATed, and 1 LAN interface with 1 /24.

Goal:
To add another /24 to the same LAN port. To have more adresses, and also the possibility to put different types of devices on different subnets and isolate them except for the nessessary traffic.

Additional info:
1. It needs to be those 2 /24s because there is a site-2site IPsec VPN, and the local subnet(s) need to be unused on the other end. So this VPN partner handed out these 2 subnets that weren't yet used by their other partners. Giving us one /16 is against their policy for just ~300 IPs.
2. If the router had one more port, I could just assign 1 subnet to one physical port and be done. But there's only one port for both subnets.

Trial&error so far:
I expected to be able to simply assign multiple subnets to the interface in the interface settings. Sorta like every OS lets you assign multiple single IPs to a NIC. But thats not possible there.

Then I thought maybe virtual IPs might be the solution under BSD/OPNsense. So I tried to create an IP alias for the whole subnet. But IP aliases are really just for single IPs it seems. "Type" is locked to "single adress".
Using mode "other" instead of "IP alias" lets me add a /24 but doesn't seem to be what I need. From the wiki: "The other type won’t respond to ICMP ping messages or reply to ARP requests, it merely is a definition of an address (or range) which can be used in NAT rules."

Then someone else suggested to just turn the two /24s into one /23. "Genious" I thought (if the other end could set up the VPN with this subnet)!
But if I'm not mistaken, 192.168.1.0/23 actually goes from 192.168.0.1 to 192.168.1.254, right?
But the assigned subnets are 192.168.1.0/24 and 192.168.2.0/24!
Which is currently breaking my brain, because if i calculate it for 192.168.2.0/23, then it goes nicely from 192.168.2.1 to 192.168.3.254.


What is the correct approach to this under BSD/OPNsense?
The more I think about it, the less I seem to understand it.

2

21.7 Legacy Series / Re: [SOLVED] HAproxy log: https/0.0.0.0:443: SSL handshake fail / acme client cert

« on: October 05, 2021, 10:57:39 am »

Glad I could help! 

3

German - Deutsch / Re: Lets Encrypt nutzt falschen herausgeber für R3

« on: September 30, 2021, 05:21:14 pm »

In System: Trust: Authorities kannst du es löschen. Bei mir hatte es die Bezeichnung R3 (Let's Encrypt). Das neue hat die Bezeichnung R3 (ACME Client).
Danach dann alle ACME Zertifikate erneuern.
Und schließlich neu zuweisen.

KH

Kann bestätigen, dass das genau so bei mir letztlich funktioniert hat (https://forum.opnsense.org/index.php?topic=24969.0).
Nur unter Services -> HAProxy -> Maintenance -> SSL Certificates taucht es dann trotzdem nicht auf. Auch nicht nach einem kompletten Reboot. Aber das ist wieder ein anderes Problem. Laufen tuts trotzdem bei mir.

4

General Discussion / WEBGUI: does the built-in self-signed SSL Cert NOT auto-renew itself?

« on: September 30, 2021, 05:11:48 pm »

Newbie question:


Under System -> Trust -> Certificates I just stumbled upon this:


Name                           Issuer            Distinguished Name
webConfigurator default       self-signed     ST=Zuid-Holland, O=OPNsense, L=Middelharnis, C=NL
CA: Yes, Server: No    
                                                Valid From:    Tue, 03 Mar 2015 00:24:10 +0100
                                                Valid Until:    Wed, 02 Mar 2016 00:24:10 +0100


That's OPNsenses own SSL cert for the webgui. And it expired years ago after 1 year. 
This is not critical in my case. But I wonder if it is normal that the default SSL cert for the webgui doesn't auto-renew, and if something is broken.

If this is normal, then what is the usual recommended way to deal with this?
Renew manually? Where?
I'm sure I can't be the only one.

5

21.7 Legacy Series / Re: crash report in webif - HAproxy log: https/0.0.0.0:443: SSL handshake failure

« on: September 30, 2021, 04:29:29 pm »

Please read these threads:

Explanation and solution:
https://forum.opnsense.org/index.php?topic=24950.0
https://forum.opnsense.org/index.php?topic=24965.0

My own case:
https://forum.opnsense.org/index.php?topic=24969.0

I guess your problem is at least somehow related to this.

6

21.7 Legacy Series / [SOLVED] Problem with SSL Certificate / ACME / HAproxy

« on: September 30, 2021, 04:27:10 pm »

============================================
Final Update: scroll all the way down! It has been solved.
I still post all these notes unedited, to hopefully help others.
And to maybe get some answers to my stupid noob questions.
============================================

Hello guys,

I have a problem with ACME+HAproxy. Unfortunately, I'm not sure if it started right after the SSL cert was autorenewed,
or 1 day later when I updated OPNsense from an older 21.1.x to the latest 21.1.x.
The problem is, since either the renew or the update, the ACME/Letsencrypt SSL cert doesn't show up under Services -> HAProxy -> Maintenance -> SSL Certificates and HTTPS connections from the internet to HAproxy are not established anymore (smartphones who use MS Exchange ActiveSync (= HTTPS) through this reverse proxy).
Today I upgraded to 21.7. but it didn't fix the problem.


On the 28th the Cert was autorenewed.

ACME Log:

2021-09-28T00:00:33   acme.sh[1870]   ] Installing full chain to:/var/etc/acme-client/certs/604f8275329168.48298406/fullchain.pem
2021-09-28T00:00:33   acme.sh[53229]   ] Installing key to:/var/etc/acme-client/keys/604f8275329168.48298406/private.key
2021-09-28T00:00:33   acme.sh[23824]   ] Installing CA to:/var/etc/acme-client/certs/604f8275329168.48298406/chain.pem
2021-09-28T00:00:33   acme.sh[17629]   ] Installing cert to:/var/etc/acme-client/certs/604f8275329168.48298406/cert.pem


On the shell I actually found these 4 files, and they have the correct timestamp. Seems OK.


2021-09-28T00:00:32   acme.sh[31219]   ] And the full chain certs is there: /var/etc/acme-client/home/mail1.EXAMPLE.de/fullchain.cer
2021-09-28T00:00:32   acme.sh[7043]   ] The intermediate CA cert is in /var/etc/acme-client/home/mail1.EXAMPLE.de/ca.cer
2021-09-28T00:00:32   acme.sh[89542]   ] Your cert key is in /var/etc/acme-client/home/mail1.EXAMPLE.de/mail1.EXAMPLE.de.key
2021-09-28T00:00:32   acme.sh[34063]   ] Your cert is in /var/etc/acme-client/home/mail1.EXAMPLE.de/mail1.EXAMPLE.de.cer


On the shell I actually found these 4 files, but mail1.EXAMPLE.de.key has a timestamp from March! Is that OK?
Shouldn't it be a new one?



After forcing a reissue of the cert in the ACME Client:

ACME Log:

2021-09-30T13:55:40   acme.sh[55535]   ] Installing full chain to:/var/etc/acme-client/certs/604f8275329168.48298406/fullchain.pem
2021-09-30T13:55:40   acme.sh[94777]   ] Installing key to:/var/etc/acme-client/keys/604f8275329168.48298406/private.key
2021-09-30T13:55:40   acme.sh[32315]   ] Installing CA to:/var/etc/acme-client/certs/604f8275329168.48298406/chain.pem
2021-09-30T13:55:40   acme.sh[41172]   ] Installing cert to:/var/etc/acme-client/certs/604f8275329168.48298406/cert.pem
2021-09-30T13:55:40   acme.sh[10644]   ] And the full chain certs is there: /var/etc/acme-client/home/mail1.EXAMPLE.de/fullchain.cer
2021-09-30T13:55:40   acme.sh[49799]   ] The intermediate CA cert is in /var/etc/acme-client/home/mail1.EXAMPLE.de/ca.cer
2021-09-30T13:55:40   acme.sh[72121]   ] Your cert key is in /var/etc/acme-client/home/mail1.EXAMPLE.de/mail1.EXAMPLE.de.key
2021-09-30T13:55:39   acme.sh[4512]   ] Your cert is in /var/etc/acme-client/home/mail1.EXAMPLE.de/mail1.EXAMPLE.de.cer
2021-09-30T13:55:39   acme.sh[46883]   ] Cert success.
2021-09-30T13:55:38   acme.sh[25725]   ] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/031cf6ff4b15af3f48b8afad7df065c101a3'
2021-09-30T13:55:38   acme.sh[57964]   ] Downloading cert.
2021-09-30T13:55:36   acme.sh[93557]   ] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/115804411/28318826760'
2021-09-30T13:55:36   acme.sh[35627]   ] Lets finalize the order.
2021-09-30T13:55:36   acme.sh[49165]   ] Verify finished, start to sign.
2021-09-30T13:55:36   acme.sh[30920]   ] autodiscover.EXAMPLE.de is already verified, skip http-01.
2021-09-30T13:55:36   acme.sh[51622]   ] mail1.EXAMPLE.de is already verified, skip http-01.
2021-09-30T13:55:36   acme.sh[99352]   ] mail1.EXAMPLE.de is already verified, skip http-01.
2021-09-30T13:55:36   acme.sh[51062]   ] Getting webroot for domain='autodiscover.EXAMPLE.de'
2021-09-30T13:55:35   acme.sh[65227]   ] Getting webroot for domain='mail1.EXAMPLE.de'
2021-09-30T13:55:35   acme.sh[49398]   ] Getting webroot for domain='mail1.EXAMPLE.de'
2021-09-30T13:55:28   acme.sh[96516]   ] Getting domain auth token for each domain
2021-09-30T13:55:28   acme.sh[90247]   ] Multi domain='DNS:mail1.EXAMPLE.de,DNS:mail1.EXAMPLE.de,DNS:autodiscover.EXAMPLE.de'
2021-09-30T13:55:28   acme.sh[69829]   ] Using CA: https://acme-v02.api.letsencrypt.org/directory


System Log:

2021-09-30T13:55:43   php[65196]   AcmeClient: running automation: Postfix
2021-09-30T13:55:41   php[65196]   AcmeClient: running automation: HAProxy
2021-09-30T13:55:41   php[65196]   AcmeClient: running automations for certificate: mail1.EXAMPLE.de
2021-09-30T13:55:40   opnsense[65196]   AcmeClient: updated ACME X.509 certificate: mail1.EXAMPLE.de
2021-09-30T13:55:40   opnsense[65196]   AcmeClient: successfully issued/renewed certificate: mail1.EXAMPLE.de
2021-09-30T13:55:26   opnsense[65196]   AcmeClient: using challenge type: http_validate
2021-09-30T13:55:25   opnsense[65196]   AcmeClient: account is registered: EXAMPLE
2021-09-30T13:55:25   opnsense[65196]   AcmeClient: using CA: letsencrypt
2021-09-30T13:55:25   opnsense[65196]   AcmeClient: issue certificate: mail1.EXAMPLE.de
2021-09-30T13:55:23   api[70849]   [2021-09-30T13:55:23+02:00][error] AcmeClient: HAProxy integration is complete
2021-09-30T13:54:28   opnsense[72181]   AcmeClient: issue/renewal not required for certificate: mail1.EXAMPLE.de
2021-09-30T13:54:26   api[61659]   [2021-09-30T13:54:26+02:00][error] AcmeClient: HAProxy integration is complete


Services -> ACME Client -> Certificates now shows the new cert with the new date/time

System -> Trust -> Certificates now shows the new cert with the new date/time

The HAproxy public service still has SSL Offloading selected, and the ACME cert is also still selected under "Certificates" and "Default Certificate".

/var/etc/acme-client/home/mail1.EXAMPLE.de/mail1.EXAMPLE.de.key STILL has a timestamp from March! Is that OK?

Services -> HAProxy -> Maintenance -> SSL Certificates STILL doesn't show any cert!



From this thread https://forum.opnsense.org/index.php?topic=9936.0 it seems HAproxy looks for the SSL cert in /var/etc/haproxy/ssl.
But /var/etc/haproxy doesn't exist:

root@OPNsense:/var/etc # ls -la
total 64
drwxr-xr-x   5 root  wheel   512 Sep 30 12:19 .
drwxr-xr-x  30 root  wheel   512 Sep  2 10:20 ..
drwxr-x---   8 root  wheel   512 Mar 15  2021 acme-client
-rw-------   1 root  wheel  1944 Sep 30 12:19 cert.pem
-rw-r--r--   1 root  wheel   187 Jul 11  2019 dhclient_wan.conf
-rw-------   1 root  wheel  3272 Sep 30 12:19 key.pem
-rw-r--r--   1 root  wheel  2522 Sep 30 14:06 lighttpd-acme-challenge.conf
-rw-r--r--   1 root  wheel  1968 Sep 30 12:18 lighttpd-api-dispatcher.conf
-rw-r--r--   1 root  wheel  5897 Sep 30 12:19 lighty-webConfigurator.conf
lrwxr-xr-x   1 root  wheel    26 Jul 11  2019 mpd.script -> /usr/local/sbin/mpd.script
-rw-r-----   1 root  wheel   968 Sep 30 12:19 mpd_wan.conf
-rw-r--r--   1 root  wheel    24 Sep 30 12:19 nameserver_pppoe0
-rw-r--r--   1 root  wheel     0 Sep 30 12:19 nameserver_v6pppoe0
-rw-r--r--   1 root  wheel   360 Sep 30 12:20 ntpd.conf
drwxr-x---   2 root  wheel   512 Mar 18  2020 openvpn
drwxr-x---   3 root  wheel   512 Jul 10  2019 openvpn-csc
-rw-r--r--   1 root  wheel  1789 Sep 30 12:19 syslog.conf

Is that OK in the current version of OPNsense and the HAproxy Plugin?
From which path and which filename does the current HAproxy plugin want to load the SSL cert?



UPDATE:
Now I'm reading this https://forum.opnsense.org/index.php?topic=24950.0


System -> Trust -> Authorities looks like this:

Name          Internal    Issuer    Certificates    Distinguished Name    
   
R3 (Let's Encrypt)    NO        external     1     O=Let's Encrypt, CN=R3, C=US
     Valid From:    Wed, 07 Oct 2020 21:21:40 +0200
     Valid Until:    Wed, 29 Sep 2021 21:21:40 +0200
   
R3 (ACME Client)    NO        external     0     O=Let's Encrypt, CN=R3, C=US
     Valid From:    Fri, 04 Sep 2020 02:00:00 +0200
     Valid Until:    Mon, 15 Sep 2025 18:00:00 +0200

Note that the old "Let's Encrypt" CA has 1 cert, while the new "ACME Client" CA has 0.
This matches System -> Trust -> Certificates:

Name                                Issuer          Distinguished Name
 mail1.EXAMPLE.de (ACME Client)      R3 (Let's Encrypt)     CN=mail1.EXAMPLE.de
CA: No, Server: Yes    
     Valid From:    Thu, 30 Sep 2021 12:55:38 +0200
     Valid Until:    Wed, 29 Dec 2021 11:55:37 +0100


So I followed this advice from mimugmail:
"You can also go to System : Trust : Authorities, remove the old CA which expires today, then go to LE plugin and renew all,
then go to your sevices and look if they are correctly linked and restart.
No patch necessary."

It worked fine. The newest renewed cert is now issued by the new "ACME Client" instead of "Let's Encrypt".
BUT: Services -> HAProxy -> Maintenance -> SSL Certificates STILL doesn't show any cert!
So I checked the HAproxy public service, and noticed that "Certificate" and "Default certificate" were empty now (as others have already warned).
So in both fields I selected the new "mail1.EXAMPLE.de (ACME Client)" cert, and clicked 'save' and then 'apply'.
BUT: Services -> HAProxy -> Maintenance -> SSL Certificates STILL doesn't show any cert!
So I stopped and started the HAproxy service from the Dashboard.
BUT: Services -> HAProxy -> Maintenance -> SSL Certificates STILL doesn't show any cert!
However, I noticed that external clients (such as my iPhones E-Mail app) can connect again without SSL error! Problem solved! Except for the Web GUI...

7

21.7 Legacy Series / Re: opnsense using wrong letsencrypt R3 intermediate certificate

« on: September 30, 2021, 04:11:42 pm »

Thank you mfedv and mimugmail! You saved my day!
EDIT: And Frank (see below) and franco and everyone else who helped fixing this!

8

General Discussion / Re: Postfix Plugin: "mail for <internal IP> loops back to myself"

« on: April 16, 2021, 11:12:54 am »

No one? Seems I hit the jackpot...

9

General Discussion / Postfix Plugin: "mail for <internal IP> loops back to myself"

« on: April 12, 2021, 01:02:45 pm »

Situation:
We are a small non-IT company who have an MS Exchange behind OPNsense. 2 Weeks ago I finally installed the postfix plugin according to the mailgateway guide in the documentation, and some other guides, to use it as an incomming SMTP Proxy.
Outgoing mail is still sent directly by Exchange (so its own correct HELO "mail1.ourcompany.de" is used).
I'll use it as a smarthost for outgoing mail too, after this problem is solved.
I'm not deep into mailservers/SMTP, so the config might be a bit rough (and wrong) around the edges, but it generally works. Almost.


Technical:
public domain name: ourcompany.de
internal Active Directory domain: company.local
internal mailserver hostname: mail01(.company.local)
MX record: mail1.ourcompany.de points to <public DSL IP of OPNsense>
rDNS of <public DSL IP of OPNsense>: mail1.ourcompany.de
Exchange internal IP: 192.168.x0.15
OPNsense internal IP: 192.168.x0.254
HELO when sending testmail to Spamhaus helocheck@abuseat.org: mail1.ourcompany.de (this must/should be the answer from Exchange, not postfix)
SMTP banner according to manual telnet check from outside: mail1.ourcompany.de (this should be the answer from postfix)
SMTP banner according to testconnectivity.microsoft.com incomming check: 220 mail1.ourcompany.de (this should be the answer from postfix)
EHLO Reply according to testconnectivity.microsoft.com incomming check: either mail1.ourcompany.de OR OPNsense (see below, both should be the answer from postfix)
Postfix Plugin Trusted networks: default + 192.168.x0.0/24
Postfix Plugin SMTP Banner: mail1.ourcompany.de
Postfix Plugin Domains: ourcompany.de destination 192.168.x0.15


Problem:
If I DO set the "System Hostname" in the postfix plugin to the mailservers public FQDN (mail1.ourcompany.de) as one should,
all incomming mails cannot be delivered. Postfix (it seems to me) generates these errormails:

Undelivered Mail Returned to Sender

This is the mail system at host mail1.ourcompany.de.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<my.name@ourcompany.de>: mail for 192.168.x0.15 loops back to myself


Attachment "message delivery status":

Reporting-MTA: dns; mail1.ourcompany.de
X-Postfix-Queue-ID: DC9768F48D3
X-Postfix-Sender: rfc822; my.privatemail@gmx.de
Arrival-Date: Mon, 12 Apr 2021 10:47:30 +0200 (CEST)

Final-Recipient: rfc822; my.name@ourcompany.de
Original-Recipient: rfc822;my.name@ourcompany.de
Action: failed
Status: 5.4.6
Diagnostic-Code: X-Postfix; mail for 192.168.x0.15 loops back to myself

If I DO NOT set the "System Hostname" in the postfix plugin, the hostname "OPNsense" is used for various things.
Also for the EHLO Reply (the HELO is correct! See "Technical" above) it seems. This doesn't prevent this setup from working, BUT it didn't take long before our IP ended up on Spamhaus CSS blocklist. Twice. This causes a lot of our outgoing mails to be undeliverable. I just got the 2nd delisting, but the IP can be blacklisted again any day.

Here are the 3 postfix GUI configs and their effect again:

1)
System Hostname: mail1.ourcompany.de
System Domain: ourcompany.de
System Origin: - empty -
Result: EHLO Reply corrrect (mail1.ourcompany.de) but delivery between postfix and Exchange is 100% broken: "mail for 192.168.10.15 loops back to myself"

2)
System Hostname: - empty -
System Domain: ourcompany.de
System Origin: mail1.ourcompany.de
Result: EHLO Reply wrong (OPNsense) and so we'll be getting blacklisted, but delivery between postfix and Exchange works

3)
System Hostname: - empty -
System Domain: ourcompany.de
System Origin: - empty -
Result: EHLO Reply wrong (OPNsense) and so we'll be getting blacklisted, but delivery between postfix and Exchange works

BTW: Can anyone elaborate a bit on the meaning/function/relevance of "System Domain" and "System Origin", and how they relate to each other? The hints in the GUI don't really explain it to me as a mailserver layman.

So, what I need is a correct EHLO Reply whithout the "mail for 192.168.10.15 loops back to myself" problem.
I guess postfix is confused that Exchange has the same HELO/EHLO as itself? If that is the cause, then the only solution I see is to change Exchange's HELO/EHLO. Or can you disable this check and force postfix to ignore it?
But then I can't use Exchange for outgoing mail anymore, and so I MUST use postfix as a smarthost then. Is that about right, or am I more and more confusing myself here?
Or is it maybe some funky DNS resolution problem?

Thanks for reading! I'll happily provide more info, if you need to know something specific.

Regards
Andre


EDIT: I found https://forum.opnsense.org/index.php?topic=19142.0 but his solution is my config 1) above.