Beantwoord

NAT loopback met v10 werkt toch niet (Hairpinning)

  • 11 januari 2018
  • 18 reacties
  • 1200 keer bekeken

Hallo,

Ik heb een probleem dat ik mijn NAS niet kan bereiken met een sub.domein.nl naam vanuit mijn LAN.
Vanuit WAN werkt dit sub.domein.nl adres wel.
Ik werk met een Experiabox v10 en die zou NAT loopback moeten ondersteunen maar dat blijkt dus niet.

Is hiervoor een instelling die je moet omzetten of is mijn experiabox defect of ben ik misinformed en kan de v10 ook niet met NAT loopbacks overweg.

Thanks,
icon

Beste antwoord door Joran 15 januari 2018, 11:24

Hoi Eric Jan, we hebben nog een melding gekregen over problemen met NAT loopback in combinatie met Sneller Internet Buitengebied. Zie ook Website met ADSL en 4G buitengebied. Ik heb navraag gedaan bij de productmanager van Sneller Internet Buitengebied. Als ik reactie heb zal ik het ook hier laten weten.
Bekijk origineel

18 reacties

Reputatie 7
Ik ondervind zelf geen problemen met het buitenom benaderen van mijn Synology NAS achter de V10. NAT loopback functioneert dus gewoon.
Heb jij dit probleem ook als je niet het domein, maar het publieke IP adres gebruikt?
Hallo wjb,

Ook met het WAN IP heb ik hetzelfde probleem.
Is dit een functie of een instelling van de modem, weet jij dit?
Volgens mij is het een functie.

Alvast bedankt
Reputatie 7
Welke firmware versie staat er op jouw V10?
Is jouw NAS op zijn LAN IP adres wel te bereiken?
Reputatie 7
Badge +30
Dat extern IP is wel het extern IP dat genoemd staat bij de status pagina van de V10?
V1.01.00T03.0_Hybrid2.4v2
Maar ik denk dat ik weet waar het mogelijk vandaan komt.
Ik heb sneller internet buitengebied.
Die zwarte ondersteunende 4G modem (Sagemcom Box) kan hier mogelijk het probleem zijn.
Maar ook hier zie ik geen instellingen die ik zou kunnen aanpassen om dit te fixen.

En binnen mijn LAN via het LAN ip is het geen probleem.
Dus alles werkt, maar ik wil niet steeds moeten wisselen van loginmanier als ik binnen of buiten mijn netwerk zit.
Oja, Robin,
Het WAN ip is inderdaad het WAN ip dat zowel https://whatismyipaddress.com/ als de V10 aangeeft dus die klopt ook.
Reputatie 7
Badge +28
Hoi Eric Jan, we hebben nog een melding gekregen over problemen met NAT loopback in combinatie met Sneller Internet Buitengebied. Zie ook Website met ADSL en 4G buitengebied. Ik heb navraag gedaan bij de productmanager van Sneller Internet Buitengebied. Als ik reactie heb zal ik het ook hier laten weten.
Hallo Joran,

Ik heb even een klein testje gedaan door mijn WAN IP in te geven met en zonder de Sagecom.
En het is bevestigd. Zonder problemloos en met kom ik er niet door.
Dus de Experiabox v10 werkt de Sagecom is degene die NATloopback niet toestaat.
Ik ben benieuwd.
Bedankt,
Eric Jan
Reputatie 7
Badge +28
Hele late reactie, het duurde even voor de fabrikant aan dit probleem toekwam. Ze bevestigen dat NAT loopback niet werkt op de Sagemcom router. Dat was geen verrassing natuurlijk. Er wordt uitgezocht of ze dit middels een update mogelijk kunnen maken. Staat op de roadmap, eindtijd nog niet bekend. Maar vooralsnog schaar ik dit onder goed nieuws 🙂
Afgelopen donderdag heb ik qua diensten de overstap gemaakt van OnsBrabantnet naar KPN. Inclusief nieuwe apparatuur van KPN.
Ook ik loop tegen het NAT Loopback /hairpin probleem aan.


