Messages

ok - since there was a new update to the plugin I decided to come back to this.

As suggested, I turned off proxy in Cloudflare but it did not work.  When I tried to browse to ha.example.com I got a BitDefender pop-up on my host machine saying 'Suspicious page blocked for your protection', and when I tried it in the W11 Sandbox of my host machine (that doesn't run Bitdefender) I got a message saying 'Your connection isn't private' and when I advance beyond that 'This page isn't working right now'.

So I decided to take Cloudflare out of the picture, and try it with Duckdns instead.

I setup duckdns entries for:  example.duckdns.org and ha-example.duckdns.org

In Caddy I setup up a domain record for example.duckdns.org and an associated http handler.  In the domain I used Certificate ACME (HTTP-1, TLS-ALPN-01), plus checked DNS-01 Challenge and Dynamic DNS.  In the Handler I checked TLS Insecure Skip Verify.  With this setup I can now browse to example.duckdns.org and get a valid ssl connection to myOPNSense box! Yeah!

I then tried to setup ha-example.duckdns.org in the same way to point to my HomeAssistant box.  The only difference was the IP address and the Port in the Handler.   However, when I browse to https://ha-example.duckdsn.org:8123  I get ERR_CONNECTION_TIMED_OUT. 

Now the scarry part.

Beyond that, and yikes, when I browse to https://ha-example.duckdns.org  (no port)  or https://ha-example.duckdsn.org:443 I get redirected to a malware site.  The same sort of thing happened last week in my testing - but I got directed to survey-smiles (or something like that) (after a few days it was clunen.com/xr.php?e=iqXRc and a bunch of other stuff which I assume amounted to some sort of injection attack ) (both of which Bitdefender was blocking) but now its redirecting to https : //crrds70hubcc73ba0m30.securedjointnetwork.co.in/01/?cid=ac910b88f486f12d .... (asking me to click on some box to prove I'm not a robot which I suspect Bitdefender should be blocking but is not)  Of note: in the link above I manually added a space between the s, colon, and slash so this post would not have that show up as a hyperlink.

Originally, I thought perhaps my PC had a virus, but I scanned it and it came up clean.  Also, at the time, as I remember it I was getting the same redirect in the W11 sandbox and on a Raspberry pi running Raspberry OS.   I am now not getting it in Windows sandbox, nor on the Raspberry Pi OS - but neither of those are connecting to my home assistant box either.

Of note - I do not have a certificate on my home assistant box (a dedicated Raspberry Pi) as I understood Caddy didn't need one to allow the connection to be secure.

A lot to digest for sure.

Thanks again.

I just spent the better part of another two hours at this and just can't get it to work.

While I can get ddns to work with cloudflare for the generic wild card *.example.com I can't get it to work with any of the subdomains.  HTTP-01 Challenge Redirection is not going to work, as I don't have a host behind the registered domain, just the registered domain - which means only DNS-01 Challenge is going to work but as I can only use  DNS-01 Challenge at the domain level, all my subdomains can't be setup for ddsn.

Beyond that, I never was able to get a subdomain to resolve correctly.

I tried the idea of various *.example.com subdomains, each with there own unique port - but even though that is noted as 'supported' they are not resolving correctly for me.   Also, even if I could get it to work the theory in behind using them assumes each unique port is only used once across all machines in my network.  So for example if pikvm uses port 443, then no other machine in my network would be able to use it.

I would like to thank @Monviech, @cloudz, and @Patrick M. Hausen for helping me out - but ultimately, I'm just going to have to put this down now as I've already dumped way too much time into it without getting the outcomes I was looking for.   However, my system does now resolve the opnsense box via ssl with is the silver lining in all of this for me, it just those pesky other machines on my internal network that I couldn't get working.

Again, with my sincere thanks!

[Caddy Web Server: Reverse Proxy - Domains]

Well I needed to use specific entries as opposed to one wildcard entry and subdomains as my individual machines on my internal network need to be accessed via different ports, for example HomeAsssistant uses 8123, while the PiKVM uses 443.  With subdomains I can't specify a port - which is what I suspect the documentation was alluding to where it reads:

If in doubt, do not use subdomains. If there should be foo.example.com, bar.example.com and example.com, just create them as three base domains. This way, there is the most flexibility, and the most features are supported.

regardless, what I've just done was add a *.example.com entry in my Services: Caddy Web Server: Reverse Proxy - Domains, and in CloudFlare, and in CanSpace (my domain registry service), updated my Cloudflare api token, and in the Caddy plugin removed dynamic dns from my pikvm.example.com, ha.example.com and router.example.com domains, and added it in the wildcard domain.

Now when I disable and enable Caddy I the error messages for the pikvm, ha, and pikvm are gone, but there is an information message for the wild card domain that reads:

   "info","ts":"2024-09-20T17:09:52Z","logger":"dynamic_dns","msg":"domain not found in DNS","domain":"*.example.com"}

