Put an internal web application behind Korthveil. Browsers connect to Korthveil over HTTPS, Korthveil checks every request with the web application firewall (WAF), and only clean requests reach the server. This guide publishes the SentinelOps web console (https://192.168.2.11) under the name sentinelops.home.arpa, for PCs inside the house only. Nothing is opened to the internet, and nothing changes on the upstream router.

What you need:

• A Korthveil firewall with the Reverse proxy and Web application firewall add-ins (System › Add-ins). Saving their settings switches them on, so there's no separate step.
• The address of the firewall in the PC's zone, for example 192.168.2.13 on the home LAN (zone MGMT) or 192.168.20.1 on the Wi-Fi (zone WIFI).
• About 20 minutes, then a few days of detect mode before you block.

The screenshots come from a test firewall with a test site shop.test behind listener e2e. Your names and values are the ones in the tables.

How it works

 PC in the house                  Korthveil firewall                      SentinelOps server
 ┌────────────────────┐  HTTPS   ┌──────────────────────────────────┐  HTTPS  ┌──────────────────┐
 │ browser            │ ───────▶ │ reverse proxy, port 8443         │ ──────▶ │ 192.168.2.11     │
 │ sentinelops.       │          │  certificate: sentinelops        │         │ web console      │
 │ home.arpa:8443     │          │  asks the WAF about each request │         └──────────────────┘
 │ trusts your CA     │ ◀─────── │ WAF: OWASP Core Rule Set 4.25.2  │
 └────────────────────┘ 403 page │  detect, or block                │
                                 └──────────────────────────────────┘

• The listener is a port in the zones you choose. Only connections to the firewall's own addresses in those zones are taken.
• The site matches the name the browser asked for, presents the certificate, and sends the request to a server pool.
• The WAF (Coraza with the OWASP Core Rule Set) scores each request. In Detect only it logs what it would block. In Block attacks it stops the request, and the browser shows Request blocked with a reference number.

Step 1: A certificate for the name, from Korthveil's own CA

Korthveil makes and renews the certificate itself (System › Certificates). The reverse proxy takes it from there, and gets each renewal automatically.

Go to System › Certificates, panel Add a certificate:

1. A CA, once: if the store has no local CA yet, choose Create a local CA: Name in the store home-ca, Common name Home web CA. Click Create. (A CA made for NAC, such as nac-ca, also works.)
2. The site's certificate: choose Issue from a local CA:

Click Create.

The key never leaves the firewall. While the site uses it, the store lists the reverse proxy under Used by, and the certificate can't be deleted by mistake. When it renews, the site serves the new one within seconds, without a commit.

The name home.arpa is reserved for home networks, so it never clashes with a real internet name.

Your CA's certificate for the PCs: in the Store, click Download on home-ca. You get home-ca.pem: the CA's public certificate, which each PC that opens the site must trust (Step 7). It holds no key.

A certificate from elsewhere (a public CA, or one you made yourself): import it on System › Certificates (Import from your registrar or CA) and choose it the same way, or upload it in the reverse proxy's Certificates tab (Uploaded certificates).

Step 2: The server pool

Tab Server pools, click Add server pool:

Getting the console's certificate: on the PC, run echo | openssl s_client -connect 192.168.2.11:443 -showcerts and copy the last -----BEGIN CERTIFICATE----- … -----END CERTIFICATE----- block (the root of its chain, or the only one if it is self-signed). Or open https://192.168.2.11 in a browser and export the certificate from the padlock.

Leave Do not verify server certificates (insecure) off. It is there only for servers whose certificate can't be checked at all.

Step 3: The listener

Tab Listeners. A new installation has a listener public with HTTP 80 and HTTPS 443 and no zone. Change it, or click Add listener:

Keep Access log on: one record per request, without cookies, credentials, or query strings.

No firewall rule is needed: the add-in opens the port in the chosen zones by itself.

Step 4: The site

Tab Sites, click Publish a site:

Click Save to pending changes. Errors and warnings appear above the button, each with the setting it is about.

Step 5: Protect the site with the WAF

Go to Security › Web application firewall and click Protect sentinelops. A new policy starts in detect mode.

Allowlist (trusted clients): click Add trusted client for your admin PC, so a false positive never locks you out:

Inspect, never block still logs what the PC triggers (labelled with the entry's name). Skip inspection doesn't look at its requests at all; use it rarely.

Click Save to pending changes.

Step 6: Commit

Click Review and commit in the bar at the top of the page. Check the Configuration changes, type a Comment such as Publish SentinelOps behind the WAF, keep Safety rollback (5 minutes) on, and click Commit. Confirm the change within five minutes, or the firewall goes back by itself.

Both add-ins start with the commit. The commit is all-or-nothing: if the certificate, the pool, or the WAF policy is wrong, nothing changes and the reason is shown.

Step 7: Prepare a PC inside the house

The name. The PC must find sentinelops.home.arpa at the firewall's address in its zone. Use one of:

• Hosts file (simplest). Add one line, as administrator:
• Windows: C:\Windows\System32\drivers\etc\hosts
• macOS and Linux: /etc/hosts

192.168.2.13 sentinelops.home.arpa On the Wi-Fi, use 192.168.20.1 instead.

• Korthveil's DNS resolver, for PCs that use the firewall as their DNS server: Network › DNS resolver, panel Local names, Add host record: name sentinelops.home.arpa, type A, value the firewall's address. Save and commit.

Don't change the upstream router for this; the hosts file or Korthveil's resolver is all it takes.

Trust your CA. Install home-ca.pem (from Step 1) as a trusted root. On Windows, rename it to home-ca.crt first:

• Windows: double-click home-ca.crt › Install Certificate › Local Machine › Place all certificates in the following store › Trusted Root Certification Authorities.
• macOS: open home-ca.pem in Keychain Access (System keychain), open the certificate, Trust › When using this certificate: Always Trust.
• Debian, Ubuntu: sudo cp home-ca.pem /usr/local/share/ca-certificates/home-ca.crt && sudo update-ca-certificates.
• Firefox keeps its own list: Settings › Privacy & Security › Certificates › View Certificates › Authorities › Import, tick Trust this CA to identify websites.

Open https://sentinelops.home.arpa:8443/. The SentinelOps console appears with a padlock and no warning.

Step 8: Detect first, then block

Let the site run in detect mode while you use the console normally, for a few days if you can (the guide WAF learning mode explains every step). Then, on the WAF page, panel Learning and readiness:

1. Click Run attack self-test. It sends 15 attacks and 7 normal requests through the committed policy; it must show passed.
2. Read Likely false positives. Accept adds a narrow rule exclusion (one rule, one path, one parameter) to the policy; save and commit it.
3. When the Verdict is READY or REVIEW, click Block at threshold 20, then Save to pending changes and commit. Only requests with several strong detections are stopped at first.
4. After a clean week, Lower threshold to 10, and a week later to 5. Back to detect mode undoes it at any time.

The verdict needs some traffic and days of observation. For a quick test you can set Mode to Block attacks in the policy directly, or type ENABLE at Block anyway, but you then skip the checks that protect you from false positives.

False positives by hand: under Rule exclusions, Add exclusion with the Rule IDs from Recent blocks, limited to a Path prefix and, better, to the one variable (for example ARGS:q), so the rule keeps protecting everything else. Write Why for the next person.

Check it

1. Normal use: the console works at https://sentinelops.home.arpa:8443/.
2. Test a request (WAF page): it runs a request through the committed policy without sending it to SentinelOps. The default /?id=1' OR '1'='1 is a classic SQL injection. Click Test: the answer says whether it would be blocked and by which rule.

3. A real attack from the browser: open https://sentinelops.home.arpa:8443/?id=1' OR '1'='1. In block mode the page says Request blocked with a reference: that is the event ID in Recent blocks. At threshold 20 a single simple attack may still pass; at 5 it is blocked. In detect mode the page loads and the request is logged as detected.
4. Live activity (WAF page): requests inspected, blocked, and detected per second, with a marker for each block. Point at a line to read the value at that moment; the rule behind each block is in Recent blocks.

5. Recent blocks (WAF page): newest first, with the action (blocked, detected, or allowlisted), the attack type and rule, the client, and the request. Details shows what was sent; passwords, tokens, cookies, and authorization values are masked.

6. Reverse proxy, tab Status: Live activity shows HTTP requests, server errors (5xx), and WAF blocks per second for all sites. Sites counts requests, 2xx, 4xx, 5xx, WAF blocked, and No server per site since the add-in started. Servers shows the health of https://192.168.2.11.

The dashboard's threat activity also shows WAF blocks per second, once a policy is running.

Change it later

Troubleshooting

More: modules/reverse-proxy.md and modules/waf.md describe both add-ins in depth.