Messages

Hi, I don't have your kind of Internet service, but I read in other threads in the past that you could use virtual IPs for your kind of setup https://docs.opnsense.org/manual/firewall_vip.html#other

Just take a look at the documentation.

Cheers

In my case, according to the log, ACME is detecting the IP correctly.

@Fright, I tried to renew a certificate using HTTP-01 to catch the logs and look for clues based on your advice, but ACME skipped the HTTP-01 verification because the domain is already verified, so I couldn't see the complete process.

The interface address has been got correctly, I just obfuscated that.

Before switching to DNS-01 challenge I tried to renew the certificates a couple of times and I could see the requests on Nginx log. Then Nginx responded with a 302 code. I could not see the details of the response but the log showed a 302 code (temporary redirection).

Hi Fright,

what if you "Disable web GUI redirect rule" at System: Settings: Administration ?

I have it disabled already. Since a long time ago.

Filtered those logs for the time at which the renewal process happened and found nothing.
Firewall had not blocked anything between 05:30:00 and 05:30:29.

This is the backend log, I see nothing either:

2024-01-22T05:30:29-03:00   Notice   configd.py   [9e5c85a1-74b3-471b-9e9f-7d8c7263d326] request pf current overall table record count and table-entries limit   
2024-01-22T05:30:29-03:00   Notice   configd.py   [24b90037-00d9-47cb-be25-df1665c8a008] Reloading filter   
2024-01-22T05:30:00-03:00   Notice   configd.py   [10ab735c-cb6f-4e84-98bb-b5c227534100] Reading primary IPv4 of wan   
2024-01-22T05:30:00-03:00   Notice   configd.py   [696cfc90-e22e-4d31-90dd-b37cbfbb1a22] request pf current overall table record count and table-entries limit   
2024-01-22T05:30:00-03:00   Informational   configd.py   message d86e94ef-a777-4271-986c-c00934c2a21e [] returned OK   
2024-01-22T05:30:00-03:00   Notice   configd.py   [d86e94ef-a777-4271-986c-c00934c2a21e] cronjob running to sign or renew certificates

Excelent, glad to see you resolved it.

May be the solution is uninstall and reinstall as you did.

Don't think its a matter of configuration because it has worked for years and it suddenly failed.

This is the ACME log of the first failure on January, 22nd:

2024-01-22T05:30:29-03:00   acme.sh   [Mon Jan 22 05:30:29 -03 2024] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
2024-01-22T05:30:29-03:00   acme.sh   [Mon Jan 22 05:30:29 -03 2024] Please add '--debug' or '--log' to check more details.
2024-01-22T05:30:29-03:00   acme.sh   [Mon Jan 22 05:30:29 -03 2024] Invalid status, example.com:Verify error detail:w.x.y.z: Fetching https://example.com/.well-known/acme-challenge/EREIaZNm_HFsxaz64fDfizrzUVKeGQ_0CPtkZYHmEmE: Timeout during connect (likely firewall problem)
2024-01-22T05:30:26-03:00   acme.sh   [Mon Jan 22 05:30:26 -03 2024] Pending, The CA is processing your order, please just wait. (9/30)
2024-01-22T05:30:23-03:00   acme.sh   [Mon Jan 22 05:30:23 -03 2024] Pending, The CA is processing your order, please just wait. (8/30)
2024-01-22T05:30:21-03:00   acme.sh   [Mon Jan 22 05:30:21 -03 2024] Pending, The CA is processing your order, please just wait. (7/30)
2024-01-22T05:30:18-03:00   acme.sh   [Mon Jan 22 05:30:18 -03 2024] Pending, The CA is processing your order, please just wait. (6/30)
2024-01-22T05:30:15-03:00   acme.sh   [Mon Jan 22 05:30:15 -03 2024] Pending, The CA is processing your order, please just wait. (5/30)
2024-01-22T05:30:12-03:00   acme.sh   [Mon Jan 22 05:30:12 -03 2024] Pending, The CA is processing your order, please just wait. (4/30)
2024-01-22T05:30:10-03:00   acme.sh   [Mon Jan 22 05:30:10 -03 2024] Pending, The CA is processing your order, please just wait. (3/30)
2024-01-22T05:30:07-03:00   acme.sh   [Mon Jan 22 05:30:07 -03 2024] Pending, The CA is processing your order, please just wait. (2/30)
2024-01-22T05:30:04-03:00   acme.sh   [Mon Jan 22 05:30:04 -03 2024] Pending, The CA is processing your order, please just wait. (1/30)
2024-01-22T05:30:04-03:00   acme.sh   [Mon Jan 22 05:30:04 -03 2024] Verifying: example.com
2024-01-22T05:30:04-03:00   acme.sh   [Mon Jan 22 05:30:04 -03 2024] Getting webroot for domain='example.com'
2024-01-22T05:30:01-03:00   acme.sh   [Mon Jan 22 05:30:01 -03 2024] Getting domain auth token for each domain
2024-01-22T05:30:01-03:00   acme.sh   [Mon Jan 22 05:30:01 -03 2024] Single domain='example.com'
2024-01-22T05:30:01-03:00   acme.sh   [Mon Jan 22 05:30:01 -03 2024] Using CA: https://acme-v02.api.letsencrypt.org/directory
2024-01-22T05:30:00-03:00   acme.sh   [Mon Jan 22 05:30:00 -03 2024] Renew to Le_API=https://acme-v02.api.letsencrypt.org/directory
2024-01-22T05:30:00-03:00   acme.sh   [Mon Jan 22 05:30:00 -03 2024] Renew: 'example.com'

