25.12.2024

2845

Hairpin-NAT mit Mikrotik Router am Telekom Glasfaseranschluss

Hallo Zusammen,

in schierer Verzweiflung ersuche ich eure Hilfe.

Ich hab einen Mikrotik RB 5009 an einem Telekom Glasfaser Modem. Via PPPoE hängt der MT am Modem (eth1).

Im Netz (172.20.0.0/16) ist ein Webserver mit diversen Diensten (172.20.0.10).

DynDNS habe ich mit einem Skript auf eine Strato-Domain umgesetzt und die entsprechenden Ports auf den Webserver weitergeleitet.

Das funktioniert auch alles von außerhalb.

Jetzt möchte ich, dass ich auch vom internen Netz (172.20.0.0/16) den Webserver via Domain erreichen kann.

Dafür habe ich nach dem offiziellen Video von MT hairpin NAT eingerichtet.

Nur passiert da einfach gar nichts und allem Anschein nach, greift die Regel auch gar nicht.

Das hier ist meine Firewall Config:

/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked  
add action=accept chain=input comment="allow WireGuard" dst-port=13231 protocol=udp  
add action=drop chain=input comment="drop invalid" connection-state=invalid  
add action=accept chain=input comment="accept ICMP" in-interface=pppoe-telekom-fiber protocol=icmp  
add action=accept chain=input comment="allow Winbox" in-interface=pppoe-telekom-fiber port=8291 protocol=tcp  
add action=accept chain=input comment="allow SSH" disabled=yes in-interface=pppoe-telekom-fiber port=22 protocol=tcp  
add action=drop chain=input comment="block everything else" in-interface=pppoe-telekom-fiber  
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-telekom-fiber
add action=masquerade chain=srcnat comment="hairpin NAT" dst-address=172.20.0.10 dst-limit=1,5,dst-address/1m40s limit=1,5:packet log=yes log-prefix=\  
    hairpindebug: out-interface=bridge protocol=tcp psd=21,3s,3,1 src-address=172.20.0.0/16 time=0s-1d,sun,mon,tue,wed,thu,fri,sat
add action=dst-nat chain=dstnat comment="webserver http" dst-port=80 in-interface=pppoe-telekom-fiber protocol=tcp to-addresses=172.20.0.10 to-ports=80  
add action=dst-nat chain=dstnat comment="webserver https" dst-port=443 in-interface=pppoe-telekom-fiber protocol=tcp to-addresses=172.20.0.10 to-ports=443  

Eventuell sieht jemand meinen Fehler.

Viele Grüße

Maximilian

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 670363

Url: https://administrator.de/forum/hairpin-nat-mit-mikrotik-router-am-telekom-glasfaseranschluss-670363.html

Ausgedruckt am: 29.01.2025 um 05:01 Uhr

19 Kommentare

Neuester Kommentar

Hallo,

Zitat von @deadrabbit:
Im Netz (172.20.0.0/16) ist ein Webserver mit diversen Diensten (172.20.0.10).

Woh! kein kleines Netz das du betreust.

Dafür habe ich nach dem offiziellen Video von MT hairpin NAT eingerichtet.

Alles genaustens befolgt?

Nur passiert da einfach gar nichts und allem Anschein nach, greift die Regel auch gar nicht.

Komische Fehlermeldung die du uns nennst.
DNS?
Den Kabelhai mal bemüht?
Kann dein Router ins Internet denn Hairpin?
https://en.wikipedia.org/wiki/Hole_punching_(networking)
https://forum.mikrotik.com/viewtopic.php?t=172380
MikroTik und Hairpin NAT
https://help.mikrotik.com/docs/spaces/ROS/pages/3211299/NAT

Eventuell sieht jemand meinen Fehler.

Schon mal in den diversen Logs geschaut?

Gruss,
Peter

Nach meiner Erfahrung funktioniert Hairpinning nicht mit Mikrotik Routern. Besagtes und hier zitiertes Tutorial funktionierte auch bei mir nicht. Ich habe an stattdessen einen statischen DNS Eintrag auf die interne IP in den Resolver gemacht. Das löste das Problem, auch wenn es nicht professionell und sauber ist.

Zitat von @mossox:

Nach meiner Erfahrung funktioniert Hairpinning nicht mit Mikrotik Routern.

