Port Forwarden op Ubee Router (standard van Ziggo) werkt niet

Status
Niet open voor verdere reacties.

Kietho

Gebruiker
Lid geworden
25 aug 2016
Berichten
9
Hallo,

Ik ben met deze slechte router al vaker problemen tegen gekomen wat het port-forwarden betreft.
Ik wil hier bijvoorbeeld de poort 4444 openen, wat mij niet lukt.
Ik heb trouwens een VPN, ik weet niet of dit veel invloed heeft, behalve dan dat ik op de external IP moet letten, voor als die veranderd.

Portforwarding.png

Portforwarding.jpg

Ik hoop dat iemand mij kan helpen ;)
 
Laatst bewerkt:
Is maar zeer de vraag of het probleem aan de Ubee ligt. Kan ook liggen aan je VPN-server:
a. Verkeerde luisterpoort ingesteld.
b. Firewall op de (VPN-)server die inkomend verkeer op poort 4444 blokkeert (denk hierbij niet alleen aan Windows Firewall, maar ook aan evt. firewall achtige instellingen/deelprogrammatuur in anti-virus programmatuur).

Eerste wat ik dus zou doen is kijken of je lokaal (dus vanaf een andere pc/laptop, aangesloten aan dezelfde Ubee) verbinding kunt maken met poort 4444 TCP en/of UDP op 192.168.178.17
Voor wat betreft TCP kun je het zo doen vanaf die andere laptop:
Installeer de telnet-client:
[Windows-toets]+R toetscombinatie -> appwiz.cpl
Klik op Windows onderdelen toevoegen en verwijderen (in de linker kantlijn).
Zoek de Telnet-client op en zet het vinkje. Klik op OK.
Dan testen of verbinding mogelijk is vanaf die computer met de VPN-server op poort 4444 TCP:
[Windows-toets]+R toetscombinatie -> cmd.exe
telnet 192.168.178.17 4444
Wordt het CMD-venster zwart (cursor linksboven en de rest zwart) dan is de VPN-server vanaf die pc bereikbaar, dus de VPN-server luistert op poort 4444 én er is geen direct firewall-probleem.

[Ik neem overigens aan dat je een OpenVPN VPN-server hebt ingericht?]

Tijs.
 
Laatst bewerkt:
Bedankt voor je reactie,

ik heb telnet geinstalleerd en gerund met de 2 cmd (admin) commands op een andere PC die verbonden is met de Ubee:
telnet 192.168.178.17 4444
telnet 192.168.178.17

Ik heb beide commands geprobeerd terwijl de VPN aan en uit stond.
In alle vier de gevallen geeft hij aan dat er geen verbinding gemaakt kan worden.

Ik hoop dat je hier iets mee kan
 
Ok, dan kunnen er 2 dingen aan de hand zijn (combinaties zijn mogelijk):
a. De VPN-configuratie gebruikt niet poort 4444 TCP en (dus) probeer je met de verkeerde poort te verbinden (en naar te portforwarden in de Ubee)
b. Er een firewall achtig probleem op de VPN-server

Je ziet dat alle mogelijkheden zich (nu) op de VPN-server richten.
Dus, op de VPN-server:
a. Start (eerst) de VPN-software.
b. Daarna: Start cmd.exe "Als Administrator uitvoeren" en bekijk de volgende zaken:
netstat -ano > netstatano.txt
notepad netstatano.txt
netstat -abo > netstatabo.txt
notepad netstatabo.txt

[netstat -abo duurt (veel) langer, en geeft de procesnaam van de luisterende en verbonden poorten, netstat -ano geeft de PID (=Process ID) van het proces van de luisterende en verbonden poorten]

Kijk in beide txt bestanden of je daar (in beide of minstens in 1 daarvan) poort 4444 TCP als "Bezig met luisteren" genoemd ziet en welke procesnaam en process ID er bij hoort.
Is poort 4444 TCP niet genoemd, probeer dan uit te zoeken welke poorten je VPN-proces dan wel op luistert.

Verder kun je (als luister poort 4444 TCP tóch bij je VPN-proces hoort) de 192.168.178.17 telnet test doen op de VPN-server zelf en kijken of je dan wel verbinding krijgt.
Onafhankelijk van of die telnet test dan wel of niet slaagt: Het moet dan zeker een firewall zijn op de VPN-server die in de weg zit.

Tijs.
 
Laatst bewerkt:
bedankt,

Ik heb beide commands gerund en in de 2 text files staat geen enkele poort 4444
Wel zie ik een groep poorten die veel gebruikt wordt, voornamelijk door chrome, van ~54500 tot 55900.
De poorten die OpenVPN gebruikt zijn 48116 en 54504, cyberghost gebruikt 54867
Ik heb geprobeerd de poort 55555 te forwarden, zonder succes helaas.
Wat ik ook niet snap is dat er bij mijn Local Address een IP staat die ik niet ken.
 
