XG125 v20.0.1 - Portweiterleitung und Zugriff auf Interne Hosts nach Update nicht mehr möglich

Hallo Michael,

wenn die Zonen und das Routing passen, sollte die regel   LAN,VPN(any) -> LAN,VPN(any)  - > Service-any zumindest für VPN alles zulassen.

Hier kann sicher der logViewer weiterhelfen, falls wirklich etwas geblockt wird. (es bleiben ja fest nur die Zonen)

Externen Zugriff baue ich immer mit dem DNAT-Wizzard. Der log-Viewer sollte hier aber auch Hinweise liefern.

Schlimmstenfalls kann der Paketmitschnitt (gefiltert auf den UnifyPort) zeigen, ob Pakete eingehen und ob/wohin diese weitergeleitet werden.

Hi Dirk,

vielen Dank für die Antwort.

Den LogViewer hab ich mir auch länger und öfter angesehen, kam damit aber nicht wirklich zu einem brauchbaren Tipp.

Wenn ich den LogViewer filter, dann sagt er mit für die Frwd Pkt. die richtige Regel an, für die Incoming Pkt. aber eine 0.

Sollte ich die Anfrage nicht über VPN/LAN machen, sondern über meine PublicACL bekomme ich sogar nicht einen ACL Fehler

anbei mal ein Screenshot von meinen Policys

Hallo Michael,

das ist nicht der LogViewer, sondern das Packet-capture. 
(Der Log-viewer hat einen eigenen Link im GUI rechts oben)
Die Ausgaben sind trotzdem hilfreich.

Bein Packet-Capture sieht man nicht nur den Verbindungsaufbau, sondern (theoretisch) auch die Antwort-Pakete.
Die fehlen mir hier aber. Kann es sein, dass der Server nicht jedem Antwortet, oder es ein internes Routingproblem gibt?

Beim 2. Problem würde ich auf eine fehlende/falsche DNAT-Regel tippen.

Hi Dirk,

Ein Routingproblem möchte ich nicht 100% ausschließen, halte ich aber für unwahrscheinlicher. Das Netzwerk dürfte eigl recht gleich wie vor dem Reset eingerichtet sein und generell können die Devices aus dem WLAN der Fritzbox auch ins WAN, das sollte also gehen.

Beim DNAT hatte ich zuerst auch eine Regel manuell angelegt, anschließend gelöscht und per Assistenten einrichten lassen. Sofern mein Verständnis von Source und Destination aber korrekt ist, macht der Assistent die NAT Regel seitenverkehrt.

Ich habe die DNAT Regel also neu angelegt, diese werden allerdings (genau wie die FW-Pol) gar nicht getriggert

Was ich mich aber gerade auch Frage, kann dies ggf. mit der abweichenden Verkabelung zutun haben?

* Die Sophos ist im Port 1 innerhalb des Subnetz 192.168.188.1/24

* Das Hauptinterface ist eine bridge aus Port 1+4+7+8.

* Am Port 1 hängt ein Switch und daran die Fritzbox (auf LAN 1 - IP 192.168.188.2) 

* die Fritzbox hängt zusätzlich an Port 3 (anderes Subnetz - 192.168.187.20)

* am Port 7 und 8 hängt die TK Anlage im gleichen Subnetz wie der Switch am Port 1. (IP 192.168.188.201+192.168.188.202)

* Die Sophos FW kann alle devices in beiden Subnetzen pingen.

* Aus dem VPN kann ich nichts Pingen

* Aus dem WAN kann ich nichts hinter der FW erreichen.

Kannst du das bitte mal kurz skizzieren?
Wer verteilt die Adressen im 192.168.188er-Netz ... und wer ist default gateway?
Warum hängt die FB vor und hinter der Firewall in den Netzen?

PS: der DNAT-Wizzard macht das schon richtig. Allerdings legt er 1-2 zusätzliche "Seitenverkehrte" NAT-Regeln an, damit ausgehende Traffic richtig maskiert wird. 

Hallo Dirk, 

das mit dem Assistenten macht natürlich sinn und werde ich gleich mal testen. 

Als Skizze gilt folgendes: 

* die Sophos ist das EingangsGW und die Fritzbox lediglich für die WLAN Bereitstellung eingerichtet. Die FB war halt schon vorhanden. 

