Server hosting - poorten werken niet van ziggo

[kandio]

Hoi,

Ik heb een tweede pc gekocht speciaal om servers voor games op te hosten. Hier heb ik Ubuntu op staan. Nu kan ik intern gewoon prima verbinden, maar vanaf buiten kom ik en anderen niet in de game en ook niet in de control panel. Ik gok zelf dat het aan de poorten ligt, die ik maar niet open weet te krijgen.
Ik heb ziggo smartwiifi.

Dit zijn mijn poorten. UPnP uit en aan gehad. Ook de dmz naar 192.168.178.202 aangepast maar niks lijkt te werken. Poort 25566 is mijn server. Poort 8080 is de panel


Enig idee hoe ik dit werkend krijg?

[Nobby]

8080 is dicht van buiten voor zover ik weet bij Ziggo van vroeger.

Kan je intern wel op je server spelen?

[ Voor 24% gewijzigd door Nobby op 11-09-2025 22:17 ]

[kandio]

Ja intern draait alles. Van buitenaf staat hij offline

[RobbyTown]

Laat intern 8080 maar pak voor buiten iets anders. Bijvoorbeeld 5180

[powerboat]

UPNP moet je altijd uit laten staan (Veiligheids ding).

DMZ zou moeten werken, zo niet dat kan het zijn dat ziggo je in cgnat heeft gepropt. Je hebt dan geen routerbaar adres. Dat kun je bij Ziggo aan laten passen maar daar moet je ze voor bellen

Als je server in je dmz werkt, haal hem dan eruit en open enkel de poorten die nodig zijn en verdiep je in het beveiligen van je server

[kandio]

Ja een beetje wanhopig aangezien ik altijd met ziggo deze problemen heb. Voorheen altijd op mn pc, dus als het dan niet lukte wat minder erg. Maar nu ik er een dedicated server voor heb moet het ook wel gewoon altijd werken.

Ik zal morgen wel eens contact met ziggo zelf opnemen

[kandio]

Ziggo zegt hier geen service op te verlenen en weigert mij verder te helpen 👌

Prachtig

[vormulier]

Na het openzetten van poorten op je ziggo router altijd hem even herstarten!?

Vorige maand mijn vpn poort opengezet en kreeg het niet werkend tot dat hij herstart werd.

[vanaalten]

kandio schreef op donderdag 11 september 2025 @ 22:16:
Hoi,

Ik heb een tweede pc gekocht speciaal om servers voor games op te hosten. Hier heb ik Ubuntu op staan. Nu kan ik intern gewoon prima verbinden, maar vanaf buiten kom ik en anderen niet in de game en ook niet in de control panel. Ik gok zelf dat het aan de poorten ligt, die ik maar niet open weet te krijgen.
Ik heb ziggo smartwiifi.
[Afbeelding]
Dit zijn mijn poorten. UPnP uit en aan gehad. Ook de dmz naar 192.168.178.202 aangepast maar niks lijkt te werken. Poort 25566 is mijn server. Poort 8080 is de panel


Enig idee hoe ik dit werkend krijg?

Je noemt smartwifi - om te beginnen zou ik de server direct en bekabeld aan de router hangen, om maar zoveel mogelijk uit te sluiten.
Daarnaast: hoe ziet je netwerk er uit, vanaf binnenkomst van de Ziggo coax kabel? Heb je behalve de Ziggo connect-box of hoe die ook heet, nog andere netwerk-apparatuur er aan of tussen hangen?

[FreakNL]

Misschien je modem in bridge laten zetten en een eigen router gebruiken?

Is wel wat overkill maargoed.

[ Voor 20% gewijzigd door FreakNL op 12-09-2025 12:23 ]

[nelizmastr]

kandio schreef op vrijdag 12 september 2025 @ 12:16:
Ziggo zegt hier geen service op te verlenen en weigert mij verder te helpen 👌

Prachtig

Is te verwachten. Providers doen liever niets in het "klantdomein" dus alles wat met apparatuur achter hun apparatuur te maken heeft. Stukje verantwoordelijkheid en aansprakelijkheid.

Heb je al wat met de tip van @RobbyTown gedaan? Probeer aan de WAN zijde eens een andere poort dan 8080, gezien die mogelijk niet gebruikt mag worden?

Als je zogenaamde control panel buiten het netwerk draait dan daar die custom poort uiteraard in overnemen.

Aan de binnenzijde laat je hem dus gewoon op 8080.

[ Voor 6% gewijzigd door nelizmastr op 12-09-2025 12:52 ]

[Bor]

kandio schreef op vrijdag 12 september 2025 @ 12:16:
Ziggo zegt hier geen service op te verlenen en weigert mij verder te helpen 👌

Prachtig

Op zich niet gek natuurlijk. Zelf gehoste servers vallen niet onder de dienstverlening van Ziggo. Daarvoor ben je zelf verantwoordelijk.

[Noob_Saibot]

Bor schreef op vrijdag 12 september 2025 @ 12:54:
[...]


Op zich niet gek natuurlijk. Zelf gehoste servers vallen niet onder de dienstverlening van Ziggo. Daarvoor ben je zelf verantwoordelijk.

Daarbij, wie houdt je tegen om jou ziggo modem op "bridge" mode te zetten + met een eigen firewall / router er tussen?

Ik heb al ontiegelijk veel omgevingen dezelfde oplossing toegepast, ziggo modem = bridge mode laten zetten met lancom / mikrotik / fortinets ertussen...

[Bor]

Noob_Saibot schreef op vrijdag 12 september 2025 @ 13:01:
[...]

Daarbij, wie houdt je tegen om jou ziggo modem op "bridge" mode te zetten + met een eigen firewall / router er tussen?

Dat is dan precies waar je zelf verantwoordelijk bent inclusief de beveiliging en het onderhoud. Ziggo ondersteund dit niet en dat kan je ook niet verwachten.

[ Voor 5% gewijzigd door Bor op 12-09-2025 13:03 ]

[jurroen]

De Connectbox in bridge modus laten zetten en daarna je eigen apparatuur is inderdaad het beste plan. Afhankelijk van wat je kiest kun je dan ook meer beveiliging toepassen. Een Minecraft server, zoals jij wil gaan draaien, zou ik persoonlijk in een eigen VLAN mieteren en afscheiden van de rest van je netwerk.