Als ik mijn VPN uitschakel en alle external IPs verander in de port forwarder naar die van mn ISP zijn de poorten ook dicht trouwens.
 
De lokale telnet test op je thuisnetwerk moet verbinden met de poorten waar de VPN-server werkelijk naar luistert!

Dus als dat 48116 is dan moet daar de telnet test naar zijn!

Tijs.
 
Laatst bewerkt:
Ik heb de telnet tests gedaan op deze en de andere pc op mn netwerk, en beide kunnen niet verbinden met poort 48116 of 54504.
Ik heb wat andere Openvpn ports met netstatabo gevonden, en ik kan met telnet 192.168.178.17 139 WEL verbinden
ook kan ik verbinden met de poorten 800 en 990, welke ik geforward heb. Als ik verbind met 800, gaat ie naar mn ftp server van filezilla

Maar als ik de yougetsignal open port check doe, geeft hij aan dat ze dicht zijn.

Ik heb wat instellingen van mijn VPN gevonden die luiden als volgt:
Use TCP instead of UDP connections:
Use random port to connect

Klopt het dat ik de laatste optie uit moet zetten?

En als ik VPN uitzet, dan geeft yougetsignal aan dat 800 wel open is. als VPN aanstaat niet
 
Laatst bewerkt:
Poort 139 is is niet van OpenVPN maar voor het (Microsoft) delen van bestanden en mappen, zie deze link.

Die poorten 48116 en 54504, zijn dat wel TCP poorten? Want met telnet (en met canyouseeme.org) kun je alleen TCP poorten testen. Mij is niet helemaal duidelijk of dezelfde beperking geldt bij yougetsignal, maar gegeven het lijstje van (TCP)poorten aan de rechterkant heb ik sterk het idee van wel.

Dus... Als de opties die je noemde slaan op het VPNserver proces, dan moet je (om in ieder geval te kunnen testen) Use TCP instead of UDP connections aan hebben staan en het verhaal over Use random ports to connect uit hebben staan.

Alvast: Je praat de hele tijd over poort 4444 en 5555 om te portforwarden, maar de echte poorten van je VPN server zijn niet die nummers. Dan kan op zich wel, maar dan moet je router porttranslatie kunnen doen, dus (in jouw geval) dat je op de router kunt instellen dat externe poort 4444 wordt geportforward naar een andere luisterpoort dan 4444 op je VPNserver.
Klein voorbeeld: Stel je hebt meerdere ip-camera's en die zijn (intern) bereikbaar op de standaard http: poort, dus poort 80 TCP en je wilt ze allemaal vanaf extern bereikbaar maken.
In dit voorbeeld moet dan, per ip-camera, een (eigen) externe poort (in dit voorbeeld: poort 30009) worden geporttransleerd naar poort 80 van de ip-camera.
Zie ook de schermafdruk.
Dus... Praat nooit over het portforwarden van een poort als je eigenlijk porttranslatie bedoelt, want anders denken de helpers dat het om 1 poort gaat die zowel extern als intern hetzelfde is, terwijl in jouw geval de interne poort afwijkt van de externe poort die je portforward. En (dus) geldt ook: Je moet, in het geval van porttranslatie, altijd de externe poort(-reeks) en de interne poort(-reeks) beiden vermelden.

Tijs.
 

Bijlagen

  • porttranslatie_zyxelUSG300.JPG
    porttranslatie_zyxelUSG300.JPG
    45 KB · Weergaven: 98
Laatst bewerkt:
Het is dus niet mogelijk om gewoon een port te forwarden via mijn router als ik gebruik maak van een VPN? Raar.
Ik wil namelijk een FTP server opzetten met FileZilla.
Zou het dan met een VPN en het zogenaamde porttranslatie mogelijk zijn om met mijn externe IP (no-ip.com DDNS in mijn geval) buiten mijn eigen netwerk met de ftp server te kunnen verbinden?
Ik heb nog nooit gehoord van porttranslatie, terwijl er denk ik aardig wat mensen zijn met VPN.

Bedankt voor je moeite tot nu toe :thumb:
 
Laatst bewerkt:
Was ik eigenlijk niet van plan (mijn vorige posting is duidelijk genoeg), maar ik reageer toch maar even:
Je praat in je startpostings en een hoop postings daarna de hele tijd over poort 4444 en poort 5555, maar die worden blijkbaar in je OpenVPN-server niet gebruikt.
Dus moeten 'aan de poort' (=provider routemodem) die externe poorten 4444 en/of 5555 bij de portforwarding 'vertaald' (=getransleerd) worden naar andere (OpenVPN-)poorten intern.
Vandaar dat ik erop hamer dat je de juiste terminologie gebruikt, waarbij verder duidelijk moet worden gemaakt welke interne poorten de OpenVPN op luistert, want dat zijn niet die 4444 of 5555 poort(!)

