RDP over SSL oplossing die werkt (zonder vertraging)

[Dysmael]

Ik heb inmiddels verscheidene apparaten getest maar geen van allen zorgt voor een fatsoenlijke RDP connectie over SSL. Bij allen is er sprake van teveel vertraging. Geen snelheidsprobleem maar een tijdsverschil.

Wanneer er een RDP connectie over SSL gebruikt wordt zit er een paar milliseconden verschil tussen het intikken van tekst en het resultaat op het beeldscherm.

Ik heb getest: Juniper SA2000, Watchguard SSL100, Sonicwall SRA4200 en Barracuda SSL280. Bij geen van allen werkt RDP over SSL fatsoenlijk.

Voor de goede orde: dit is gereproduceerd op verschillende verbindingen waar een rechtstreekse verbinding met RDP wel goed en vlot werkt. Het aanpassen van MTU groottes heeft nagenoeg geen verschil gemaakt (zowel aanpassingen op de server zelf als op de interfaces van de SSL apparatuur). Waar mogelijk is TCP_NODELAY uitgeschakeld.

Als een reguliere tunnel gebruikt wordt lijkt het verschil soms minder te zijn. Mogelijke oorzaak is het ontbreken van packet-rewriting wat dat als gevolg heeft.

Deze ervaring heb ik niet wanneer gebruikgemaakt wordt van een TS Gateway.

Wat zijn jullie ervaringen?
Maakt er iemand gebruik van een apart apparaat om bronnen binnen het netwerk mee te publiceren waarbij RDP over SSL wel fatsoenlijk werkt?

Ik heb nog geen apparatuur van Cisco getest maar verwacht daar dezelfde problemen mee.