Absoluter Bullshit, sorry. Läuft hier schon seit eh und je einwandfrei.
https://help.mikrotik.com/docs/spaces/ROS/pages/3211299/NAT#NAT-HairpinN ...

add action=masquerade chain=srcnat comment="hairpin NAT" dst-address=172.20.0.10 dst-limit=1,5,dst-address/1m40s limit=1,5:packet log=yes log-prefix=hairpindebug: out-interface=bridge protocol=tcp psd=21,3s,3,1 src-address=172.20.0.0/16 time=0s-1d,sun,mon,tue,wed,thu,fri,sat

Die Limit und PSD und time Parameter haben da nix zu suchen, das ist eh Traffic von intern da macht das ehrlich gesagt auch keinen Sinn...
Also erst mal nur die Basics wie im Link setzen und erst dann weitere Spielereien treiben.

Das hier ist meine Firewall Config

Keinerlei Forward-Chain Regeln ??

out-interface=bridge

Hängen in der Bridge VLANs mit vlan-filtering? Wenn ja muss das interface das entsprechende VLAN-Interface sein, nicht die Bridge selbst.

An deiner Stelle würde ich auch mal über Split-Brain DNS nachdenken, dann ist das für den Router ressourcen aufwendige NATing auch nicht mehr nötig. Also intern die Domain auf die private IP auflösen lassen statt die Externe.

Gruß gastric

Hallo gastric,

das ist kein „Bullshit“.
Es gibt in mehreren Foren unzählige berichtende User, die die Umsetzung exakt so wie in der Dokumentation beschrieben vorgenommen haben und ebenso erfolglos geblieben sind. Und alle habe am Ende schlicht einen statische DNS Eintrag vorgenommen.

Zitat von @mossox:

Hallo gastric,

das ist kein „Bullshit“.
Es gibt in mehreren Foren unzählige berichtende User, die die Umsetzung exakt so wie in der Dokumentation beschrieben vorgenommen haben und ebenso erfolglos geblieben sind.

Das liegt dann zu 99% an den Firewall-Konfigurationen dieser User die eben nicht bei jedem gleich sind, und die sich dann erst mal beschweren, der Fehler dann im Endeffekt aber beim User selbst liegt. Das ist meist normal wenn es sich um komplexere Dinge handelt. Ich kann nur aus eigener jahrelanger Erfahrung mit Mikrotik sagen das die NAT Regeln absolut fehlerfrei arbeiten wenn man sich in das Thema eingearbeitet und vor allem auch den Packetflow verstanden hat läuft das fehlerlos. Das sind absolute Basics und solche Fehler wären schon längst gefixt worden wenn es in dem Bereich welche gäbe, gibt es aber diesbezüglich nicht denn dann wäre das SRC-NAT ja komplett defekt. Kann ich später gerne eine Demo hier posten wenn du willst.

Wenn ja muss das interface das entsprechende VLAN-Interface sein, nicht die Bridge selbst.

Das Mikrotik Tutorial weist ebenso darauf hin!

Keinerlei Forward-Chain Regeln ??

Ich habe mich hierbei auch an die Dokumentation von Mikrotik selbst gehalten.

Leider waren bei meinem Initialbeitrag Fehler drin. Die Limit, PSD und Time Parameter sind aus versehen durch geklicke in der UI entstanden.

Hier nochmal die aktualisierste Version:

/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked  
add action=accept chain=input comment="allow WireGuard" dst-port=13231 protocol=udp  
add action=drop chain=input comment="drop invalid" connection-state=invalid  
add action=accept chain=input comment="accept ICMP" in-interface=pppoe-telekom-fiber protocol=icmp  
add action=accept chain=input comment="allow Winbox" in-interface=pppoe-telekom-fiber port=8291 protocol=tcp  
add action=accept chain=input comment="allow SSH" disabled=yes in-interface=pppoe-telekom-fiber port=22 protocol=tcp  
add action=drop chain=input comment="block everything else" in-interface=pppoe-telekom-fiber  
/ip firewall nat
add action=masquerade chain=srcnat comment="hairpin NAT" dst-address=172.20.0.10 log=yes log-prefix=hairpindebug: src-address=172.20.0.0/16  
add action=masquerade chain=srcnat out-interface=pppoe-telekom-fiber
add action=dst-nat chain=dstnat comment="webserver http" dst-port=80 in-interface=pppoe-telekom-fiber protocol=tcp to-addresses=172.20.0.10 to-ports=80  
add action=dst-nat chain=dstnat comment="webserver https" dst-port=443 in-interface=pppoe-telekom-fiber protocol=tcp to-addresses=172.20.0.10 to-ports=443  