Overigens is poort 8080 niet nodig voor MC zelf - misschien dat je een script gebruikt om de server te beheren; als dat zo is kun je die misschien beter niet exposen naar het internet.

[MAX3400]

kandio schreef op vrijdag 12 september 2025 @ 12:16:
Ziggo zegt hier geen service op te verlenen en weigert mij verder te helpen 👌

Prachtig

Gezien de volgorde van je reacties; iets zegt me dat een gedeelte van het gesprek niet startte of is gegaan zoals je hoopte en dat daarmee mogelijk de wederzijdse kwaliteit van elkaar begrijpen en helpen snel omlaag gegaan is.

Zoals @powerboat aangeeft zou je iets met CGNAT kunnen vragen aan Ziggo; ik lees dat vooralsnog niet terug in je antwoorden.

Letterlijk met 10 seconden Googlen op "minecraft port forwards" stuurde me in hit 2 naar https://pinggy.io/blog/minecraft_port_forwarding/ en daar kan je met een aanpassing qua software ook CGNAT omzeilen cliamen ze.

[PNJvG]

Misschien lees ik er overheen, maar heb je in Ubuntu de firewall evt aan staan?

>> Aan de andere kant, dan zou het intern ook niet moeten werken... <<

[ Voor 33% gewijzigd door PNJvG op 13-09-2025 17:21 ]

[powerboat]

Er is nog een mogelijkheid om CGNAT te omzeilen en dat is eventueel met Cloudflare tunnels.

Maar ik zou eerst eens met ziggo om tafel gaan en zeggen dat je een routeerbaar adres wil hebben.

[Midas.e]

CGNAT bij ziggo komt uit 1 range, dat kan je makkelijk testen. https://community.vodafon...GNAT-netwerk/td-p/1354849
Welk ip adres vanaf buiten probeer je naar te verbinden? als je aan de andere persoon het 192.168.x.x ip geeft gaat het niet werken. je kan externe porten testen via https://www.yougetsignal.com/tools/open-ports/

[kandio]

Ondertussen zijn we al even bezig en heb ik het nog steeds niet werkend. Ik heb een router gekocht - Archer C80 - en de modem op bridge gezet. Maar die ports weigeren open te gaan. Firewall staat uit en ik ben een beetje radeloos. Iemand nog enig idee wat hier fout gaat?

[FreakNL]

Het probleem lijkt eerder intern te zitten bij jou dan bij Ziggo... Maar laten we het stap voor stap bekijken;

Dus je Ziggo modem staat 100% zeker in Bridge?

Kun je laten zien wat het WAN IP is van de Archer C80? Desnoods alleen de eerst 3 octets... Dus bijvoorbeeld: 82.86.170.xxx

[ Voor 18% gewijzigd door FreakNL op 27-01-2026 18:09 ]

[kandio]

Natuurlijk. 24.132.236.xxx

[FreakNL]

Je screenshot lijkt me van je modem en niet je router ?

Log eens in op je router en kijk daar wat je WAN IP is

[ Voor 34% gewijzigd door FreakNL op 27-01-2026 19:34 ]

[kandio]

Die had ik erboven geschreven

Maar bij deze ;

[ Voor 30% gewijzigd door kandio op 27-01-2026 19:43 ]

[nelizmastr]

Zit je server ook aangesloten op je router? De poorten op je modem werken immers niet meer. Via kabel geprobeerd of alleen wifi? Een server hoort on ieder geval aan een kabel voor betere stabiliteit.

Zijn de services ook daadwerkelijk actief op de server als je test of de poorten open staan? Als er niets luistert werken de forwards ook niet. Gebruik eens yougetsignal.com om de poorten te checken, als die zeg poort is dicht dan laat je router het niet door of je server.

Sidenote - een €50 tp-link wifirouter is niet echt een upgrade over een ziggo modem, zal ook moeite hebben als je een snel abonnement hebt (>600Mbit). Gezien het met deze ook niet werkt zou ik ‘m retourneren en de Ziggo modem weer in router modus zetten of het ding daarna als wifipunt gebruiken o.i.d.

[kandio]

Ja modem zit aan de router en de router zit aan mn pc en aan de server met ethernet.


Wat bedoel je met services actief?

De enige reden dat de router ertussen zit is omdat via Ziggo de poorten niet open gingen en dat het advies in deze thread was.

[Jim423]

Een router ertussen zetten helpt niets. Slecht advies dus.
Ook je firewall zou ik weer inschakelen. Ziggo doet aan CGNAT waardoor je dit niet werkend gaat krijgen. powerboat zit op het goede spoor dus. Je zou op community.vodafoneziggo.nl kunnen vragen of ze een uitzondering willen maken voor je, je gaat dan een ander ip-adres krijgen als het goed is. 82.xxx of 83.xxx

[ Voor 5% gewijzigd door Jim423 op 27-01-2026 23:03 ]

[kandio]

Maar als ik google afstruin kom ik op dit uit:
https://community.vodafon...GNAT-netwerk/td-p/1354849
Volgens wat daar staat zou ik dus geen cgnat hebben. Of is dat complete onzin?

[FreakNL]

Jim423 schreef op dinsdag 27 januari 2026 @ 23:01:
Een router ertussen zetten helpt niets. Slecht advies dus.
Ook je firewall zou ik weer inschakelen. Ziggo doet aan CGNAT waardoor je dit niet werkend gaat krijgen. powerboat zit op het goede spoor dus. Je zou op community.vodafoneziggo.nl kunnen vragen of ze een uitzondering willen maken voor je, je gaat dan een ander ip-adres krijgen als het goed is. 82.xxx of 83.xxx

Dit is net zo slecht advies.

Die range van Ziggo (van de TS) zit helemaal niet op CGNAT.

Ik vermoed een lokaal issue.

[kandio]

Maar wat zou dat probleem dan kunnen zijn?

[sdk1985]

Wat heb je in iptables ingesteld?

[kandio]

Daar heb ik niet aangezeten.

Overigens als ik poorten op mijn normale pc probeer te openen lukt dat ook niet.

Ik heb een ethernet kabel vanaf mijn router naar boven. Dan een switch die naar beide toe gaat. Kan dat een probleem veroorzaken?

[Sander]

Hoe test je dit? Want als je zelf vanaf intern je eigen IP 'buitenlangs' probeert te benaderen dan zijn er nogal wat routers die dit niet snappen. Test je met een mobiel op 5G of via tethering oid?

