Userbase

Ik heb een WD My Cloud gekocht

Een soort NAS dus. Het spijtige is natuurlijk dat het toestel niet toelaat om de poorten te veranderen, het loopt altijd op 80 of 443.
Daarom moet je volgens WD gewoon aan portforwarding doen: extern 8080 verwijs je naar intern 80. (of 8443 -> 443).

Bij Telenet blokkeren ze echter bijna alle poorten onder 1024 én je kan geen poorten remappen met hun mijn.telenet.be portforwarding "oplossing".
Dit betekent dus dat je enkel een poort kan "forwarden" als deze intern en extern gelijk zijn. Dus een "remap" is niet mogelijk.

Ik heb dit natuurlijk gemeld aan de Telenet helpdesk en dan maar uit collère gezegd dat ik naar EDPNet ga overstappen.

Via de site van WD kan je echter ook inloggen op je NAS. Hoe dat precies werkt weet ik niet, maar het werkt wel en je kan de NAS zelfs mounten in Windows! Ideaal eigenlijk...

Ik vermoedde dat dit ongeveer zo werkt: je NAS pollt de WD website en connecteert dan van binnen naar de externe computer. Zo zou je een connectie kunnen opzetten.

Echter, om dat te verifiëren heb ik WireShark laten lopen. Ik zie inderdaad dat er iets gebeurd via SSL naar de site van WD.
Maar direct daarna wordt er een connectie opgezet die geïnitieerd wordt vanaf de externe PC én die verbinding maakt met mijn Telenet IP op poort 443...

WTF?

Als ik mijn Telenet IP nu in mijn browser zet via https://ip (dus poort 443) dan kom ik gewoon op mijn NAS

Instellingen router:
uPnP staat aan
Firewall staat uit
Portforwarding staat uit
DMZ staat niet ingesteld

Hoe komt dit?
Heeft uPnP hier iets mee te zien?
Hoe weet de router naar welk intern IP ik wil connecteren?

En vooral waarom wordt dit niet geblokkeerd door Telenet

binnen het telenet netwerk staat poort 80 open dacht ik. Daarbuiten niet.
Dus vanaf vrienden die ook telenet hebben zal dit werken. Vanaf bijvoorbeeld belgacom niet.

Vroeger stonden alle poorten open in dezelfde telenet service zones, volgens mij zitten de acl die het inkomende verkeer blokkeren ergens op centralere routers. Ik moet wel zeggen dat het al enkele jaren geleden is dat ik zoiets proefondervindelijk heb vastgesteld.


Die wd tunnel is dat niet een omgekeerde connectie, de schijf maakt connectie met de centrale service en die geeft je dan omgekeerd door dezelfde connectie toegang ?

Het werkt inderdaad niet op een ander netwerk, bv via Proximus !
Het blokkeren van poorten is dan nog ridiculer!

@Tomsworld: ik zie toch een aparte tcp connectie opgezet worden. Verder is het feit dat een reguliere browser (zonder WD software geinstalleerd) toegang geeft tot het toestel dat op poort 80 draait, zonder enige vorm van portforwarding.

Hmmm hier werkt het niet hoor met dezelfde instellingen

gvmit schreef:Het blokkeren van poorten is dan nog ridiculer!

Tja, dat hebben veel mensen TN al trachten duidelijk te maken... maar om één of andere reden houden ze vol aan dit absurde gedoe

gvmit schreef:Verder is het feit dat een reguliere browser (zonder WD software geinstalleerd) toegang geeft tot het toestel dat op poort 80 draait, zonder enige vorm van portforwarding.

Op je eigen LAN heb je natuurlijk geen port forwarding nodig... da's enkel vanaf je WAN poort.

gvmit schreef:Als ik mijn Telenet IP nu in mijn browser zet via https://ip (dus poort 443) dan kom ik gewoon op mijn NAS

Hoe weet de router naar welk intern IP ik wil connecteren?

En vooral waarom wordt dit niet geblokkeerd door Telenet

Je router komt er gewoon niet aan te pas zolang je op je eigen LAN blijft (de reden hierachter heb ik in andere topics al geschreven)... er valt dus ook niets te blokkeren/forwarden op je eigen LAN.