Nein, VLANs sind keine weiteren konfiguriert.

Kann ich später gerne eine Demo hier posten wenn du willst.

Ich denke das wäre sehr hilfreich.

Problem ist das der TO das Quellinterface beim der DST-NAT Regel angibt denn dann matcht diese DST-NAT Regel nicht für den Traffic internen User, folgendermaßen klappt das (X.X.X.X an externe Adresse anpassen)...

/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-telekom-fiber
add action=dst-nat chain=dstnat comment="webserver http(s)" dst-address=X.X.X.X dst-port=80,443 protocol=tcp to-addresses=172.20.0.10  
add action=masquerade chain=srcnat comment="hairpin NAT" dst-address=172.20.0.10 out-interface=bridge src-address=172.20.0.0/16  

Also entweder nur DST-Addresse angeben wie oben oder zusätzliche Regeln definieren die auch das DST-NATen von internen interfaces macht.

Wenn du die externe Adresse nicht angeben willst/kannst (wegen dynamischer IP), arbeite alternativ mit einer Interface-Liste

/interface list 
add name=PORT-FORWARD-LIST

/interface list member
add interface=pppoe-telekom-fiber list=PORT-FORWARD-LIST
add interface=bridge list=PORT-FORWARD-LIST

/ip firewall address-list
add address=192.168.0.0/16 list=RFC1918
add address=10.0.0.0/8 list=RFC1918
add address=172.16.0.0/12 list=RFC1918

/ip firewall nat
add chain=srcnat out-interface=pppoe-telekom-fiber action=masquerade
add chain=dstnat protocol=tcp dst-port=80,443 dst-address-list=!RFC1918 dst-address-type=local in-interface-list=PORT-FORWARD-LIST action=dst-nat to-addresses=172.20.0.10
add chain=srcnat src-address=172.20.0.0/16 dst-address=172.20.0.10 out-interface=bridge action=masquerade

Das klappt im Test einwandfrei mit einem aktuellen RouterOS 7.16.2 stable.

Besser ist es wie gesagt immer mit Split-DNS zu arbeiten weil schneller.

@151183

Vielen Dank, das war die Ursache.

Ich kann aber bei deiner Config ja keine dst-address angeben, da diese nicht statisch ist?

Zitat von @deadrabbit:
Ich kann aber bei deiner Config ja keine dst-address angeben, da diese nicht statisch ist?

Die Alternative für dynamische IPs habe ich oben noch ergänzt.

Vielen Dank! Deine Erläuterung dazu macht Sinn - Ich habe Tutorials gefunden wo eben mit den Listen gearbeitet wird, was ich aber erst mal nicht verstanden habe.

Danke auch für den Hinweis mit Split-DNS. Schau ich mir mal an...

👍
Dann bleibt ja nur noch frohe Weihnachtstage und ein gutes Neues zu wünschen!

Sorry, anscheinen war es das doch noch nicht.

Wenn ich das richtig verstehe, hast du alle privaten Adressen in einer Liste zusammengefasst und diese von der NAT-Regel ausgenommen.

So funktioniert zwar das hairpinning, aber ich komme auch sonst nicht mehr ins Internet.

So sieht meine Konfiguration jetzt aus:

/interface list member
add interface=pppoe-telekom-fiber list=PORT-FORWARD-LIST
add interface=bridge list=PORT-FORWARD-LIST

/ip firewall address-list
add address=172.16.0.0/12 list=RFC1918
add address=10.0.0.0/8 list=RFC1918
add address=192.168.0.0/16 list=RFC1918

/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked  
add action=accept chain=input comment="allow WireGuard" dst-port=13231 protocol=udp  
add action=drop chain=input comment="drop invalid" connection-state=invalid  
add action=accept chain=input comment="accept ICMP" in-interface=pppoe-telekom-fiber protocol=icmp  
add action=accept chain=input comment="allow Winbox" in-interface=pppoe-telekom-fiber port=8291 protocol=tcp  
add action=accept chain=input comment="allow SSH" disabled=yes in-interface=pppoe-telekom-fiber port=22 protocol=tcp  
add action=drop chain=input comment="block everything else" in-interface=pppoe-telekom-fiber  