[rhodium]

Als je elkaar intern al niet eens kan benaderen..... en normaal gesproken als ze op de zelfde switch zitten moeten ze elkaar gewoon zien, tenzij je met vlans bezig bent geweest.

Ga eerst maar eens proberen met je eigen pc bij de server te komen, zelf moest ik altijd mijn ziggo modem herstarten na het wijzigen van poorten. Geen idee waarom... na het herstarten werkte het altijd wel.

[mrmrmr]

Bij problemen kun je best eerst de situatie vereenvoudigen, bij het begin beginnen en stap voor stap alles controleren. Geen router, alleen de Ziggo modem (als router, niet als bridge). Ziggo modem via DHCP IP adressen laten toewijzen. Daarna controleren of er internettoegang is. Gebruik een ethernetswitch, geen router met switch.

Informatie verzamelen:

Ubuntu command line (als root)
ping -4 -c 4 nu.nl
host nu.nl
ip a
cat /etc/resolv.conf
route -4 -n
iptables -L -n

Windows command line (start cmd.exe, als beheerder via rechtermuisknop)
ping nu.nl
nslookup nu.nl
ipconfig /all
route print

In Windows kun je in de lokale firewall een ICMP allow regel voor uitgaand en inkomend verkeer toevoegen zodat deze computer kan reageren op pings. Daarna moet de Ubuntu kunnen pingen naar de Windows computer en andersom.

Post de output van alle bovenstaande opdrachten, dan kunnen we meekijken en problemen oplossen.

[Jim423]

kandio schreef op woensdag 28 januari 2026 @ 01:28:
Maar wat zou dat probleem dan kunnen zijn?

Daar komt geen antwoord op denk ik. Binnen je LAN kun je namelijk prima spelen op je Linux server.

Het zou kunnen zijn dat er nog andere poorten gebruikt worden die jij niet hebt geforward.
Maar ik neem aan dat je dat wel goed hebt uitgezocht. Je kan als wijze van test nog iets van usbwebserver installeren en daar een poort voor open zetten (dezelfde als je in usbwebserver gebruikt). Andere mensen moeten dan op http://24.132.jouw ip adres (dubbele punt) poort een webpagina te zien krijgen. Je eigen computers zien dit op 192.168.178.xxx. Als dit ook niet werkt weet je wel genoeg.

[ Voor 7% gewijzigd door Jim423 op 28-01-2026 07:27 ]

[kandio]

mrmrmr schreef op woensdag 28 januari 2026 @ 07:03:
Bij problemen kun je best eerst de situatie vereenvoudigen, bij het begin beginnen en stap voor stap alles controleren. Geen router, alleen de Ziggo modem (als router, niet als bridge). Ziggo modem via DHCP IP adressen laten toewijzen. Daarna controleren of er internettoegang is. Gebruik een ethernetswitch, geen router met switch.

Informatie verzamelen:

Ubuntu command line (als root)
ping nu.nl
host nu.nl
ip a
cat /etc/resolv.conf
route -4 -n
iptables -L -n

Windows command line (start cmd.exe, als beheerder via rechtermuisknop)
ping nu.nl
nslookup nu.nl
ipconfig /all
route print

In Windows kun je in de lokale firewall een ICMP allow regel voor uitgaand en inkomend verkeer toevoegen zodat deze computer kan reageren op pings. Daarna moet de Ubuntu kunnen pingen naar de Windows computer en andersom.

Post de output van alle bovenstaande opdrachten, dan kunnen we meekijken en problemen oplossen.

code:

C:\WINDOWS\system32>ping nu.nl

Pinging nu.nl [88.221.24.50] with 32 bytes of data:
Reply from 88.221.24.50: bytes=32 time=12ms TTL=58
Reply from 88.221.24.50: bytes=32 time=13ms TTL=58
Reply from 88.221.24.50: bytes=32 time=12ms TTL=58
Reply from 88.221.24.50: bytes=32 time=12ms TTL=58

Ping statistics for 88.221.24.50:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 13ms, Average = 12ms

C:\WINDOWS\system32>nslookup nu.nl
Server:  UnKnown
Address:  192.168.0.xxx

Non-authoritative answer:
Name:    nu.nl
Addresses:  2a02:26f0:6d00:2a::210:1b97
          2a02:26f0:6d00:2a::210:1ba0
          88.221.25.42
          88.221.25.18
          88.221.25.131
          88.221.25.24
          88.221.25.26
          88.221.25.72


