Recent posts

#1
26.7, 26.10 Series / [26.7.8_2] Unable to Display T...
Last post by Ashraaf - Today at 05:03:49 PM
Hello,

I have OpenVPN configured with TOTP-based two-factor authentication (2FA) and allow users to manage their own OTP seeds through the OPNsense web interface.

After updating OPNsense to 26.7.8_2, I noticed that users can no longer display the QR code when requesting a new OTP seed. Instead, the QR code area displays a broken image placeholder.

I'm not sure which version introduced this issue, as I regularly update my OPNsense installation on a weekly basis. I only noticed it today when some of my teammates switched to new mobile phones and attempted to use the "Request new OTP seed" function to configure their authenticator applications.

Current configuration

- OpenVPN users are members of the `OpenVPN` group.
- The following privileges are granted to this group under System → Access → Privileges:
  - `page-openvpn-client-export`
  - `page-system-usermanager-passwordmg`

These privileges are intended to allow users to export their own OpenVPN client configurations and manage their OTP seeds without requiring administrator intervention.

Additional observation

After revisiting the official [OPNsense Two-Factor Authentication Guide](https://docs.opnsense.org/manual/how-tos/two_factor.html#step-4-activate-authenticator-for-this-otp-seed), I found that an administrator (root) can still display the QR code through:

`ui/auth/user` → Edit user (pencil icon) → OTP seed → Show

However, this appears to require administrator access. Does this mean regular users can no longer display their own OTP QR codes, and must rely on an administrator whenever they need to register a new authenticator device?

Browser developer console error

I also checked the browser's F12 Developer Console and found the following Content Security Policy (CSP) error:

```
system_usermanager_passwordmg.php:1 Loading the image
'data:image/gif;base64,<redacted>' violates the following
Content Security Policy directive: "default-src 'self'".

Note that 'img-src' was not explicitly set, so 'default-src'
is used as a fallback. The action has been blocked.
```

Based on this error, could this be related to a CSP restriction preventing the browser from loading the QR code image embedded as a Base64 data URI?

Questions

1. Is this a known issue in OPNsense 26.7.8_2, or is this an intentional security policy change?
2. Should the `page-system-usermanager-passwordmg` privilege still allow regular users to generate and display their own OTP QR codes?
3. If this is a CSP-related regression, could the relevant `img-src` policy be adjusted to allow the required data URI without weakening the overall security policy?

I would appreciate any clarification or suggestions. Ideally, users should be able to manage their own OTP enrollment independently without requiring administrator intervention.

Security context: I understand that allowing users to request a new OTP seed themselves may raise security concerns, particularly in environments where the management interface is publicly accessible. However, my OPNsense deployment is within a closed network, and OpenVPN is used exclusively for internal access to a small number of isolated servers. The intention is simply to provide a convenient self-service OTP enrollment process for authorized internal users without requiring administrator intervention each time they change devices.

That said, I fully understand and respect it if restricting this functionality is an intentional security decision by the OPNsense developers. I am not requesting that the security policy be relaxed; I would just appreciate clarification on whether this behaviour is intentional or an unintended regression. If it is an intentional change, I am perfectly fine with that and will adjust our internal procedures accordingly.

Thank you.
#2
Ich weiß nicht, wie Wazuh funktioniert, aber die Access Logs von Caddy landen in /var/log/caddy/access/*, nicht in /var/ossec/logs/opnsense_syslog.log.
#3
General Discussion / My OPNsense home-lab gateway d...
Last post by jahmed - Today at 04:33:42 PM
Hi everyone,

I've been building a self-hosted gateway portal for my OPNsense home lab and have published the code:

Source code and README on GitHub

It runs as a separate portal alongside OPNsense and brings connectivity, clients, traffic, DNS, VPNs and security alerts into one place.

Some of the dashboard features:
  • Latency/loss, bandwidth and availability graphs, with local-time axes, timestamp tooltips and visible gaps when telemetry is missing.
  • A separate two-second interface-counter feed and rolling live WAN graph. Historical charts refresh every minute while the page and charts stay mounted.
  • A network flow map with current network rates, stable device ordering and separate device/topology refreshes. Expanding a network only loads the map fragment.
  • Device search, alert filters, bounded historical queries and CSV exports.
  • CrowdSec information refreshed in the background with visible freshness.

The web application firewall runs separately at the edge: Caddy + Coraza + OWASP CRS, alongside CrowdSec. The supplied configuration starts in DetectionOnly mode for tuning. The portal reports Coraza matches and interruptions; it does not count every application HTTP 403 as a WAF block. Installing the portal alone does not protect a website.

For access, the portal supports passkeys/security keys or password + TOTP. Optional firewall actions require an operator signature that the OPNsense agent verifies independently. The example agent configuration starts with actions disabled.

This is a home-lab project under active development. Automated tests cover authentication, signed actions, metrics, filters and exports; deployment checks and rule tuning still matter. I'd welcome feedback on the dashboard, deployment documentation, false-positive tuning and how others separate their edge and management networks.

What would make a gateway dashboard more useful in your own lab?
#4
General Discussion / Re: Learn firewall, NAT, routi...
Last post by Bob.Dig - Today at 03:29:21 PM
For some basic stuff in German, you can go here:
https://www.youtube.com/watch?v=HrUZjqqWPZM
But you probably don't speak German, I guess. ;)
#5
26.7, 26.10 Series / Nesting aliases does not work ...
Last post by ErikvL - Today at 03:21:12 PM
I have several single host aliases (One name, One IP).
Then I have a nested alias that groups a few of those aliases.

Such a nested alias added to a rule works.

But, I also have a nested alias that groups a few of the single hosts aliases and the above mentioned nested alias.

Having this multilevel nested alias in a rule does not work for the nested alias in the group.

The nesting is as illustrated below. Similar to what is documented here: https://docs.opnsense.org/manual/aliases.html#nesting

alias A
  alias for IP 1
  alias for IP 2
  alias B
    alias for IP 3
    alias for IP 4

#6
General Discussion / Re: nfSensei ( fork pfsense )
Last post by bob9999 - Today at 02:59:27 PM
Why so much rage?

I just saw this thread and was surprised by so much uninformed hatred. Like children hating on something childish.

pfSense started out as the top shelf alternative a long time ago. Then OPNsense came along with some different ideas to apply to the same overall concept. At first I wasn't interested because I used pfSense for pfBlockerNG. The ad blocker in the router allows the network to have fewer failure points (hint to people who use VM routers). AdGuard Home along with some upgrade issues with pfSense gave me the idea to switch over to OPNsense. It does the job I need.

pfSense at one time long ago had the most obnoxious hateful children posting in their forum. Eventually, they wised up and cleared them out and made sure that someone knowledgeable and helpful was always there to answer questions. That decision probably gave pfSense a lifeline as at one time the forum made a  bad first impression for users.

The OPNsense forum is better than the old pfSense forum, but the children always need to make noise.
#7
General Discussion / Re: Learn firewall, NAT, routi...
Last post by bob9999 - Today at 02:39:08 PM
I have always been under the impression that many posters here learn OPNsense and confuse that with learning networking. Hopefully you aren't making that mistake. If you learn basic networking concepts as if you were taking a survey course, you will much better understand what you are actually doing when you want to give your network a new feature.

With your network plans, first decide what objective you want to accomplish in a conceptual way without regard to OPNsense. Then figure out the generic way to do it, more or less. Finally, figure out how it's done in OPNsense.

Look up Intro To Networking courses on YouTube. Long ones in many parts that cover a lot of territory. Maybe even buy a cheap old used text book on it from Amazon. Basic networking hasn't changed a lot in over a decade. The basic stuff is what you want to learn so you can understand the newer and more exotic things later.
#8
German - Deutsch / Re: Frage zu Zertifikaten und ...
Last post by Pete5 - Today at 02:34:31 PM
Hi,

Quote from: viragomann on October 31, 2026, 08:25:55 PMHallo,

Quote from: Pete5 on October 30, 2026, 09:10:58 AMAuf meiner opnsense ist der ACME-Client und der caddy proxy eingerichtet, als lokalen DNS nutze ich unbound.
Caddy verteilt das Let's Encrypt Wildcard Zertifikat an die Dienste die in meinem Netz laufen,
d.h., du hast ein Wildcard-Zertifikate für *.mydomain.de, das der ACME-Client besorgt, und das auch in jedem Frontend in Caddy angegeben?
Und vielleicht auch in den General Settings "Auto HTTPS" deaktiviert?

Ich habe unter caddy/Reverse proxy/domains eine domain *.mydomain.de angelegt und dort als Certificate mein wildcard Let's encrypt Zertifikat, heißt mydomain.de (ACME Client) ausgewählt. Dann habe ich für z.B. jeden switch eine subdomain angelegt, also switch1.mydomain.de und switch2.mydomain.de angelegt. Der entsprechende Handler hat als protocol http und als IP die entsprechende IP des switch eingegeben. Für switch1 wird eine https-Verbindung aufgebaut und die Login Maske erscheint, bei switch2 wird anscheinden auch einen https-Verbindug aufgebaut, zumindest zeigt der Browser das Schild vor der URL, aber die Seite bleibt weiß die Login Maske erscheint nicht. Wenn ich den switch2 direkt über die IP anspreche funktioniert es.

Quote from: Pete5 on October 30, 2026, 09:10:58 AMBei switch1 kommt eine https Verbindung zustande bei switch2 nicht
Wie genau äußert sich das?

In der logdatei von caddy findet ich zu switch2 folgendes
2026-10-31T14:42:44    Debug    caddy     "debug","ts":"2026-10-31T13:42:44Z","logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"192.168.64.8:80","duration":0.223602661,"request":{"remote_ip":"192.168.64.51","remote_port":"38366","client_ip":"192.168.64.51","proto":"HTTP/2.0","method":"GET","host":"switch2.mydomain.de","uri":"/static/js/app.e075fc3b.gzip.js","headers":{"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Fetch-Dest":["script"],"Accept-Language":["de,en-US;q=0.9,en;q=0.8"],"Accept":["*/*"],"X-Forwarded-Host":["switch2.mydomain.de"],"Via":["2.0 Caddy"],"Sec-Fetch-Mode":["no-cors"],"Sec-Fetch-Site":["same-origin"],"Te":["trailers"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:159.0) Gecko/20100101 Firefox/159.0"],"X-Forwarded-For":["192.168.64.51"],"Referer":["https://switch2.mydomain.de/main.html"],"Dnt":["1"],"Sec-Gpc":["1"],"Cookie":["REDACTED"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"switch1.mydomain.de","ech":false}},"headers":{"Cache-Control":["must-revalidate"],"Etag":["\"1774072632-206311\""],"X-Xss-Protection":["1; mode=block"],"Set-Cookie":["REDACTED"],"Content-Length":["206311"],"Content-Type":["application/javascript; charset=UTF-8"],"X-Frame-Options":["SAMEORIGIN"],"X-Content-Type-Options":["nosniff"],"Content-Encoding":["gzip"],"Date":["Wed, 29 Apr 2026 00:37:30"]},"status":200}
2026-10-31T14:42:44    Debug    caddy     "debug","ts":"2026-10-31T13:42:44Z","logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"192.168.64.8:80","duration":0.105739659,"request":{"remote_ip":"192.168.64.51","remote_port":"38366","client_ip":"192.168.64.51","proto":"HTTP/2.0","method":"GET","host":"switch2.mydomain.de","uri":"/static/js/chunk-elementUI.22a0a6c6.gzip.js","headers":{"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Fetch-Dest":["script"],"Sec-Fetch-Mode":["no-cors"],"X-Forwarded-Proto":["https"],"Accept":["*/*"],"Sec-Fetch-Site":["same-origin"],"Accept-Language":["de,en-US;q=0.9,en;q=0.8"],"X-Forwarded-Host":["switch2.mydomain.de"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:159.0) Gecko/20100101 Firefox/159.0"],"Cookie":["REDACTED"],"Te":["trailers"],"X-Forwarded-For":["192.168.64.51"],"Referer":["https://switch2.mydomain.de/main.html"],"Dnt":["1"],"Sec-Gpc":["1"],"Via":["2.0 Caddy"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"switch1.mydomain.de","ech":false}},"headers":{"Content-Type":["application/javascript; charset=UTF-8"],"Cache-Control":["must-revalidate"],"X-Frame-Options":["SAMEORIGIN"],"X-Xss-Protection":["1; mode=block"],"Content-Encoding":["gzip"],"Content-Length":["156512"],"Date":["Wed, 29 Apr 2026 00:37:30"],"Etag":["\"1774072632-156512\""],"X-Content-Type-Options":["nosniff"],"Set-Cookie":["REDACTED"]},"status":200}
2026-10-31T14:42:44    Debug    caddy     "debug","ts":"2026-10-31T13:42:44Z","logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"192.168.64.8:80","duration":0.069756515,"request":{"remote_ip":"192.168.64.51","remote_port":"38366","client_ip":"192.168.64.51","proto":"HTTP/2.0","method":"GET","host":"switch2.mydomain.de","uri":"/static/js/chunk-echarts.a837dac1.gzip.js","headers":{"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:159.0) Gecko/20100101 Firefox/159.0"],"Accept":["*/*"],"Accept-Language":["de,en-US;q=0.9,en;q=0.8"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Gpc":["1"],"Sec-Fetch-Site":["same-origin"],"Dnt":["1"],"Referer":["https://switch2.mydomain.de/main.html"],"Cookie":["REDACTED"],"Sec-Fetch-Mode":["no-cors"],"Te":["trailers"],"X-Forwarded-Proto":["https"],"X-Forwarded-Host":["switch2.mydomain.de"],"Via":["2.0 Caddy"],"Sec-Fetch-Dest":["script"],"X-Forwarded-For":["192.168.64.51"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"switch1.mydomain.de","ech":false}},"headers":{"Content-Length":["133941"],"Date":["Wed, 29 Apr 2026 00:37:30"],"Content-Type":["application/javascript; charset=UTF-8"],"Cache-Control":["must-revalidate"],"Etag":["\"1774072632-133941\""],"X-Content-Type-Options":["nosniff"],"Set-Cookie":["REDACTED"],"Content-Encoding":["gzip"],"X-Frame-Options":["SAMEORIGIN"],"X-Xss-Protection":["1; mode=block"]},"status":200}
2026-10-31T14:42:43    Debug    caddy     "debug","ts":"2026-10-31T13:42:43Z","logger":"http.handlers.reverse_proxy","msg":"selected upstream","dial":"192.168.64.8:80","total_upstreams":1}
2026-10-31T14:42:43    Debug    caddy     "debug","ts":"2026-10-31T13:42:43Z","logger":"http.handlers.reverse_proxy","msg":"selected upstream","dial":"192.168.64.8:80","total_upstreams":1}
2026-10-31T14:42:43    Debug    caddy     "debug","ts":"2026-10-31T13:42:43Z","logger":"http.handlers.reverse_proxy","msg":"selected upstream","dial":"192.168.64.8:80","total_upstreams":1}

