Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

Hallo Zusammen,

unglücklicherweise wurde ein Update der XG125 von 19.5. auf 20.0 durchgeführt und anschließend war die gesamte Konfiguration zurückgesetzt. Nachdem ich nun die meisten Einstellungen mühsam wieder eingerichtet habe, scheint mir entweder ein Fehler in der Konfiguration passiert zu sein, oder die neue Firmware reagiert anders. Meine Situation ist folgende: 

* An einem GF-Modem hängt die XG125 mit Port2

* An Port 1 hängt ein Switch 

* An Port 3 (auf WAN) und Port 4 (auf LAN) hängt eine Fritzbox 

* Port 1 und 4 teilen sich das Subnetz 192.168.188.0/24

* Port 3 nutzt das Subnetz 192.168.187.0/24

* An Port 7 und Port 8 hängt eine Unify Telefonanlage (mit einer IP im Netz 192.168.188.x) 

Ich möchte nun, dass ich sowohl per VPN (SSL-Client) und WAN (Portweiterleitung) auf diverse interne Geräte zugreifen kann. Vor dem Update ging das und die Firewallregeln sowie DNAT Regeln existieren (nach bestem Wissen), doch leider kann ich die WebServices der internen Geräte nur über LAN erreichen. Ein Zugriff über WAN oder VPN geht nur auf die Telefone, nicht aber auf die Fritzbox oder die Telefonanlage. Kann jemand aus der Community hier einen Fehler feststellen oder mir einen Tipp zur Validierung geben? 

Vielen Dank für die Hilfe

Michael Nährig 

Regel : LocalTraffic - Accept 

Source: LAN, VPN
Source Network: Any
Src Service: Any 

Destination: LAN, VPN
Destination Network: Any
Dst Service: Any 

Regel : Remote to Fritzbox - Accept 

Source: WAN
Source Network: Any
Src Service: Any

Destination: Any
Destination Network: Any
Dst Service: FritzboxPort

NAT Rule: 

Original Source: Any
Original Service: FritzboxPort
Original Dest: Any

Translated Source: Original
Translated Service: Original
Translated Dest: Fritzbox IP 

Regel : Remote to Unify - Accept 

Source: WAN
Source Network: Any
Src Service: Any

Destination: Any
Destination Network: Any
Dst Service: UnifyPort

NAT Rule: 

Original Source: Any
Original Service: UnifyPort
Original Dest: Any

Translated Source: Original
Translated Service: Original
Translated Dest: Unify IP 

 



Added TAGs
[edited by: Raphael Alganes at 3:47 PM (GMT -7) on 14 Jun 2024]
  • 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.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 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.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 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?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 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. 


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 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.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.