Which probably means it is not working - any may have not been working yesterday as well and I didn't notice it as it comes up as info rather than a warning or an error.

[nslookup pikvm.example.com]

@Monviech , @cloudz

Thank you for your suggestions:

I went through the https://docs.opnsense.org/manual/how-tos/caddy.html#help-nothing-works documentation but couldn't find the solution

However, I notice the command nslookup pikvm.example.com responds with:

Server:  router.example.com
Address:  192.168.1.1

Non-authoritative answer:
Name:    pikvm.example.com
Addresses:  2606:4700:3036::6815:a7b
          2606:4700:3030::ac43:be24
          104.21.10.123
          172.67.190.36

with those ipv4 and ipv6 addresses mapping back to CloudFlare not to my external IP address - so I'm not sure why?

Also, I am now getting these errors in my log (where xxx = each of router, ha, and pikvm)

Error   caddy   "error","ts":"2024-09-20T16:11:40Z","logger":"dynamic_dns","msg":"failed setting DNS record(s) with new IP address(es)","zone":"xxx.example.com","error":"expected 1 zone, got 0 for router.rlatour.ca"}

I had gotten them yesterday, but got rid of them by unchecking Dynamic DDS in Services: Caddy Web Server: Reverse Proxy but now that I have them checked again I see that the errors again.  So I assume the dynamic dns isn't working either.

@cloudz

I tried changing to cnames, but that didn't work either.   I ran into this yesterday, and had more success with A records.

Also, I read thru the documentation and tried truning on hairpinning but with no success - perhaps I did that wrong too as the doc assumes a dmz which I don't have.

I've been working on this literally all week, not sure what the issues are but have appreciated your help.

Yesterday, with help from this forum, I got Caddy to provide ssl access to my OPNSense router - which was for me a great first step.

Today, for the second step, I had hoped to get it working for some local machines - for example one running Home Assistant and another PiKVM.

At first I tried the subdomain route - but couldn't get it to work.  Also, I found it didn't let me use specific ports - so I attempted to follow the advice of the documentation here: https://docs.opnsense.org/manual/how-tos/caddy.html#wildcard-domain-with-subdomains

If in doubt, do not use subdomains. If there should be foo.example.com, bar.example.com and example.com, just create them as three base domains. This way, there is the most flexibility, and the most features are supported.

but did not succeed.

For this this I removed the wildcard entries I had previously used, and replaced them with three domains:

router.example.com
ha.example.com
pikvm.example.com

router.example.com is working fine.

ha.example.com and pikvm.example.com are not.

When I try to browse to either ha.example.com or pikvm.example.com I get a CloudFlare page served up that says Connection timed out - 502.

There are no error, warning or even informational entries in my Caddy log to show what might be going on.

My registry domain dns records are set up as follows:

Name                     Type        TTL          RDATA 
@                           A            14400      xxx.xxx.xxx.xxx
@                           NS          86400      xxxxx.ns.cloudflare.com
@                           NS          86400      xxxx.ns.cloudflare.com
ha.example.com      A            14440      xxx.xxx.xxx.xxx
pikvm.example.com A            14440      xxx.xxx.xxx.xxx
router.example.com A            14440      xxx.xxx.xxx.xxx
www                        CNAME      14440      example.com

My Cloudflare records are as follows:
Type     Name            Content               Proxy status    TTL      
A          ha                 xxx.xxx.xxx.xxx   Proxied          Auto
A          pikvm            xxx.xxx.xxx.xxx   Proxied          Auto
A          example.com  xxx.xxx.xxx.xxx   Proxied          Auto
A          router            xxx.xxx.xxx.xxx   Proxied          Auto
CNAME  www              example.com       Proxied          Auto

For the IP addresses of the two machine, even though I think the right think to do is use the external addresses, I have also tired using my internal IP address (non proxied) such as 192.168.1.123 ; but when I used the internal address they didn't work either.  Also, CloudFlare throws an error if I try to use the internal ones and Proxy them.  My gut feel I should be using external proxied addresses so Caddy can set them to what it needs.

