OPNsense: Zugriff auf das Web-Interface über WAN

Das OPNsense-Projekt beobachte ich seit seiner Gründung. Für viele Anwender ist es eine Alternative zu pfSense oder der Nachfolger der m0n0wall. Im Gegensatz zu den beiden genannten ist es bei OPNsense weniger einfach, einen Zugriff auf das Web-Interface über die WAN-Schnittstelle zu ermöglichen.

Warum sollte man sowas überhaupt tun?

WAN muss nicht immer gleich das “böse” Internet bedeuten. So kann die Firewall im eigenen Netz Bereiche oder Server abtrennen. Fernadministration oder Support wäre ein anderer Punkt. Testumgebungen ein weiterer.

Zugriff erlauben

Während es bei pfSense und seinerzeit bei der m0n0wall ausreichend war, auf der WAN-Seite in der Firewall die notwendigen Ports (z.B. 22, 443) freizuschalten, so reicht das bei OPNsense allein nicht.

In der WAN-Regel selbst muss zusätzlich unter

Advanced Options - disable reply-to

aktiviert werden:

Im übrigen gilt dies auch, wenn man den Zugriff via ssh erlauben möchte.

Verwendet man Port-Forwarding, so steht diese Option nicht in der WAN-Regel zur Verfügung. Dann kann man alternativ unter “Firewall – Settings – Advanced” global “disable reply-to” aktivieren. Beim Testen über mehrere Versionen hinweg war diese Änderung mal notwendig und mal nicht. Im Einzelfall also immer prüfen.

Wichtig zu wissen: Ist die genannte Option an einen der genannten Stellen aktiviert, so greift dies dann auch auf einem anderen Weg. Z.B. ist “disable reply-to” in einer WAN-Regel aktiviert, so funktioniert es dann auch beim Port-Forwarding, selbst wenn sie global inaktiv ist.

Den Hintergrund mit dieser Option verstehe ich um ehrlich zu sein nicht ganz. Das man aus Sicherheitsgründen den Zugriff verwährt macht wiederum Sinn. Das allein scheint hier allerdings nicht der Grund bzw. Ursache zu sein.

Quellen:

OPNsense Forum – External access to opnsense GUI

OPNsense Forum – Access webGui from WAN

4 Kommentare

  1. Beneboy

    Sers, “Blockiere private Netze” unter Schnittstellen -> WAN muss man noch ausmachen 🙂

  2. ttk

    Boah, danke. Ich habe gerade 2 Tage damit verschwendet, wieso ein auf der Firewall laufender HAproxy sowie das Webfrontend nicht über IPv6 erreichbar ist, während die Firewall den eingehenden Traffic sehr wohl erkennt und durchleitet.
    Diese Option hat mir gerade meinen Tag gerettet.

  3. Johannes

    Danke für deine Anleitung. Ich hab grad auf meinem WAN-Link eben SSH und HTTPS enabled von zwei Remotehosts, rennt tadellos, ohne dieses „disable reply-to“. Was genau soll das bewirken?

    Danke schonmal 🙂

    LG
    Johannes

  4. Der der nix weiss

    Servus Andy,

    vielen Dank für deinen Artikel. Verwunderung hat auch bei mir diese Option “mal Global deaktivieren und dann noch auf Policyebene deaktivieren ausgelöst.
    Ich habe für mich die Erklärung gefunden, das man mit MultiWan`s arbeitet und sich die Option offen lassen will,
    sich mit einem WAN 2 via Gui zu verbinden, wenn z.B ein Transfernetzwerk zum Einsatz kommt,
    OPNsense-Transfernetzwerk-Fritzbox-Internet. So hätte man die Möglichkeit sich über VPN-Fritzbox zu verbinden ohne das Wan”Webgui im Internet zu presentieren.

    VG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

© 2024 Andy's Blog

Theme von Anders NorénHoch ↑