Messages

Thanks! That makes it a lot easier. I was already looking at creating a custom script using pcftl, aliases, and a cron job.

I was looking at scheduling FW rules but it seems they work on a calendar one year in advance max. Am I correct in concluding it isn't possible to create a schedule that is more crontab like, like "every day from 09:00-17:00" or "every Sunday from 10:00-12:00"?

Problem solved and it is not a bug.

It turns out the Geolocation was at least one of the issues. There was a pass on a (pretty wide) source alias of countries for the NAT rule and it turns out an IP-address that all systems I checked tell me is in Germany wasn't seen that way by recent Geolocation by OPNsense. Geolocation is of course by definition not perfectly reliable, so this was technically my own fault.

Addition:

• Connecting from inside to the internal server on port 953 with dig works
• Connecting from inside to the internal server using hairpin (so outside IP address) on port 53 times out, but does not show a log entry from the firewall that it has been blocked
• Connecting from the outside to the outside IP address on port 53 times out and does show a firewall block log message on the default blocking rule

I recently updated to 25.4.2 Business Edition from 24.x Business Edition and it seems this has somehow made OPNsense block something it should not. I must stress 'seems' as I really suspect this is probably my problem, but I have been unable to understand what is going on. This is a bit of a pressing issue for me, as this blocks my upcoming LE certificate renewals.

I have a system on the inside that provides a DNS server on port 953 (this is for ACME DNS challenge and it runs alongside a regular internal DNS that listens on port 53, only reachable on the LAN). The ACME DNS challenge server works and internally is reachable internally on that server on port 953.

I have a NAT Port Forwarding rule that maps an outside port 53 on the WAN interface of one of my public IPs to an inside server port 953.

But when I try to reach the ACME DNS challenge server from the outside (and I have been running this without issue in 24.x for years, which is why I am now suspecting the upgrade) the traffic is blocked by the default deny rule. Hence, LE certificate updating has stopped working as LE cannot reach my ACME DNS Challenge server.

There is a FW rule on the WAN interface that explicitly passes it, but it seems not to be triggered:

Code Select Expand

@96 pass in log quick on igb0 inet proto tcp from <countries_letsencrypt_allowed:0> to <wan_vanroodewierda_rna_nl:1> port = domain flags S/SA keep state label "216b045bfd3fbe399846a0acb206d45b"
evaluations: 5
packets: 0
bytes: 0
states: 0
inserted: uid 0 pid 74119
state_creations: 0
time: n/a
@97 pass in log quick on igb0 inet proto udp from <countries_letsencrypt_allowed:0> to <wan_vanroodewierda_rna_nl:1> port = domain keep state label "216b045bfd3fbe399846a0acb206d45b"
evaluations: 0
packets: 0
bytes: 0
states: 0
inserted: uid 0 pid 74119
state_creations: 0
time: n/a
Any ideas where to look? Could this be a bug in 25.4 Business Edition?

I did not see a separate feature request possibility somewhere so I'm posting it here: it would be really helpful for me if the HAProxy version in OPNsense would support proxying UDP. I understand this is available in HAProxy, but OPNsense does not include a HAProxy that has that.

[UDP]

Thank you. I would like to try to set this up. However, I don't know how to make it so that UDP requests to port 53 are proxied. Can I, or does this mean only TCP DNS requests will be answered by that new virtual IP?

I want to use my OPNsense router as a proxy for two internal DNS resolvers. Preferably, I want a HA-setup where on the OPNsense a proxy runs that tests if my two internal DNS-es are alive and routes the UDP port 53 to an alive one. That way, I can let the DHCP of the OPNsense router hand out the OPNsense router's IP address as DNS to the DHCP clients.

Reason: I run two internal DNS resolvers. Currently, the DHCP on OPNsense hands out both to clients. It turns out I have many clients that will stick to the one they select first (especially iOS/macOS devices, but it may be the same for others). Recently, I have had availability issues on both where one failed because a switch in front of it had trouble, and the other failed because it had an ethernet hardware issue. Not at the same time, but that doesn't matter, because when I client had settled on one, it would stubbornly keep trying. that one, not switching to the other one. I think that is a problem with macOS/iOS, but as this is what I have to deal with (good luck in getting Apple to fix anything), I want my setup to be robust under the scenario that one of my internal DNS resolvers is unavailable.

