[2003] RDP op poort 80 naast IIS*

[jbr]

Ik zit met het volgende probleem: op mijn werk draaien we een Windows 2003 Server met Terminal Server erop. Sommige klanten hebben connecties via de default poort (3389) dichtgezet: vaak is er wel verkeer mogelijk via poort 80.

Nu weet ik hoe ik de listening poort van TS moet veranderen, alleen draaien we ook IIS op poort 80 op de Win2k3 server. Deze gaan elkaar dus bijten. Een optie (aangezien we geen https gebruiken, is de listening poort op 443 te zetten. Ik heb nog niks kunnen proberen (ik riskeer liever niet om de TS listening poort op de server vanaf thuis te veranderen en dan er niet meer bij te kunnen), maar een alternatief idee is misschien dit:

1. TS web connection installeren op de server
2. Een nieuwe website in IIS definieren, op poort 80 maar dmv een host header (blabla.dyndns.org oid) te onderscheiden.
3. De properties van de nieuw gedefinieerde website zo instellen dat deze website naar een andere poort op de server verwijst (dus http://blabla.dyndns.org:3389)

Vervolgens zou je (hopelijk) bij klanten dan in een webbrowser via http://blabla.dyndns.org op de server moeten kunnen komen, maar of dit dus werkt weet ik niet.

Mijn vraag is dus of iemand weet of dit gaat werken, maar eigenlijk liever of iemand een alternatief weet aangezien dit het enige is wat ik kan bedenken om toch een connectie te kunnen maken.

[sanfranjake]

Ga het eerst eens even proberen allemaal. GoT is geen helpdesk waar je deze vragen klakkeloos neer kan kwakken Zoek even goed rond.Een tweakers wil altijd graag zelf dingen uitvinden. Wat weerhoudt je hier van?

Ik zet nog even [2003] in de titel, omdat dat verplicht is in Windows Operating Systems. Lees daarover Windows Operating Systems - Policy nog even door

[ Voor 23% gewijzigd door sanfranjake op 24-03-2005 10:43 ]

[mutsje]

gewoon terminal server web installeren via add/remove programs??? dan kun je gewoon via de default RDP poort via het internet naar je server toe.

[jbr]

sanfranjake schreef op donderdag 24 maart 2005 @ 10:42:
Ga het eerst eens even proberen allemaal. GoT is geen helpdesk waar je deze vragen klakkeloos neer kan kwakken Zoek even goed rond.Een tweakers wil altijd graag zelf dingen uitvinden. Wat weerhoudt je hier van?

Ik vind de oplossing redelijk omslachtig, ik vraag of iemand een beter idee heeft.
Zoeken kan ik ook, maar de meeste vragen op dit forum over RDP gaan over het verzetten van de listening port en port forwarding op routers om RDP mogelijk te maken of over andere pakketten (zoals VNC) maar dat is geen goede oplossing omdat we geen TS licenties hebben aangekocht om vervolgens een ander pakket te gaan gebruiken. En ten tweede duurt het een tijdje voordat ik weer op kantoor ben en er dus een risico inzit dat ik (en andere systeembeheerders) niet meer op het systeem kunnen met TS als ik die verbinding verklooi, daarom zou ik graag willen dat iemand kan verifieren of dit werkt voordat ik er mee ga zitten spelen. Wat is daar erg aan?

[jbr]

mutsje schreef op donderdag 24 maart 2005 @ 11:06:
gewoon terminal server web installeren via add/remove programs??? dan kun je gewoon via de default RDP poort via het internet naar je server toe.

Bedankt voor de optie, maar ik denk dat je het probleem niet helemaal begrijpt..

[Verwijderd]

je kan geen 2 applicatie's op dezelfde port draaien. je enige mogelijkheid is dus port 443 gebruiken.

hostheaders is iets wat gespecificeerd wordt in http verkeer. het werkt dus niet voor mstsc...
(en dus ook niet als je web gebruikt, onderwater wordt er nog steeds een ts client opgestart).

[Verwijderd]

je wilt vanaf die klanten verbinding met je eigen TS maken ?

[jbr]

Verwijderd schreef op donderdag 24 maart 2005 @ 12:16:
je kan geen 2 applicatie's op dezelfde port draaien. je enige mogelijkheid is dus port 443 gebruiken.

Ik wilde dit doen:
De properties van de nieuw gedefinieerde website zo instellen dat deze website naar een andere poort op de server verwijst (dus http://blabla.dyndns.org:3389)
Dat zou dus moeten kunnen...

hostheaders is iets wat gespecificeerd wordt in http verkeer. het werkt dus niet voor mstsc...

Is dat niet met TS Web Connection te omzeilen? Ik bedoel: als ik mijn pakketjes maar naar poort 80 kan sturen dan ben ik denk ik al geholpen....

(en dus ook niet als je web gebruikt, onderwater wordt er nog steeds een ts client opgestart).

Dat is eventueel wel waar... dus hard een poort opgeven in het adres helpt dan ook niet? (dus: http://blabla.dyndns.org:80)

[jbr]

Verwijderd schreef op donderdag 24 maart 2005 @ 12:18:
je wilt vanaf die klanten verbinding met je eigen TS maken ?

Dat klopt... ik ben dus ook afhankelijk van de LAN->WAN policy die zij hun clients opleggen.

[mutsje]

je kunt via de webpagina gewoon server en port opgeven. Als je dat niet lukt iemand op got heeft de asp al eens veranderd hoe tsweb eruit moet zien etc moet je daar even op zoeken.

offtopic:
* mutsje snapt gelukkig terminal servers absoluut niet

[Verwijderd]

jbr666 schreef op donderdag 24 maart 2005 @ 13:21:
[...]

Dat klopt... ik ben dus ook afhankelijk van de LAN->WAN policy die zij hun clients opleggen.

je zal dan een http tunnel oid moeten gebruiken. tenminste als ze alleen http verkeer toestaan ga ik er vanuit dat er ook een proxy staat...

[sanfranjake]

Als ze het protocol blokkeren heb je nog steeds weinig kans natuurlijk

[jbr]

Verwijderd schreef op donderdag 24 maart 2005 @ 13:37:
je zal dan een http tunnel oid moeten gebruiken. tenminste als ze alleen http verkeer toestaan ga ik er vanuit dat er ook een proxy staat...

Er staat inderdaad een proxy bij de meesten.

EN ik las net dit:

wat je ook kan doen met de nieuwe tsweb versie is de default.htm aanpassen. Zoek naar de regels waar MsRdpClient.AdvancedSettings2 staan en voeg een extra regel met toe met : MsRdpClient.AdvancedSettings2.RDPPort = xxxx .

Zo zou ik dus mijn TS Web Connection aan kunnen passen om over poort 80 te werken. De vraag is alleen of ik IIS kan gebruiken om op de server (via host header) het verkeer te forwarden naar de TS server. Anders moet ik inderdaad op de router van mijn werk poort 443 open moeten zetten en deze moeten forwarden naar poort 3389 op de server.

Eens kijken of ik beide opties kan uitproberen zonder dat er dingen erg mis gaan.

[mutsje]

als je de listening port van een terminal server aanpast moet je rebooten

draai je alleen remote desktop of terminal server in application mode. als je dan de poort veranderd zul je alle andere gebruikers ook op de hoogte moeten brengen dat ze ander poortnr op moeten geven

[ Voor 58% gewijzigd door mutsje op 24-03-2005 13:52 ]

[jbr]

sanfranjake schreef op donderdag 24 maart 2005 @ 13:47:
Als ze het protocol blokkeren heb je nog steeds weinig kans natuurlijk

Jah dat klopt...
Maar ik denk dat er toch wel enkelen zijn die alleen de poorten dichtzetten en niet het protocol. (weinig cisco's gezien iig )

[Verwijderd]

een proxy blokt het ook hoor... weinig kans dat je rdp kan cachen

[sanfranjake]

jbr666 schreef op donderdag 24 maart 2005 @ 13:50:
[...]

Jah dat klopt...
Maar ik denk dat er toch wel enkelen zijn die alleen de poorten dichtzetten en niet het protocol. (weinig cisco's gezien iig )

Niet alleen cisco blokkeert protocollen, maar ook ISA server, Checkpoint en heel veel anderen doen dat ook. Feit is eigenlijk als je een goede oplossing hebt dat deze dit kan

[jbr]

Het was ook maar een voorbeeldje... de meesten gebruiken namelijk Vigors enzo (hier en daar ook Linksys) en voor zover ik weet hebben die alleen een poort en site blocker. De grotere gebruiken ook ISA ja, maar dan ligt het nog aan de instellingen...

[0fbe]

Draai je een router? Anders zou je bijv. poort 81 82 whatever, kunnen door routen naar 3389 intern

[jbr]

timcooijmans schreef op donderdag 24 maart 2005 @ 15:12:
Draai je een router? Anders zou je bijv. poort 81 82 whatever, kunnen door routen naar 3389 intern

Jazeker, maar dit gaat natuurlijk voorbij aan het probleem met de verbinding die ik vanuit klanten mag maken (alleen naar poort 80 / 443 van externe servers). Het portforwarden was dan waarschijnlijk ook niet nodig geweest, want als ik poort 81 of 82 mag benaderen, dan was poort 3389 ook geen probleem geweest

[jbr]

Het werkt gedeeltelijk:

• Listening Port veranderd naar 443
• Router aangepast
• verbinden met adres.nl:443

Het werkt dus alleen niet op plekken waar ze het protocol geblokkeerd hebben, maar bij het grootste gedeelte van de klanten kijkt men alleen naar poorten en adressen.

Helemaal goed werkt het dus nooit, maar ik ben iig een stuk geholpen. Bedankt voor de reacties!

[jbr]

Uiteindelijk hebben we het opgelost door een SSH Server te installeren, te weten Bitvise WinSSHD. Hiermee kun je een SSH connectie leggen en vervolgens een Remote Desktop Sessie hierover openen. Je moet dan wel gebruik maken van het (gratis) programmaatje Tunnelier (ook van Bitvise) maar het draait als een tierelier!

[sanfranjake]

Waarom laat je de firewall-regels niet gewoon aanpassen als het zo belangrijk is dat je op die server kan komen vanaf projecten.... Als jij je werk niet goed kunt doen zonder terminalserver-connectie lijkt me dat heel wat waard voor bedrijven die je vast flink geld betalen
Anders gaat dit topic eigenlijk tegen de regels in, aangezien het over het omzeilen van een beveiliging gaat

[jbr]

Hmm... je hebt een punt, alhoewel ik "omzeilen van een beveiliging" een iets te overtrokken set termen vind om deze situatie te beschrijven. De meeste firewall rules zijn ingesteld om de meest standaard aanvallen (dus een doelbewuste poging van buitenaf) af te weren. Dat dit betekent dat ik mijn werk niet goed kan doen is een lastige bijkomstigheid, maar als ik met medeweten van de mensen daar de benodigde connectie kan maken zonder dat daar (soms op vele niveaus hoger) aanpassingen aan het netwerk voor gedaan hoeven worden dan is dat een workaround in mijn optiek.

Het is dat we geen inbelmogelijkheid meer hebben, maar anders had het hele euvel ook omzeild kunnen worden door in te bellen met een ISDN of analoge telefoonlijn binnen het bedrijf, maar aangezien ook dat niet mogelijk is, moet je creatief zijn.

En dan te bedenken dat we die RDP nodig hebben om vanaf het IP van het werk (anderen worden niet toegestaan) remote configuratie van clienten mogelijk te maken