Dit filmpje demonstreert het probleem: [YouTube: http://www.youtube.com/watch?v=pzDDV8BToZ4]. Daarbij moet worden opgemerkt dat bij de andere apparaten wel een vloeiende beweging ontstaat wanneer een toets ingedrukt wordt. Het duurt wel altijd iets te lang voordat het resultaat zichtbaar is op het scherm. Citrix Speedscreen boodt geen verbetering.

[salvador4]

Ik heb verschillende implementaties met Cisco SSL webvpn uitgerold (zowel op IOS routers als met ASA appliances) en heb nog nooit een langere vetraging ontdekt met RPD verbindingen. Vroeger ook verschillende openvpn servers ingericht (ook SSL) en ook hier geen last van trage RDP verbindingen. De appliciances die jij opnoemt heb ik nooit mee gewerkt, en kan ik ook niets zinnigs over zeggen.

PS ik heb hier hier wel over reguliere SSL tunnels.

[ Voor 6% gewijzigd door salvador4 op 26-03-2011 15:59 ]

[Rolfie]

Een TS Gateway is juist bedoelt voor een secure remote ontsluiting via een reverse proxy.
Eventueel zou je eens kunnen kijken naar SSTP VPN's of UAG applicaties van MS.

[Dysmael]

SSTP is inderdaad heel interessant maar niet de oplossing die ik zoek. Hoewel ik er intussen wel naar neig om de zoektocht te staken en over te stappen naar op Windows gebaseerde oplossingen. Een aparte server als TS Gateway i.c.m. evt SSTP en NAP zit qua kosten net zo hoog als een aparte SSL appliance.

Toch blijf ik me erover verbazen dat geen enkele van de genoemde SSL oplossingen RDP tunneling waar kan maken.

Reguliere SSL tunnels (alleen TCP tunneling) hebben dit probleem inderdaad minder Salvador. Ik zoek echter een oplossing die bij klanten kan worden ingezet waarbij ze geen gebruik hoeven te maken van tunneling maar simpelweg kunnen inloggen op een portal waar authenticatie plaatsvind om vervolgens middels een ActiveX / Java applet gepubliseerde bronnen kunnen benaderen.

[Bl@ckbird]

Heb je support cases gelogd bij de betreffende fabrikanten en wat zeggen zij?
Ze kennen hun eigen producten het beste en weten ook hoe je dit het beste kan debuggen en wat best practices zijn voor RDP over SSL...

[Dysmael]

Fabrikanten erkennen het probleem niet, kunnen het niet oplossen en Watchguard heeft na 8 maand lang 'troubleshooten' aangegeven dat ze het probleem wel erkennen maar niet kunnen oplossen. Daarop hebben we alle SSL100's gecrediteerd gekregen.

Edit: het probleem is consistent en doet zich voor bij alle apparaten die ik inmiddels getest heb. Watchguard heeft enkele maanden lang aangegeven dat ze het probleem niet kennen maar na iemand van Watchguard op bezoek te hebben gehad waarbij ik 'live' het probleem gedemonstreerd heb is toegegeven dat het probleem wel bestaat maar niet op te lossen is.

Ik ben niet van plan om bij de andere fabrikanten een soortgelijk traject in te gaan. Zodra men aangeeft het probleem niet te kennen / snappen en te suggereren dat het wel aan de verbinding zal liggen of dat 'Themas' in RDP uitgeschakeld moeten worden weet ik al voldoende.

Mijn gevoel zegt me dat op dit moment een fatsoenlijke RDP over SSL oplossing niet bestaat. Niet als 'Access Gateway' - achtige oplossing welke meerdere bronnen in een netwerk 'clientless' kan aanbieden tenminste.

[ Voor 63% gewijzigd door Dysmael op 27-03-2011 17:50 ]

[deandb]

Wij werken bij onze klanten heel veel met FortiGate's van Fortinet. Bij verschillende klanten kunnen we perfect werken in RDP over een SSL VPN.

FortiGate bied zelfs een SSL bookmark portal aan, waarin je een RDP 'bookmark' kan maken. Dan start je RDP op in een java applet. En deze werkt sinds een aantal firmware releases echt goed. Op die manier moet je zelfs geen volledige tunnel aanbieden aan je clients. Al is dat wel even goed mogelijk natuurlijk.

Verder kun je ook verschillende tunnels/bookmark pages aanbieden aan verschillende user groepen.

Wat bij Fortinet ook nog tof is, is dat je geen licenties nodig hebt voor je SSL VPN. De capaciteit van hardware van het toestel is de enigste beperkende factor voor je aantal sessies.

[ Voor 7% gewijzigd door deandb op 31-03-2011 09:22 ]

[Dysmael]

Fortinet heb ik nog niet naar gekeken. Met 'perfect werken' bedoel je neem ik aan: 'met dezelfde ervaring als een rechtstreekse RDP verbinding, zonder additionele vertraging' ?
Naast RDP kan ik, neem ik aan, ook andere bronnen beschikbaarbaar maken zoals ICA, SMB etc ?

[itlee]

deandb schreef op woensdag 30 maart 2011 @ 22:17:
Wij werken bij onze klaten heel veel met FortiGate's van Fortinet. Bij verschillende klanten kunnen we perfect werken in RDP over een SSL VPN.

FortiGate bied zelfs een SSL bookmark portal aan, waarin je een RDP 'bookmark' kan maken. Dan start je RDP op in een java applet. En deze werkt sinds een aantal firmware releases echt goed. Op die manier moet je zelfs geen volledige tunnel aanbieden aan je clients. Al is dat wel even goed mogelijk natuurlijk.

Verder kun je ook verschillende tunnels/bookmark pages aanbieden aan verschillende user groepen.

Wat bij Fortinet ook nog tof is, is dat je geen licenties nodig hebt voor je SSL VPN. De capaciteit van hardware van het toestel is de enigste beperkende factor voor je aantal sessies.

kan ik beamen,...ik verkoop die spullen en installeer ze ook nog dus ben volledig met bovenstaand eens.
fortinet is goed te doen, maar wil je echt hardcore spullen en heb je knap budget dus niet een paar honderd of een paar duizend euro moet je even kijken bij F5 networks. www.f5.com kan je pimp apparatuur krijgen tegen helaas pimp prijzen, maar t werkt wel. (met name de f5 firepass)

[pizzaboertje]

Voor hoeveel gebruikers moet de oplossing geschikt zijn en heb je indicatie van het beschikbare budget?

[Dysmael]

Tot 25 gelijktijdige gebruikers, budget is niet van toepassing. Niet voor intern gebruik bedoeld maar voor reselling.

[deandb]

RolfLobker schreef op woensdag 30 maart 2011 @ 22:48:
Fortinet heb ik nog niet naar gekeken. Met 'perfect werken' bedoel je neem ik aan: 'met dezelfde ervaring als een rechtstreekse RDP verbinding, zonder additionele vertraging' ?
Naast RDP kan ik, neem ik aan, ook andere bronnen beschikbaarbaar maken zoals ICA, SMB etc ?

Dat klopt, je hebt dezelfde ervaring als via de interne LAN.

Fortinet biedt 2 SSL VPN oplossingen (alle FortiGate's vanaf de 50B kunnen dit standaard):
1. Je werkt met bookmarks. Dan kun je RDP bookmark aanmaken en werk je via een Java Applet, of fungeert hij als een soort reverse proxy voor HTTP(S), SMB, FTP enzo
2. Of je geeft een volledige tunnel over SSL aan je clients, en dan kunnen ze inderdaad alle bronnen gebruiken die beschikbaar zijn in je LAN. Uiteraard kun je via firewall policies hun toegang beperken tot wat je wil.

Beide opties kunnen ook naast elkaar werken.

Je moet maar eens zien naar een FortiGate 60C. Die kan zeker aan wat je wilt.

[Verwijderd]

Ik neem aan dat die vertraging ontstaat omdat een van de routers (ergens in het netwerk) het pakket moet fragmenteren, waardoor jij dus ' lag ' waarneemt. Is het niet mogelijk middels Path MTU de juiste MTU size te achterhalen, zodat geen enkele router in het netwerk van jouw of je ISP deze moet fragmenteren?

Wanneer je deze waarde gevonden hebt, je connectie zo op te stellen dat de pc die de connectie opzet default een kleiner ethernet frame naar buiten zend dan dat deze normaal zou doen?

[Dysmael]

MTU is al verlaagd op de server. Dat heeft weinig of geen effect gehad. Gister twee desktops op twee interfaces van de Sonicwall aangesloten gehad en daarmee dus switches et cetera uitgesloten. Ervaring daarbij was wel goed. Dat was bij de Watchguard niet het geval en bij de Barracuda en Juniper niet mogelijk (slechts 1 interface)
Ik ben er zelf ook redelijk van overtuigt dat het met de framegroote te maken heeft. Het aanpassen van de framegroote heeft echter in een 'productieomgeving' geen effect gehad.

Na het weekend ga ik er verder mee aan de slag n.a.v. de resultaten bij een directe connectie. In de praktijk moet het natuurlijk wel werken wanneer het apparaat wordt aangesloten op dezelfde switch als waar de firewall en servers op zitten en ook met een tweede switch ertussen.

De Fortigate ziet er erg interessant uit. Is zo te zien meer een firewall die ook rudimentair als portal voor een 'clientless' verbinding kan fungeren?

[fds]

Voor het onderhoud van Windows servers en met Windows Terminal Services gebruik ik altijd RDP door een SSL tunnel en ondervind totaal geen hinderlijke vertraging. Door de compressie van SSL werkt het in veel gevallen zelfs vlotter.
Wel moet ik stellen dat er altijd een Linux server/firewall tussen de Windows servers en het internet zit. Deze Linux doos is de SSH server en daarop moeten SSL accounts gemaakt worden om de tunnel te kunnen maken. Dit heeft wel als voordeel dat er bepaald kan worden wie er op afstand toegang krijgt tot het interne netwerk.

Aan de gebruikerskant heb ik zelf een C programmaatje gemaakt die de tunnel opbouwd en de RDP-client configureert en opstart (met single sign-on). Hierdoor merkt de gebruiker helemaal niets van het opbouwen van een SSL tunnel en het starten van de RDP-client. De verbinding wordt automatisch verbroken bij het afsluiten van de RDP-client.

Het systeem is eventueel wel te hergebruiken.

[Dysmael]

Zoiets is voor jou en mij te doen maar niet voor de doelgroep waar de apparatuur voor bedoeld is.
Het is de bedoeling een oplossing te bieden die geen installatie op de client-apparatuur behoeft. Dwz. 'clientless' voor zover het clientless kan. Natuurlijk moet er wel een ActiveX of Java applet geladen worden. Anders was het inderdaad snel opgelost door SSH tunneling toe te gaan passen en lokaal de RDP client op te starten. Het is juist de bedoeling dat de eindgebruiker naar een website kan gaan en daar iets aan mag klikken.

[Verwijderd]

Heb je al eens naar de Cisco ASA mogelijkheden gekeken? Voor diverse klanten heb ik een webvpn portal gemaakt met daarin de rdp plugin. Nooit geen klachten gehoord en ik heb zelf ook geen verschil in de performance gemerkt tegenover een "normale" RDP sessie

Klein minpuntje; voor fullscreen RDP dient de ActiveX versie gebruikt te worden, de Java applet biedt deze functionaliteit v.z.i.w. niet.

[deandb]

De Fortigate ziet er erg interessant uit. Is zo te zien meer een firewall die ook rudimentair als portal voor een 'clientless' verbinding kan fungeren?

Inderdaad, de fortigate is een firewall, die ook ssl vpn portals afhandeld.
'clientless' is niet geheel waar, je moet een kleine applicatie installeren (700k) voor de volledige tunnel, maar indien je die niet hebt, bied de portal die vanzelf aan (aan windows gebruikers). Mac en Linux users moeten manueel de client installeren.
(voor louter RDP via de java applet is dit niet nodig)

Deze Linux doos is de SSH server en daarop moeten SSL accounts gemaakt worden om de tunnel te kunnen maken. Dit heeft wel als voordeel dat er bepaald kan worden wie er op afstand toegang krijgt tot het interne netwerk

Op de Fortigate kan je dmv een LDAP connector ook enkel een bepaalde OU of user group gaan toelaten.
Of je kan ook op het toestel lokale accounts aanmaken. Het is zoals je zelf wel.

Heb je al eens naar de Cisco ASA mogelijkheden gekeken?

Correct me if I'm wrong, maar moet (of moest) je bij Cisco geen licenties kopen voor SSL vpn voor het aantal tunnels je kan opzetten? Zoiets maakt dat de TCO wel een pak hoger komt te liggen...

[Bl@ckbird]

Standaard zitten er op de ASA 2 Premium SSL VPN licenties.
Hiermee kan je al een webportal bouwen voor 2 concurrent / gelijktijdig aantal SSL sessies.

Er zijn ook bundeltjes van een ASA met SSL licenties, voor 10 of 25 concurrent sessies:
ASA5505-SSL10-K9 - ASA 5505 VPN Edition w/ 10 SSL Users, 50 FW Users, 3DES/AES
ASA5505-SSL25-K9 - ASA 5505 VPN Edition w/ 25 SSL Users, 50 FW Users, 3DES/AES

Let op dat deze bundels maar 50 interne netwerk users hebben.
( 50 IP adressen kunnen contact zoeken met Internet binnen 24 uur.
Dus access points en switches tellen niet mee. )

Wil je dit upgraden naar unlimited aantal users, dan heb je deze licentie upgrade nodig:
L-ASA5505-10-50= - ASA 5505 10-to-50 User Upgrade License

Wil je ook een fatsoenlijk DMZ hebben dan heb je een upgrade nodig naar Security Plus:
L-ASA5505-SEC-PR= - Promo SKU for ASA 5505 Sec. Plus Lic. w/ HA, DMZ, VLAN trunk

Een goedkope oplossing is om een standaard ASA5505-50-BUN-K9, ASA5505-UL-BUN-K9 of ASA5505-SEC-BUN-K9 te nemen en hier een Anyconnect Essentials licentie op af te sluiten:
L-ASA-AC-E-5505= - AnyConnect Essentials VPN License - ASA 5505 (25 Users)

Deze licentie sluit je af per ASA. (Niet per SSL sessie.)
Maar met de Essentials SSL VPN Licentie kan je alleen de Anyconnect SSL VPN client gebruiken.
( En dus geen webportal bouwen. )

Wil je mobiele devices voorzien van een SSL VPN client, dan zijn ook daar licenties voor.
( Apple iOS, Windows Mobile en in de toekomst Android. )

Zie ook:
http://www.cisco.com/en/U...e_management/license.html
http://www.cisco.com/en/U...heet0900aecd802930c5.html
http://www.cisco.com/en/U...heet0900aecd80402e3f.html
http://www.cisco.com/en/U..._Products_Data_Sheet.html

[fds]

Het client programmaatje (ca 700KB) verspreid ik juist via een web-site en vereist totaal geen kennis van de eindgebruiker. Het werkt volledig stand-alone, zonder enige Windows afhankelijkheden, op alle 32 en 64 bits Windows.
Er zijn 2 versies mogelijk: 1 die geinstalleerd kan worden (met een pictogram op de desktop) en 1 die tijdelijk werkt (en dus telkens gedownload dient te worden).

Programmaatje downloaden en uitvoeren, gebruikersnaam en wachtwoord opgeven en hoppeta daar is het Externe Bureaublad. Simpeler kan echt niet.