C:\WINDOWS\system32>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : Cas-Desktop
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) I211 Gigabit Network Connection
   Physical Address. . . . . . . . . : 0C-9D-92-7F-B2-38
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:1c0c::50f:fb1e:d07a:f3a9(Deprecated)
   Lease Obtained. . . . . . . . . . : Saturday, January 17, 2026 18:55:47
   Lease Expires . . . . . . . . . . : Saturday, January 31, 2026 19:43:53
   Link-local IPv6 Address . . . . . : fe80::405e:226e:7c49:1460%15(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.104(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, January 27, 2026 18:09:30
   Lease Expires . . . . . . . . . . : Wednesday, January 28, 2026 18:09:31
   Default Gateway . . . . . . . . . : 192.168.0.xxx
   DHCP Server . . . . . . . . . . . : 192.168.0.xxx
   DHCPv6 IAID . . . . . . . . . . . : 437034386
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-24-F4-EB-29-0C-9D-92-7F-B2-38
   DNS Servers . . . . . . . . . . . : 192.168.0.xxx
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Ethernet 4:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Surfshark Windows Adapter V9
   Physical Address. . . . . . . . . : 00-FF-79-14-D8-B0
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Unknown adapter OpenVPN Data Channel Offload for Surfshark:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : OpenVPN Data Channel Offload
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

C:\WINDOWS\system32>route print

code:

64 bytes from a88-221-24-11.deploy.static.akamaitechnologies.com (88.221.24.11): icmp_seq=248 ttl=58 time=12.2 ms

Dit is wat er uit komt dan. Bij Ubuntu blijft hij pingen waardoor ik de rest niet in de input krijg?

rhodium schreef op woensdag 28 januari 2026 @ 03:26:
Als je elkaar intern al niet eens kan benaderen..... en normaal gesproken als ze op de zelfde switch zitten moeten ze elkaar gewoon zien, tenzij je met vlans bezig bent geweest.

Ga eerst maar eens proberen met je eigen pc bij de server te komen, zelf moest ik altijd mijn ziggo modem herstarten na het wijzigen van poorten. Geen idee waarom... na het herstarten werkte het altijd wel.

Intern werkt alles gewoon prima?

Jim423 schreef op woensdag 28 januari 2026 @ 07:21:
[...]


Daar komt geen antwoord op denk ik. Binnen je LAN kun je namelijk prima spelen op je Linux server.

Het zou kunnen zijn dat er nog andere poorten gebruikt worden die jij niet hebt geforward.
Maar ik neem aan dat je dat wel goed hebt uitgezocht. Je kan als wijze van test nog iets van usbwebserver installeren en daar een poort voor open zetten (dezelfde als je in usbwebserver gebruikt). Andere mensen moeten dan op http://24.132.jouw ip adres (dubbele punt) poort een webpagina te zien krijgen. Je eigen computers zien dit op 192.168.178.xxx. Als dit ook niet werkt weet je wel genoeg.

Ja ik krijg niets open. Maar poorten die ik probeer open te gooien voor m'n pc lukt ook niet.

[DataGhost]

Je doet heel panisch over het verbergen van je IP-adressen, terwijl je wel een gameserver wilt draaien die publiek bereikbaar moet zijn (dus IP bekend moet zijn). In het ene screenshot verberg je wel IP's, in het andere niet, in nog eentje verberg je een IP maar vergeet je het andere IP weg te vegen en in alle diagnostische output die gevraagd is veeg je ze ook weg zodat je ze eigenlijk net zo goed niet had kunnen posten. Maar je laat wel doodleuk je IPv6-adressen staan die dan juist wél weer van buitenaf bereikbaar zouden kunnen zijn. Wat mij betreft haal je helemaal geen IP's weg tenzij je heel erg zeker weet dat die niet relevant zijn, maar op het moment dat je weet welke dat wel en niet zijn kan je waarschijnlijk je probleem zelf ook al oplossen.

Wat betreft interne IP's (192.168.enz): die zijn sowieso onbereikbaar vanaf het internet en je hebt er doorgaans maar 254 van, waarvan het ongeveer precies in de buurt van minder dan een halve seconde kost om ze allemaal te scannen *als* iemand al op je netwerk is binnengekomen. Dus die hoef je sowieso niet weg te halen. Maakt het alleen maar lastiger voor ons om te zien wat je wel en niet, en goed en fout doet.

Het enige IP wat je eventueel weg zou kunnen willen vegen is je externe IP, maar het grootste deel ervan heb je allang gepost waardoor er voor iemand die "jouw IP zou willen weten" nog maar 256 mogelijkheden overblijven die dus ook enorm snel gescand zijn. Maar nogmaals dat wegvegen lijkt me redelijk nutteloos als je toch dingen publiek aan het internet gaat draaien. Vroeg of laat (eerder vroeg dan laat) krijg je de standaard achtergrond-ruis daarop aankloppen, dat zijn gewoon bots die volautomatisch alles afscannen en niet mensen die op fora gaan kijken of er mensen toevallig hun IP niet hebben weggepoetst uit een screenshot. Als je dat niet fijn vindt moet je wat mij betreft helemaal geen server willen draaien. Niet dat je externe IP verder nog heel relevant is buiten dat we daarmee nu wel weten dat het hoogstwaarschijnlijk geen CG-NAT betreft.

Verder heb je het over een tweede PC met Ubuntu waar de server op moet draaien, maar er komen nu allerlei output van Windows-tooltjes langs. Dat heeft ook helemaal geen nut want dat is niet de machine waar je problemen mee hebt. Daarom zou ik nogmaals zeggen dat, als je niet snapt wat er allemaal gevraagd wordt en waarom, je beter geen server aan het internet gaat hangen totdat je op andere manieren wat kennis hebt opgedaan mbt netwerken. Er wordt nu van alles aan je gevraagd wat waarschijnlijk maar heel vaagjes aan je eigenlijke probleem raakt, omdat je behoorlijk weinig relevante informatie verstrekt zelfs als daar om gevraagd wordt. Dat maakt het erg moeilijk om de oorzaak te achterhalen.

Wat wel nuttig zou kunnen zijn:
- mrmrmr in "Server hosting - poorten werken niet van ziggo" nogmaals de ubuntu-commando's uitvoeren en het resultaat daarvan laten zien
- Opzet (evt tekeningetje) van je netwerk. Waar zit je router, wat heeft die voor intern IP, waar zit je server + IP, welke devices zitten daartussen, welke devices zijn eventueel nog meer relevant (je primaire PC? +IP)
- Als je met je server probeert te verbinden, welk IP gebruik je daar dan voor? Of gebruik je een of andere domeinnaam? Zo ja, waar resolvet die heen?
- Kijk of je een firewall hebt draaien in je router of een van de tussenliggende apparaten
- Kijk of je een firewall hebt draaien op je ubuntu-bak
- Traceroute/tracert vanaf je ubuntu-bak naar nu.nl
- Zet je gameserver uit, start een netcat listener op je ubuntu-bak op bijv. poort 25566 en verbind dan vanaf je windows-bak met telnet ofzo daarheen over het interne netwerk. Typ wat en kijk of het aan de andere kant verschijnt.
- Doe dit nogmaals maar verbind dan met je externe IP ipv het interne IP
- Doe dit nogmaals maar vanaf een andere verbinding(!) dus bijvoorbeeld dat je je 4G/5G (niet wifi) deelt met je windows-bak

[mrmrmr]

@kandio De route print van Windows staat er niet bij. Ik heb de pingopdracht voor Ubuntu aangepast zodat die stopt na 4 keer.

Wegens de ontbrekende informatie is het nog niet mogelijk te zien wat en of er iets mis is. Je kan gerust zoals @DataGhost schrijft interne IPv4 192.168.x.y adressen vermelden. MAC adressen zijn uniek en publieke IPv4 en IPv6 adressen ook.

[kandio]

mrmrmr schreef op woensdag 28 januari 2026 @ 18:22:
@kandio De route print van Windows staat er niet bij. Ik heb de pingopdracht voor Ubuntu aangepast zodat die stopt na 4 keer.

Wegens de ontbrekende informatie is het nog niet mogelijk te zien wat en of er iets mis is. Je kan gerust zoals @DataGhost schrijft interne IPv4 192.168.x.y adressen vermelden. MAC adressen zijn uniek en publieke IPv4 en IPv6 adressen ook.

code:

cas@games:~$ sudo ping -4 -c 4 nu.nl
[sudo] password for cas:
PING nu.nl (88.221.24.50) 56(84) bytes of data.
64 bytes from a88-221-24-50.deploy.static.akamaitechnologies.com (88.221.24.50): icmp_seq=1 ttl=58 time=12.1 ms
64 bytes from a88-221-24-50.deploy.static.akamaitechnologies.com (88.221.24.50): icmp_seq=2 ttl=58 time=13.1 ms
64 bytes from a88-221-24-50.deploy.static.akamaitechnologies.com (88.221.24.50): icmp_seq=3 ttl=58 time=12.7 ms
64 bytes from a88-221-24-50.deploy.static.akamaitechnologies.com (88.221.24.50): icmp_seq=4 ttl=58 time=14.3 ms

--- nu.nl ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.098/13.045/14.343/0.825 ms
cas@games:~$ sudo host nu.nl
nu.nl has address 88.221.24.50
nu.nl has address 88.221.24.11
nu.nl has address 88.221.24.72
nu.nl has address 88.221.24.113
nu.nl has IPv6 address 2a02:26f0:b200::58dd:18c3
nu.nl has IPv6 address 2a02:26f0:b200::58dd:18c2
nu.nl has IPv6 address 2a02:26f0:b200::58dd:18b2
nu.nl has IPv6 address 2a02:26f0:b200::58dd:18c9
nu.nl has IPv6 address 2a02:26f0:b200::58dd:18c1
nu.nl mail is handled by 10 alt3.aspmx.l.google.com.
nu.nl mail is handled by 5 alt1.aspmx.l.google.com.
nu.nl mail is handled by 1 aspmx.l.google.com.
nu.nl mail is handled by 5 alt2.aspmx.l.google.com.
nu.nl mail is handled by 10 alt4.aspmx.l.google.com.
cas@games:~$ sudo ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 9c:7b:ef:b2:7e:5d brd ff:ff:ff:ff:ff:ff
    altname enp5s0f0
    inet 192.168.0.106/24 metric 100 brd 192.168.0.255 scope global dynamic eno1
       valid_lft 3604sec preferred_lft 3604sec
    inet6 fe80::9e7b:efff:feb2:7e5d/64 scope link
       valid_lft forever preferred_lft forever
cas@games:~$ sudo cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
cas@games:~$ sudo route -4 -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 eno1
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eno1
192.168.0.1     0.0.0.0         255.255.255.255 UH    100    0        0 eno1
cas@games:~$ sudoiptables -L -n
sudoiptables: command not found
cas@games:~$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2223 /* AMP:ADS01:FileManagerPlugin.SFTP.SFTPPortNumber */
ACCEPT     17   --  0.0.0.0/0            0.0.0.0/0            udp dpt:12820 /* AMP:ADS01:ADSModule.Network.MetricsServerPort */
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2224 /* AMP:test01:FileManagerPlugin.SFTP.SFTPPortNumber */
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2225 /* AMP:Meatballs01:FileManagerPlugin.SFTP.SFTPPortNumber */
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:2226 /* AMP:Skies201:FileManagerPlugin.SFTP.SFTPPortNumber */
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:8080 /* AMP:ADS01:Core.Webserver.Port */
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25565 /* AMP:test01:MinecraftModule.Minecraft.PortNumber */
ACCEPT     17   --  0.0.0.0/0            0.0.0.0/0            udp dpt:25565 /* AMP:test01:MinecraftModule.Minecraft.PortNumber */
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25566 /* AMP:Meatballs01:MinecraftModule.Minecraft.PortNumber */
ACCEPT     17   --  0.0.0.0/0            0.0.0.0/0            udp dpt:25566 /* AMP:Meatballs01:MinecraftModule.Minecraft.PortNumber */
ACCEPT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25567 /* AMP:Skies201:MinecraftModule.Minecraft.PortNumber */
ACCEPT     17   --  0.0.0.0/0            0.0.0.0/0            udp dpt:25567 /* AMP:Skies201:MinecraftModule.Minecraft.PortNumber */

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
cas@games:~$

code:

C:\WINDOWS\system32>ping nu.nl

Pinging nu.nl [88.221.24.120] with 32 bytes of data:
Reply from 88.221.24.120: bytes=32 time=12ms TTL=58
Reply from 88.221.24.120: bytes=32 time=13ms TTL=58
Reply from 88.221.24.120: bytes=32 time=12ms TTL=58
Reply from 88.221.24.120: bytes=32 time=13ms TTL=58

Ping statistics for 88.221.24.120:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 13ms, Average = 12ms

C:\WINDOWS\system32>nslookup nu.nl
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
Name:    nu.nl
Addresses:  2a02:26f0:b200::58dd:18a9
          2a02:26f0:b200::58dd:18b2
          2a02:26f0:b200::58dd:18b0
          2a02:26f0:b200::58dd:18c1
          2a02:26f0:b200::58dd:18b1
          88.221.24.98
          88.221.24.50


C:\WINDOWS\system32>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : Cas-Desktop
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) I211 Gigabit Network Connection
   Physical Address. . . . . . . . . : 0C-9D-92-7F-B2-38
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:1c0c::50f:fb1e:d07a:f3a9(Deprecated)
   Lease Obtained. . . . . . . . . . : Saturday, January 17, 2026 18:55:47
   Lease Expires . . . . . . . . . . : Saturday, January 31, 2026 19:43:55
   Link-local IPv6 Address . . . . . : fe80::405e:226e:7c49:1460%15(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.104(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, January 27, 2026 18:09:30
   Lease Expires . . . . . . . . . . : Friday, January 30, 2026 00:09:34
   Default Gateway . . . . . . . . . : 192.168.0.1
   DHCP Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6 IAID . . . . . . . . . . . : 437034386
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-24-F4-EB-29-0C-9D-92-7F-B2-38
   DNS Servers . . . . . . . . . . . : 192.168.0.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Ethernet 4:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TAP-Surfshark Windows Adapter V9
   Physical Address. . . . . . . . . : 00-FF-79-14-D8-B0
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Unknown adapter OpenVPN Data Channel Offload for Surfshark:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : OpenVPN Data Channel Offload
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

C:\WINDOWS\system32>route print
===========================================================================
Interface List
 15...0c 9d 92 7f b2 38 ......Intel(R) I211 Gigabit Network Connection
 10...00 ff 79 14 d8 b0 ......TAP-Surfshark Windows Adapter V9
  8...........................OpenVPN Data Channel Offload
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.104     25
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.0.0    255.255.255.0         On-link     192.168.0.104    281
    192.168.0.104  255.255.255.255         On-link     192.168.0.104    281
    192.168.0.255  255.255.255.255         On-link     192.168.0.104    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link     192.168.0.104    281
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link     192.168.0.104    281
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    331 ::1/128                  On-link
 15    281 2001:1c0c::50f:fb1e:d07a:f3a9/128
                                    On-link
 15    281 fe80::/64                On-link
 15    281 fe80::405e:226e:7c49:1460/128
                                    On-link
  1    331 ff00::/8                 On-link
 15    281 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

C:\WINDOWS\system32>

[remco_k]

@kandio er wordt nog veel meer gevraagd door DataGhost in "Server hosting - poorten werken niet van ziggo"
Die vragen zijn allemaal belangrijk en essentieel om verder te komen met je probleem.

[ Voor 3% gewijzigd door remco_k op 30-01-2026 00:01 ]

[sdk1985]

kandio schreef op woensdag 28 januari 2026 @ 01:49:
Daar heb ik niet aangezeten.

Overigens als ik poorten op mijn normale pc probeer te openen lukt dat ook niet.

Dat lijkt me wel essentieel want of alles staat open, of alles staat dicht. Beiden onwenselijk.

Tevens wordt terecht vermeld dat je bij testen dat niet lokaal kunt doen. Dat kan alleen door bijvoorbeeld een hotspot te gebruiken om via je mobiele data terug naar je eigen publieke ipadres te verbinden.

Begin anders eens met het opzetten van een simpel web of ftp servertje.

[mrmrmr]

remco_k schreef op donderdag 29 januari 2026 @ 23:54:
@kandio er wordt nog veel meer gevraagd door DataGhost in "Server hosting - poorten werken niet van ziggo"
Die vragen zijn allemaal belangrijk en essentieel om verder te komen met je probleem.

Inderdaad, ik zie geen geen configuratiefout van de 2 computers. Er wordt wel een lokale DNS gebruikt op de Ubuntu server, wat niet altijd even goed werkt door bugs (bv. geen tcp ondersteuning, grote packets of fragmentatie, timeout problemen, etc). Ook zijn de firewallregels niet nodig. Zo te zien zijn het alleen access regels en geen forwards e.d. Ik zou voor de test die iptables regels opslaan met iptables-save > iptables.rules.v4 en vervolgens de iptables service of opstart uitschakelen of deze opdrachten uitvoeren na iedere herstart. Distributies ondersteunen diverse methoden voor het laden van iptables/ip6tables regels tijdens opstarten.

Je kan IPv6 uitschakelen (in DNS als je een hostnaam gebruikt) voor de test, om het wat eenvoudiger te maken.

De 2 computers horen elkaar te kunnen pingen en de Windows computer moet de Linux computer kunnen benaderen op open poorten op het lokale netwerk mits de Windows firewall correct configureerd is. Je kan nu verder met de vragen van @DataGhost.

Het komt wel eens voor dat serverapplicaties verwachten rechtstreeks op internet te zitten. Soms wordt dienst geweigerd als de IP adressen lokaal zijn. Dat kunnen bedrijven doen om licenties te kunnen controleren.

[MasterL]

Dit moet je (TS) echt wat methodischer gaan aanpakken.

Stap 1: draai eens tcpdump op die Ubuntu machine en probeer (vanaf een externe locatie) te verbinden op de geforwarde poort:

- apt install tcpdump
- tcpdump dst port 443 -i any (verander de poort voor de juiste poort)
- https://dnschecker.org/port-scanner.php (zoiets) en de juiste gegevens invullen (IP 24.132.236.xxx) en de goede poort.

Komen de pakketten binnen op de machine? Top je port forwards werken.. Je hoeft niet meer naar je router(s)/modems e.d. te kijken. Zie je geen packets binnen komen?

Stap 2:
- Sluit eens je server direct aan op de (bridged) modem je krijgt nu een publiek (24.132.236.xxx?) IP en herhaal bovenstaande test.
Zet wel je IF even op DHCP en zorg dat je FW even dicht staat in de input chain m.u.v. de open poorten uiteraard en eventueel SSH management.

Hieruit kun je conclusies trekken, als er bij stap 2 geen packets binnen komen kun je eigenlijk wel concluderen dat er iets mis zit bij Ziggo/modem e.d. maar dit verwacht ik niet. Komen ze bij stap 1 niet binnen en bij stap 2 wel dan ligt het aan je router.

De rest van de tests kun je overslaan, DNS resolving resolving/nslookup is compleet nutteloos zelfs ping/traceroute is niet nodig om in deze fase te doen aangezien zelfs als je geen gateway/default route hebt er nog steeds packets zouden moeten binnen komen. Uiteraard is er geen (two way) communicatie mogelijk maar de packets
zou je moeten kunnen zien.

Paar vragen opmerkingen:
- Wat voor machine is de "games" Ubuntu? VM? Bare metal? Indien VM:
* Bridged network? Of NAT network?
- Je IPtables rules hebben geen nut, je hebt (accept) rules aangemaakt maar je chain default is al accept dus ongeacht je rules is alles toch al allowed.

[DataGhost]

MasterL schreef op vrijdag 30 januari 2026 @ 11:53:
zelfs ping/traceroute is niet nodig om in deze fase te doen aangezien zelfs als je geen gateway/default route hebt er nog steeds packets zouden moeten binnen komen.

Met een traceroute kan je toch ietsjes beter zien of er niet tóch een CG-NAT of dubbel NAT aan de hand is, ondanks het externe IP wat zogezegd niet in gebruik zou zijn voor CG-NATed verbindingen.

[MasterL]

DataGhost schreef op vrijdag 30 januari 2026 @ 16:06:
[...]

Met een traceroute kan je toch ietsjes beter zien of er niet tóch een CG-NAT of dubbel NAT aan de hand is, ondanks het externe IP wat zogezegd niet in gebruik zou zijn voor CG-NATed verbindingen.

Dubbel NAT heb je geen traceroute voor nodig, TS heeft al zijn public IP (range) gepost en deze zit niet in de RFC1918 range. CGNAT zelfde verhaal deze range staat niet geregistreerd als GCNAT range. In theorie kan een ISP natuurlijk een willekeurig IP pakken voor CGNAT doeleinden maar dit "bewijs" je toch niet met een traceroute.
Dus een traceroute is zonde van de tijd en er valt geen enkele conclusie uit te trekken in dit specifieke scenario. Een tcpdump op de machine of een counter op de fw rules (gaat niet lukken met consumenten spul) laat ongeveer meteen het probleem zien.

[ Voor 8% gewijzigd door MasterL op 30-01-2026 16:34 ]

[sypie]

N.v.t. Ik lees net dat er al van buiten is geprobeerd om binnen te komen.

[ Voor 73% gewijzigd door sypie op 30-01-2026 16:37 ]

[MasterL]

sypie schreef op vrijdag 30 januari 2026 @ 16:36:
Kan het ook zijn dat het modem niet tegen een loopback kan? Dat je niet van binnenuit via buiten weer bij jezelf naar binnen kunt?

Je moet dus via een andere verbinding, bijvoorbeeld even je telefoon gebruiken als hotspot, gebruiken om dit te omzeilen.

Daarom testen vanaf een externe bron.
We kunnen blijven speculeren maar testen testen testen.
Pak een externe bron en kijk of packets binnen komen op de machine ja of nee.

[DataGhost]

MasterL schreef op vrijdag 30 januari 2026 @ 16:30:
[...]


CGNAT zelfde verhaal deze range staat niet geregistreerd als GCNAT range. In theorie kan een ISP natuurlijk een willekeurig IP pakken voor CGNAT doeleinden maar dit "bewijs" je toch niet met een traceroute.

Toch wel, dan zie je na de thuisrouter nog een ander intern-ish (rfc1918/100.x) adres verschijnen voordat het verkeer naar buiten gaat. Met al die provider-customised modem/routers tegenwoordig zie ik nog best gebeuren dat ze CG-NAT verbergen in hun interface en dus het "werkelijke" externe IP laten zien.

Dus een traceroute is zonde van de tijd en er valt geen enkele conclusie uit te trekken in dit specifieke scenario. Een tcpdump op de machine of een counter op de fw rules (gaat niet lukken met consumenten spul) laat ongeveer meteen het probleem zien.

Een traceroute kost je 30 seconden max en hoef je niets meer voor te doen dan het commando intypen en op enter drukken. In het geval van iemand die vrijwel geheel onbekend lijkt met netwerkzaken bovendien een stuk makkelijker dan tcpdump optuigen en leren lezen. Tenminste, ik ken eigenlijk niemand die dat kan zonder correct een poort te kunnen openen.

[ Voor 7% gewijzigd door DataGhost op 30-01-2026 16:49 ]

[kzin]

Bij grc.com (shields up) kun je testen of je een poort open hebt staan:
grc.com, kies bij services voor shields up! Je kunt nu ook je publiek IP adres zien.
Kies voor proceed, scroll wat naar onderen en voer de te testen poort in het invoerveld (b.v. 80).
Click op "user specified custom port probe" en grc kijkt of de poort open staat.

[MasterL]

@DataGhost Het hele idee van GCnat is om ipv4 adressen te besparen. Waarom zou een ISP je een public IP geven om deze vervolgens verder in het netwerk alsnog een src nat te doen? Kost alleen maar onnodig resources ik heb dit nog nooit gezien. Om traceroute (goed) te analyseren is ook kennis nodig net als een packet dump. Niemand vraagt ts om dit te doen, slechts om de resultaten te posten. Hoe gaat een traceroute helpen om te bepalen of de port forward werkt? We kunnen met z'n allen blijven speculeren waar het aan ligt maar het feit is pakketen komen aan of niet. Of pakketen bij de server aankomen controleer je met firewall rule counters of tcpdump achtige tools en niet met ping/traceroute oid

[DataGhost]

MasterL schreef op vrijdag 30 januari 2026 @ 20:40:
Of pakketen bij de server aankomen controleer je met firewall rule counters of tcpdump achtige tools en niet met ping/traceroute oid

Daar heb je gelijk in ja. Dat was ook helemaal het doel niet.

@DataGhost Het hele idee van GCnat is om ipv4 adressen te besparen. Waarom zou een ISP je een public IP geven om deze vervolgens verder in het netwerk alsnog een src nat te doen? Kost alleen maar onnodig resources ik heb dit nog nooit gezien.

Ik krijg het gevoel dat je het niet helemaal begrijpt, sorry als ik dat mis heb. CG-NAT gooit even heel bot gezegd gewoon een extra router tussen de klant en het internet. Om verbinding te kunnen maken (en data terug te krijgen) heb je op een gegeven moment een publiek IP nodig. Dat geldt voor iedereen, CG-NAT of niet. Dus aan het feit dat er "een publiek IP" van TS bekend is kan je op zichzelf niet afleiden of dat direct op de router van TS uitkomt of niet, want dat publieke IP zegt niks over de infrastructuur erachter tot aan de klant, en dus over of dat publieke IP ook "het IP van TS" is of dat van een router waar TS toevallig aan hangt. De enigen die daar iets meer over kunnen zeggen zijn de netwerk-engineers van de betreffende provider en de klant zelf (mits die weet hoe). Aangezien we met de eerste groep niet in gesprek zijn, blijft alleen TS over. Met een traceroute heb je een redelijke kans dat je kan zien of er toevallig CG-NAT tussen gemieteterd is en dat is meestal zichtbaar in de vorm van een 100.64.-adres of iets anders wat normaliter niet routeerbaar/bereikbaar is vanaf het internet in de hops voordat er publiek bereikbare IPs zichtbaar worden.

Om traceroute (goed) te analyseren is ook kennis nodig net als een packet dump. Niemand vraagt ts om dit te doen, slechts om de resultaten te posten.

???? Het resultaat van een traceroute is iets wat gewoon copy-pastebaar is en als tekst in een forumpost te plaatsen is. De analyse kan vervolgens door ons gedaan worden. Een tcpdump zal voor iemand zonder kennis stampvol staan met allemaal ruis-traffic van de machine zelf en het lokale netwerk en is daarmee wellicht alsnog bruikbaar maar minder handig om hier te posten zonder dat het een gigantisch bericht wordt. Verder kan je met een tcpdump alleen maar zien of packets aankomen of niet, niet waarom. Met een traceroute kan je wellicht iets meer over het waarom te weten komen.

Hoe gaat een traceroute helpen om te bepalen of de port forward werkt?

En, dus, weer terugkomend op CG-NAT, als dat aan de hand is kan je dat in een traceroute meestal zien, en dan kan je daar de conclusie uit trekken dat een port forward niet gaat werken, omdat die dan ook aan de providerkant geforward moet zijn, en dat gaan ze niet doen.

Dus we zijn nu al veel comments nutteloos aan het lullen over een simpele traceroute die TS in een minuutje gedaan kan hebben en die gewoon licht kan schijnen op een eventuele oorzaak, of die zoekrichting af kan sluiten. Waarschijnlijk dat laatste, maar het zou wel érg dom zijn als het tóch CG-NAT blijkt te zijn, niet?

[Rob vd Hoeven]

Voor mijn eigen webserver maak ik gebruik van Cloudflare tunnels. Op de webserver machine draait een daemon die een tunnel maakt tussen de webserver en de Cloudflare servers. (er wordt een uitgaande verbinding gebruikt, dus het is niet nodig om firewall poorten open te zetten). Als een Cloudflare systeem een request krijgt voor mijn webserver, dan wordt deze via de tunnel naar mijn systeem gestuurd.

Hoe Cloudflare tunnels werken wordt in dit artikel goed uitgelegd. Bij het artikel is ook een YouTube video.

[dion_b]

DataGhost schreef op vrijdag 30 januari 2026 @ 22:12:
[...]

Dus aan het feit dat er "een publiek IP" van TS bekend is kan je op zichzelf niet afleiden of dat direct op de router van TS uitkomt of niet, want dat publieke IP zegt niks over de infrastructuur erachter tot aan de klant, en dus over of dat publieke IP ook "het IP van TS" is of dat van een router waar TS toevallig aan hangt.

Dat kun je wel, Hele idee van CG-NAT is om publieke IP-adressen te besparen. Als je een publiek IP hebt op de WAN van je eigen router, zit je niet achter CG-NAT. Het is ook niet toegestaan:

Service Providers MUST NOT number the interfaces in question from
usurped globally unique address space

Zit je wel achter CG-NAT, dan heb je op die WAN een RFC6598 IP, dus een IP uit de reeks 100.64.0.0/10.

TS meldt een 24.x.x.x IP op zijn WAN, dus zit niet achter CG-NAT.

[liberque]

Prft wat een hoop tekst voor een simpel probleem. TS wilt gameservers draaien op Ubuntu. De hamvraag is of TS wilt of die gameservers continue bereikbaar moeten zijn. If so: is het vrij simpel.

Modem in bridge
Ubuntu server direct op de modem
2e netwerkkaart in Ubuntu server
Ubuntu instellen als NAT router op die 2e netwerkkaart
Switch (dus geen router) aansluiten op de UTP van die 2e netwerkkaart
Op die switch sluit je al je thuismeuk aan voor internet en als je Wifi wilt ook een AP
Gameserver meuk installeren in Ubuntu die luistert naar beide NICS

Wilt men van buitenaf connecten op de gameserver dan doet men dat via WAN IP van TS
Wilt TS van binnenaf (lokaal) connecten dan doet ie dat op het LAN IP van de Ubuntu router

Het wordt pas ingewikkelder als TS zijn gameserver niet 24/7 wilt laten draaien.

[ Voor 0% gewijzigd door liberque op 03-02-2026 13:44 . Reden: typetyfus ]

[dion_b]

liberque schreef op dinsdag 3 februari 2026 @ 13:43:
Prft wat een hoop tekst voor een simpel probleem. TS wilt gameservers draaien op Ubuntu. De hamvraag is of TS wilt of die gameservers continue bereikbaar moeten zijn. If so: is het vrij simpel.

Modem in bridge
Ubuntu server direct op de modem
2e netwerkkaart in Ubuntu server
Ubuntu instellen als NAT router op die 2e netwerkkaart
Switch (dus geen router) aansluiten op de UTP van die 2e netwerkkaart
Op die switch sluit je al je thuismeuk aan voor internet en als je Wifi wilt ook een AP
Gameserver meuk installeren in Ubuntu die luistert naar beide NICS

Wilt men van buitenaf connecten op de gameserver dan doet men dat via WAN IP van TS
Wilt TS van binnenaf (lokaal) connecten dan doet ie dat op het LAN IP van de Ubuntu router

Het wordt pas ingewikkelder als TS zijn gameserver niet 24/7 wilt laten draaien.

Of je doet gewoon een port forward, zonder je server volledig open en bloot aan het internet te hangen. Die funtionaliteit is aanwezig en werkt sinds jaar en dag prima. Iets gaat hier mis, maar in plaats van te troubleshooten krijgt TS aan de lopende band goedbedoelde adviezen om iets anders te doen die hem van regen in de drup kunnen doen belanden. Als TS een port forward niet voor elkaar krijgt is het niet evident dat een Ubuntu bak als NAT-router inrichten gaat lukken, laat staan dat de beveiliging dan geborgd op orde is.

[liberque]

dion_b schreef op dinsdag 3 februari 2026 @ 14:46:
[...]
Als TS een port forward niet voor elkaar krijgt is het niet evident dat een Ubuntu bak als NAT-router inrichten gaat lukken, laat staan dat de beveiliging dan geborgd op orde is.

Zou ik met je eens zijn als port forwarding op iedere router en/of modem goed werkt, betrouwbaar en logisch in te stellen is, maar dat is helaas niet altijd het geval. In mijn ervaring vaker niet dan wel (maar ik werk dan ook bij Delta lol). Het is dan veel beter om het in eigen beheer te hebben, want dan klopt het altijd. Zeker als er toch 24/7 een computer gaat draaien dan biedt dat een legio aan mogelijkheden. Denk aan eigen webserver, eigen cloudservice, eigen NAS etc.

Ja de learningcurve is wellicht hoger, maar met chatgpt kom je een eind. Daarnaast: geef een TS een portforwardinstelling en hij kan zijn gameserver bereikbaar maken, leer hem Linux en hij is van niemand meer afhankelijk