I accept that makes the OPNsense into a SPOF, but if the router is down, not much will work anyway.

What is the best way to do this on an OPNsense business edition?

I have two internal DNS resolvers running on two different servers (different OS too). I currently give the IP addresses of both to the clients via DHCP, so each client gets two IP addresses to use as resolver (e.g. 192.168.1.5 and 192.168.1.6). But when one of these servers dies, the clients tend to remain stuck on that server for their DNS needs, and thus a lot of stuff starts failing. In general, it seems my clients (mostly Apple) don't really react to one of the DNS resolvers being unavailable, or at least not quickly.

I would like to add a virtual IP-address to OPNsense (e.g. 192.168.1.53) that passes traffic on to either 192.168.1.5 or 192.168.1.6, specifically UDP on port 53 of course, depending on availability. Is that possible and if so, how? I am running 24.10 business edition.

I'd like to see the 'Mode' (None/Active/Backup/Disabled) of a server in the Real Servers overview. Added this to github.

OK, my issue is now solved, but I am not sure why.

• I started with a GoDaddy-authenticated cert for my router, but the cert I ask for is a wildcard (not strictly necessary, but my router doesn't have a public DNS name and I like to keep it that way).
• I was hit my GoDaddy's sudden dropping everyone <50 certs from API access. My cert was still valid (until July 12)
• I spent a day trying to get CloudFlare and NameSilo running on OPNsense/ACME.sh, but failed. I did a few resets of teh ACME.sh plugin for OPNsense
• I moved to CNAME + self-hosted acme-dns, first getting that to work on another systems (Linux+Docker+certbot)
• I got acme-dns to work with the Linux+Docker+certbot system, but then for some reason, a test cert could be had via the ACME.sh plugin, but a production cert not
• I got the certbot+acme-dns working on macOS
• I still did not get it to work (production) on OPNsense. The log shows that curl fails to talk to my acme-dns server because of the cert acme-dns is setup with, but the other machine have no problem with that (fine) cert.

This was where I was when I posted the question.

Now, I did some editing and trial runs again. Staging cert worked. Then I tried production cert mostly to get logging for my problem-hunt. And lo and behold, suddenly it worked. It was able to use acme-dns, update the TXT record, and LE could validate.

Happy enough that it works now. But not really an idea why acme.sh from OPNsense first had problems connecting to my self-hosted acme-dns (with its curl throwing up the error with value 60, whereas the certbots on my LAN had no issue with it) where now it does work. A mystery.

I got acme-dns and certbot+plugin to work. My acme-dns service is fine.

I am starting to suspect OPNsense has an outdated Intermediate cert that is no longer used by LetsEncrypt.

ACME fails to create an update in my acme-dns service, which other machines on my LAN can do it and acme-dns seems to work properly.

From an inside machine (not the router), two successive updates with a slightly different value for TXT:

Code Select Expand

gerben@hermione% curl -X POST https://acmedns-service-lan.rna.nl:943/update -H "X-Api-User: <snip>" -H "X-Api-Key: <snip>" --data '{"subdomain": "1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe", "txt": "___validation_token_recieved_from_the_CA___"}'| python3 -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   161  100    54  100   107    646   1280 --:--:-- --:--:-- --:--:--  1939
{
    "txt": "___validation_token_recieved_from_the_CA___"
}
gerben@hermione% curl -X POST https://acmedns-service-lan.rna.nl:943/update -H "X-Api-User: <snip>" -H "X-Api-Key: <snip>" --data '{"subdomain": "1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe", "txt": "___validation_token_recEIved_from_the_CA___"}'| python3 -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   161  100    54  100   107    710   1407 --:--:-- --:--:-- --:--:--  2146
{
    "txt": "___validation_token_recEIved_from_the_CA___"
}
The logging from acme-dns says:

Code Select Expand

time="2024-06-10T12:57:04Z" level=info msg="Handler: Actual request"
time="2024-06-10T12:57:04Z" level=info msg="  Actual request no headers added: missing origin"
time="2024-06-10T12:57:04Z" level=debug msg="TXT updated" subdomain=1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe txt=___validation_token_recieved_from_the_CA___
time="2024-06-10T12:57:31Z" level=info msg="Handler: Actual request"
time="2024-06-10T12:57:31Z" level=info msg="  Actual request no headers added: missing origin"
time="2024-06-10T12:57:31Z" level=debug msg="TXT updated" subdomain=1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe txt=___validation_token_recEIved_from_the_CA___

These updates work, so my acme-dns is functioning. I can check that by resolving from the outside:

Code Select Expand

$ dig @acmedns-service.rna.nl -t txt 1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe

; <<>> DiG 9.11.36-RedHat-9.11.36-14.el8_10 <<>> @acmedns-service.rna.nl -t txt 1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12969
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe. IN TXT

;; ANSWER SECTION:
1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe. 1 IN TXT "___validation_token_recieved_from_the_CA___"
1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe. 1 IN TXT "___validation_token_recEIved_from_the_CA___"

;; Query time: 37 msec
;; SERVER: 213.125.118.50#53(213.125.118.50)
;; WHEN: Mon Jun 10 14:59:38 CEST 2024
;; MSG SIZE  rcvd: 249

And the logging from acme-dns says:

Code Select Expand

time="2024-06-10T12:59:38Z" level=debug msg="Answering question for domain" domain=1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe. qtype=TXT rcode=NOERROR

So it seems my acme-dns service is working properly.

But ACME from OPNsense cannot handle it. The System log says:

Code Select Expand

2024-06-10T13:17:13 opnsense-business AcmeClient: validation for certificate failed: *.rna.nl
2024-06-10T13:17:13 opnsense-business AcmeClient: domain validation failed (dns01)
2024-06-10T13:17:13 opnsense-business /usr/local/opnsense/scripts/OPNsense/AcmeClient/lecert.php: AcmeClient: The shell command returned exit code '1': '/usr/local/sbin/acme.sh --issue --syslog 7 --debug 3 --server 'letsencrypt' --dns 'dns_acmedns' --home '/var/etc/acme-client/home' --cert-home '/var/etc/acme-client/cert-home/6666dff9dbca50.73529818' --certpath '/var/etc/acme-client/certs/6666dff9dbca50.73529818/cert.pem' --keypath '/var/etc/acme-client/keys/6666dff9dbca50.73529818/private.key' --capath '/var/etc/acme-client/certs/6666dff9dbca50.73529818/chain.pem' --fullchainpath '/var/etc/acme-client/certs/6666dff9dbca50.73529818/fullchain.pem' --domain '*.rna.nl' --days '1' --force --keylength '4096' --accountconf '/var/etc/acme-client/accounts/63c416d30df460.27753549_prod/account.conf''

and the AMCE Log says:

Code Select Expand

2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] skip dns.
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] dns_entries
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] _clearupdns
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] No need to restore nginx, skip.
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] pid
#define WITH_DEFAULT_IPV 4
#define WITH_MSGLEVEL 0 /*debug*/
#define WITH_RETRY 1
#define WITH_FILAN 1
#define WITH_SYCLS 1
#define WITH_LIBWRAP 1
#undef WITH_FIPS
#define WITH_OPENSSL 1
#define WITH_PTY 1
#undef WITH_TUN
#undef WITH_READLINE
#define WITH_EXEC 1
#define WITH_SHELL 1
#define WITH_SYSTEM 1
#define WITH_PROXY 1
#undef WITH_NAMESPACES
#undef WITH_VSOCK
#define WITH_SOCKS5 1
#define WITH_SOCKS4A 1
#define WITH_SOCKS4 1
#undef WITH_POSIXMQ
#define WITH_LISTEN 1
#define WITH_UDPLITE 1
#define WITH_DCCP 1
#define WITH_SCTP 1
#define WITH_UDP 1
#define WITH_TCP 1
#undef WITH_INTERFACE
#define WITH_GENERICSOCKET 1
#define WITH_RAWIP 1
#define WITH_IP6 1
#define WITH_IP4 1
#undef WITH_ABSTRACT_UNIXSOCKET
#define WITH_UNIX 1
#define WITH_SOCKETPAIR 1
#define WITH_PIPE 1
#define WITH_TERMIOS 1
#define WITH_GOPEN 1
#define WITH_CREAT 1
#define WITH_FILE 1
#define WITH_FDNUM 1
#define WITH_STDIO 1
#define WITH_STATS 1
#define WITH_HELP 1
features:
running on FreeBSD version FreeBSD 13.2-RELEASE-p11 stable/24.1-n255007-1d6e165fb40 SMP, release 13.2-RELEASE-p11, machine amd64
socat version 1.8.0.0 on Apr 16 2024 13:14:23
socat by Gerhard Rieger and contributors - see www.dest-unreach.org
socat:
nginx doesn't exist.
nginx:
apache doesn't exist.
apache:
OpenSSL 1.1.1t-freebsd 7 Feb 2023
openssl:openssl
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] Diagnosis versions:
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] code='200'
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] _ret='0'
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.rto0x1MF -g '
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] _post_url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/362089707667/vY4KAg'
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] POST
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] payload='{}'
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/362089707667/vY4KAg'
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] =======Begin Send Signed Request=======
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] Please add '--debug' or '--log' to check more details.
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] _on_issue_err
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] Error add txt for domain:_acme-challenge.rna.nl
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] invalid response of acme-dns
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] response
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] _ret='60'
0140: ......
0100: .5.....|^..V...~.......S......./s?...n......?.IR..E^..7..e...5[C
00c0: .........$...Zy..M...5l..~.M.4.....W.....M. T...V.n}..+..{..KK.R
0080: ..240711215245Z0.1.0...U....*.rna.nl0.."0...*.H.............0...
0040: ...U....US1.0...U....Let's Encrypt1.0...U....R30...240412215246Z
0000: ...........0...0..............W..s........cf0...*.H........021.0
<= Recv SSL data, 2581 bytes (0xa15)
== Info: TLSv1.3 (IN), TLS handshake, Certificate (11):
0000: .
<= Recv SSL data, 1 bytes (0x1)
0000: ....&
<= Recv SSL data, 5 bytes (0x5)
0000: .............h2
<= Recv SSL data, 15 bytes (0xf)
== Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
0000: .
<= Recv SSL data, 1 bytes (0x1)
0000: ....
<= Recv SSL data, 5 bytes (0x5)
0000: .....
<= Recv SSL data, 5 bytes (0x5)
0040: .....'3......+.....3.$... ...O.U.U.w...H.`...uM..t.o..I..2
0000: ...v....|...!B....&....M.hy.....M.L!pz ...B.....0/.+T!..)...-4..
<= Recv SSL data, 122 bytes (0x7a)
== Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
0000: ....z
<= Recv SSL data, 5 bytes (0x5)
01c0: ................................................................
0180: ................................................................
0140: ....*....S...36.S...............................................
0100: ......................+............-.....3.&.$... ....+&.?.X=...
00c0: ................h2.http/1.1.........1.....*.(...................
0080: <.5./.....u.........acmedns-service-lan.........................
0040: .....'3.>.......,.0.........+./...$.(.k.#.'.g.....9.....3.....=.
0000: .......). ./'[.~...M.i2.o...D...K..... ...B.....0/.+T!..)...-4..
=> Send SSL data, 512 bytes (0x200)
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
0000: .....
=> Send SSL data, 5 bytes (0x5)
== Info: ALPN: curl offers h2,http/1.1
== Info: Connected to acmedns-service-lan (192.168.2.125) port 943
== Info: Trying 192.168.2.125:943...
== Info: IPv4: 192.168.2.125
== Info: IPv6: (none)
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] == Info: Host acmedns-service-lan:943 was resolved.
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] Here is the curl dump log:
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
2024-06-10T13:17:12 acme.sh [Mon Jun 10 13:17:12 CEST 2024] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.rto0x1MF -g '
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _post_url='https://acmedns-service-lan:943/update'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] POST
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] data='{"subdomain":"1f1c3244-8dbd-4d9e-8fa9-ee3bda01f9fe", "txt": "hxH0Ioya1YDUFDpt9U8qk9V87xSWRJVU_guMsFnbl0s"}'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] txtvalue hxH0Ioya1YDUFDpt9U8qk9V87xSWRJVU_guMsFnbl0s
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] fulldomain _acme-challenge.rna.nl
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] Using acme-dns
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] Adding txt value: hxH0Ioya1YDUFDpt9U8qk9V87xSWRJVU_guMsFnbl0s for domain: _acme-challenge.rna.nl
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] Found domain api file: /usr/local/share/examples/acme.sh/dnsapi/dns_acmedns.sh
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] d_api='/usr/local/share/examples/acme.sh/dnsapi/dns_acmedns.sh'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] txt='hxH0Ioya1YDUFDpt9U8qk9V87xSWRJVU_guMsFnbl0s'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] txtdomain='_acme-challenge.rna.nl'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _d_alias
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] d='*.rna.nl'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] vlist='*.rna.nl#o48qno-LyORkD7Y5YnDOi1BYtIkyBQyKWBogFRIVtXQ.Myo2wog0rUg4AoAJAY_dxLhBjjDhZ3QUo-swjma-_QM#https://acme-v02.api.letsencrypt.org/acme/chall-v3/362089707667/vY4KAg#dns-01#dns_acmedns#https://acme-v02.api.letsencrypt.org/acme/authz-v3/362089707667,'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] d
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] dvlist='*.rna.nl#o48qno-LyORkD7Y5YnDOi1BYtIkyBQyKWBogFRIVtXQ.Myo2wog0rUg4AoAJAY_dxLhBjjDhZ3QUo-swjma-_QM#https://acme-v02.api.letsencrypt.org/acme/chall-v3/362089707667/vY4KAg#dns-01#dns_acmedns#https://acme-v02.api.letsencrypt.org/acme/authz-v3/362089707667'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] keyauthorization='o48qno-LyORkD7Y5YnDOi1BYtIkyBQyKWBogFRIVtXQ.Myo2wog0rUg4AoAJAY_dxLhBjjDhZ3QUo-swjma-_QM'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] uri='https://acme-v02.api.letsencrypt.org/acme/chall-v3/362089707667/vY4KAg'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] token='o48qno-LyORkD7Y5YnDOi1BYtIkyBQyKWBogFRIVtXQ'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] entry='"type":"dns-01","status":"pending","url":"https://acme-v02.api.letsencrypt.org/acme/chall-v3/362089707667/vY4KAg","token":"o48qno-LyORkD7Y5YnDOi1BYtIkyBQyKWBogFRIVtXQ"'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _authz_url='https://acme-v02.api.letsencrypt.org/acme/authz-v3/362089707667'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _currentRoot='dns_acmedns'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _w='dns_acmedns'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] Getting webroot for domain='*.rna.nl'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] d='*.rna.nl'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] code='200'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _ret='0'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.rto0x1MF -g '
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _post_url='https://acme-v02.api.letsencrypt.org/acme/authz-v3/362089707667'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] POST
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] payload
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] url='https://acme-v02.api.letsencrypt.org/acme/authz-v3/362089707667'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] =======Begin Send Signed Request=======
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/1770125187/277106615897'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/1770125187/277106615897'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] code='201'
2024-06-10T13:17:11 acme.sh [Mon Jun 10 13:17:11 CEST 2024] _ret='0'
2024-06-10T13:17:10 acme.sh [Mon Jun 10 13:17:10 CEST 2024] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.rto0x1MF -g '
2024-06-10T13:17:10 acme.sh [Mon Jun 10 13:17:10 CEST 2024] _post_url='https://acme-v02.api.letsencrypt.org/acme/new-order'
2024-06-10T13:17:10 acme.sh [Mon Jun 10 13:17:10 CEST 2024] POST
2024-06-10T13:17:10 acme.sh [Mon Jun 10 13:17:10 CEST 2024] _ret='0'
2024-06-10T13:17:10 acme.sh [Mon Jun 10 13:17:10 CEST 2024] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.rto0x1MF -g -I '
2024-06-10T13:17:10 acme.sh [Mon Jun 10 13:17:10 CEST 2024] _post_url='https://acme-v02.api.letsencrypt.org/acme/new-nonce'
2024-06-10T13:17:10 acme.sh [Mon Jun 10 13:17:10 CEST 2024] HEAD
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] RSA key
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] payload='{"identifiers": [{"type":"dns","value":"*.rna.nl"}]}'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] url='https://acme-v02.api.letsencrypt.org/acme/new-order'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] =======Begin Send Signed Request=======
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] d
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] Getting domain auth token for each domain
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] Single domain='*.rna.nl'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] _createcsr
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] Read key length:4096
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] _saved_account_key_hash is not changed, skip register account.
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] d
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] _currentRoot='dns_acmedns'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] Check for domain='*.rna.nl'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] d='*.rna.nl'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] Le_LocalAddress
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] _chk_alt_domains
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] _chk_main_domain='*.rna.nl'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] _on_before_issue
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] Using CA: https://acme-v02.api.letsencrypt.org/directory
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ACME_NEW_NONCE='https://acme-v02.api.letsencrypt.org/acme/new-nonce'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ACME_AGREEMENT='https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ACME_REVOKE_CERT='https://acme-v02.api.letsencrypt.org/acme/revoke-cert'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ACME_NEW_ACCOUNT='https://acme-v02.api.letsencrypt.org/acme/new-acct'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ACME_NEW_ORDER='https://acme-v02.api.letsencrypt.org/acme/new-order'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ACME_NEW_AUTHZ
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ACME_KEY_CHANGE='https://acme-v02.api.letsencrypt.org/acme/key-change'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:09 CEST 2024] ret='0'
2024-06-10T13:17:09 acme.sh [Mon Jun 10 13:17:08 CEST 2024] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.J8dLzTVp -g '
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] timeout=
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] url='https://acme-v02.api.letsencrypt.org/directory'
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] GET
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] _init api for server: https://acme-v02.api.letsencrypt.org/directory
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] Using ACME_DIRECTORY: https://acme-v02.api.letsencrypt.org/directory
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] Le_NextRenewTime
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] DOMAIN_PATH='/var/etc/acme-client/cert-home/6666dff9dbca50.73529818/*.rna.nl'
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] Using config home:/var/etc/acme-client/home
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] _alt_domains='no'
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] _main_domain='*.rna.nl'
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] Running cmd: issue
2024-06-10T13:17:08 acme.sh [Mon Jun 10 13:17:08 CEST 2024] Using server: https://acme-v02.api.letsencrypt.org/directory
The curl call from acme.sh fails, it seems, on a certificate issue (error 60). But why? It seems I am so so close, but I can't get it to work.

