Skip to main content

Ik heb afgelopen december mijn Telfort Glasvezel abonnement ‘vernieuwd’ naar een KPN Hussel Glasvezel abonnement.

Sinds de ‘overstap’ werkt NAT Loopback niet meer. Ik kan dus mijn apparaten die ik extern kan benaderen niet via het DDNS adres (of het WAN IP) bereiken vanuit mijn eigen netwerk. Ik moet dan dus het LAN IP gebruiken en dat is enorm vervelend. Het gekke is dat ik wel een response krijg op een Ping naar het DDNS adres, maar het benaderen van mijn NAS of mijn IP camera werkt dus niet en daarvoor moet ik het interne LAN IP gebruiken. Wellicht ten overvloede, maar van buiten mijn eigen netwerk (dus via een andere vaste verbinding of via mobiel internet) werkt het probleemloos, portforwarding is dus correct ingesteld.

Voorheen (dus toen ik nog Telfort had) werkte dit probleemloos. Er is in mijn netwerk niets gewijzigd, ook het modem is niet vervangen. 

Modem: Experiabox V10 (H369A) met softwareversie V1.01.00T03.8V4

Ik zou graag willen dat de NAT Loopback functionaliteit weer hersteld wordt. Wie kan mij helpen?

De NAT loopback zou op een V10 (zonder a) gewoon moeten werken, ik heb het jaren kunnen gebruiken.

Ik hoop dat er snel iemand van KPN zal reageren om hier verder in te duiken.


Ha @michel_b, welkom! Vreemd.. Ik zie ook niet meteen iets geks, om eerlijk te zijn. Er is ook geen storing o.i.d. Heb je de Experia Box al eens teruggezet naar de fabrieksinstellingen? Let erop dat je de portforwardings dan wel weer opnieuw in moet stellen. 


Een reset heb ik al uitgevoerd, helaas zonder resultaat. Ik ben benieuwd wat er nog meer gedaan kan worden om het probleem te verhelpen.


Ik heb dit probleem ook gehad (op mijn thuis of werkadres, ben ik even kwijt, maar beiden Telfort, nu KPN) en ik kreeg NAT loopback alleen werkend op apparaten die een statisch IP adres via de DHCP van de Experiabox kregen.

 

Dus het werkte bij mij NIET met apparaten waarop ik een manueel adres had ingesteld.

WEL als ik in de Experiabox een statisch intern IP adres aan een device MAC adres koppelde.

(Ik bedoel hiermee de apparaten waarNAAR verbonden wordt. Deze moesten bij mij in de DHCP tabel staan dus.--edit)

 

Misschien heb je hier wat aan. 

 

 


Ik heb dit probleem ook gehad (op mijn thuis of werkadres, ben ik even kwijt, maar beiden Telfort, nu KPN) en ik kreeg NAT loopback alleen werkend op apparaten die een statisch IP adres via de DHCP van de Experiabox kregen.

 

Dus het werkte bij mij NIET met apparaten waarop ik een manueel adres had ingesteld.

WEL als ik in de Experiabox een statisch intern IP adres aan een device MAC adres koppelde.

 

Misschien heb je hier wat aan.

Dat is een heel goed punt dat je hier aandraagt. Hoewel dat gedrag alleen zou mogen optreden bij services die op basis van UPnP beschikbaar gesteld worden is het inderdaad zo dat ook gewone port-forwardings alleen lijken te werken als het apparaat waarop de service draait zijn iP adres via DHCP heeft verkregen.


Helaas. dat heb 

Ik heb dit probleem ook gehad (op mijn thuis of werkadres, ben ik even kwijt, maar beiden Telfort, nu KPN) en ik kreeg NAT loopback alleen werkend op apparaten die een statisch IP adres via de DHCP van de Experiabox kregen.

 

Dus het werkte bij mij NIET met apparaten waarop ik een manueel adres had ingesteld.

WEL als ik in de Experiabox een statisch intern IP adres aan een device MAC adres koppelde.

(Ik bedoel hiermee de apparaten waarNAAR verbonden wordt. Deze moesten bij mij in de DHCP tabel staan dus.--edit)

 