Stutzig macht mich dabei das an mancher Stelle switch1.mydomain.de auftaucht.

In einer anderen VM läuft Debian 13 als Host für Docker Container, der öehnt die Verbindung ab, wieso habe ich noch nicht rausfinden können. Denn wenn ich nicht caddy benutze sondern im lokalen Netzwerk DNS mittels Unbound mache, dann kann ich auf den Dockerhost zugreifen, halt ohne https. Da cadyy logfile sagt dazu:
"warn","ts":"2026-10-31T18:43:54Z","logger":"http.handlers.reverse_proxy","msg":"aborting with incomplete response","upstream":"192.168.64.25:9443","duration":0.001091551,"request":{"remote_ip":"192.168.64.51","remote_port":"52754","client_ip":"192.168.64.51","proto":"HTTP/2.0","method":"GET","host":"dockerhost.mydomain.de","uri":"/","headers":{"Sec-Gpc":["1"],"Sec-Fetch-Mode":["navigate"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:159.0) Gecko/20100101 Firefox/159.0"],"Sec-Fetch-Site":["none"],"X-Forwarded-Host":["dockerhost.mydomain.de"],"Accept-Language":["de,en-US;q=0.9,en;q=0.8"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Sec-Fetch-Dest":["document"],"X-Forwarded-Proto":["https"],"Via":["2.0 Caddy"],"Dnt":["1"],"Priority":["u=0, i"],"Upgrade-Insecure-Requests":["1"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Fetch-User":["?1"],"Te":["trailers"],"X-Forwarded-For":["192.168.64.51"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"dockerhost.mydomain.de","ech":false}},"error":"reading: read tcp 192.168.64.1:3540->192.168.64.25:9443: read:connection reset by peer"}
Die Webbrowser geben heute speziell bei SSL-Problemen aber meist keine vernünftige Fehlermeldung aus. Wenn du cURL oder OpenSSL verfügbar hast, untersuche die Serverantwort damit.

Mit cURL
curl -v https://switch2.mydomain.deDas zeigt, auf welche Domain das gelieferte Zertifikat ausgestellt ist.
Mache dasselbe mit switch1 zum Vergleich.

Die Ausgabe dazu sieht soweit ich das beurteilen kann auch in Ordnung aus:

switch1
curl -v https://switch1.mydomain.de
* Host switch1.mydomain.de:443 was resolved.
* IPv6: (none)
* IPv4: mypublicIP
*   Trying mypublicIP:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519MLKEM768 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=mydomain.de
*   start date: Oct 23 12:27:27 2026 GMT
*   expire date: Jan 21 12:27:26 2027 GMT
*   issuer: C=US; O=Let's Encrypt; CN=YR1
*   Certificate level 0: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 3: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "switch1.mydomainr.de" matches cert's "*.mydomain.de"
* SSL certificate verified via OpenSSL.
* Established connection to switch1.mydomain.de (mypublicIP port 443) from 192.168.64.51 port 33808
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://switch1.mydomainr.de/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: switch1.mydomain.de]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.18.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: switch1.mydomain.de
> User-Agent: curl/8.18.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< cache-control: no-store
< content-type: text/html; charset=utf-8
< via: 1.1 Caddy
< content-length: 466
< date: Sun, 01 Nov 2026 15:29:50 GMT
<
<html>
<script>RT='/DGS-1100-24_1.10.B020/';
Prefix="<script src='"+RT+"FilenamePrefix.js'></s";
Prefix+='cript>';
document.write(Prefix);
</script>
<title>Login</title>
<script>jsInclude(0,'login.js');</script>
<script>
InitCookie();
docW("<frameset><center>");
docW("<frame src='"+RD+"login2.htm' frameborder='no' scrolling='yes' noresize marginhight=0>");
</script>
<noframes>
sorry, your browser does not support frames.
</noframes>
</center></frameset>
</html>
* Connection #0 to host switch1.mydomain.de:443 left intact

switch2
curl -v https://switch2.mydomain.de
* Host switch2.mydomain.de:443 was resolved.
* IPv6: (none)
* IPv4: mypublicIP
*   Trying mypublicIP:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
*   CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519MLKEM768 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=mydomain.de
*   start date: Oct 23 12:27:27 2026 GMT
*   expire date: Jan 21 12:27:26 2027 GMT
*   issuer: C=US; O=Let's Encrypt; CN=YR1
*   Certificate level 0: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 3: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "switch2.mydomain.de" matches cert's "*.mydomain.de"
* SSL certificate verified via OpenSSL.
* Established connection to switch2.mydomain.de (mypublicIP port 443) from 192.168.64.51 port 48742
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://switch2.mydomain.de/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: switch2.mydomain.de]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.18.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: switch2.mydomain.de
> User-Agent: curl/8.18.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< cache-control: no-cache
< content-type: text/html; charset=UTF-8
< date: Thu, 30 Apr 2026 02:23:31
< set-cookie: HttpOnly=true;HttpOnly;Secure
< via: 1.1 Caddy
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
<
<!DOCTYPE html>
<html>

<head>
  <meta charset=utf-8>
  <meta name=viewport content="width=device-width,initial-scale=1">
  <script type=text/javascript>
    document.writeln('<script type="text/javascript" src="/iss/specific/const_common.js?&_='+new Date().getTime()+'"></s'+'cript>');
  </script>
  <link id="logo" rel="shortcut icon" type="image/x-icon" />
  <script type=text/javascript>
    document.writeln('<script type="text/javascript" src="/static/specific/config.js'+'"></s'+'cript>');
    document.getElementById('logo').href = '/static/specific/favicon.ico';
  </script>
  <script>
    function receiveMessage(event) {
      const arrurl = window.location.href.split('/')
      const url = arrurl[0] + '//' + arrurl[2]
      if (event.origin !== url) { // 安全问题,需在同一个域名
        return
      }
      // 解login进入后输入chklst.txt无效问题
      if (arrurl[3] && arrurl[3].indexOf('chklst.txt') !== -1) {
        const key = 'FFBF48953A799EEF6FC8EC5F4E09916E'
        const gibt = sessionStorage.getItem(key)
        if (gibt) {
          sessionStorage.removeItem(key)
          window.location.replace(window.location.href)
        }
      }
      event.source.postMessage("checkindexok ", event.origin) // 使用event.origin取代 '*', '*'存在安全问题
      if (typeof event.data !== 'string') {
        return
      }
      if (event.data.indexOf('NewIP') !== -1) {
        const objData = JSON.parse(event.data)
        const newUrl = objData.NewIP
        const TimeOut = (typeof objData.TimeOut !== 'undefined') ? objData.TimeOut : 1000
        if (TimeOut > 1000 && TimeOut < 240000) { //1000: 1秒 , 240000:4 分钟
          setTimeout(function() {
            window.location.replace(newUrl)
          }, TimeOut)
        }
      }
      if (event.data.indexOf('reload') !== -1) { // reload
        // 方式1在chrome与ie11下可以重新加载,但是firefox下显示"Error: Incorrect contents fetched, please reload."
        // 暂时使用方式2可以兼容三种浏览器
        // 方式1
        // window.location.reload()
        // 方式2
        window.open(location.href,'_self')
      }
    }
    // 用于check index iframe loading
    window.addEventListener('message', receiveMessage, false)
    function changeFrameHeight() {
      var ifm = document.getElementById("iframemain");
      ifm.width = document.documentElement.clientWidth;
      ifm.height = document.documentElement.clientHeight;
    }
    window.onresize = function () {
      changeFrameHeight();
    }
  </script>
</head>

<body onLoad="pageInit()" style="margin:0;padding:0;overflow: hidden;">
  <div>
    <iframe name="iframemain" src="/main.html" id="iframemain" marginheight="0" frameborder="0" scrolling="yes"
      onload="changeFrameHeight()" width="1024" height="860"></iframe>
  </div>
</body>

</html>
* Connection #0 to host switch2.mydomain.de:443 left intact

Danke und Gruß
#9
26.7, 26.10 Series / Re: Unable to import Trust Aut...
Last post by franco - Today at 02:20:33 PM
The private key requirement was fixed in 26.7.8_2.


Cheers,
Franco
#10
General Discussion / Learn firewall, NAT, routing a...
Last post by beneix - Today at 02:06:11 PM
I have used OPNSense for over five years now. I have gradually introduced more and more advanced configurations such as road warrior Wireguard access, OpenVPN client, VLANs, various plugins, etc. All along, I have felt that I was behind the learning curve on really understanding the firewall rules, NAT, interfaces/aliases and gateways. I have somehow managed to get things working, but sometimes without understanding why. I find the interaction between these concepts particularly confusing.

Now I would like to address my knowledge deficit and learn these things properly before I attempt the long-delayed migration from legacy firewall rules. I would appreciate pointers to good learning resources that will help.