Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 998 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM9: SSL_VPN Einwahl klappt, aber kein Zugriff auf interne Netze

Christian Buczek

Hallo allesamt,

ich verzweifel pünktlich zum Arbeits-Wochenstart an meiner UTM (v9.712-13, SG125, Total protect Lizenz)

Da bis letzten Mittwoch noch alle User sich von extern über SSL-VPN einwählen und in ihre interne Netze gelangen konnten, um dort arbeiten zu können - dies nun aber nicht mehr der Fall ist habe ich das ganze noch einmal von vorne aufgerollt und bin wie folgt vorgegangen:

1) Benutzer timtest erstellt

2) "timtest" der Benutzergruppe "SSL_VPN_Test-All" hinzugefügt

3) unter Remote Access -> SSL das Profil "SSL_VPN_Test-All (Profil)" erstellt und die Benutzergruppe "SSL_VPN_Test-All" hinzugefügt. Als lokale Netzwerke dem profil das "internal" Netzwerk hinzugefügt (10.0.0.0/24)

Spoileralarm: sowohl mit automatischer   Firewallregel, wie auch manuell zusammengeklickter Regel wird es nachher Probleme geben als VPN Benutzer in das internal-Netz zu gelangen

4)  unter Network Protection -> Firewall eine Regel (Nummer 3) erstellt für

3

  • SSL_VPN_Test-All (User Group Network)
  • AD_DC_Domänen-Kommunikation
  • Any
  • DNS
  • Microsoft Remote Desktop (RDP)
  • SMB_Dateifreigabe
  • Internal (Network)

im Anschluss OVPN Datei über das Benutzerportal heruntergeladen und auf unterschiedlichen PCs auf unterschiedlichen Clients importiert (Spoiler: mit jedem Client geht der Verbindungsaufbau. OpenVPN, SOPHOS Connect, etc)

Einwahl mit Benutzer, Kennwort und OTP klappt, an der SOPHOS wird mir auch angezeigt, dass der Benutzer sich sauber eingewählt und die IP 10.242.2.2 aus dem ssl_VPN-Pool gekommen hat.

Will ich mit dem Benutzer nun im internen Netzwerk per RDP auf einen Server zugreifen, so wid mir im Firewall-Log auch angezeigt, dass die Regel Nr. 3 greift und es wird laut Logfile nichts ge-DROP-t:

 

10:18:17 WebAdmin connection TCP  
10.242.2.2 : 53656
→
10.242.2.1 : 4444
 
[SYN] len=52 ttl=128 tos=0x00
10:31:01 Packet filter rule #3 TCP  
10.242.2.2 : 53657
→
10.0.0.13 : 3389
 
[SYN] len=52 ttl=127 tos=0x00 srcmac=c8:4f:86:xx:xx:xx

Allerdings bekommt der Client sowohl beim Aufruf des Benutzerportals der SOPHOS, as auch bei der RDP Verbindung jeweils gesagt, die Gegenstelle sei nicht verfügbar.

Was in der letzten Woche an dem Netzwerk, der SOPHOS etc geändert wurde: das Update auf die aktuelle Firmware der SOPHOS. Allerdings war nach dem Update noch ein Arbeiten per SSL-VPN und RDP von extern möglich. Daher bin ich komplett ratlos.

Weitere Infos:

der Server auf den per RDP zugegriffen werden soll ist von intern erreichbar, wurde auch schon neu gestartet. DIe SOPHOS ist ebenfalls durchgestartet worden, um hier einen Fehlerteufel auszuschließen

Jmd noch eine Idee?

Besten Gruß

Christian 



This thread was automatically locked due to age.
Parents
  • 0

    Da die o.g. SOPHOS nicht die einzige UTM ist, auf die ich Zugriff habe, eine weitere Info: auf einer v9.711-5 läuft das o.g. Konstrukt problemlos.

    Ärgerlich, dass ich die o.g. SOPHOS aber auch erst am gestrigen Montag gegen 19:00 von 9.711-5 auf 9.712-13 aktualisiert habe. Den schwarzen Peter kann ich so nicht komplett an die neue Version abgeben.

    Mittlerweile haben noch zwei weitere Kollegen auf das Konstrukt geschaut. Wir sind einstimmig ratlos :) 

  • 0 in reply to Christian Buczek

    Hallo,

    falls nicht schon gelöst ... gibt es in dem Netz weitere Gateways?

    Welchen Weg nimmt ein Packet beim Traceroute vom Server (10.0.0.13) in Richtung 10.242.2.2?


    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.

  • 0 in reply to dirkkotte

    Hallo Dirk,

    wir haben aktuell nichts weiter an der Konfiguration gemacht und dennoch funktioniert es seit dem 06.10.2022 (zwei Tage später) wieder alles ordentlich. Ich vermute, wenn auch ganz weit hergeholt, dass es am ISP lag. Es gab zu der Zeit in der Gegend größere Störungen bei der Versatel / 1und1 im Netz. Wie gesagt, alles nur Mutmaßungen, Verschwörungstheorien und Stammtischparolen, aber ganz offensichtlich läuft alles wieder, wie es soll. 

    Danke der Nachfrage, ich schließe das Thema hier in der Hoffnung, dass ich es nicht erneut öffnen muss.

    Gruß

    Chris

Reply
  • 0 in reply to dirkkotte

    Hallo Dirk,

    wir haben aktuell nichts weiter an der Konfiguration gemacht und dennoch funktioniert es seit dem 06.10.2022 (zwei Tage später) wieder alles ordentlich. Ich vermute, wenn auch ganz weit hergeholt, dass es am ISP lag. Es gab zu der Zeit in der Gegend größere Störungen bei der Versatel / 1und1 im Netz. Wie gesagt, alles nur Mutmaßungen, Verschwörungstheorien und Stammtischparolen, aber ganz offensichtlich läuft alles wieder, wie es soll. 

    Danke der Nachfrage, ich schließe das Thema hier in der Hoffnung, dass ich es nicht erneut öffnen muss.

    Gruß

    Chris

Children
No Data
Unfiltered HTML