Port forward werkt van buiten, niet van binnen

Je hebt een port forward gemaakt naar je NAS, je camerarecorder of je server. Vanaf mobiele data werkt hij: je typt het publieke adres of je eigen domeinnaam en je komt binnen. Zit je op je eigen wifi, dan loopt dezelfde naam vast. Soms duurt het lang en komt er niets, soms komt er meteen een foutmelding.

Wat het niet is: de port forward zelf is goed. Dat heb je net van buiten bewezen. Het is ook geen firewallregel die te streng staat, want dan zou het van buiten ook niet werken. Wat hier misgaat, gebeurt op de router, in de NAT-tabel, met verkeer dat via dezelfde kant naar binnen en weer naar buiten moet. Dat heet hairpin NAT, of NAT loopback.

De reden is meetkunde, niet beveiliging. Je laptop op 192.168.88.20 stuurt een pakket naar het publieke adres. De router vertaalt de bestemming naar 192.168.88.10, de NAS. Die ziet een pakket van 192.168.88.20 en antwoordt daar rechtstreeks op, zonder de router. Je laptop krijgt dus een antwoord van 192.168.88.10 terwijl hij op het publieke adres wachtte, en gooit het weg. De oplossing is dat de router ook het afzenderadres vervangt.

De snelle controles, op volgorde

1. Werkt het van buiten? Zet je telefoon op mobiele data en probeer het. Goed antwoord: je komt binnen. Zo niet, dan is dit je hoofdstuk niet, zie Port forward doet niets.
2. Staan er hairpin-regels? /ip firewall nat print stats. Goed antwoord: naast de gewone dstnat-regel met in-interface-list=WAN staan er twee regels met hairpin in de opmerking, een dstnat met dst-address-type=local in-interface-list=LAN en een srcnat-masquerade. Staan die er niet, dan is dit precies het probleem.
3. Lopen de tellers op? Probeer het vanaf je laptop en kijk opnieuw. Goed antwoord: de teller van de hairpin-dstnat stijgt. Blijft hij op nul, dan komt je pakket niet bij die regel aan.
4. Heeft de router het publieke adres zelf? /ip address print op de WAN-interface. Goed antwoord: een echt publiek adres. Staat er 100.64.x.x, 10.x.x.x of 192.168.x.x, dan zit er een modem of de provider voor je, en dan bestaat het publieke adres niet op deze router.
5. Welk adres krijgt je laptop eigenlijk terug? Vanaf de router: :put [:resolve nas.example.nl]. Krijg je het publieke adres, dan gaat het verkeer de hele weg. Krijg je het interne adres, dan is er al split DNS en hoef je niets met NAT.

De gewone oorzaken, meest voorkomend eerst

Er is helemaal geen hairpin-regel

Een kale port forward in RouterOS matcht op in-interface-list=WAN. Verkeer van je eigen LAN komt daar nooit langs. Dit is de standaardsituatie op een router die je met de hand hebt ingericht. De oplossing is het regelpaar dat hieronder beschreven staat: een tweede dstnat voor verkeer vanaf LAN, plus een masquerade zodat het antwoord terugkomt.

Je zit in een VLAN, de masquerade niet

De dstnat-regel matcht op de hele LAN-lijst, dus ook op je VLANs. De masquerade matcht op één subnet. Zit je laptop in een VLAN en staat de masquerade op het hoofdnetwerk, dan wordt de bestemming wel vertaald en het afzenderadres niet, en hangt de verbinding op precies de manier die hierboven beschreven staat. Dit is het geval dat het vaakst blijft liggen, omdat het van het ene apparaat wel werkt en van het andere niet.

Het publieke adres zit niet op de router

Staat er een modem in routermodus voor je MikroTik, of zet je provider je achter CGNAT, dan is het publieke adres een adres van een ander apparaat. Een hairpin-regel die op "een adres van deze router" matcht kan dan niets vinden, want het publieke adres is dat niet. Zie Dubbele NAT.

De dienst zelf weigert het

Een NAS met een strikte lijst toegestane netwerken, of een applicatie die zich aan de publieke hostnaam vastklampt, geeft hetzelfde beeld terwijl de router zijn werk gewoon doet.

Wat de configurator hiervan doet

Zodra je in het onderdeel Firewall & NAT één port forward toevoegt, verschijnt de schakelaar Hairpin NAT, en die staat aan. Per forward schrijft het script dan drie regels in plaats van één: de gewone dstnat vanaf WAN, een tweede dstnat met dst-address-type=local en in-interface-list=LAN, en een srcnat-masquerade voor verkeer uit het LAN-subnet naar het interne adres en de interne poort. Alle drie krijgen ze een opmerking, dus je herkent ze terug in /ip firewall nat print.

Wees eerlijk over de grens: die masquerade gebruikt het subnet uit het onderdeel LAN, en alleen dat. Heb je VLANs en zit het apparaat waar je vandaan werkt in een VLAN, dan dekt de meegeleverde regel je niet. Voeg er zelf een tweede masquerade bij met dat VLAN-subnet als src-address, of los het op met DNS in plaats van met NAT.

Die tweede weg is de mooiere, en de tool ondersteunt hem: in het onderdeel DNS kun je Statische DNS-records invullen. Zet daar je publieke hostnaam met het interne adres erbij, dan komt binnen verkeer nooit meer bij de NAT-tabel en heb je van hairpin geen last. Buiten je netwerk blijft de publieke naam gewoon naar het publieke adres wijzen. Zie DNS.

Let nog op één bijwerking van dst-address-type=local: die matcht op elk adres van de router, ook het LAN-adres waar je WebFig op benadert. Forward je poort 443 naar een server en gebruik je HTTPS op de router zelf ook op 443, dan pakt de hairpin-regel dat verkeer mee. Verzet in dat geval de HTTPS-poort in Beheertoegang.

Als het niet aan je router ligt

• De DNS van je client. Een telefoon met DNS over HTTPS omzeilt de statische records van de router. Dan krijgt hij het publieke adres terug en zit je alsnog op hairpin.
• Een modem dat zelf NAT doet. Zet hem in bridge-modus, dan heeft je MikroTik het publieke adres en werkt alles hier.

Verder lezen: Port forwarding, Firewall & NAT en DNS.