Ubee - RDP

Ik wil mijn PC thuis overnemen vanaf mijn werk, echter hebben ze poort 3389 dicht gezet. Mijn mijn ouder router kon ik de port forwarding van de inkomende port anders zetten dan de lokale poort. Dus bv inkomend poort 22 en lokal port 3389. Echter kan dit niet meer met de nieuwe Ubee modem/router van Ziggo.

Nu heb ik al geprobeerd om in de registry de RDP port anders te zetten, maar dat is nog niet gelukt. Mogelijk te maken met de windows firewall instellingen? Echter is het mij nog niet gelukt om deze juist te zetten.

Hebben jullie misschien nog tips?
Mogelijk dat je bv een soort port conversion kan doen in de firewall.

Ieder tip is welkom!!

En voor de rest: allemaal prettige kerst en al het goeds voor 2012

Port forwards zijn altijd mogelijk, maar port translations niet.
Mijn wndr3700 router ondersteunt dat zelfs niet.
De lokale firewall kun je testen door thuis RDP te gebruiken. Het netwerk verkeer in je lokale netwerk gaat niet langs de router. Dus het moet eerst in je eigen netwerk werken. De proxy op je werk zal trouwens wel bijna alles tegenhouden behalve poort 80/8080.

mesa57 zei:

Port forwards zijn altijd mogelijk, maar port translations niet.
Mijn wndr3700 router ondersteunt dat zelfs niet.
De lokale firewall kun je testen door thuis RDP te gebruiken. Het netwerk verkeer in je lokale netwerk gaat niet langs de router. Dus het moet eerst in je eigen netwerk werken. De proxy op je werk zal trouwens wel bijna alles tegenhouden behalve poort 80/8080.

Klik om te vergroten...

https://secure.logmein.com/nl/

of

https://www.teamviewer.com/nl/

mear zei:

Ieder tip is welkom!!

Klik om te vergroten...

google, search,
" tunnels rdp mstsc ssh "

Tips:
ssh-server op je window$-box op port 443 laten draaien,
op je ubee inkomende port 443 forwarden naar het FIXED ip-dres van je window$-pc (mac-ip instelling op je ubee)
rdp-server gewoon op port 3389 laten (window$-FW port 443 en 3389 toe-laten-staan)
zie verder document hieronder,

Q: waarom ssh-server op port 443 en niet op 22 ?
A: omdat in een coorporative netwerk outgoing port 22 nagenoeg altijd dichtstaat, evenzo port 3389. vaak staan daar alleen de uitgaande porten 80 en 443 open.

ssh-server over port 80 gaat meestal niet lukken, omdat iets van een proxy en/of smart-defender o.i.d. (uitbreiding van de coorporative FW) in de pakketjes van port 80 ziet dat het geen html is. (header-info van de tcp-pakketjes), in zo'n geval worden die pakketjes gedropt.

port 443 gaat wel werken omdat daarin altijd encrypte data staat, dus kan de smart-defender daarin niet koekeloeren.

een fijne en simpele window$-ssh-server is 'bitvise winsshd'
je kan dan mbv winscp oid. bestanden naar/van huis en werk op encrypte manier heen-en-weer-overfluiten.

urls zoals die van logmein (en aanverwante) plus hobby, xxx- en hack/crack-sites worden ook vaak geblokkeerd in een coorporative netwerk (staan dan in iets van een banned-list) dus is dat niet altijd mogelijk.

succes enzo.

https://www.google.com/url?sa=t&rct...IQBRSBgl_u59TGsqA&sig2=QWOECcp1J0qdC-cK6SOS5Q

