Recent posts

#81

25.7, 25.10 Series / Re: Monitoring gateway status ...

Last post by julsssark - November 22, 2025, 03:58:48 AM

Thank you Meyergru! You led me to the right solution. In researching how to parse the status of the specific gateway, I realized that I was using the wrong JSON expression notation. Uptime Kuma uses JSONata and not JSONpath. I also learned that if you clear off the last error message and the same error exists, you won't get a new error message. In case anyone else finds this thread:

* You can query for a specific gateway status using: items[name="XXX"].status_translated == Online where XXX should be replaced with the gateway name you want to monitor
* The correct syntax for checking the success of the gateway request: status == ok (not $.status == ok)
* Select basic auth from the Authentication method dropdown, put the key in for the username and the secret for the password

If you just need basic up/down monitoring in your home lab, I highly recommend Uptime Puma.

#82

25.7, 25.10 Series / Re: Decoding "detailed rule in...

Last post by pfry - November 22, 2025, 02:46:07 AM

[...]I click on the rid link, OPNsense opens a new window [...], but then immediately closes the window[...]

Sounds like an automatic rule. Those don't have configuration pages.

As for the rule info, that's the automatic default deny ("label  Default deny / state violation rule"). It looks rather like you don't have an appropriate pass rule on vtnet0 ("interface  vtnet0") for HTTPS ("dstport  443"), but the TCP flags ("tcpflags   RA") indicate a reset/reject (TCP term/firewall term, respectively), from the client (not the server, where it might be the Watchguard). If in fact you have an appropriate pass rule for HTTPS on vtnet0, this indicates a TCP RA packet outside of an established session; if you do not, it's an odd client behavior, as you can't start a session with a reset. Circumstances where you normally see this include multiple network paths (where at least one bypasses the firewall), junk from the Internet (not normally in this direction), or when the firewall state table is cleared. I suppose if you used the client HTTPS request to set up the tunnel, delay and/or packet loss could upset the client, and a reset might appear to the firewall to be outside of an established session. This circumstance should be temporary. I haven't actually set up a tunnel in about 15 years (and never on OPNsense), so I'm a bit behind the times.

By the way, you can locate the rules by rid under "Firewall: Diagnostics: Statistics" -> "rules" -> "filter rules" (the "label" field, not the same as the text label/Description).

#83

General Discussion / OPNSense VM to manage ACME/LE/...

Last post by bernieo - November 22, 2025, 02:21:21 AM

Hi
I'm trying to set up OPNsense to request and manage renewals of SSL certs.  The server should work together with a separate HAProxy server, which should handle the receipt of cert uploads for client machines.
My problem is I can't seem to get certificate (.PEM) files to upload successfully from OPNsense using remote SFTP/SSH.

Using a small script:

Code Select Expand

mkdir -p /root/testcert
cd /root/testcert

# Self-signed test cert (doesn't matter what it is)
openssl req -x509 -nodes -newkey rsa:2048 \
  -keyout test.key \
  -out test.crt \
  -subj "/CN=mydomain.com" \
  -days 1

cat test.crt test.key > test.pem

Now push it to HAProxy:

Code Select Expand

cat /root/testcert/test.pem | \
  ssh -i /var/etc/acme-client/sftp-config/id.ed25519 \
      -p 22 \
      acme-certpusher@192.168.99.252 \
      "mydomain.com"




The 2 errors I keep getting are:

1. bash: line 1: mydomain.com: command not found

2. It seems OPNsense ACME automation (type "SSH remote command") does not pipe any certificate data so I end up with:

Code Select Expand

Nov 21 12:54:36 mydomain acme-certpush[142212]: Fri Nov 21 12:54:36 GMT 2025 Starting certpush for domain/command: mydomain.com
Nov 21 12:54:36 mydomain acme-certpush[142220]: PEM missing certificate block
The indication is that I'm not getting the fullchain.pem, which is supposed to end up in /etc/haproxy/certs/domainx/.
On checking OPNsense, I can see the fullchain.cer, the mydomaain.com/cer .csr & .key , sitting in /var/etc/acme-client/cert-home/12345678901112.84768251/mydomain.com

Can anyone tell me if this plan, of running separate HAProxy instead of HAProxy running on OPNsense, will work?

[vlan]

#84

25.7, 25.10 Series / Re: Adding a VLAN takes 26 cli...

Last post by mtlynch - November 22, 2025, 01:43:03 AM

Basically what people are asking for is a setup wizard. We'll be extending the existing wizard with a few use-case type presets in 26.1 but nothing that resembles a non-first-time setup yet.

Not sure if this is in response to the blog post or subsequent discussion, but I think one of the important pieces here is that OPNsense in a lot of places asks the user to manually enter data when OPNsense already knows the answer:

• On the create VLAN device page, OPNsense insists the user manually prefix the name with vlan
• On the DHCPv4 page, OPNsense makes the user type the IP range assignment instead of defaulting to the full range of the subnet

I also feel like there are low-lift opportunities to improve the default options, like when the user assigns a static IPv4 to a VLAN, the default is a /32, when it feels like /24 is likely a more common choice. I think on a lot of these "whatever the user chose last time" would be a pretty good default.

[*]

#85

25.7, 25.10 Series / Re: Transparent Filtering Brid...

