none
Zugriff auf SBS2011 über openVPN/SSL-VPN funktioniert nicht RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen, ich habe ein Problem mit dem Zugriff über openVPN auf einen SBS2011.

    Ich habe eine Securepoint Firewall beim Kunden stehen, über diese möchte ich einen SSL-VPN/openVPN Tunnel aufbauen. Der Tunnel wird auch aufgebaut, ein Ping zum Server ist über die Eingabe der IP des Servers möglich, es können aber keine Daten übertragen werden, auch RDP funktioniert nicht.

    Die Client-IP  hinter dem Tunnel ist 192.168.251.6/24
    Die Server-IP ist 192.168.20.10/24

    Ein Anruf beim Support von Securepoint brachte das Ergebnis, dass es nicht am Tunnel oder der Firewall liegt, die schaltet alles durch. Der Supporter meinte, ich müsse auf dem Server andere Netze für den Zugriff erlauben. Ich weiß aber leider nicht wo.

    Ich habe gleiche konstellation bei verschiedenen anderen Kunden fehlerfrei am Laufen ohne an der Serverconfig etwas anpassen zu müssen, auch mit SBS2011.

    Wo finde ich diese Einstellungen?

    Dienstag, 7. Mai 2013 10:57
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Mach bitte einen beidseitigen (d.h. gleichzeitig auf betroffenen Client und SBS) Netzwerk-Trace (z.B. mittels Microsoft Network Monitor bzw. "netsh trace" oder Wireshark) während Du das Problem nachstellst und analysiere das Ergebnis.

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Dienstag, 7. Mai 2013 16:23
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hallo Norbert,

    Hast du die Tipps von Tobias ausprobiert? Bist Du mit dem Troubleshooting weitergekommen?

    Viele Grüße,
    Alex

    Alex Pitulice, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Donnerstag, 9. Mai 2013 14:12
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Alex,

    sorry, ich bin bisher nicht dazu gekommen, werde am Wochenende mal schauen, da ich auch niemand im Büro.

    Viele Grüße
    Norbert

    Freitag, 10. Mai 2013 11:05
    |
  • Question
    Anmelden
    0
    Anmelden

    So, ich habe auf beidden Rechnern, also Server und Client (Client nicht in der Domain) ein Trace mit MS Network Monitak mitlaufen lassen.

    Der Client versucht zu verbinden:

    1142	08:11:56 13.05.2013	16.8428589	RdpManager.exe	WS02  	192.168.20.10	TCP	TCP:Flags=......S., SrcPort=49946, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=674222046, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192	{TCP:296, IPv4:224}
1143	08:11:56 13.05.2013	16.9263064	RdpManager.exe	192.168.20.10	WS02  	TCP	TCP:Flags=...A..S., SrcPort=MS WBT Server(3389), DstPort=49946, PayloadLen=0, Seq=587211271, Ack=674222047, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152	{TCP:296, IPv4:224}
1144	08:11:56 13.05.2013	16.9264543	RdpManager.exe	WS02  	192.168.20.10	TCP	TCP:Flags=...A...., SrcPort=49946, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=674222047, Ack=587211272, Win=64 (scale factor 0x8) = 16384	{TCP:296, IPv4:224}
1145	08:11:56 13.05.2013	16.9269615	RdpManager.exe	WS02  	192.168.20.10	RDP	RDP:Windows stub parser: Requires full Common parsers. See the "How Do I Change Parser Set Options(Version 3.3 or before) or Configure Parser Profile (Version 3.4)" help topic for tips on loading these parser sets.	{TCP:296, IPv4:224}
1146	08:11:57 13.05.2013	17.0157416	RdpManager.exe	192.168.20.10	WS02  	TCP	TCP:Flags=...A.R.., SrcPort=MS WBT Server(3389), DstPort=49946, PayloadLen=0, Seq=587211272, Ack=674222047, Win=0 (scale factor 0x8) = 0	{TCP:296, IPv4:224}

    Am Server kommt auch was an: 

    539    08:12:21 13.05.2013    19.3763629        192.168.251.6    192.168.20.10    TCP    TCP:Flags=......S., SrcPort=49946, DstPort=MS WBT Server(3389), PayloadLen=0, Seq=674222046, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192    {TCP:100, IPv4:53}
540    08:12:21 13.05.2013    19.3775565        192.168.20.10    192.168.251.6    TCP    TCP:Flags=...A..S., SrcPort=MS WBT Server(3389), DstPort=49946, PayloadLen=0, Seq=587211271, Ack=674222047, Win=8192 ( Negotiated scale factor 0x8 ) = 2097152    {TCP:100, IPv4:53}

    Eine Verbindung kommt jedoch nicht zustande.

    Wenn ich hingegen auf der Firewall die Gruppe der VPN-SSL-User für die 192.168.20.1 (Ip der Firewall) zulasse, werden Daten übertragen.

    Wo ist der Fehler? Wie gesagt, gleiche konstellation bei anderen Kunden, hier jedoch ohne Fehler.

    Montag, 13. Mai 2013 06:56
    |
  • Question
    Anmelden
    0
    Anmelden

    Sorry, aber mit diesen Informationen lässt sich nichts anfangen.

    Entweder wir brauchen die echten Details (und nicht nur Copy&Paste von irgendeinem Netzwerk-Trace Ausschnitt ohne Kontext) bzw. einer mir nichts sagenden Aussage: "Wenn ich hingegen auf der Firewall die Gruppe der VPN-SSL-User für die 192.168.20.1 (Ip der Firewall) zulasse, werden Daten übertragen" oder Du musst selber weiterschauen, wo das Problem liegt...

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Montag, 13. Mai 2013 17:39
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    hm, ok, nachdem ich nicht genau weiß wonach ich suchen soll, hab ich die beiden Traces auf Skydrive hochgeladen. Ich habe auch einen Screenshot der HideNat-Einstellungen hochgeladen, die untere Zeile ist relevant. Ohne diesen Eintrag kann ich vom Client den Server (IP) zwar per Ping erreichen, aber kann auf den Server nicht zugreifen (rdp oder andere Dienste). Sobald die untere Zeile gesetzt ist, funktioniert alles.

    https://skydrive.live.com/#cid=CFD5FDC2FCFFFFBB&id=CFD5FDC2FCFFFFBB!112

    In der Gruppe SSL_VPN_USR sind alle SSL-VPN-User enthalten, sie bekommen durch den Eintrag einen direkten Zugriff auf die interne Firewall-Schnittstelle. Es funktioniert zwar so, ist aber keine saubere Lösung.

    Montag, 13. Mai 2013 18:19
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke für die Traces.

    Um diese für Dein Szenario besser zu verstehen, kannst Du bitte auch noch zwei weitere Szenarien tracen:

    • Im selben Umfeld wie oben, jedoch wenn die Verbindung zustande kommt (sprich: "Wenn ich hingegen auf der Firewall die Gruppe der VPN-SSL-User für die 192.168.20.1 (Ip der Firewall) zulasse, werden Daten übertragen")
    • Bei einem anderen Kunden, wo es nach Deiner Aussage ohne diesen unsauberen Workaround funktioniert.

    Lad diese bitte auch dementsprechend gekennzeichnet und ggf. mit zugehörigen Hintergrundinformationen wie Client/Server-IP, Ablaufprotokoll des Traces inkl. ungefähre Zeitangaben usw.

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Mittwoch, 15. Mai 2013 08:30
    |
    Moderator