In any case, here too is my Caddy file:

Code Select Expand



# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# caddy_user=root

# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}

dynamic_dns {
provider cloudflare xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
domains {
ha.example.com @
pikvm.example.com @
router.example.com @
}
versions ipv4
}

email me@example.com
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}
# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# caddy_user=root

# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}

dynamic_dns {
provider cloudflare xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
domains {
ha.example.com @
pikvm.example.com @
router.example.com @
}
versions ipv4
}

email me@example.com
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


# Reverse Proxy Domain: "bf960db4-a3f6-432c-8be4-be6ed247d7b2"
ha.example.com {
tls {
issuer acme {
dns cloudflare xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
resolvers 1.1.1.1
}
}

@b91182d4-6b27-4ef1-a8a3-8d45e1578a76 {
client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @b91182d4-6b27-4ef1-a8a3-8d45e1578a76 {
handle {
reverse_proxy 192.168.1.173:8123 {
transport http {
tls_insecure_skip_verify
}
}
}
}
}
# Reverse Proxy Domain: "9a3a66c5-aeff-4401-a697-b34de6525a10"
pikvm.example.com {
tls {
issuer acme {
dns cloudflare xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
resolvers 1.1.1.1
}
}

@b91182d4-6b27-4ef1-a8a3-8d45e1578a76 {
client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @b91182d4-6b27-4ef1-a8a3-8d45e1578a76 {
handle {
reverse_proxy 192.168.1.166:443 {
transport http {
tls_insecure_skip_verify
}
}
}
}
}
# Reverse Proxy Domain: "17af584e-7fcf-4ca0-b5f9-fbd9712f95e4"
router.example.com {
tls {
issuer acme {
dns cloudflare xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
resolvers 1.1.1.1
}
}

@b91182d4-6b27-4ef1-a8a3-8d45e1578a76 {
client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @b91182d4-6b27-4ef1-a8a3-8d45e1578a76 {
}
}

import /usr/local/etc/caddy/caddy.d/*.conf





I have also tried both handlers without tls_insecure_skip_verify - but it still didn't work.


Also, and as and aside although I don't think it matters much, when I deleted the wild card entry from before, and when I created and then deleted some other Services: Caddy Web Server: Reverse Proxy - Domains it appears their certificates are still hanging around (as I see them in the Dashboard under the Caddy Certificates widget) rather being cleaned up when their associated domains were deleted.  I suppose it is possible these unused certificates may be getting in the way some how - but I don't know how to otherwise get rid of them.

Any help would be much appreciated.

Thank you.

It worked!

You are my hero! 

[Services: Caddy Web Server: General Settings : DNS Provider tab]

Thank you @Monviech - but it appears I'm still not there - to recap:

Services: Caddy Web Server: General Settings : DNS Provider tab
DNS Provider                        CloudFlare
DNS API Standard Field         my CloudFlare token is here
Resolvers                             1.1.1.1

Services: Caddy Web Server: Reverse Proxy : Domains tab
Enabled               checked
Domain                *.example.com
Port                     443
Dynamic DNS       unchecked (your comments above had an X, but also said '(you dont need dynamic DNS here' so I was unsure of this?
Custom Certificate   None
Access List              privatre_ipV4 Allow access from private IPV4 range  (from Docs)

Services: Caddy Web Server: Reverse Proxy : Subdomains tab
Enabled               checked
Domain                *.example.com 443
Subdomain           router.example.com
Dynamic DNS       checked

After that I disabled and enabled caddy to try certificates again.

Did not work.

Code Select Expand

2024-09-18T14:20:05-04:00 Error caddy "error","ts":"2024-09-18T18:20:05Z","logger":"tls.obtain","msg":"will retry","error":"[*.example.com] Obtain: [*.example.com] solving challenges: *.example.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme.zerossl.com/v2/DV90/order/OVH8CgD_qmLgyGglHeMUNA) (ca=https://acme.zerossl.com/v2/DV90)","attempt":1,"retrying_in":60,"elapsed":1.461963369,"max_duration":2592000}
2024-09-18T14:20:05-04:00 Error caddy "error","ts":"2024-09-18T18:20:05Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.example.com","issuer":"acme.zerossl.com-v2-DV90","error":"[*.example.com] solving challenges: *.example.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme.zerossl.com/v2/DV90/order/OVH8CgD_qmLgyGglHeMUNA) (ca=https://acme.zerossl.com/v2/DV90)"}
2024-09-18T14:20:04-04:00 Error caddy "error","ts":"2024-09-18T18:20:04Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.example.com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"[*.example.com] solving challenges: *.example.com: no solvers available for remaining challenges (configured=[http-01 tls-alpn-01] offered=[dns-01] remaining=[dns-01]) (order=https://acme-v02.api.letsencrypt.org/acme/order/1952357436/306264234986) (ca=https://acme-v02.api.letsencrypt.org/directory)"}


EDIT: I noticed you didn't say that I should specify a port on the Services: Caddy Web Server: Reverse Proxy : Domains tab so I removed it.  This changed the Sub Domains entry so I selected the domain as *.example.com  (not *.example.com 443 as it previously read) and tried it again.  Still not working.

Thank you,

Originally, I did have an A record with a name of router.example.com pointing to my ip address - but it did not work; it was generating the same error messages in the logs.

Regardless, after reading your suggestion, I removed the two cname records:
router.example.com   CNAME   14440   example.com
*.example.com          CNAME   14440   example.com

and re-created an A record to replace it:
router.example.com   A             14440   xxx.xxx.xxx.xxx

and tried it again - by which I mean that I go in to OPNSense - Services: Caddy Web Server: Reverse Proxy, edit the domain record, don't make changes, save it, and clicked Apply (which I have found generates a series of log entries showing the error - which I take as the system is trying it again).

However, it generated the same error messages in the log.

Also, I had previously set up the Services: Caddy Web Server: General Settings - DNS Provider to use CloudFlare, and I pasted the API Tolken created as per this webpage walkthru https://homenetworkguy.com/how-to/replace-opnsense-web-ui-self-signed-certificate-with-lets-encrypt/ . 

This portion of my setup had remained unchanged when I ran the most recent attempt to get this working as refenced above.  Regardless, I have now since gone into Cloudflare and removed the existing DNS API entry and created a new one, and got the new token from that (as I believe somewhere I read the Cloudflare token can only be used once) which I then used to update within Services: Caddy Web Server: General Settings - DNS Provider.

I then tried it again (as explained above) but it still didn't work - same errors.

Dynamic DNS has been enabled throughout all of this.

Unless I get other feedback between now then, I will wait another hour (to wait past the one hour wait period between multiple failed certification request attempts ) and then recreate another CloudFlare token and try it again.

Using the OPNSense Caddy plug in - I can't seem to the automatic certificates to work.

I've followed and reviewed the instructions at https://docs.opnsense.org/manual/how-tos/caddy.html (several times) and watched the video at https://www.youtube.com/watch?v=6ip8Sx4zcDA many times, however, I can't seem to get automatic certificates to work.

screenshot of what I am getting on the dashboard: https://ibb.co/5TLqKzM
greyed out is my hostname . domain name - but it matches the hostname and domain name found in OPNSense - System - Settings - General.  For example:  router.example.com

Having that said, I do seem to have a valid certificate for the hostname . domain in system trust certificates - due to expire in December.  Not sure how it got there - I've tried many things, and prior to this I had been using the acme client (now uninstalled - so maybe it was created from there).   I am however hesitant to delete it from trust so that I could take a fresh run at all this; Regardless, I tried and it said it was being used by webgui and AcmeClient - validation for OPNSense router {AcmeClient.certificates.certificate.xxxx-xxxxx-xxx...-xxx}


My domain dns records look like this:

Name                        Type          TTL   RDATA 
@                             A           14400   xxx.xxx.xxx.xxx
@                             NS           86400   xxxx.ns.cloudflare.com
@                             NS           86400   xxxx.ns.cloudflare.com
www                         CNAME   14440   example.com
router.example.com   CNAME   14440   example.com
*.example.com          CNAME   14440   example.com

These are the errors I see in the log is:

Code Select Expand

2024-09-18T11:11:08-04:00 Error caddy "error","ts":"2024-09-18T15:11:08Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"router.example.com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:dns - DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain"}
2024-09-18T11:11:08-04:00 Error caddy "error","ts":"2024-09-18T15:11:08Z","logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"router.example.com","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]},"order":"https://acme-v02.api.letsencrypt.org/acme/order/1952357436/306227172126","attempt":2,"max_attempts":3}
2024-09-18T11:11:08-04:00 Error caddy "error","ts":"2024-09-18T15:11:08Z","logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"router.example.com","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]}}
2024-09-18T11:11:06-04:00 Error caddy "error","ts":"2024-09-18T15:11:06Z","logger":"tls.issuance.acme.acme_client","msg":"validating authorization","identifier":"router.example.com","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]},"order":"https://acme-v02.api.letsencrypt.org/acme/order/1952357436/306227166306","attempt":1,"max_attempts":3}
2024-09-18T11:11:06-04:00 Error caddy "error","ts":"2024-09-18T15:11:06Z","logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"router.example.com","challenge_type":"http-01","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: NXDOMAIN looking up A for router.example.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for router.example.com - check that a DNS record exists for this domain","instance":"","subproblems":[]}}
2024-09-18T11:11:04-04:00 Error caddy "error","ts":"2024-09-18T15:11:04Z","logger":"tls","msg":"job failed","error":"router.example.com: obtaining certificate: [router.example.com] Obtain: [router.example.com] solving challenges: [router.example.com] context canceled (order=https://acme.zerossl.com/v2/DV90/order/jmMN4DSlnzSi3PaZlGl9aQ) (ca=https://acme.zerossl.com/v2/DV90)"}
2024-09-18T11:11:04-04:00 Error caddy "error","ts":"2024-09-18T15:11:04Z","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"router.example.com","issuer":"acme.zerossl.com-v2-DV90","error":"[router.example.com] solving challenges: [router.example.com] context canceled (order=https://acme.zerossl.com/v2/DV90/order/jmMN4DSlnzSi3PaZlGl9aQ) (ca=https://acme.zerossl.com/v2/DV90)"}
2024-09-18T11:11:04-04:00 Error caddy "error","ts":"2024-09-18T15:11:04Z","logger":"tls.issuance.acme.acme_client","msg":"deactivating authorization","identifier":"router.example.com","authz":"https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw","error":"attempt 1: https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw: context canceled"}
2024-09-18T11:11:04-04:00 Error caddy "warn","ts":"2024-09-18T15:11:04Z","logger":"tls.issuance.acme.acme_client","msg":"HTTP request failed; retrying","url":"https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw","error":"performing request: Post \"https://acme.zerossl.com/v2/DV90/authz/9L4C-rZlm-gfP4mrONWqDw\": context canceled"}

Note: all references to example.com and router.example.com have been included above to safeguard privacy, the actual domain name is used on my system in real life.

When I make changes, I wait an hour - which is making this a long process, but have yet to have success so I though at this point it would be best to reach out for help.

Any help would be appreciated.

This plug in looks great - but also a bit over my paygrade.

I've read thru the documentation, and this post, and have a request ...

Would it be possible to put together a youtube video showing a setup walk through for the following scenario (which I suspect would be beneficial for many homelab users):

Assuming the user already has a registered domain name ( for example: example.com )
Assuming they are already set up with a Cloudflare account

The video to show what would be required in OPNSense / the caddy plug in to:

set up to have a certificate that automatically renews associated with example.com

set up to have caddy used to securely reference specific internal addresses such as:

opnsense.example.com
homeassistant.example.com
openmediavault.example.com
jellyfin.example.com
etc.
(on which ever ports are required)

setup to ensure none of the above can be accessed externally from the internet  (i.e. access only applies to internal accesses)

setup to have the external ip address of example.com updated via Cloudflare when it changes.

Looks great!

Thanks for your observation, it really helped further solidify for me the reason that rules aren't evaluated between devices working under the same interface umbrella.

I was trying to 'protect' a particular device with an additional level of restrictions around it - that it to say allow some devices on my network interface to have access to it and others not.  In the end I just moved it to its own separate interface and from there I have been able to allow and restrict the accesses I wanted quite easily.

Well well well, that would certainly explain it.  Thank you.

I've been working on this for hours, can you please help me figure out what am I missing?

Why is this ping not being blocked?

Here are screen shots of my ping and the rules.
https://ibb.co/P6PGcxS
https://ibb.co/qgyJcLK

I also tried disabling all the floating rules, but they had no impact on my test results.

Should the ping not be returning that it can't reach the destination?

It looks like that via the OPNsene API you can enable/disable rules that defined on the Firewall - Filter - Automation window, but you not those that are defined under a Firewall - interface window.  For example if you have rules defined under Firewall - LAN you cannot enable/disable them using the OPNsense API.

I am using the Community edition, so maybe this is possible in the business edition - but the help documentation doesn't seem to say that it is.  Is this the case? 

I just want to be sure before opening up a feature request for it.