My OPNsense router doesn't use the inside DNS so it isn't dependent on it. This means it always goes outside for resolving. What I did for now is add a private IP A entry in my public DNS. That way, I can explicitly tell the router to go to the inside machine for the /update API. This works.

I have another issue, I'll create a separate post for that.

I do not fully understand your suggestion, sorry (not too regular work for me, this).

Suppose the router is at 192.168.2.2.
There is a mail server running on 192.168.2.15:25, which on the outside is 100.100.100.53:25 and in between is haproxy on 192.168.2.2
There is a DNS server running on 192.168.2.16:953, which on the outside is 100.100.100.54:53
There is a DNS server running on 192.168.2.16:53, which is LAN-only
There is a HTTPS server running on 192.168.2.16:443, which on the outside is 100.100.100.54:443
If I go outside to the WAN, to somewhere else, my outgoing traffic seems to come from

• 100.100.100.53 if it is going to port 25 (outgoing NAT rule so that my mail server's DNS name fits the reverse DNS when connecting other mail servers
• 100.100.100.51 for all other traffic

I want system 192.168.2.10 go to 192.168.2.16:953, but it should arrive there as if it comes from src 100.100.100.51 and it tries to connect to 100.100.100.54:53

Currently, with my setup, I can connect to the mail server from the LAN to the WAN address
```
gerben@192.168.2.10% nc -v 100.100.100.53 25
Connection to 100.100.100.53 port 25 [tcp/smtp] succeeded!
220 mail.rna.nl
```
But the postfix mail server's log says (uit knows about haproxy)
```
Jun 10 14:23:54 hermione smtp_haproxy/postscreen[95404]: CONNECT from [192.168.2.10]:61001 to [192.168.2.2]:25
```
And all other public IPs and ports fail, e.g.
```gerben@192.168.2.10 nc -v 100.100.100.54 443``` simply hangs.

From an outside machine it works:
```
$ nc -v -z 100.100.100.54 443
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 100.100.100.54:443.
Ncat: 0 bytes sent, 0 bytes received in 0.04 seconds.
```

How setting up a NAT rule on the LAN helps here, I do not understand.