/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-telekom-fiber
add action=dst-nat chain=dstnat comment="webserver http(s)" dst-address-list=!RFC1918 dst-port=80,443 in-interface-list=PORT-FORWARD-LIST protocol=tcp to-addresses=172.20.0.10  
add action=masquerade chain=srcnat comment="hairpin NAT" dst-address=172.20.0.10 out-interface=bridge src-address=172.20.0.0/16  

🙈 Sorry, das dst-address-type=local ist mir beim copy n paste untergegangen, ist oben ergänzt.

Hier die Regel nochmal für dein Verständnis als Text beschrieben

add chain=dstnat protocol=tcp dst-port=80,443 dst-address-list=!RFC1918 dst-address-type=local in-interface-list=PORT-FORWARD-LIST action=dst-nat to-addresses=172.20.0.10

TCP Traffic auf Port 443/80 der an einem der Interfaces der Liste "PORT-FORWARD-LIST" eintrifft, und an eine Adresse geht die "keine (!)" private IP-Adresse ist und einem Interface des Routers zugeordnet ist, dessen Zieladresse wird zu 172.20.0.10 umgeschrieben.

Herzlichen Dank auch nochmal für die Erkärung.

Hairpin NAT geht jetzt, aber dafür funktioniert das WireGuad VPN nicht mehr, ich vermute hier einen Zusammenhang mit dst-address-type=local?

Kann das sein?

Zitat von @deadrabbit:
Hairpin NAT geht jetzt, aber dafür funktioniert das WireGuad VPN nicht mehr, ich vermute hier einen Zusammenhang mit dst-address-type=local?

Kann das sein?

Nein. Wireguard läuft über UDP die Regel kann also bei Wireguard aus Prinzip niemals matchen. Läuft hier im Test auch einwandfrei im Zusammenhang mit mehreren Wireguard Tunneln.

"dst-address-type=local" bedeutet nur das der Matcher nur eine Adresse des Routers selbst matcht.
Kannst du hier nachlesen: Comon firewall matchers

local - if dst-address is assigned to one of the router's interfaces

Da die Regel bei Wireguard aber wegen UDP eh nicht matcht kann dieser nicht die Ursache bei dir sein.

Stimmt, das mit UPD hatte ich vergessen.

Merkwürdig. Ich habe festgestellt, dass der Tunnel grundsätzlich funktioniert, aber ich komme nicht mehr auf den Server wenn der VPN aktiv ist. Auch nicht auf eine VM die auf dem Server läuft und eine eigene IP hat.

Auf alle anderen Netzwerkteilnehmer schon.

Zitat von @deadrabbit:
Merkwürdig. Ich habe festgestellt, dass der Tunnel grundsätzlich funktioniert, aber ich komme nicht mehr auf den Server wenn der VPN aktiv ist. Auch nicht auf eine VM die auf dem Server läuft und eine eigene IP hat.

Wie greifst du von innerhalb des Tunnels auf den Server zu? Per Domain-Name oder mit direkter interner IP des Servers? Wenn per Domain-Name dann musst du das Wireguard-Interface selbstverständlich auch mit in die Interface-Liste aufnehmen wenn du sämtlichen Internet-Traffic über den Tunnel leitest da ja ansonsten das DST-NAT nicht greifen kann

. Die Interface-Liste ist auch nur Optional um das NAT zusätzlich pro Interface einzuschränken, zwingend nötig ist sie nicht.

Ansonsten haben die Regeln damit nichts zu tun. Ohne eine Gesamtübersicht deiner Config bzw. des Servers aus welchen Subnetzen dieser bspw. Traffic firewall technisch zulässt ist das hier Glaskugel polieren und auch nicht mehr Thema des Threads.

Nein, das ist mir klar. Mit der internen IP des Servers.

Es antworten alle Geräte - mit Ausnahme des Servers und dessen VM.

Ja, damit hast du recht, aber ich bin mir an dieser Stelle aktuell relativ sicher, dass ich da selbst drauf komme.

Aber herzlichen Dank an dieser Stelle nochmal an deine super Unterstützung sowieso schöne Feiertage und einen guten Rutsch.

gelöst Frage Router, Routing DNS

Mehr von deadrabbit

Mikrotik Wireguard VPNdeadrabbit - 20 Kommentare

Heiß diskutiert