NAT loopback / hairpin werkt niet meer na software update KPN Box 12

Ik neem aan dat je dan het interne netwerkadres gebruikt (192.168.2.x).

Werkt het ook als je vanaf je interne LAN de server probeert te benaderen met je externe IP adres? (https://whatismyipaddress.com/)

Klopt, interne netwerkadres ja.

Je 2e suggestie (ik zei eerst: lukt ook). Correctie, dat werkt ook niet: ERR_CONNECTION_TIMED_OUT

Ik ervaar geen problemen met NAT loopback op mijn V12 als ik deze op z'n WAN IP adres benader.

Geeft die dynamische DNS wel het juiste IP adres? (https://www.nslookup.io)

Je bedoelt denk ik ‘geen problemen’ :D? En je hebt ook .38 firmware?

Juiste IP-adres: Het IPv4 adres (A-record) klopt, maar het IPv6 adres onder AAAA-record is anders; weet niet of dat uit kan maken? Ik dacht dat enkel het A-record IPv4 van belang was.

RJBanthum schreef:

Juiste IP-adres: Het IPv4 adres (A-record) klopt, maar het IPv6 adres onder AAAA-record is anders; weet niet of dat uit kan maken? Ik dacht dat enkel het A-record IPv4 van belang was.

Tegenwoordig prefereren bijna alle OSen IPv6 boven IPv4 en dus zal het IPv6 adres uit het AAAA record gebruikt worden. Dat IPv6 adres Is inderdaad anders want dat is het IPv6 adres van het apparaat waarop die dynamic DNS entry aangevraagd is. Als dat een ander apparaat is dan het apparaat die je wilt bereiken, dan gaat dat dus niet werken. In dat geval zal je die dynamic DNS service alleen een IPv4 adres moeten laten bepalen maar ik weet niet of dat instelbaar is.

Als je IPv6 uit zet op de V12 of op het apparaat dat je gebruikt om verbinding te maken, werkt het dan wel?

Ahh oke, IPv6 gaat dan rechtstreeks naar het betreffende apparaat, en niet meer via extern → NAT → intern? Overigens klopte het IPv6 adres (dns lookup) nog steeds niet met het IPv6 adres van het apparaat dat de registratie doet. Heb de configuratie nog een keer goed bekeken, en ik denk dat het update protocol inderdaad enkel de v4 updatet, en niet de v6, vandaar dat het waarschijnlijk verschilde.

Ik heb echter nog steeds geen resultaat na het volgende geprobeerd te hebben:

• IPv6 DNS entry updaten naar het IPv6 adres van de server » geen verandering
• IPv6 uitzetten bij DynDNS provider » geen verandering
• IPv6 uitzetten op de KPN box » geen verandering

De DNS lookup geeft nu enkel het A-record voor het IPv4, en dat klopt 100%.
Maar zelfs die 1e poging, met het juiste IPv6 adres, had dan toch al moeten werken?

Dank zover voor je hulp, wjb!

Als jij via 4G naar die URL gaat, werkt het dan wel?

Plaats hier eens screenshots van jouw Port-Forwarding, zowel IPv4 als IPv6.

Poets bij IPv6 wel het derde blokje van het IPv6 adres weg.

Heb wat dingen weggepoetst waar ik me wat minder comfortabel bij voelde, maar hoop dat je hier toch genoeg informatie aan hebt.

Overige services zijn allemaal andere poorten, 1 poort per rule, geen overlap met de getoonde.

Ik heb geen IPv6 forwarding rules.

(Heb tevens mijn vorige comment aangepast met wat vreemde testresultaten).

Als je geen IPv6 rules hebt, dan kan je van buitenaf dus ook geen IPv6 gebruiken om jouw services te benaderen. Dat betekent dat er geen AAAA record mag zijn voor het domein.

Ik neem aan dat het "Internet IP adres" in al die regels leeg is, klopt dat?

Kan je die services vanaf jouw thuisnetwerk wel bereiken op het IP adres 192.168.2.200?

Dat klinkt wel logisch ja! Ik moet eerlijk zeggen dat ik het IPv6 stukje nooit aandacht gegeven heb, blijkbaar stond dat altijd al aan op mijn DynDNS configuratie, en is me nooit opgevallen dat er een PortForwarding configuratie voor IPv6 mogelijk is in de KPN box.

Geen AAAA record → Check, dat staat dan sinds vanmiddag uit, ook volgens DNS lookup.

Internet IP adres leeg → klopt, geen filtering

Services bereikbaar vanaf LAN, met lokale IP 2.200 → Ja, dat gaat altijd goed (al krijg ik dan natuurlijk wel de klacht over het certificaat dat dat niet matcht met het domein, maar dat is logisch).

Als jij via 4G naar https://<jouw publieke IP adres> gaat, kom je dan op jouw server?

En als je dan i.p.v. dat IP adres het domein gebruikt?

Heb dezelfde versie. Ik heb hier ipv4 port forward staan naar een oud ipv4 only apparaatje.

Van buiten af kan ik die dus aankiezen op het publieke ipv4 modem adres plus specifiek het geforwarde port nummer wat ook in de overzichtspagina van het modem staat.

Daarnaast kan ik hetzelfde publieke ipv4 ook aankiezen vanuit de LAN zijde op het modem ipv het LAN IP adres waar het beschreven apparaatje werkelijk op draait.

Dit betekent voor mij dat NAT hairpinning functioneert.

Als ik de port forward op disable zet dan werkt alleen de lokale toegang nog op het LAN ip adres.

Haha, ik moet echt iets goed fout doen, want in een tijdspanne van 10 minuten is het van “werkt op geen van beide meer via 4G (publiek IP / domein)” naar “werkt toch voor beide” weer naar “werkt toch niet meer” gegaan…

Het lijkt nu heel willekeurig te worden, en dat maakt het er niet makkelijker op. :(

Ik moet nu helaas de deur uit, waardoor ik wat minder makkelijk kan testen. Ik hoop hier morgenmiddag nog weer mee verder te stoeien. Mochten jullie nog ideeen hebben voor testjes of logs te analyseren; altijd welkom!

In ieder geval wederom bedankt voor de tijd die jullie erin stoppen!

@BruisTablet Ik weet niet zeker of dat direct een bevestiging is dat NAT hairpinning werkt. Als het modem naar je oude apparaatje het WAN IP als client IP gebruikt, is de routering alsnog extern geweest, waardoor het voor je oude apparaatje lijkt alsof de call van buiten het netwerk is gekomen. De hairpinning / loopback zorgt er dacht ik voor dat het modem zich realiseert dat de call niet via externe routering hoeft te gaan, en het lokale IP gebruikt als client IP. Tenminste, zo dacht ik dat het werkte.

De router met hairpinning herschrijft de ip adressen van apparaten van het lokale lan (bij kpn dus bv een 192.168.2.100 adres ) naar het publieke adres wat het modem in gebruik heeft. Daardoor lijkt het voor het andere apparaat wat lokaal aangekozen wordt alsof er een sessie binnenkomt vanaf de internet zijde. Daarom moet er ook een valide port forward open staan richting het aan te kiezen LAN apparaat.

Oke, ik ben nog iets verder gekomen met dit issue, maar nog niet helemaal waar het moet zijn.

Ik kan nu zowel van binnen als buiten het LAN consistent verbinden met de dynamische URL. Dat is positief! Ik heb nu:

• In de Dynamic Domain provider enkel een IPv4 verwijzingen staan.
• Enkel IPv4 poorten geforward in de KPN box.

Voor externe requests werkt het precies zoals zou moeten. Voor interne requests (binnen het LAN) nog niet, en dat haalt eigenlijk precies jouw verhaal aan, @BruisTablet .

Als ik met een LAN Client (zeg 192.168.2.10) de server probeer aan te spreken (zeg 192.168.2.20) via het dynamische adres, gaat dit via de Box (zeg 192.168.2.254, en laten we zeggen WAN IP 1.2.3.4).

Wat ik dan zie in de access logs op de server is een binnenkomend request vanaf client IP ‘1.2.3.4’.
Wat ik verwacht had te zien was een binnenkomend request vanaf client IP ‘192.168.2.254’, omdat de NAT hairpinning functionaliteit dit omschrijft van 1.2.3.4 naar het interne adres. Precies andersom dus dan jij beschreef, @BruisTablet .

Zo werkte het in ieder geval voorheen; ik deed exact dit en in de access logs zag ik het interne IP.

Waarom is dit belangrijk? Ik heb services draaien die d.m.v. een firewall enkel lokale requests accepteren (zeg 192.168.2.x ). Daar kom ik nu dus vanaf het interne netwerk ook niet bij, omdat de service denkt dat de request van extern komt (WAN IP).

Of ik begrijp niet goed hoe NAT hairpinning werkt, maar dan begrijp ik ook niet hoe dit in het verleden dan wel zo ging. Of er gaat toch iets mis in de KPN Box.

Heeft iemand nog een idee?

NB: Requests rechtstreeks naar het LAN IP van de server (dus als client 192.168.2.10 rechtstreeks het IP intypt van de server 192.168.2.20 met eventueel de poort van de service), gaat het om de firewall heen en dat gaat prima. Maar ik wil bereiken dat het via het dynamische adres lukt; dat heeft altijd gewerkt!

Hi, ik loop hier tegen hetzelfde probleem - maar gebruik geen DDNS - maar gewoon een normal domain provide. het domein werkt vanuit extern - maar vanuit mijn intern is het domein niet benaderbaar zoals bij jouw initeel het geval. Even snel er door geeen gelezen, maar hoe heb je dit nog werkend gekregen ? en ben je nog verder gekomen ?

Hi @MogamiXL ,

Ik ben erachter dat de ERR CONNECTION REFUSED door mijn webserver kwam. Daar zat een ongerelateerd probleem dat nu is opgelost.

Ik kan dus nu met mijn ddns wel verbinden, zowel intern als extern. Alleen de firewall blokkeert alsnog alle interne verkeer omdat hij denkt dat het van buiten komt. Daarvoor heb ik nog geen oplossing toegepast, eventueel zou ik mijn eigen wan ip kunnen allowen, dan zou het wel werken.

Ik denk nog steeds dat dit een bug in de KPN box 12 is.

Maar dus een combi van de volgende maatregelen:

- DDns enkel ipv4 ingesteld

- op box 12 IPv6 helemaal uit

- enkel ipv4 poorten geforward

Weet niet of je ook een firewall hebt en wat je precies ziet als je vanuit intern verbindt?

Dat is mijns inziens ook de juiste oplossing.