Situatie:
Publiek IP : a.b.c.d. (fictief)
Experiabox intern IP: 192.168.1.254
Server: 192.168.1.1
Client: 192.168.1.106


(ZTE H369A).
Ik heb gekeken met TCPdump (in mijn geval interne server (192.168.1.1) en Wireshark (op laptop/client 192.168.1.106) naar de verkeersstromen.
Wat er na het instellen van een port-forward op de ZTE ontstaat wordt perfect weergegeven in het plaatje wat al eerder hier op het forum is gepost:
https://uploads-eu-west-1.insided.com/kpn-prive-nl/attachment/1c42e809-cbee-4bef-9c15-f7243c0deefa.png
(Simplistic Hairpin situatie).

De Experiabox doet voor interne hosts alleen een Destination NAT waarbij het Externe IP adres wordt vervangen door het internet IP-adres op het LAN. Wat ontbreekt is dus ook een Source NAT, waarbij het originele IP-adres van de afzender wordt vervangen door het IP-adres van de Experiabox. Hierdoor gaat de sessie stuk.

De client welke het verkeer initieert (naar het publieke IP-adres) krijgt een antwoord terug van het interne IP-adres (van dezelfde doelhost) waar de client geen verkeer van verwacht te ontvangen. Dit verkeer wordt genegeerd of ge-reset door de client en de uiteindelijke sessie komt niet tot stand.

ZTE info:
Model H369A
Hardware versie V1.00
Software versie V1.01.00T03.4
Boot loader versie V1.0.00


Situatie:
Client 192.168.1.106 wil naar IMAP-server op publiek IP-adres (van Experiabox) ...stel a.b.c.d (port 993)
Dit wordt op de client qua DNS goed geresolved ...echter komt het als volgt op de server (192.168.1.1) binnen. (Experiabox heeft in mijn geval 192.168.1.254 als IP op 't LAN)

14:23:07.383204 IP 192.168.1.106.34911 > 192.168.1.1.993: Flags [Syn], seq 3416358809, win 65535, options [mss 1460,sackOK,TS val 2720712 ecr 0,nop,wscale 7], length 0
( ZTE heeft origineel destination IPadres vervangen van a.b.c.d naar 192.168.1.1)

14:23:07.383337 IP 192.168.1.1.993 > 192.168.1.106.34911: Flags [Syn-ack.], seq 1030413718, ack 3416358810, win 28960, options [mss 1460,sackOK,TS val 227158502 ecr 2720712,nop,wscale 7], length 0
( de server geeft antwoord direct terug richting 192.168.1.106.
hier had dus eigenlijk een antwoord terug moeten gaan naar 192.168.1.254.
Doordat er geen source-NAT heeft plaatsgevonden krijg je hier een assymetrische verkeersstroom)

14:23:07.386267 IP 192.168.1.106.34911 > 192.168.1.1.993: Flags [Reset], seq 3416358810, win 0, length 0
(client (192.168.1.106) heeft een IP packet ontvangen van 192.168.1.1 waarvoor niet eerder een TCP-syn is uitgegaan. De client reset daarom de verbinding (Flags R))

Deze NAT-constructie werkt wel in de situatie waarin het verkeer vanaf internet komt.
In zo'n situatie bevindt de eindhost zich niet in het lokale LAN komt en moet de server via de default-gateway (Experiabox) met de afzender moet communiceren. In dat geval is er geen assymetrisch verkeer (op het lokale LAN)

Volgens mij is het een bug in de Experiabox.
Reputatie 7
Ook ik loop tegen het NAT Loopback /hairpin probleem aan.
...
Volgens mij is het een bug in de Experiabox.
Waarom ervaar ik geen enkel probleem met NAT Loopback/hairpin terwijl ook ik een Experia Box V10 met firmware versie V1.01.00T03.4 heb?
Goeie vraag WJB

Veel feitelijker dan een TCPdump kan ik 't niet maken.
Reputatie 7
Lang geleden heb ik de "Wake On LAN Gateway" voor de Synology NAS ontwikkeld. Deze toepassing biedt de mogelijkheid om een apparaat op jouw thuisnetwerk m.b.v. een Wake on LAN magic packet wakker te schudden. Deze toepassing controleert of het source IP gerechtigd is om het apparaat wakker te schudden.
Nu stuur ik vanaf een tablet met IP adres 192.168.2.9 een WoL magic packet bericht naar 86.86.x.y en via een port-forwarding wordt die doorgezet naar mijn Synoloogy NAS op 192.168.2.240. Wat jij aangeeft is dat het source IP adres dat op de Synology NAS ontvangen wordt dan 192.168.2.9 zou zijn (simplistic hairpin NAT) i.p.v. 192.168.2.254 van de V10 (proper hairpin NAT). Het source IP adres dat door de Synology NAS ontvangen wordt is echter zelfs het publieke IP van de Experia Box. (86.86.x.y)
Blijkbaar is er dus een verschil in de werking van de hairpin NAT op onze V10's. Nu hoop ik niet dat dat veroorzaakt zou kunnen worden door het feit dat ik het standaard subnet 192.168.2.0/24 terwijl jij deze gewijzigd hebt in 192.168.1.0/24.
Dat zou niet mogen, maar ik heb ondertussen genoeg vreemde implementaties gezien bij KPN. 😎
workaround wat voor mij werkt inmiddels:
Eenmalig verwijderen van port forwards.
Configureren als DMZ host (aan)
Reboot
DMZ-host configuratie weer (uit)
Portforwards terugzetten

(enkel een reboot verhielp het probleem niet)


TCPdump laat nu ook source-NAT zien (van extern IP van de ZTE)
Reputatie 7
workaround wat voor mij werkt inmiddels:
Eenmalig verwijderen van port forwards.
Configureren als DMZ host (aan)
Reboot
DMZ-host configuratie weer (uit)
Portforwards terugzetten

(enkel een reboot verhielp het probleem niet)

TCPdump laat nu ook source-NAT zien (van extern IP van de ZTE)
Mooi dat het probleem nu dan in ieder geval verholpen is. Ik zou KPN Webcare willen vragen dit topic eens aan het modem developmentteam voor te leggen want ik ben wel benieuwd wat de oorzaak geweest zou kunnen zijn, mede omdat we dit probleem wel vaker op het forum tegenkomen.

De acties die door @ReCharge uitgevoerd zijn zouden eigenlijk geen impact gehad mogen hebben op de NAT loopback functionaliteit, maar blijkbaar is dat wel het geval. Dat is een interessante constatering die wel eens richting zou kunnen geven aan het vinden van de oorzaak.
Hallo @@wjb en @ReCharge

Het probleem ligt niet in de V10 maar in de combinatie V10 en sneller internet buitengebied. En dit werkt nog niet. Wat ook niet werkt in deze combinatie is een bedrijfs VPN. Want dan laat hij de 4G modem links liggen en gaat hij enkel over de V10 met zijn tergend langzame koper verbinding.
Dus twee problemen op te lossen.

Maar verder werkt het wel snel.

Thanks voor het meedenken.
Reputatie 5
Badge +7
Ik heb dezelfde ervaring als Eric Jan. Sinds vorige week (begin april) heb ik ook Sneller Internet Buitengebied. Ik heb 2 Hikvision camera's en voordat ik Sneller Internet Buitengebied (SIB) aangesloten had op mijn Experiabox V10 kon ik de beelden van mijn camera's via mijn mobiele telefoon bekijken (mbv. de app IVMS-4500). Nu ik het SIB heb aangesloten kan ik de beelden niet meer zien via de app. Maak ik mijn SIB weer los van mjn V10 dan heb ik direct weer beeld op mijn mobiele telefoon.
Ik heb een andere oplossing gevonden voor NAT loopback problemen en dat is het draaien van een DNS server. Die vertaalt de lokale vragen naar een lokale plek voordat de overige vragen doorgezet worden naar een DNS server buiten. Maar ik vraag mij alleen af of ik hiervoor mijn poort 53 open moet zetten. En indien dat nodig is krijg ik het niet voor elkaar. Geen idee wat ik verkeerd doe.

Maar Eigen DNS server draaien is de oplossing voor NAT loopback of hairpinning wat niet werkt.

Reageer