Heeeeeel korte les TCP/IP:
De PC beslist, adhv het IP adres en de subnetmask, of de bestemmeling zijn IP adres zich binnen hetzelfde netwerk bevindt of niet.
Is dat zo, dan wordt het pakketje verstuurd met het IP van de nas als bestemming, en zal de switch dit direct naar de nas routen (via mac adressen en arp, maar da's technischer). Dit pakketje krijgt de router (of routersoftware, als de switch in de router is ingebouwd) niet eens te zien.
Is de bestemming op een ander netwerk, dan zal de pc zijn gateway aanspreken (die eigenlijk als tussenpersoon gebruikt wordt). Die gateway is in de meeste gevallen de default gateway, de router dus. Die moet dan maar zien wat hij ermee doet.

[ Post made via mobile device ]

Het gaat hier niet over mijn eigen LAN... Ik zit op 't werk bij Telenet en thuis bij Telenet. Zo dus.

Ik ben professioneel software ontwikkelaar & netwerk admin, dus UDP/TCP/... snap ik wel.
uPnP daar heb ik nooit theorie over gezien en de wiki bracht niet meer verheldering.

Hoe kan een extern device nu connecteren naar een intern device zonder portforwarding of de 'telenet DMZ' instelling aan?
Het betrof echt tcp verbinding die opgezet werd vanaf mijn werk naar mij thuis... op poort 443 dan nog wel.

Als ik een IIS webserver loop op 443, dan kan voor een inkomende connectie, de router toch niet weten of hij nu de webserver moet doorgeven of de NAS?
of zorgt uPnP voor een soort van advertentie aan de router?

gvmit schreef:Het gaat hier niet over mijn eigen LAN... Ik zit op 't werk bij Telenet en thuis bij Telenet. Zo dus.

Zover was ik al

gvmit schreef: Hoe kan een extern device nu connecteren naar een intern device zonder portforwarding of de 'telenet DMZ' instelling aan?
Het betrof echt tcp verbinding die opgezet werd vanaf mijn werk naar mij thuis... op poort 443 dan nog wel.

Ik denk dat uPnP dit doet.

gvmit schreef: Als ik een IIS webserver loop op 443, dan kan voor een inkomende connectie, de router toch niet weten of hij nu de webserver moet doorgeven of de NAS?
of zorgt uPnP voor een soort van advertentie aan de router?

Probeer eens een webserver op te zetten met https?

Ik heb dit geprobeerd met apache en openssl en bleek niet te werken zowel LAN als bij mensen die ook bij Telenet zitten.
(Wss doordat apache/openssl niet gebruik maakt van uPnP?)

gvmit schreef:Ik ben professioneel software ontwikkelaar & netwerk admin, dus UDP/TCP/... snap ik wel.

Opletten met dergelijke uitspraken... die heb ik hier nog gelezen maar dan kent men plots niet de betekenis van een subnet

Ik ken niets van PC's en netwerken... ik help hier maar gewoon wat

gvmit schreef:Hoe kan een extern device nu connecteren naar een intern device zonder portforwarding of de 'telenet DMZ' instelling aan?
Het betrof echt tcp verbinding die opgezet werd vanaf mijn werk naar mij thuis... op poort 443 dan nog wel.

Dat kan niet... poort 443 is dan wel geen probleem (omdat beide kanten Telenet zijn)... maar zonder de forwarding kan NAT het nooit correct afleveren.

gvmit schreef:of zorgt uPnP voor een soort van advertentie aan de router?

IIS doet dat zeker niet.

Ik heb mij even proberen inlezen over upnp...

I guess that: de NAS iets stuurt via broadcast of rechtstreeks naar de router om aan te kondigen dat hij luistert op poort 443 in dit geval. De router kan dan automatisch externe verbindingen die 443 willen gebruiken forwarden naar de NAS op het interne netwerk. Ik zal wireshark eens tussen de NAS en router hangen om te zien wat er precies gestuurd wordt, veel nuttige informatie over de commando's heb ik niet direct gevonden.

Een andere manier waarop ik toch zou kunnen communiceren met mijn NAS is via 'hole punching', maar ik denk niet dat dat van toepassing was.
http://en.wikipedia.org/wiki/TCP_hole_punching

Ik ga nog even voor de zekerheid bevestigen dat port 80 of 443 (met correcte portforwarding naar een IIS of Apache bv.) op het Telenet-netwerk werkt. Dan mogen ze mij nog eens uitleggen waarom ze die poorten "voor mijn veiligheid" blokkeren, maar dan niet voor 1 miljoen Telenet klanten, daar kunnen geen "onveilige mensen" tussen zitten?

Je kan altijd eens proberen uPnP uit te schakelen op je TN router (lijkt mij trouwens het meest veilig, je wil niet dat een programma zomaar zelf port mappings kan aanmaken).

One solution for NAT traversal, called the Internet Gateway Device Protocol (IGD Protocol), is implemented via UPnP. Many routers and firewalls expose themselves as Internet Gateway Devices, allowing any local UPnP control point to perform a variety of actions, including retrieving the external IP address of the device, enumerate existing port mappings, and add or remove port mappings. By adding a port mapping, a UPnP controller behind the IGD can enable traversal of the IGD from an external address to an internal client.

Hey gvmit

Ik heb mij ook een WD my cloud aangeschaft en ondervind ook heel wat problemen met Telenet. Een aantal vraagjes ?

Er in geslaagd om via de app toegang te krijgen tot de cloud via 3G ?

Uiteindelijk iets veranderd aan je poortinstellingen ? (mijntelenet of in cloud zelf ? )

CLoud een vast ip adres gegeven ? Beter ?

Kan je video's afspelen op uw tv ? Ik bezit een smarttv maar na enkele seconden afspelen van video krijg ik telkens foutmelding "apparaat afgesloten". Enig idee wat de oorzaak kan zijn ?

gvmit schreef:Via de site van WD kan je echter ook inloggen op je NAS. Hoe dat precies werkt weet ik niet, maar het werkt wel en je kan de NAS zelfs mounten in Windows! Ideaal eigenlijk...

Is dat niet gewoon hetzelfde als een reverse-ssh tunnel of iets als UDP hole punching? Ik ben geen echte expert op IT gebied maar ik vraag mij al lang af waarover het (in mijn ogen vermeende probleem van) blokkeren van poorten door provider X eigenlijk gaat. Ik begrijp dat voor publieke services dit een probleem is. Ik begrijp des te meer waarom provider X de gemiddelde gebuiker wil beschermen. Ik ben zelfs content dat ik achter een NAT/ firewall zit. In geen 100.000 jaar wil ik mijn NAS (persoonlijke data) rechtstreeks op het internet zien.
Maar een IT'er die iet of wat weet wat hij doet kan daar toch geen punt van maken? Er zijn 101 mogelijkheden om je thuisnetwerk van buitenaf te bereiken.
PS: Mijn netwerk hangt (enkel) op een 3G connectie met dubbele NAT en zelfs dat is geen probleem.

Er zijn natuurlijk evenveel opinies als mensen hier, dat begrijp ik, maar providers gaan uit van gemiddelde gebruikers die zich geen fluit aantrekken wat het verschil tussen 'Word' en 'Internet'.

brubbel schreef:Er zijn 101 mogelijkheden om je thuisnetwerk van buitenaf te bereiken.

Spijtig genoeg heb je over die mogelijkheden niet altijd zelf controle ! Als je op een plaats zit waar enkel poort 80 en 443 worden toegelaten (ziekenhuizen, hotels, werk, ... genoeg voorbeelden) dan sta je daar maar leuk met je 101 oplossingen die allemaal gebaseerd zijn op het gebruik van poorten boven de 1024 !

brubbel schreef:Ik begrijp des te meer waarom provider X de gemiddelde gebuiker wil beschermen.

Probleem is dat X blijkbaar enkel Telenet is... geen enkele van de xDSL providers maakt het je onmogelijk poort 80/443 te gebruiken !

De gemiddelde gebruiker heeft trouwens de bescherming van zowel NAT als de Windows firewall.

Ongeveer een maand geleden kocht ik een Cloud systeem van IOMEGA. Het systeem werkte niet omdat Telenet bepaalde poorten sluit. Ik heb zonder probleem het systeem kunnen omruilen voor een WD MyCloud systeem. Alles werkte perfect. Tijdens de installatie van de software zocht het systeem zelf naar beschikbare open poorten. Alles werkte perfect, zowel thuis op eigen WIFI netwerk, op andere WIFI of hotspotnetwerken én zelfs via het mobile netwerk van proximus.

Nu, sinds enkele dagen werkt heb ik enkel nog toegang tot de WD MyCloud als ik thuis ben. Ook via andere WIFI netwerken is mijn cloud niet meer toegankelijk en ook niet meer via het mobile netwerk van prorimus. Is het mogelijk dat TELENET bepaalde poorten op mijn modem heeft afgesloten, of is er ergens een fout geslopen in de configuratie van mijn WD MyCloud?

Iemand ervaring hiermee? En hoe los je dat op?

wat wil je eigenlijk doen? welk soort acces heb je gebruikt?

is het enkel https:// ?

Synman schreef:wat wil je eigenlijk doen? welk soort acces heb je gebruikt?

is het enkel https:// ?

Hallo Synman,

Het is de bedoeling dat ik mijn bestanden op de WD installatie van overal, via eender welk netwerk kan opvragen. Volgens mij kwam of komt daar geen 'https' aan te pas. Ik diende enkel de nodige software te installeren op de apparaten waarmee ik toegang wil hebben tot mijn WD. Voor een korte tijd heeft dat perfect gewerkt en sinds een paar dagen plots niet meer. Nochtans heb ik geen wijzigingen gedaan aan de configuratie van mij WD MyCloud, dus heb ik het vermoeden dat TELENET iets blokkeert. Het rare is dat ik nu enkel nog met mijn laptop of tablet toegang heb tot mijn MyCloud wanneer ik mij thuis bevindt, binnen mijn eigen WIFI of kabel netwerk.

r2504 schreef: Dat kan niet... poort 443 is dan wel geen probleem (omdat beide kanten Telenet zijn)... maar zonder de forwarding kan NAT het nooit correct afleveren.

Dat systeem om externe clients te connecteren aan de NAS via de WD-website zal wel met systeem van Skype zijn. Die gebruiken een truukje om routers de misleiden. Het is een UDP-verbinding. Er wordt een connectie geïnitieerd, uitgaand van de NAS naar WD, die wordt zonder dat je router het beseft overgenomen door de client. Dit wordt geregeld door tussenkomst van de WD-site. Dat kan omdat , meen ik , omdat er bij UDP geen controle is op afzenderadres.

Er zijn daar in de pers en op internet al artikels over geweest. Skype heeft immers net het zelfde probleem. Je denkt toch niet dat al die data via hun site gaat ! Zij zetten enkel de verbinding op en moeten ook de routers passeren.

UDP of TCP maakt niets uit... je kan van buiten nooit een verbinding opzetten zonder een correcte forward rule.

Die forward rule kan er natuurlijk wel komen via uPnP... dus je hoeft hem niet manueel in te stellen (als je software en router dat ondersteunen).

Dat heb je mis voor. Ik zeg het : Skype gebruikt een truukje om NAT te misleiden. Ze gaan invers door je router. Wat schijnbaar onmogelijk is.
Het heeft niets met UPnP te maken. Het is een tekortkoming van UDP die ze benutten.
Zoek dat eerst eens uit voor je mij afschiet. Er stond enkele jaren geleden een artikel over in het C'T je.

edit: ik zie dat er op wikipedia ook al veel over te vinden is http://en.wikipedia.org/wiki/NAT_traversal

MarkDM schreef:Dat heb je mis voor.

Nee... jij verward bepaalde dingen

MarkDM schreef:Ik zeg het : Skype gebruikt een truukje om NAT te misleiden. Ze gaan invers door je router.

Invers... jij als client zet dus de connectie op... tja, da's een totaal ander verhaal.

MarkDM schreef:Zoek dat eerst eens uit voor je mij afschiet. Er stond enkele jaren geleden een artikel over in het C'T je.

Linkje... ik ben altijd geintresseerd in nieuwe technieken... maar dan wel de correcte details.

Er zit wel een grond van waarheid in hetgene wat Mark hier probeert uit te leggen: http://www.h-online.com/security/featur ... 47197.html

Ni stom gezien. UDPtje verzenden int wild en uwe NAT router gaat automatisch incoming packets op die poort beschouwen als reply op da UDPtje.
Benieuw hoeveel botnets die truc ook al toepassen

[ Post made via mobile device ]

Kenw00t schreef:Er zit wel een grond van waarheid in hetgene wat Mark hier probeert uit te leggen: http://www.h-online.com/security/featur ... 47197.html

Het artikel in het tijdschrift beschreef dezelfde techniek. Maar beter voorgesteld. Meer visueel met pijlen , berichtflows en diagramma's.
Ik denk dat het al bijna tien jaar geleden is. Intussen zijn die truukjes gemeengoed geworden.

Ook al is UDP connectionless... je technieke start van een connectie opgezet vanaf de client (net zoals iedere andere TCP client die bijvoorbeeld gewoon surft).

Da's dus een heel ander verhaal dan dat iemand op internet zomaar door jou firewall kan... en dan ook nog weet naar welk achterliggend adres. Mijn statement hierboven van "je kan van buiten nooit een verbinding opzetten zonder een correcte forward rule" klopt dus volgens mij ook nog altijd (gelukkig maar want anders was iedere firewall nutteloos).

Absoluut. En dat is een NAT unit, ik wil ervoor wedden dat een fatsoenlijke firewall tegenwoordig ook ni zomaar returning packets doorlaat als die niet met zijn rules overeen komen.

[ Post made via mobile device ]