WebGUI via WAN nicht möglich

[davorin]

Tag allerseits (o;

Ich habe hier eine kleine Intel Appliance mit 2 * 2.5GB und 2 * 10GB Ports und frisch OPNSEnse 26.1.2 installiert mit Standardwerten.
WAN als DHCP und LAN belassen mit 192.168.1.1/24.

Von der LAN Seite alles wunderbar. Nur wenn ich eine FW Rule einfüge, damit ich WAN-seitig hier im lokalem LAN zugreifen kann, passiert nix, dabei habe ich testweise alles WAN-seitig zur WAN-Adresse erlaubt.

In den FW Logs erscheint auch nichts. Nur wenn ich explizit z.B. nur HTTP zulasse, sehe ich in den Logs, wenn ich HTTPS zugreifen will.

LAN-seitig auf die WAN-IP zugreifen geht, also "horcht" die OPNSense WebGUI auf der WAN-Seite.


Jemand irgendeine Idee, was hier schief läuft?

[viragomann]

Hallo,

WAN als DHCP

wenn das eines Subnetz ist (RFC 1918), dann muss du in den WAN Interface-Einstellungen "block private networks" deaktivieren.

Abgesehen von einer entsprechenden Firewall-Regel muss auch in System: Settings: Administration WAN als Listen Interface gesetzt werden.

[Patrick M. Hausen]

Und reply-to deaktivieren, wenn der PC, von dem aus man zugreifen möchte, im selben Netz hängt wie die WAN Schnittstelle.

Firewall: Settings: Advanced

[davorin]

Genau das war's: reply-to deaktivieren...dachte das wäre nur bei Multi_WAN nötig.

Eigenartig, auf einer anderen OPNSense Installation auf der gleichen Hardware ist das nicht deaktiviert und der Zugriff WAN-seitig funktionierte von Anfang an. und die hat zwei WAN Schnittstellen.

[Patrick M. Hausen]

reply-to ist nur bei Multi-WAN nötig, richtig. Deshalb muss man es für alle anderen deaktivieren. Weshalb es per Default eingeschaltet ist, ist wahrscheinlich "historisch".

[davorin]

Wie sieht es denn bei Master/Backup mit CARP aus?

Hier im Betrieb haben wir etliche OPNSense Instanzen mit nur einem WAn Anschluss, und da ist reply-to nicht deaktiviert.

[Patrick M. Hausen]

reply-to bedeutet, Antwort-Pakete werden immer an den Default-Gateway geschickt. Das ist nur dann ein Problem, wenn der WAN-Anschluss ein Ethernet ist (ist bei CARP wohl der Fall) und man von einem PC, der im selben Ethernet hängt, auf das UI zugreifen möchte.

Wenn man aus "dem Internet", also von irgendwo jenseits des Default-Gateway zugreift, ist reply-to nie ein Problem. Genauso wenig bei einer punkt-zu-punkt Leitung wie PPPoE.