Misschien heb je hier wat aan. 

 

 

Dank voor de suggestie. Helaas heb ik het al op deze manier ingericht. De apparaten krijgen dus allemaal via DHCP hun IP en via DHCP binding in de Experiabox is dat IP dus statisch. Dat is het dus helaas in mijn geval niet.


Jammer dat het mysterie nog niet ontrafeld is.. Zou je voor de zekerheid toch eens een screenshot kunnen plaatsen van de portforwards? Dat we zeker weten dat dat goed gaat? Daarnaast ben ik benieuwd hoe je de NAS en IP camera benadert. Doe je dit via een pc of met een app o.i.d.?


De config is ook hetzelfde als voor de overstap naar KPN Hussel. Onderstaand deze post de screenshots van mijn configuratie.

Voor mijn (Synology) NAS forward ik poort 443 (https) naar de https poort van de software op mijn Synology (5001). Poort 5006 is voor WebDAV (https).

Voor mijn IP Camera forward ik poort 34000 naar de standaard poort van de Camera (poort 88).

Resultaten

Rood = niet ok, groen = ok

Vanuit mijn eigen netwerk:

  • Nas benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url>/ → ERR_CONNECTION_TIMED_OUT
  •  Camera benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url>:34000 → Dit werkt gek genoeg WEL (ik dacht echt dat dit ook niet werkte, maar ik heb me wellicht vergist, wel vreemd dat dit dus wel werkt).
  • Camera benaderen vanuit Camera app: https://<ddns url>:34000 → Werkt niet
  • Alle devices benaderen via lokaal IP en het juiste poortnummer werkt uiteraard wel (dus https://<ddns url>:5001 naar mijn NAS en https://<ddns url>:88 naar mijn IP Cam), zowel in browsers als in Camera app.

Vanaf een andere internetverbinding (mobiel internet):

  • Nas benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url> → Werkt
  •  Camera benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url>:34000 → Werkt
  • Camera benaderen vanuit Camera app: https://<ddns url>:34000 → Werkt
DHCP Binding
Port Forwarding
Application Configuration Foscam
Application Configuration Synology

 


Vanuit mijn eigen netwerk:

  • Alle devices benaderen via lokaal IP en het juiste poortnummer werkt uiteraard wel (dus https://<ddns url>:5001 naar mijn NAS en https://<ddns url>:88 naar mijn IP Cam), zowel in browsers als in Camera app.

Klopt het dat je hier niet de ddns url gebruikt maar het LAN IP adres van de NAS resp. Foscam camera?


Vanuit mijn eigen netwerk:

  • Alle devices benaderen via lokaal IP en het juiste poortnummer werkt uiteraard wel (dus https://<ddns url>:5001 naar mijn NAS en https://<ddns url>:88 naar mijn IP Cam), zowel in browsers als in Camera app.

Klopt het dat je hier niet de ddns url gebruikt maar het LAN IP adres van de NAS resp. Foscam camera?

Excuus, dat klopt inderdaad niet. Ik gebruik daar inderdaad het LAN IP van de devices.


Waar staat de DHCP pool op ingesteld?

Heb je de Experia Box aleen keer opnieuw opgestart om zo de DNS cache op de Experia Box zelf leeg te maken?


De experiabox is wel regelmatig van stroom geweest. Zojuist nog een keer een herstart gegeven, zonder resultaat.

Hieronder een screenshot van de DHCP pool instellingen (de IP adressen vallen dus allemaal binnen de DHCP scope):

 


Dat ziet er allemaal goed uit.

Ik leg de bal graag bij @Marcia_ neer om hier eens wat vragen bij de techneuten over te stellen.

Je zou nog één laatste test kunnen doen en dat is de dns te flushen op de computer waarmee je de testen uitvoert.


Dat ziet er allemaal goed uit.

Ik leg de bal graag bij @Marcia_ neer om hier eens wat vragen bij de techneuten over te stellen.

Je zou nog één laatste test kunnen doen en dat is de dns te flushen op de computer waarmee je de testen uitvoert.

Dat heb ik nog even gedaan, geen resultaat.


Yes, bedankt voor je uitgebreide uitleg en screenshots! Ik heb alles doorgestuurd naar een paar collega's waarvan ik denk dat ze ons verder kunnen helpen! Zodra ik meer informatie heb, laat ik het weten. 


De config is ook hetzelfde als voor de overstap naar KPN Hussel. Onderstaand deze post de screenshots van mijn configuratie.

Voor mijn (Synology) NAS forward ik poort 443 (https) naar de https poort van de software op mijn Synology (5001). Poort 5006 is voor WebDAV (https).

Voor mijn IP Camera forward ik poort 34000 naar de standaard poort van de Camera (poort 88).

Resultaten

Rood = niet ok, groen = ok

Vanuit mijn eigen netwerk:

  • Nas benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url>/ → ERR_CONNECTION_TIMED_OUT
  •  Camera benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url>:34000 → Dit werkt gek genoeg WEL (ik dacht echt dat dit ook niet werkte, maar ik heb me wellicht vergist, wel vreemd dat dit dus wel werkt).
  • Camera benaderen vanuit Camera app: https://<ddns url>:34000 → Werkt niet

Maakt het uit of je i.p.v. ddns url een ipv6 of ipv4 adres gebruikt?

Het enige wat ik zo even nog kan bedenken is dat een uiteindelijke request via IPv6 zou kunnen gaanen daar zijn in ieder geval geen portforwards voor gedefinieerd. Dat zou dan een verschil kunnen maken. En had je bij Telfort volledig Dual-Stack? Iets dergelijks heb ik in het verleden wel eens aan de hand gehad bij buitenlandse ISP en toendertijd zwabberde de voorkeur m.b.t. IPv4 of IPv6 per OS enz nogal. Maar is al lang geleden en gezien moderne randverschijnselen m.b.t. IPv4/IPv6 zou er wel vrij intelligent dubbel geprobeerd moeten worden indien nodig. Maar dat zou je met wireshark o.i.d. moeten monitoren.


De config is ook hetzelfde als voor de overstap naar KPN Hussel. Onderstaand deze post de screenshots van mijn configuratie.

Voor mijn (Synology) NAS forward ik poort 443 (https) naar de https poort van de software op mijn Synology (5001). Poort 5006 is voor WebDAV (https).

Voor mijn IP Camera forward ik poort 34000 naar de standaard poort van de Camera (poort 88).

Resultaten

Rood = niet ok, groen = ok

Vanuit mijn eigen netwerk:

  • Nas benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url>/ → ERR_CONNECTION_TIMED_OUT
  •  Camera benaderen vanuit browser laptop of browser Android telefoon: https://<ddns url>:34000 → Dit werkt gek genoeg WEL (ik dacht echt dat dit ook niet werkte, maar ik heb me wellicht vergist, wel vreemd dat dit dus wel werkt).
  • Camera benaderen vanuit Camera app: https://<ddns url>:34000 → Werkt niet

Maakt het uit of je i.p.v. ddns url een ipv6 of ipv4 adres gebruikt?

Het enige wat ik zo even nog kan bedenken is dat een uiteindelijke request via IPv6 zou kunnen gaanen daar zijn in ieder geval geen portforwards voor gedefinieerd. Dat zou dan een verschil kunnen maken. En had je bij Telfort volledig Dual-Stack? Iets dergelijks heb ik in het verleden wel eens aan de hand gehad bij buitenlandse ISP en toendertijd zwabberde de voorkeur m.b.t. IPv4 of IPv6 per OS enz nogal. Maar is al lang geleden en gezien moderne randverschijnselen m.b.t. IPv4/IPv6 zou er wel vrij intelligent dubbel geprobeerd moeten worden indien nodig. Maar dat zou je met wireshark o.i.d. moeten monitoren.

Interessant… IPv6 heb ik nog niet geprobeerd. Maar n.a.v. je bericht heb ik ook even IPv6 portforwarding aangezet voor mijn NAS. Het resultaat was dat ik WEL bij mij NAS kan komen via https://<ddns url>, maar ik word dan wel geforward naar het poortnummer op de NAS, dus naar https://<ddns url>:5001. Ik weet niet of dat verwacht is? Het lukte me nu alleen niet meer om van ‘buiten’ bij mijn NAS of IP camera te komen, dus ik heb de regels weer weggehaald. Helaas gaat er nu nog steeds iets niet goed en kan ik mijn NAS en camera helemaal niet meer van ‘buiten’ benaderen. Maar gek genoeg mijn NAS nog WEL steeds binnen mijn eigen netwerk via de DDNS url.

Het lijkt op een soort mixup van de IPv4/IPv6 instellingen… De config is exact hetzelfde als een uur geleden, maar nu met een heel ander resultaat. Helaas dus… Ik vermoed dat ik nu maar een hard reset moet gaan doen en het weer opnieuw moet instellen om het in ieder geval weer enigszins werkend te krijgen, de Experiabox lijkt me in ieder geval niet helemaal betrouwbaar met de instellingen rondom portwarding.


Update: Na een herstart van het modem werkt het weer zoals voor het toepassen en verwijderen van de IPv6 forwarding. Ik kan dus vanuit mijn eigen netwerk niet meer via de DDNs url bij mijn NAS, maar van ‘buiten’ kan ik wel weer overal bij.


Update: Na een herstart van het modem werkt het weer zoals voor het toepassen en verwijderen van de IPv6 forwarding. Ik kan dus vanuit mijn eigen netwerk niet meer via de DDNs url bij mijn NAS, maar van ‘buiten’ kan ik wel weer overal bij.

Mijn vraag was eigenlijk niet om een IPv6 portforwarding toe te voegen, maar om in eerste instantie je directe WAN IP adres, dus geen FQDN, (achtereenvolgens IPv4 en dan ook eens IPv6) te gebruiken in de http(s) request. Daarmee sluit je effecten van DNS uit. Stap verder is gericht met een tool als netcat de diverse paden en opties te testen, zijn er heel wat, maar ik weet niet of je voldoende bederven bent met (linux) commandline tools.


Update: Na een herstart van het modem werkt het weer zoals voor het toepassen en verwijderen van de IPv6 forwarding. Ik kan dus vanuit mijn eigen netwerk niet meer via de DDNs url bij mijn NAS, maar van ‘buiten’ kan ik wel weer overal bij.

Mijn vraag was eigenlijk niet om een IPv6 portforwarding toe te voegen, maar om in eerste instantie je directe WAN IP adres, dus geen FQDN, (achtereenvolgens IPv4 en dan ook eens IPv6) te gebruiken in de http(s) request. Daarmee sluit je effecten van DNS uit. Stap verder is gericht met een tool als netcat de diverse paden en opties te testen, zijn er heel wat, maar ik weet niet of je voldoende bederven bent met (linux) commandline tools.

Ja excuus, niet helemaal goed gelezen, maar je vraag triggerde mij om toch even de IPv6 portforwarding te testen :wink:

Verbinding maken via het WAN IP heb ik uiteraard al geprobeerd en dat geeft exact hetzelfde resultaat. Ik kan enigszins uit de voeten met commandline tools, maar dan moet ik er echt in gaan duiken waar ik precies naar moet kijken. Ik wacht eerst even af wat KPN te zeggen heeft. Zo exotisch is mijn use case niet lijkt me, dus dat zou toch gewoon werkend te krijgen moeten zijn.


Ik heb er naar laten kijken, maar de collega's komen er ook niet uit waarom het niet zou werken bij je. Bij ons werkt het verder prima en we hebben ook geen andere meldingen binnen gekregen. Daarom wil ik graag je Experia Box om laten ruilen. Ik stuur je een privébericht met meer informatie! 


Gisteren de Experiabox omgeruild voor een andere. Er hangt nu een V10a in de meterkast en alles werkt nu zoals het hoort 🙂 Ik kan nu zowel de NAS als de IP Camera van buiten en binnen mijn netwerk benaderen via dezelfde url. Bedankt!


Super! Fijn dat je het nog even liet weten 🙂.