Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 2847 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

Sophos XG SSL VPN Client - Remote Desktop Abbrüche

danny_mv

Hallo Zusammen,

ich weiß nicht mehr weiter. Folgendes Problem: 

Wir haben einige User, die sich mit dem SSL Client verbinden und dann per RDP auf einen Terminalserver oder ihre lokalen Workstations schalten. Unabhängig vom Zielbetriebssystem ( Windows 10, Win SRV 2k12, Win SRV 2k8R2) gibt es immer wieder regelmäßige Abbrüche der RDP Verbindung. Die Session wird dann i. d. R. nach ein oder zweimaligen Versuch des Neuaufbaus automatisch wieder verbunden. 

Das Problem trat schon einmal auf, dann habe ich SSL VPN auf TCP umgestellt und alles war gut. Inzwischen häufen sich die Probleme jedoch wieder und in der aktuellen Situation, steht mein Telefon nicht still. Ich habe heute noch auf SFOS 17.5.10 geupdatet, jedoch ohne Erfolg. Auch das hinzufügen von UDP 3389 als Remotedesktop Dienst auch ohne Besserung. 

Im SSL Client Log steht nichts, im Firewalllog auch nicht. Einzig im Windows Eventlog. 

Ohne SSL VPN, also direkt aus dem LAN funktionieren die RDP Zugriffe fehlerfrei. 

 

Hatte jemand ähnliches Problem oder hat eine Idee? 



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

    Wir konnten die Abbrüche nun beheben. Microsoft nutzt seit einiger Zeit für das Remotedesktop Protokoll neben TCP auch UDP:

    10:20:37.945807 Port8, IN: IP 10.50.57.39.3389 > 10.81.234.44.49898: Flags [P.], ack 1, win 63135, length 51
    10:20:37.945822 tun0, OUT: IP 10.50.57.39.3389 > 10.81.234.44.49898: Flags [P.], ack 1, win 63135, length 51
    10:20:38.023094 tun0, IN: IP 10.81.234.44.49898 > 10.50.57.39.3389: Flags [.], ack 867, win 509, length 0
    10:20:38.023132 Port8, OUT: IP 10.81.234.44.49898 > 10.50.57.39.3389: Flags [.], ack 867, win 509, length 0
    10:20:39.951051 Port8, IN: IP 10.50.57.39.3389 > 10.81.234.44.49898: Flags [P.], ack 1, win 63135, length 51
    10:20:39.951079 tun0, OUT: IP 10.50.57.39.3389 > 10.81.234.44.49898: Flags [P.], ack 1, win 63135, length 51
    10:20:40.027322 tun0, IN: IP 10.81.234.44.49898 > 10.50.57.39.3389: Flags [.], ack 918, win 508, length 0
    10:20:40.027332 Port8, OUT: IP 10.81.234.44.49898 > 10.50.57.39.3389: Flags [.], ack 918, win 508, length 0
    10:20:40.893683 Port8, IN: IP 10.50.57.39.3389 > 10.81.234.44.49454: UDP, length 12
    10:20:40.893712 tun0, OUT: IP 10.50.57.39.3389 > 10.81.234.44.49454: UDP, length 12
    10:20:40.958420 tun0, IN: IP 10.81.234.44.49454 > 10.50.57.39.3389: UDP, length 17
    10:20:40.958668 Port8, OUT: IP 10.81.234.44.49454 > 10.50.57.39.3389: UDP, length 17
    10:20:41.023329 Port8, IN: IP 10.50.57.39.3389 > 10.81.234.44.49454: UDP, length 11
    10:20:41.023370 tun0, OUT: IP 10.50.57.39.3389 > 10.81.234.44.49454: UDP, length 11

     

    Per GPO lässt sich jedoch TCP erzwingen, sodass kein UDP mehr genutzt wird:

    13:40:57.462132 Port8, OUT: IP 10.81.234.32.49722 > 10.10.57.4.3389: Flags [.], ack 92946, win 2580, length 0
    13:40:57.466111 Port8, IN: IP 10.10.57.4.3389 > 10.81.234.32.49722: Flags [P.], ack 4793, win 63669, length 310
    13:40:57.466118 tun0, OUT: IP 10.10.57.4.3389 > 10.81.234.32.49722: Flags [P.], ack 4793, win 63669, length 310
    13:40:57.481946 tun0, IN: IP 10.81.234.32.49722 > 10.10.57.4.3389: Flags [.], ack 93560, win 2578, length 0
    13:40:57.481966 Port8, OUT: IP 10.81.234.32.49722 > 10.10.57.4.3389: Flags [.], ack 93560, win 2578, length 0
    13:40:57.485888 Port8, IN: IP 10.10.57.4.3389 > 10.81.234.32.49722: Flags [P.], ack 4793, win 63669, length 352
    13:40:57.485894 tun0, OUT: IP 10.10.57.4.3389 > 10.81.234.32.49722: Flags [P.], ack 4793, win 63669, length 352
    13:40:57.506887 Port8, IN: IP 10.10.57.4.3389 > 10.81.234.32.49722: Flags [P.], ack 4793, win 63669, length 335
    13:40:57.506897 tun0, OUT: IP 10.10.57.4.3389 > 10.81.234.32.49722: Flags [P.], ack 4793, win 63669, length 335

    Ergebnis:

    Es gibt keine Abbrüche mehr bei RDP Verbindungen über den SSL Client. Die Performance ist geringfügig schlechter als bei UDP aber dafür dauerhaft stabil.

  • 0 in reply to danny_mv

    Ich kenne die XG nicht, aber was spricht dagegen in der Firewall auch UDP zu erlauben, da wie Du schon bemerkt hast RDP inzwischen auch UDP statt nur TCP ist?

    Beste Grüße 

    Alex 

    -

  • 0 in reply to Alexander Busch

    Hi Alex,

    in der FW war/ist UDP 3389 erlaubt. Wurde auch durch den Paketfilter durchgelassen und geloggt. Die Abbrüche sind trotzdem entstanden. Also irgendwas mag RDP in Verbindung mit SSL nicht. 

    Die Abbrüche waren auch nur im Eventlog auf den Remotehosts zu sehen, nicht im SSL oder Firewalllog.

     

    Betroffen sind/waren aber diverse Gateways, die SSL Clients anbieten, nicht nur Sophos. Also scheint es ein allgemeines Problem zu sein.

  • 0 in reply to danny_mv

    Es kann auch am Provider liegen.

    Hatte ähnliche Abrisse mit Sipgate und UDP, auch Sipgate kann man auf rein TCP um konfigurieren und dann war alles gut.

    Der Techniker von Sipgate bei dem ich die Portdaten erfragt hatte, hat mir erzählt das die in UnityNetzen das oft haben.

Reply
  • 0 in reply to danny_mv

    Es kann auch am Provider liegen.

    Hatte ähnliche Abrisse mit Sipgate und UDP, auch Sipgate kann man auf rein TCP um konfigurieren und dann war alles gut.

    Der Techniker von Sipgate bei dem ich die Portdaten erfragt hatte, hat mir erzählt das die in UnityNetzen das oft haben.

Children
No Data
Unfiltered HTML