And this is the System Log:

2024-01-22T05:30:30-03:00   opnsense   AcmeClient: validation for certificate failed: example.com
2024-01-22T05:30:30-03:00   opnsense   AcmeClient: domain validation failed (http01)
2024-01-22T05:30:00-03:00   opnsense   AcmeClient: using challenge type: HTTP-01
2024-01-22T05:30:00-03:00   opnsense   AcmeClient: using IPv4 address: w.x.y.z
2024-01-22T05:30:00-03:00   opnsense   AcmeClient: account is registered: Admin
2024-01-22T05:30:00-03:00   opnsense   AcmeClient: using CA: letsencrypt
2024-01-22T05:30:00-03:00   opnsense   AcmeClient: renew certificate: example.com
2024-01-22T05:30:00-03:00   opnsense   AcmeClient: certificate must be issued/renewed: example.com

Hi markus, as far as I know there is no way to import the iptables rules. You are going to need to rewrite the rules in the OPNSense menues.
It is very straightforward.

Hi opn_minded, I've reported this issue here in the forum some days ago, and after that some other users reported this as well.
Here are the reports:
https://forum.opnsense.org/index.php?topic=38585.0
https://forum.opnsense.org/index.php?topic=38535.0
https://forum.opnsense.org/index.php?topic=38484.0 (this is my report)

As in your case, I have realized that the certificates were not being renewed some days after the first error occurred.
Because I have other certificates that had successfully renewed before, I can infer that the problem started to happen between January, 1st and 22nd. There was an update in the middle. The 23.7.11 update.

From what I could see, the server responds with a 302 redirect when the HTTP-01 challenge is trying to download the test token at /.well-known/acme-challenge/<TOKEN>.
I saw this at the Nginx logs.

I had the same issue.
In my case, the last renewal was on January, 1st.
I reported this on the General Discussion Forum https://forum.opnsense.org/index.php?topic=38484.0
I solved the issue changing the challenge to DNS-01 using cPanel API.
I was using HTTP-01 challenge and after the 23.7.11 update it stopped working.

Same thing happened to me. I had to add the gateway by hand again.
Only the IPv4 gateway disappeared, the v6 one was still there.

First of all, I've already solved the problem changing to DNS-01 challenge using cPanel API. But the issue is that I have 6 domains behind Nginx reverse proxy and the last successful renewal was on January, 1st. After that the next renew event on January, 22nd failed and I received an email from Letsencrypt warning me about the failure.
Between the two renew events there was an update from 23.7.10 to 23.7.11 and no other changes.
The renewal was done using HTTP-01 challenge and it worked fine for some years. 

I found this github issue https://github.com/opnsense/plugins/issues/1967#issue-675753796
The error that is reported in this github issue is the same than the reported on my case and there is a change listed in the 23.7.11 log that, in my opinion, could be related:

[system: include IPv6 link-local interface addresses for web GUI and OpenSSH (contributed by Maurice Walker)]

I opened this issue as a placeholder in case someone else has encountered this problem.

Hi oliviermyre.
Regarding your first question, a trunk port should pass tagged traffic, so the answer is yes.
And about the second question, if I understood right, you are referring to the the lagg0 port, and I answer yes.

When you define link aggregations, then have a single logical port. That is the port where you must define the VLANs, not the physical ones.

The communication between any host and a switch is untagged in both ways. Ports used to connect a single host is in access mode.
When you connect two switches with a single physical port or a logical aggregation of ports, communication between those ports is tagged. The switch is responsible of tagging packets that come from a host and go to another switch and untag packets that come from a switch and go to a host.
The same is true for packets that flow between a switch and a router.