Messages

I'm already doing that with adguard, they are not accessible outside my network.

Yes that's the problem, it is blocked but I can still access it, if I use the domain which causes it to be routed through Caddy it is serving the page on 443 through https even though that port should be blocked, thus preventing access to the webui. However if I go to https://192.168.1.1:443 I get a rejected response as expected.

Welp I set this up today here's a write up of what I did.

1. Download beszel_agent to `/usr/local/bin`
2. Create `beszel_agent` in `/usr/local/etc/rc.d/` with the following contents:

Code Select Expand

#!/bin/sh
#
# PROVIDE: beszel_agent
# REQUIRE: DAEMON
# KEYWORD: shutdown
#
# This script starts bezel-agent at system boot.
#
. /etc/rc.subr

name="beszel_agent"
rcvar=beszel_agent_enable

command="/usr/local/bin/beszel-agent"
command_args=""
pidfile="/var/run/${name}.pid"

load_rc_config $name
: ${beszel_agent_enable:="NO"}

# Ensure required environment variables are set.
if [ -z "${beszel_agent_key}" ] || [ -z "${beszel_agent_port}" ]; then
    echo "ERROR: beszel_agent_key and beszel_agent_port must be set in /etc/rc.conf.d/beszel_agent"
    exit 1
fi
beszel_agent_start() {
    echo "Starting beszel-agent..."
    # Launch the command with the required environment variables.
    env KEY="${beszel_agent_key}" PORT="${beszel_agent_port}" ${command} ${command_args} &
    echo $! > ${pidfile}
}

beszel_agent_stop() {
    echo "Stopping beszel-agent..."
    if [ -f ${pidfile} ]; then
        kill "$(cat ${pidfile})" && rm -f ${pidfile}
    fi
}

beszel_agent_status() {
    if [ -f "${pidfile}" ]; then
        pid=$(cat "${pidfile}")
        if kill -0 "${pid}" 2>/dev/null; then
            echo "beszel-agent is running (pid: ${pid})."
            return 0
        else
            echo "beszel-agent is not running (stale pid file)."
            return 1
        fi
    else
        echo "beszel-agent is not running."
        return 1
    fi
}

start_cmd="beszel_agent_start"
stop_cmd="beszel_agent_stop"
status_cmd="beszel_agent_status"

run_rc_command "$1"

3. Create `beszel_agent` in `/etc/rc.conf.d/` with the following contents:

Code Select Expand

beszel_agent_enable="YES"
beszel_agent_key=""
beszel_agent_port=""

4. Be sure to put the correct ssh key and port here given to you by beszel.
5. Run `service beszel_agent start`

I can confirm that caddy is running on 443 as shown here:


Also thanks for the tip about using `This Firewall` that allowed me to delete the Gateways alias, however even after making that change anything that runs through the Caddy proxy is still accessible on the WIFI vlan.

Oddly enough the block on port 444 is working, so it seems there's something preventing 443 from being blocked?

I took a peek at it, seems it's just a binary was able to extract the agent and run it. Complained that I didn't have my `KEY` environment variable set. So seems to run just fine, would just need to do some manual work to set it up as a service.

It looks like their documentation has a guide for setting it up manually on linux (you'd be looking at step 2 not step 1):
https://beszel.dev/guide/agent-installation#binary

However their guide for setting up the service is using systemd, which would not work on freebsd so you'd have to read up on setting up a freebsd service and do that instead.

I'm not sure what the implications are of copying a binary to `/bin` on opnsense, I've never had to do it before and am unsure if such things will survive updates though.

I'm using Caddy as a reverse proxy to serve SSL certs for my webui and a few other things running on the firewall.

On my WIFI subnet I've created a rule that blocks access to 443 and 444 (the port I changed the webui to bind to without the proxy). If I try to access these ports via the IP e.g. 192.168.1.1:444, 192.168.1.1:443. These connections are being blocked.

However if I try to access through the reverse proxy e.g. firewall.mydomain.com it's still accessible despite firewall.mydomain.com resolving to 192.168.1.1 and since it's being served using https that would be on port 443.

Do I need to add the domains for these services to the alias?

Anyway here's the rule config:
Action: Reject
Quick: checked
Interface: WIFI
Direction: in
TCP/IP Version: IPv4
Protocol: TCP/UDP
Source: WIFI net
Destination: Gateways
Destination port range from: OPNsense_Access_Ports
Destination port range to: OPNsense_Access_Ports

Gateways is an alias pointing to: 192.168.1.1, 192.168.2.1
OPNSense_Access_Ports is an alias pointing to: 444, 443

I do believe I know what is happening now, I'm running adguard in front of this which is also caching requests, I'm assuming adguard is caching them long enough that they are falling out of the unbound cache which is why almost all of the requests are cache misses.

You have not said anything about the environment or the number and type of clients

This is a homelab setup so not many clients:
- a few cellphones
- a few TV
- a desktop
- a NAS with various containers running on it

That's about it, you're correct I haven't noticed it be problematic, this is just my first time using unbound and this seemed out of the ordinary to me so I wanted to ask.

Code Select Expand

Total
Recursion time (average):    0.107628
Recursion time (median):    0.077739
TCP usage:    0
IP ratelimited queries:    0
Recursive replies:    13412
Cache misses:    13412
Cache hits:    1275
Serve expired:    0
Prefetch:    1200
Queries:    14687
Request queue avg:    0.238434
Request queue max:    23
Request queue overwritten:    0
Request queue exceeded:    0
Request queue size (all):    0
Request queue size (client):    0
Times
Now:    1739705201.337157
Uptime:    40561.484009
Elapsed:    40561.484009

This is after running for a few hours, the only settings I changed are:

Code Select Expand

Prefetch Support: ON
Message Cache Size: 20m
Number of Hosts to cache: 50000

Which I believe these changes to make cache hits more common, but this many misses seems fairly bad to me.