Last post by Jose - November 21, 2025, 11:55:51 PM

Hello, I will post my rather clunky TFB setup and my own answer, in case someone is asking for a similar config on a Transparent Filtering Bridge with slightly different config from the How-To's, just for the non-networking guys like me, IPv6 is completely disabled in this example*.

This requires for 3 interfaces as expected, in my case two physical IF(passthrough) for the [TFB] and one virtual admin IF(vtnet0, virtio).

Scenario, you follow the How-To to setup an TFB, but added an 3rd interface to administer OPNsense, now Updates and/or Plugins downloads does not work because you've set the Transparent Filtering Bridge related interfaces to NONE as recommended in the How-To:

Set Interfaces [WAN] + [LAN] + [BRIDGE] to:
  IPv4 Configuration Type: NONE
  IPv6 Configuration Type: NONE*

However since we added a 3rd interface for admin, all we have to do is to set the Gateway for it under [System: Gateways: Configuration], my admin interface is called [ADM]:
You cannot view this attachment.

Now under [System: Settings: General] I've set the preferred DNS to use that Gateway (192.168.0.1):
You cannot view this attachment.

After reboot OPNsense is now able to update and install plugins again thru the admin interface while leaving its pure Transparent Filtering Bridge operation intact:
You cannot view this attachment.

However in my case this was a bit different as the OPNsense is a VM guest and the admin virtual interface(vtnet0) is connected to the host(Bhyve) on the public switch, so the admin interface internet-connection will be thru the hypervisor which in contrast loops back to the TFB access-point.

Regards

#86

25.7, 25.10 Series / Re: Monitoring gateway status ...

Last post by meyergru - November 21, 2025, 11:24:26 PM

I just did that and it works fine the way you described it - although the $.status probably is only the request status, not the status of a specific gateway in the response (you would have to select that).

Of course, you have to have an API key and secret, those must not be quoted in the Uptime Kuma input fields. You can use them verbatim as in the curl parameters. The key must be associated to a user that has the appropriate permissions, but if it did not, you would be getting an error with curl as well.

Since you do not get any qualified error at all: Can your Uptime Kuma instance access the HTTPS port of your OpnSense or is it blocked by a firewall rule? You can check by using a plain HTTPS request.

#87

25.7, 25.10 Series / Re: High CPU on Dashboard

Last post by JimmyLostOne - November 21, 2025, 11:01:29 PM

I'm seeing something similar since upgrading to 25.7.  Same CPU spikes on dashboard loads, same errors in the logs, but I also see some of the widgets failing to load.  I'm curious if this has to do with the number of widgets and types?  Seems like a bunch of connections being opened for each widget?

My specs:
J4125 Intel
8G DDR4
Msata 128G drive
6x I226v7

----------- This turned out to be a ram issue on my part, so I retrack my original statement :D

#88

25.7, 25.10 Series / [Solved] Monitoring gateway st...

Last post by julsssark - November 21, 2025, 10:36:10 PM

I am trying to monitor the status of my WAN gateway using Uptime Kuma and the OPNsense API. Despite my best efforts and google skills, I cannot get it to work and would appreciate any help. The monitor is showing red/down continually and there are no errors in the Uptime Kuma messages area. I am pretty sure it is an error in the way I am configuring Uptime Kuma. Here's what I have done:

1) Setup a new user, with access to the Gateways and generated the key/secret
2) Used CURL -k -u "<key>":"<secret>" https://myIP/api/routes/gateway/status from the Uptime Kuma console and I get the expected response
3) Configured Uptime Kuma as follows:

• Monitor type = HTTP(s)-Json Query and the URL is the same as in step #2
• Json Query expression and associated fields are set to $.status == ok
• Method is GET, body encoding is JSON and body/header fields are blank
• Authentication is set to basic auth and I put the key/secret into the username/password fields

I've tried various combinations of putting the authorization into the header/body, encoding the key/secret into base64, checking/unchecking the "ignore TLS/SSL errors". I'm probably just not using the right combination of things.

#89

General Discussion / Re: Rule confusion between sep...

Last post by meyergru - November 21, 2025, 09:29:45 PM

Usually, you will want an "in" rule like "allow any to any" for normal LANs and there is such a default rule for the first LAN.

However, this is generally too broad, because it allows access to any other (V)LAN when applied to all (V)LANs. The general recommendation is to use a "block any to RFC1918" rules before the "allow any to any" rule, with RFC1918 created as an alias for all RFC1918 ranges.

You can achieve the same effect if you deny access for specific destination interfaces.

Usually, you will have one or more (V)LANs that really have the permission to allow access to all other (V)LANs, like your main LAN or a Management VLAN. Only for those, you will not define a block rule.

#90

High availability / Re: HA setup is flapping betwe...

Last post by Tanker_UA - November 21, 2025, 09:25:06 PM

I just completely removed the backup firewall/router from my network, and all is working correctly. Until I get this resolved, I will not connect the backup unit to my network. It is amazing how little help I got from these forums! I wonder if I paid for a license (which I'm inclined to do so there are no excuses for lack of support), I would get the same treatment from the pricey support.

Thank you all,

Martin M. Mune
US Army Combat Veteran
Operation Iraqi Freedom
 
Volunteer Soldier
International Legion for the Defense of Ukraine

Слава Україні!
Героям Слава!