En, nogmaals vermeld, als vanaf intern geen (netwerk-)verbindingen mogelijk zijn op de werkelijke OpenVPN-poorten, dan ga je het extern (via portforwarding/porttranslatie) ook zéker niet werkend krijgen.
Ik hintte als oorzaak daarvan dat je uitgaat van de verkeerde OpenVPN-poorten en/of firewalls op de OpenVPN-server en/of de OpenVPN software niet gestart op momenten van testen.

Tijs.
 
Laatst bewerkt:
Als ik de goede OpenVPN poort vind, hoe transleer ik de poorten die ik open wil naar die poort?
Ik zie geen optie in de software van de router, zijn hier andere opties voor? Ik kan niks op Google vinden.
 
Je Ubeen kan porttransleren (ik heb nergens beweert dat hij dat niet kan). Waar je iedereen mee in het bos gestuurd hebt is dat je in je startposting net doet alsof de VPN-server op interne poort 4444 bereikbaar zou zijn, maar dat helemaal niet is omdat het een andere poort moet zijn.

Kijk (bijv.) eens naar dit filmpje, vanaf 2:30 tot 3:20 (en evt. ook naar de schermafdrukken in je startposting):
Het ip-adres van de VPN-server vul je in bij Local IP.
In de Local Start Port vul je in het werkelijke poortnummer waar de VPN-server bereikbaar is.
In de External Start Port vul je in welke externe poort je wilt forwarden naar de poort die je bij Local Start Port hebt ingevuld.

In jouw geval: Beide typen poorten mogen qua getal aan elkaar gelijk zijn, maar ze mogen ook verschillend zijn. Als de getallen verschillend mogen zijn, dan is de router tot porttranslatie in staat, dus jouw Ubee kan porttransleren.
[Laat je de poorten bij beide types gelijk, dan doe je 'klassieke' portforwarding, als je verschillende poortnummers bij beide types invult dan laat je de Ubee de External Start Port naar de Local Start Port porttransleren.]

Voorbeeld:
Dus stel dat je poort 5555 extern wilt portforwarden naar interne poort 48116 dan vul je als Local Start Port 48116 in en als External Start Port 5555.

En nog een aantekening (zie ook het filmpje): Je mag het External IP gewoon altijd op 0.0.0.0 laten staan, de router weet dan zelf wel welk publieke ip-adres hij heeft, zelfs als die ondertussen door Ziggo is gewijzigd.

Tijs.
 
Laatst bewerkt:
Nu is het mij allemaal een stuk duidelijker, bedankt. Ik had helemaal geen idee dat de interne en externe ports verschillen...
Mijn doel ik om de poort 21 te transleren voor mijn ftp server, en een range van poorten voor de verbindingen.
Hoe moet ik die range van poorten (bijv. 55000-56000) transleren? Moet ik dan bij port triggers doen?
Ik heb deze 2 openvpn ports geprobeerd bij het transleren van mijn ftp, zonder succes (zie afbeelding)

Dit zijn alle openvpn.exe processen in netstatabo.txt:
[openvpn.exe]
TCP 127.0.0.1:48116 PC:53106 ESTABLISHED 4324

[openvpn.exe]
TCP 127.0.0.1:53106 PC:48116 ESTABLISHED 3188

[openvpn.exe]
TCP [::]:21 PC:0 LISTENING 2236


yougetsignal geeft nog steeds aan dat port 21 gesloten is.

Bedankt voor de uitleg, sorry dat ik dit zo langdradig maak, ik heb aardig wat gegoogled maar ik kan niks nuttigs vinden.

5.png
 
Nu moet je ophouden stomme dingen te doen, want de bereidheid om nog tijd te besteden aan je vraag neemt nu rap af.
Zie in je schermafdruk van zojuist dat je een publiek ip-adres hebt ingevuld bij Local IP, namelijk 109.236.90.144, maar daar moet je gewoon het 192.168.178.17 ip-adres invullen! Dat stukje deed je eerder wel al goed bij de schermafdruk uit posting #1, dus geen idee waarom je daar nu weer aan bent gaan *******.
[External IP kun je te allen tijde op 0.0.0.0 laten staan, zoals ik al schreef in mijn vorige posting.]

Tijs.
 
Laatst bewerkt:
Ik citeer "Het ip-adres van de VPN-server vul je in bij Local IP."
Ik dacht dat je de VPN-server bedoelde waarme ik geconnect ben, wat mijn external IP is.

Ook al vul ik 192.168.178.17 in, geeft yougetsignal nog steeds aan dat hij geclosed is.
Ik heb nu ook de neiging om op te geven...
 
Laatst bewerkt:
Test in ieder geval of de VPN server vanaf intern bereikbaar is op poort 21.
Dat was het laatste wat ik doe voor je vraag.

Succes,

Tijs.
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan