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
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Sers, “Blockiere private Netze” unter Schnittstellen -> WAN muss man noch ausmachen 🙂
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.
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
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