Messages

I think I found the problem. Every single conf file for the certificates has a value

Code Select Expand

Le_OCSP_Staple='1'
even though the GUI clearly shows it's disabled

When I force a renewal it works, but when I check the file it's still enabled

If I change the value in the file to 0 and then renew it also works, but it remains 0

Hey, we are facing the same issue.

Did you manage to solve this for good?

Sorry for not responding over the past week.

I spent some time testing different identifier settings, which of course caused some connection issues during configuration.
I wasn't able to get this to work using just one DSL line.
Even though the connection only dropped for a few seconds at a time, employees at the remote sites told the manager they were unable to work.

Because of that, I was told to stop changing anything as soon as it's working.

We'll see what happens when the main DSL line goes down – but until then, I'd say this scenario doesn't really work with OPNsense.
So I guess it's kinda solved for now.

Anyway, thanks for your help Monviech!

if i set the PSK values on both to the same, then the OPNsense would still match only based on the ip address and still use only one of the two configs.
Then the proposal would still not match for the second VPN.

I could set both VPNs to use the same proposal, then that would leave me basically with only one config for both remotes.
Can the OPNsense differentiate which ip network needs to go to which remote if anything else is identical?

They use a different Gateway.

I forgot to mention that both VPNs work if they use a different DSL line, but i want them on the same since the second DSL Line is only a backup.

Hello everyone,

I'm working on an existing infrastructure which is a new infrastructure to me. The network previously used three SonicWalls (one per site). Because of a very limited budget, only the main site can be migrated right now.

Current setup:
Main site: OPNsense (running on the latest business edition release) with two DSL lines (static IPs: 1.1.1.1 and 2.2.2.2) in failover mode, plus an LTE connection that is manually activated only if both DSL lines fail.
Two remote sites: each with a SonicWall, a single DSL line, and a dynamic IP (changes almost daily)

I'm trying to establish two site-to-site VPNs (one per remote site). Previously, both SonicWalls connected to 1.1.1.1 using IKEv1 Aggressive Mode. I'm trying to replicate this with OPNsense, but only one VPN connection works at a time.
Right now both VPNs are configured in IKEv1 Main Mode, i tried it with Aggressive Mode but it didnt seem to work at all.

The issue:
Site A: uses AES256-SHA256-ECP256 – connects successfully
Site B: uses AES256-SHA256-MODP2048 (the highest supported by that SonicWall) – fails to connect

Log shows:
Received proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Configured proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256

I've created two separate IPsec configs on OPNsense with the correct proposals. Both use 1.1.1.1 as the local address and 0.0.0.0/0 as remote peer.
Both have different local IKE IDs, remote IKE IDs and Pre Shared Keys which of course match with the corresponding remote site.
However, OPNsense seems to match only by IP and not by IKE ID. As a temporary workaround, I let Site A connect to 1.1.1.1 and Site B to 2.2.2.2. Ultimately, both should prefer 1.1.1.1 and automatically fail over to 2.2.2.2 if the primary DSL fails.

Is there a way to get this to work with the current SonicWalls and the OPNsense?

Thank you very much!
This helped me switching from regular certificates to wildcard certificates!
I now also do score 100% A+ in the SSL test.

So the thing is... (If I understood your setup correctly.)
To solve your issue you would have to create the relevant ACME condition, rule and a frontend listening on port 80 with the acme rule on it. This rule redirects all ACME challenges to localhost:ACMEport of your OPNsense. The Lets Encrypt Plugin is listening on the "ACMEport" of your OPNsense. All of that is created by the Lets Encrypt plugin automatically if you configure it to use HAProxy for SSL offloading.

But instead of the acme rule forwarding acme challenges to the localhost you would have to forward them to your seafile server.
As soon as there is another server that also has a certbot running things get very complicated!
Also I don't know if the conditions for the le-plugin_acme_challenges are identical to the ones of the certbot!

Since you are already reverse proxying, why don't you just let the OPNsense do the SSL offloading?
Just use the Let's Encrypt plugin and configure HAProxy with it.
Then you don't have to run certbots on every single server in your network.

Hello,

since the latest version of HAProxy now supports OCSP stapling I thought it would be a good idea to switch from the "workaround-script" to the official option.

However the option is not working for me. The system log shows the error below.

Code Select Expand

2021-04-06T03:42:01 configd.py[18127] [b2eb554c-4009-4e75-9e58-3f8a1a64e656] Script action stderr returned "b'WARNING: no nonce in response\nResponse verify OK\nWARNING: no nonce in response\nResponse verify OK'"
2021-04-06T03:42:00 configd.py[18127] [b2eb554c-4009-4e75-9e58-3f8a1a64e656] update haproxy ocsp data

I also made some pictures of my config.
https://imgur.com/a/XM9tpZt

Services --> Let's Encrypt --> Challenge Type

Make a new HTTP challenge using the 2nd WAN.

In the meantime someone in the german forum already told me to do so.
But thank you still!

This works perfectly fine.

Hat funktioniert, besten Dank!

Also im HAProxy ein zweites Frontend (z.B. Frontend_WAN2) für das Let's Encrypt Plugin erstellen, das auf "WAN2_IP:80" lauscht.
Anschließend im LE Plugin unter Validation Methods eine zweite HTTP-01 Validation Methode erstellen (siehe Bild) und diese dann im Zertifikat2 hinterlegen.
Natürlich noch die Firewall entsprechend anpassen.



Ist das so richtig oder habe ich irgendwo einen Denkfehler?

I know that LE issues certificates for domains not IPs.

I updated the first post.

Hallo,

ich habe bei mir die OPNsense als Reverse Proxy im Einsatz.

Bisher benötigte ich ich nur ein Zertifikat für eine meiner WAN IPs.
Allerdings benötige ich jetzt ein weiteres Zertifikat für eine meiner anderen WAN IPs.

Wie kann ich das erreichen?
Ich weiß, wie ich ein zweites WAN Interface auf der OPNsense anlege und die anderen Einstellungen tätige.
Aber wie kann ich dem ACME Client sagen, dass er WAN1 für Zertifikat1 und WAN2 für Zertifikat2 nutzen soll?

Denn wenn ich das zweite Zertifikat erstellen möchte, nutzt ACME den default Gateway (WAN1), wodurch die Erstellung fehlschlägt, weil die Domain nicht zur IP passt.

Hello,

I have set up my OPNsense as a reverse proxy using HAProxy and Let's Encrypt.

Right now I only have one certificate for my domain1.browne.com that has WAN1_IP.
However I need another certificate for my domain2.browne.com that has WAN2_IP.

My setup looks like this:
WAN1_IP (10.1.1.1) --> domain1.browne.com --> already uses a LE certificate (certificate1)
WAN2_IP (10.1.1.2) --> domain2.browne.com --> doesn't use LE certificate, but needs one (certificate2)

I know how to create the 2nd WAN interface and all that...
But how do I tell the ACME client to use WAN1 to generate certificate1 and use WAN2 for certificate2?

When I try to get certificate2 the ACME client on OPNsense always uses the default gateway, which is in my case WAN1 (10.1.1.1). The certificate generation then fails because certificate2 is resolving domain2 (10.1.1.2) during acme challenge. So the IP (WAN1) requesting the certificate (certificate2) is not matching to the IP of the domain (domain2) listed inside the certificate.