Beste Mesa57,
Het gaat binnen mijn lokale netwerk ook al niet, dus zal inderdaad iets zijn met de instellingen van mij firewall. Hier nog tips/links voor te vinden?
Ik draai op Win7 64bit.
PS zou wel een de mooiste oplossing zijn van de ideeen die tot zoverre aangedragen zijn (denk ik :roll

Beste Schollaert,
het Teamviewer al draaien, maar ben niet zo weg van de snelheid en kwaliteit (wil graag volledig beeld)

Beste Pietsnot,
Hier moet ik me even in verdiepen. Bedankt voor je bericht.
Maar kan je dan echt het scherm overnemen of alleen data overzenden?

mear zei:

Beste Mesa57,
Het gaat binnen mijn lokale netwerk ook al niet, dus zal inderdaad iets zijn met de instellingen van mij firewall. Hier nog tips/links voor te vinden?
Ik draai op Win7 64bit.
PS zou wel een de mooiste oplossing zijn van de ideeen die tot zoverre aangedragen zijn (denk ik :roll

Beste Schollaert,
het Teamviewer al draaien, maar ben niet zo weg van de snelheid en kwaliteit (wil graag volledig beeld)

Beste Pietsnot,
Hier moet ik me even in verdiepen. Bedankt voor je bericht.
Maar kan je dan echt het scherm overnemen of alleen data overzenden?

Klik om te vergroten...

jij boft nog dat TeamViewer doorgelaten/toegestaan wordt !

andere nadelen m.g.v. teamviewer/logmein en aanverwanten:
je bent altijd afhankelijk van die TV/logmein/o.i.d.-server, als 'ie down is heb je geen connectie naar huis.
en tijdens "de spitsuren" traag enzo.
da's logisch want de datatransmissie verloopt via een TV/logmein o.i.d.-server.
bovendien weet je niet wat ze daar uitspoken met jouw "gevangen" data.
maar TV blijft altijd handig om erbij te hebben. (die werkt ook tussen win-linux-mac, vv, dus handig wel)

dat verdiepen in deze materie valt reuze mee: google is je vriend.
Bovendien heeft deze oplossing louter voordelen:
- secure
- geen third-party/intermediate server, dus altijd sneller zonder dit TV gebeuren
- wanneer outgoing port 443 wordt toegestaan, gaat dit werken.
- non-network/linux-newbies werken vaak op deze wijze
- geldt voor alle remote/private-servers (mbv ssh-tunneling), niet alleen voor je rdp-servertje thuis
- JAHA, je kan je scherm overnemen,
doe maar ff :
google-button afbeeldingen op "ssh tunnel rdp" ,
google-button-video "windows rdp ssh tunnel",
of
youtube, search " rdp mstsc ssh tunnel"
enzo
willen is kunnen, en je wordt er weer wat slimmer door, zodra je dit gaat bestuderen en tzt snappen, dus.

pietsnot zei:

andere nadelen m.g.v. teamviewer/logmein en aanverwanten:
je bent altijd afhankelijk van die TV/logmein/o.i.d.-server, als 'ie down is heb je geen connectie naar huis.
en tijdens "de spitsuren" traag enzo.
da's logisch want de datatransmissie verloopt via een TV/logmein o.i.d.-server.

Klik om te vergroten...

[offtopic]
Dat klopt niet. Nadat de mediation server beide nodes met elkaar in kontakt heeft gebracht is er een directe point to point verbinding waar de mediation server geen rol meer in speelt. Maar de udp hole punching die daarbij nodig is gaat sowieso waarschijnlijk niet werken achter de proxy.
[/offtopic]

mesa57 zei:

[offtopic]
Dat klopt niet. Nadat de mediation server beide nodes met elkaar in kontakt heeft gebracht is er een directe point to point verbinding waar de mediation server geen rol meer in speelt. Maar de udp hole punching die daarbij nodig is gaat sowieso waarschijnlijk niet werken achter de proxy.
[/offtopic]

Klik om te vergroten...

feiten:
teamviewer is in het weekend aanzienlijk trager dan door-de-weeks in de ochtend.
teamviewer werkt wel degelijk achter coorporative proxies

Ziet er naar uit dat het nu werkt nadat ik een exeption rule heb gemaakt in de firewall settings op de zakelijk laptop (gelukkig kon ik daarin wijzigingen maken).

In ieder geval via VNP via mijn werk werkt het nu, van de week maar eens op de zaak proberen :-)

pietsnot zei:

dat verdiepen in deze materie valt reuze mee: google is je vriend.
Bovendien heeft deze oplossing louter voordelen:
- secure
- geen third-party/intermediate server, dus altijd sneller zonder dit TV gebeuren
- wanneer outgoing port 443 wordt toegestaan, gaat dit werken.
- non-network/linux-newbies werken vaak op deze wijze
- geldt voor alle remote/private-servers (mbv ssh-tunneling), niet alleen voor je rdp-servertje thuis
- JAHA, je kan je scherm overnemen,
doe maar ff :
google-button afbeeldingen op "ssh tunnel rdp" ,
google-button-video "windows rdp ssh tunnel",
of
youtube, search " rdp mstsc ssh tunnel"
enzo
willen is kunnen, en je wordt er weer wat slimmer door, zodra je dit gaat bestuderen en tzt snappen, dus.

Klik om te vergroten...

Vond ik wel een goed idee
Helaas draait er hier een ISA proxy en werkt de combinatie PUTTY en COPSSH niet. Als je nog een oplossing hebt ?