* Die Sophos XG hat dem BridgeInterface das Subnetz 192.168.188.0/24 mit der EigenIP 192.168.188.1 

* am Port 1 hängt ein Switch für die LAN Verteilung und an dem Switch hängt die FB mit der IP 192.168.188.2

* am Port 3 hängt die FB aus Redundanzgründen (und weil mein Kollege es damals nicht besser wusste) (per WAN Anschluss). 

* Per WAN Anschluss hat die FB die IP 192.168.187.20 (aus dem DHCP-Bereich der Sophos) erhalten

* Die Fritzbox hat per Port1/Lan1 die IP/GW Verbindung 192.168.188.2 -> 192.168.188.1

* Die Fritzbox hat per Port3/WAN die IP/GW Verbindung 192.168.187.20 -> 192.168.187.1

* Per DiagnoseTool der Sophos kann ich die IPs 192.168.188.2 und 192.168.187.20 erreichen, per VPN allerdings noch nicht so richtig. 

* An Port 7 hängt die UnifyTK Anlage direkt per IP 192.168.188.201 

* An Port 8 hängt die UnifyTK Zusatzkarte direkt per IP 192.168.188.202 

* beide IPs sind per Sophos Diagnose erreichbar, aber per VPN nicht. 

Wie sieht denn ein Traceroute vom VPN-Gerät in Richtung "Server/TK" aus ... und umgekehrt.

Das war nochmal 'nen guter Hinweis. Ich hatte den zwar schon durchgeführt, dieser ist nun aber doch etwas anders. 

* Beim TraceRoute zur FB (192.168.188.2) komme ich nur bis zum VPN GW 

* Beim TraceRoute zur TK (192.168.188.201) komme ich bis zum Device, kann den WebService aber nicht erreichen

* Beim TraceRoute zur TK-Zusatzanlage (192.168.188.202) komme ich nur bis zum VPN GW 

Ich habe übrigens nun auch die NAT-Rules neu per Assistent angelegt und mir erscheinen die Regeln wieder Seitenverkehrt. 

aber immerhin reagieren hier nun die UsageCounts

Rule 1 und 3 sehen doch gut aus. Nur warum kommt da drüber nix rein?
Die IP 94.31.x.x ist direkt an ein Firewall-Interface gebunden? 
Ich glaube, wir kommen hier nicht wirklich weiter. 
Evtl. solltest du einen SupportCall mit Sophos oder deinem/einem Sophos Partner in Betracht ziehen.
Mit direktem Kontakt ist das bestimmt schnell zu lösen.

Die 94er Ip ist mein PublicIp aus meinem privaten Heimnetz. Diese IP musste ich als ACL/Exception einstellen, damit ich die XG überhaupt Remote erreichen konnte. Der generelle WAN Zugriff ist nach dem Update nicht mehr aktivierbar. 

Bei NAT Rule 1 hätte ich gesagt, dass die Original Destination nicht korrekt ist. MN-Remote ist original Source (so wurde es im Assistenten auch eingestellt) 

Gleiches gilt bei Rule 3. 

Das mit dem Berater hatte ich auch in Betracht gezogen, hatte hier aber leider bisher sehr sehr schlechte Erfahrungen machen müssen. Mein Verkäufer ist eher in der UTM Trainiert und der direkte Sophossupport war dann bei einem anderen Thema etwas "schwierig". 

Die 94er Ip ist mein PublicIp aus meinem privaten Heimnetz. Diese IP musste ich als ACL/Exception einstellen, damit ich die XG überhaupt Remote erreichen konnte. Der generelle WAN Zugriff ist nach dem Update nicht mehr aktivierbar. 

Bei NAT Rule 1 hätte ich gesagt, dass die Original Destination nicht korrekt ist. MN-Remote ist original Source (so wurde es im Assistenten auch eingestellt) 

Gleiches gilt bei Rule 3. 

Das mit dem Berater hatte ich auch in Betracht gezogen, hatte hier aber leider bisher sehr sehr schlechte Erfahrungen machen müssen. Mein Verkäufer ist eher in der UTM Trainiert und der direkte Sophossupport war dann bei einem anderen Thema etwas "schwierig". 

Die "Original Destination" sollte eine externe Interface-IP der Sophos Firewall sein ...