27.12.2024

2398

Mikrotik Wireguard VPN

Hallo,

wie hier schon angedeutet, komme ich nicht auf meinen Server via WireGuard.

Grundsätzliches zu meinem Aufbau:

Ein RB5009 stellt über ein Glasfaser-Modem (PPPoE) der Telekom eine Verbindung zum Internet her.

export hide-sensitive
/interface bridge
add name=bridge
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface vlan
add interface=ether1 name=vlan7-pppoe vlan-id=7
/interface pppoe-client
add add-default-route=yes allow=pap,chap,mschap2 disabled=no interface=vlan7-pppoe name=pppoe-telekom-fiber profile=default-encryption user=XXXXXXX@t-online.de
/interface list
add name=PORT-FORWARD-LIST
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
add bridge=bridge interface=ether6
add bridge=bridge interface=ether7
add bridge=bridge disabled=yes interface=ether8
add bridge=bridge interface=sfp-sfpplus1
/interface detect-internet
set detect-interface-list=all
/interface list member
add interface=pppoe-telekom-fiber list=PORT-FORWARD-LIST
add interface=bridge list=PORT-FORWARD-LIST
add interface=bridge list=LAN
add interface=wireguard1 list=LAN
/interface wireguard peers
add allowed-address=10.9.0.2/32 interface=wireguard1 name=Poco public-key="XXXXXXX"  

Jetzt ist es so, dass die Wireguard Verbindung als Road Warrior grundsätzlich funktioniert. Ich komme auf alle Geräte in meinem lokalen Netz (172.20.0.0/16), mit Ausnahme des Servers und dessen virtuelle Maschine.

Dieser ist ein Ubuntu Server mit einer VM mit Home Assistant. Der Server selbst hat die IP 172.20.0.10 und die VM 172.20.0.30.

Pinge ich den Server, kommt der Ping zwar an, wird jedoch nicht beantwortet:

Mache ich das gleiche mit einer anderen IP, funktioniert es wie erwartet:

Die Firewall und NAT-Regeln sehen wie folgt aus:

/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=accept chain=input comment="allow WireGuard traffic" src-address=10.9.0.0/24  
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-address-type=local 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  

Ich denke, meine WireGuard Konfiguration ist an dieser Stelle nicht notwendig, da der Tunnel ja grundsätzlich funktioniert.

Leider fehlt mir irgendwie das Wissen und Können um hier den Fehler zu finden.

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

Content-ID: 670379

Url: https://administrator.de/forum/mikrotik-wireguard-vpn-670379.html

Ausgedruckt am: 27.01.2025 um 17:01 Uhr

20 Kommentare

Neuester Kommentar

Wenn der Ping am Mikrotik richtung Server raus geht aber nichts zurück kommt, ist das Problem am Server zu suchen, nicht am Mikrotik. Also entweder die Firewall am Server selbst oder falsches Routing/Default-GW am Server selbst.
Mach also mal ein Wireshark Capture am Server.

Nur mal so nebenbei, du hast keinerlei Forward-Chain Regeln in der Firewall, das Teil ist also offen wie ein Scheunentor, sowas ans Internet zu hängen ist schon ziemlich fahrlässig.Da tummelt sich bestimmt schon so einiges Ungetüm in deinem Netz ..

add action=accept chain=input comment="allow Winbox" in-interface=pppoe-telekom-fiber port=8291 protocol=tcp

Und selbst Winbox am WAN aufzumachen ist schon echt derb.... Da kann man nicht mehr viel dazu sagen 🙊🙊🙊

Leider fehlt mir irgendwie das Wissen und Können um hier den Fehler zu finden.

Deswegen besser erst nochmal die Grundlagen üben und dann erst die Praxis. Ansonsten als erstes ein wasserdichtes Firewall-Regelwerk nehmen und darauf aufbauen.
https://help.mikrotik.com/docs/spaces/ROS/pages/328513/Building+Advanced ...

Gruß gastric

Damit hast du bestimmt recht, aber irgendwie muss ich ja mal anfangen und grundsätzlich will ich damit ja mal lernen.

Ich hatte die Regeln von der MT Dokumentation. Die öffnen an dieser Stelle auch die entsprechenden Ports. SSH habe ich aus diesem Grund ohnehin schon deaktiviert.

Pinge ich den Server, kommt der Ping zwar an, wird jedoch nicht beantwortet:

Kollege @gastric hat es ja oben schon beantwortet. Bei einem solchen Ping ist es oftmals wichtig eine dedizierte IP Adresse als Absender mitzugeben. In sofern kann es Sinn machen im Reiter "Advanced" des Ping Menüs auch eine dedizierte Absender IP eines MT Interfaces mitzugeben. Ansonsten wird willkürlich eine je nach IP Adressierung genommen was dann den Ping wegen ggf. fehlender Routen usw. scheitern lässt, ganz besonders im VPN Umfeld. Das solltest du also beachten.
Der Ping Fehler oben ist also de facto am Server selber zu sehen. Ggf. fehlt dort die Default Route auf den MT im Netzwerk Setup?! Auch tcpdump (auch hier) am Server kann helfen zu checken was genau mit den ICMP Paketen (Ping) am Server passiert!

Zu den Sicherheitsfehlern der Firewall hat Kollege @gastric ja schon deutliche Worte gefunden.
Wenn du hier unsicher bist reboote den MT und belasse die Default Konfig auf dem Router. Der richtet eine wasserdicht arbeitende Firewall mit entsprechenden Regeln und NAT am ether1 Port ein die du dann einfach nur erweitern bzw. auf deine Belange customizen musst. Wenn man unsicher ist, ist das immer eine sichere Bank.
Was du auch machen kannst ist, wie oben schon angesprochen, diese Default FW Settings einfach in deine bestehende Konfig zu übernehmen.

Danke an dieser Stelle auf jeden Fall für den Hinweis.

Auch wenn das OT ist, erlaube ich mir jetzt trotzdem mal meinen Stand zu zeigen:

/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=drop chain=input comment="WAN -> FW | Ping blockieren" in-interface=pppoe-telekom-fiber protocol=icmp  
add action=accept chain=input comment="ALLG. | Aufgebaute Verbindungen erlauben" connection-state=established  
add action=accept chain=input comment="ALLG. | Aufgebaute Verbindungen erlauben" connection-state=related  
add action=accept chain=input comment="LAN -> FW | Zugriff zur Firewall erlauben" in-interface=bridge  
add action=accept chain=input comment="allow WireGuard" dst-port=13231 protocol=udp  
add action=accept chain=input comment="allow WireGuard traffic" src-address=10.9.0.0/24  
add action=drop chain=input comment="ALLG. | Alle ohne Verbindungsstatus blockieren"  
add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben"  
add action=accept chain=forward comment="LAN -> WAN | Internetzugriff" in-interface=bridge out-interface=pppoe-telekom-fiber  
add action=drop chain=forward comment="ALLG. | Alles andere verwerfen"  
/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-address-type=local 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  

M.E. sollte das jetzt passen. Zumindest sind keine Ports, bis auf 80 und 443, mehr offen, wenn ich da mit nmap drauf schaue.

Nö, genauso offen wie vorher da fehlt der state und first match wins.

add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben"

Und wenn du die Forward Chain am Ende komplett zu machst musst du immer an alle Verbindungen denken, seinen es DST-NATs oder Traffic der aus dem VPN an andere Stationen geht. Deswegen sag ich ja Firewall Grundlagen zu den Chains sind unerlässlich wenn du selbst das Regelwerk bauen willst, ansonsten wie oben verlinkt die Firewall Config Seite von Mikrotik durchlesen .

Bau mal im Lab von Hand mit iptables oder nftables eine Firewall auf, denn im Grunde ist die Mikrotik Firewall gleich aufgebaut wie die.

Unerlässlich fürs Verständnis des Regelwerkes ist diese Seite
https://help.mikrotik.com/docs/spaces/ROS/pages/328227/Packet+Flow+in+Ro ...

Guck vielleicht besser mal hier:
https://help.mikrotik.com/docs/spaces/ROS/pages/328513/Building+Advanced ...

Dann ist dieses Video also nonsens?

Ich werde mal mit der Default-Konfiguration komplett von vorne beginnen...

Zitat von @deadrabbit:

Dann ist dieses Video also nonsens?

Wenn du die Hälfte nicht richtig übernimmst, tja 🤷. Ich kann nur von solchen Videos abraten. Wenn du von sowas nur abkupferst, lernst du nichts. Besser ist es wenn man von Grund auf das Chain-System auch versteht dann kann man sich später auch selbst helfen und steht nicht wie ein Ochs vorm Berg wenn mal was nicht so will wie man selbst.

Ich werde mal mit der Default-Konfiguration komplett von vorne beginnen...

Besser ist das nur wenn man sich selbst etwas anstrengen muss lernt man auch nachhaltig..
Die Lernkurve beim Mikrotik ist sehr steil, aber die Investition lohnt sich, glaub's mir.

Ich versuche nach wie vor, den Fehler in meiner obigen Config zu finden.

Mir ist klar, dass ich in Zeile 13 alle eingehenden Verbindungen erlaube. Aber davor (Zeile 12) ist doch eine Drop Rule?

Nach meinem Verständnis wird das hier und hier auch so gemacht.

Nochmal, so wie ich meine Regeln oben verstehe:

Zeile 6: Pings am WAN werden gedropt
Zeile 7+8: Verbindungen mit dem Status established und related werden erlaubt
Zeile 9: Verbindungen von jedem Netzwerkport (Ausnahme eth1 da WAN) zum Router werden erlaubt.
Zeile 10+11: UDP Verbindungen auf den WireGuard VPN Port 13231 werden erlaubt. Außerdem wird der Traffic von dem IP Adressraum 10.9.0.0/24 erlaubt, was das WireGuard Netz ist.
Zeile 12: Alle Pakete die bis hierhin gekommen sind, werden gedropt.
Zeile 13: Was bis hierher gekommen ist, wird erlaubt und weitergeleitet.
Zeile 14: Zugriff vom LAN nach WAN wird erlaubt
Zeile 15: Alles weitere wird verworfen

Weiterhin habe ich die Services auf ein notwendiges reduziert und auch sonst die Hinweise hier befolgt.

Könnt ihr mir nochmal einen Hinweis geben, wo ich meinen Fehler nicht sehe?

Oder fehlt mir hier grundsätzlich noch etwa zum Verständnis?

Zitat von @deadrabbit:
Mir ist klar, dass ich in Zeile 13 alle eingehenden Verbindungen erlaube. Aber davor (Zeile 12) ist doch eine Drop Rule?

Nein, INPUT und FORWARD Chain sind zwei vollkommen unterschiedliche Dinge!! INPUT definiert alles was an den Router selbst geht, FORWARD das was den Router nur passiert, das Ziel also nicht der Router selbst ist!

Nochmal, so wie ich meine Regeln oben verstehe:

Zeile 6: Pings am WAN werden gedropt

OK, macht aber heutzutage ehrlich gesagt keinen großen Sinn mehr das zu droppen. Hacker hält es nicht auf und für Debugzwecke fehlt es einem dann im Zweifel selbst.

* Zeile 7+8: Verbindungen mit dem Status established und related werden erlaubt

OK, kannst du aber beides zu einer einzigen Regel zusammenfassen indem du die States alle in einer Regel angibst.

* Zeile 9: Verbindungen von jedem Netzwerkport (Ausnahme eth1 da WAN) zum Router werden erlaubt.

OK.

* Zeile 10+11: UDP Verbindungen auf den WireGuard VPN Port 13231 werden erlaubt.

Außerdem wird der Traffic von dem IP Adressraum 10.9.0.0/24 erlaubt, was das WireGuard Netz ist.

Da diese Regel in der INPUT Chain liegt betrifft das nur Traffic der auf den Router selbst geht nicht auf andere Geräte im Netz!

* Zeile 12: Alle Pakete die bis hierhin gekommen sind, werden gedropt.

Aber nur die die an den Router selbst gehen.

* Zeile 13: Was bis hierher gekommen ist, wird erlaubt und weitergeleitet.

Nein, die Forward-Chain ist eine separate Chain und vollkommen getrennt von der INPUT Chain. Mit deiner Regel erlaubst du quasi das Durchrouten auch aus dem Internet aus weil deine Regel, ich zitiere sie hier nochmal

add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben"  

keinerlei Matches hat (du hast da keinerlei Connection-State angegeben). Das Forwarding lässt man ebenfalls nur in "established,related,untracked" zu und natürlich aus dem internen Netz, von extern sollte das immer gedroppt werden, außerdem muss auch eventuell via Port-Forwarding (DST-NAT) weitergeleiteter Traffic die Forward-Chain passieren und dort ebenfalls zugelassen werden. Das macht man in der Regel so das man eine generische Regel in der Forward Chain anlegt die den Matcher "connection-nat-state=dstnat" verwendet.

/ip firewall filter add action=accept chain=forward comment="allow dstnated traffic"  in-interface=pppoe-telekom-fiber connection-nat-state=dstnat  

* Zeile 14: Zugriff vom LAN nach WAN wird erlaubt

* Zeile 15: Alles weitere wird verworfen

Oder fehlt mir hier grundsätzlich noch etwa zum Verständnis?

Offensichtlich hast du noch Verständnisprobleme was FORWARD und INPUT sind, deswegen habe ich dir oben die Seite zum Paket-Flow verlinkt, damit wird der Traffic flow verständlicher. Dieser ist essentiell wenn man Firewall Regeln baut.

Danke für deine Erläuterung.

Das lässt mich aber nach wie vor zu dem Schluss kommen, dass das

Dann ist dieses Video also nonsens?

hier Mist ist.

Hier wird nämlich auch die Regel für die Input Chain ohne State angegeben.

Hier auch die Stelle mit Zeitstempel, damit nicht alles angesehen werden muss.

Hier wird definitiv kein State angegeben und es gibt auch vorher noch keine Rule mit Forward Chain.

Ich habe aber das Gefühlt, dass es schön langsam wird.

Surprise, surprise, mit dem Setzen von established, related und untracked bekommt jetzt auf einmal auch die letzte Drop Regel mit der Forward Chain etwas ab...

Zitat von @deadrabbit:

Danke für deine Erläuterung.

Das lässt mich aber nach wie vor zu dem Schluss kommen, dass das

Dann ist dieses Video also nonsens?

hier Mist ist.

Nicht alles, aber zum Teil, wurde nicht ganz zu Ende gedacht.

Hier wird nämlich auch die Regel für die Input Chain ohne State angegeben.

Es gibt bei einer Statefull-Firewall im INPUT und FORWARD immer eine Related,Established Rule, für jede Chain eine separate, denn diese stellen sicher das Traffic der rausfließt und aufgebauten Verbindungen zugeordnet wird auch wieder rein darf!!
Die letzte Regel für das generelle Dropping am Ende kann natürlich ohne State angelegt werden.

Hier auch die Stelle mit Zeitstempel, damit nicht alles angesehen werden muss.

Hier wird definitiv keine State angegeben und es gibt auch vorher noch eine Rule mit Forward Chain.

Das ist definitv Mist ... Deswegen sag ich ja, kein Copy n Paste aus solchen Videos.

Nur was man selbst gefälscht hat ist selbst gefälscht. 😉

Schau dir doch einfach das Mikrotik Standardregelwerk an und Versuche jede Regel davon zu verstehen, dann siehst du wie es richtig geht, und lass das mit den Videos, die sind 🤮 und lernst du nichts von, denn sonst hättest du zumindest meine Links von oben schon mal durchgelesen, hast du aber leider nicht und hängst immer noch wie ein Tropf am Video 😕 ...

Schau dir doch einfach das Mikrotik Standardregelwerk an und Versuche jede Regel davon zu verstehen, dann siehst du wie es richtig geht, und lass das mit den Videos, die sind 🤮 und lernst du nichts von, denn sonst hättest du zumindest meine Links von oben schon mal durchgelesen, hast du aber leider nicht und hängst immer noch wie ein Tropf am Video 😕 ...

Es ist nicht so, dass ich das nicht tue. Es ist nur so, dass mir es über die Videos gerade leichter fällt.

Irgendwie fehlte mir bis jetzt das gewisse Grundverständnisse um die von dir verlinkten Regelwerke überhaupt im Ansatz zu verstehen.

Hallo,

kleine Zwischenfrage.

M.E. sollte das jetzt passen. Zumindest sind keine Ports, bis auf 80 und 443, mehr offen, wenn ich da mit nmap drauf schaue.

Wo läuft der nmap? Bei dir Zuhause? Im Internet?

Grüße

Wo läuft der nmap? Bei dir Zuhause?

🤣

Im Internet.

@Visucius

??

hast du aber leider nicht und hängst immer noch wie ein Tropf am Video 😕 ...

Ich habe es jetzt mehrmals versucht, die Doku zu verstehen. Ganz ist mir das aber noch nicht gelungen, da muss ich es nochmal ein paar mal durchlesen. Dinge wie fasttrack und fastpath habe ich jetzt ohnehin mal außen vor gelassen.

Allerdings geht es leider immer noch nicht, so wie es sein sollte.

Hier jetzt meine Konfiguration:

/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="ALLG. | Aufgebaute Verbindungen erlauben \"established, related\"" \  
    connection-state=established,related
add action=accept chain=input comment="LAN -> FW | Zugriff zur Firewall erlauben" in-interface=bridge  
add action=accept chain=input comment="VPN | WireGuard Port erlauben" dst-port=13231 protocol=udp  
add action=accept chain=input comment="VPN | WireGuard Traffic zum Router erlauben" connection-state="" \  
    src-address=10.9.0.0/24
add action=accept chain=forward comment="VPN | WireGuard -> LAN erlauben" connection-state=established,related \  
    in-interface=bridge out-interface=wireguard1
add action=drop chain=input comment="ALLG. | Alle ohne Verbindungsstatus blockieren"  
add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben" connection-state=\  
    established,related,untracked
add action=accept chain=forward comment="WEBSERVER | dstnat erlauben" connection-nat-state=dstnat \  
    connection-state="" in-interface=pppoe-telekom-fiber  
add action=accept chain=forward comment="WEBSERVER | Hairpin NAT erlauben" dst-address=172.20.0.10 in-interface=\  
    bridge out-interface=bridge
add action=accept chain=forward comment="LAN -> WAN | Internetzugriff" connection-state="" in-interface=bridge \  
    out-interface=pppoe-telekom-fiber
add action=drop chain=forward comment="ALLG. | Alles andere verwerfen"  
/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-address-type=local \  
    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

So funktioniert auch Hairpin NAT wieder, wobei ich mir unsicher bin, ob diese Regel dazu:

add action=accept chain=forward comment="WEBSERVER | Hairpin NAT erlauben" dst-address=172.20.0.10 in-interface=\  
    bridge out-interface=bridge

korrekt ist. Mir leuchtet es nicht ein, warum ich da bei out- und in-interface die bridge angeben muss.

Außerdem geht nach wie vor nix was den Tunnel angeht. Der Aufbau und Handshake passen auch und den Router selbst kann ich auch anpingen. Was m.E. wegen der input chain funktionert.

Die anderen IP Adressen gehen leider nicht, obwohl das mit dieser Regel meines erachtens aber funktionieren müsste:

add action=accept chain=forward comment="VPN | WireGuard -> LAN erlauben" connection-state=established,related \  
    in-interface=bridge out-interface=wireguard1

Ich hatte diese auch mal mit den IP-Adressbereichen bestückt anstelle der Interfaces, aber auch dies hat nicht funktioniert.

Wo habe ich da noch einen Denkfehler?

Wo habe ich da noch einen Denkfehler?

Leider noch diverse Fehler vorhanden. Hauptsächlich die leeren Felder für den "connection-state", wenn du da "nichts" einträgst heißt das nicht das sie nicht wirken, wenn du sie nicht im Filter benutzen willst musst du sie auch ganz "zurücksetzen", also entweder in der Winbox den Pfeil rechts neben der jeweiligen Einstellung nach oben anklicken oder in der Konsole die Property mittels unset Befehl aus der jeweiligen Regel entfernen ansonsten wirken die weiterhin und machen dir die Regel kaputt indem sie eben nicht zutrifft!!

Hier ein minimales getestetes Regelset mit dem du keine Probleme bei deinem absoluten Basic-Setup haben wirst. Wenn doch, hast du es nicht richtig/fehlerhaft umgesetzt bzw. noch weitere Leichen in deiner Konfiguration wenn du das Schema mit den Properties noch nicht in Gänze verstanden hast, leider sehen wir hier immer noch nicht in gänze sondern nur Ausschnitte was keine Komplettbewertung zulässt.

/interface list
add name=LAN
add name=WAN

/interface list member
add interface=bridge list=LAN
add interface=wireguard1 list=LAN
add interface=pppoe-telekom-fiber list=WAN

/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
add address=172.20.0.0/16 list=LAN_NET

/ip firewall filter
# INPUT chain
add action=accept chain=input comment="ALLG. | Aufgebaute Verbindungen erlauben \"established, related\"" connection-state=established,related  
add action=drop chain=input comment="ALLG. | Block invalid input" connection-state=invalid  
add action=accept chain=input comment="LAN/VPN -> FW | Zugriff zur Firewall erlauben" in-interface-list=LAN  
add action=accept chain=input comment="VPN | WireGuard Port vom WAN aus erlauben" dst-port=13231 protocol=udp in-interface-list=WAN    
add action=drop chain=input comment="ALLG. | Alle ohne Verbindungsstatus blockieren"  
# FORWARD chain
add action=fasttrack-connection chain=forward connection-mark=no-mark comment="Fasttrack" connection-state=established,related hw-offload=yes  
add action=accept chain=forward comment="ALLG. | Aufgebaute Verbindungen erlauben" connection-state=established,related,untracked  
add action=drop chain=forward comment="ALLG. | Block invalid forward" connection-state=invalid  
add action=accept chain=forward comment="WEBSERVER | dstnat erlauben" connection-nat-state=dstnat in-interface-list=WAN  
add action=accept chain=forward comment="LAN -> WAN | Internetzugriff" in-interface-list=LAN  
add action=drop chain=forward comment="ALLG. | Alles andere verwerfen"  

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN comment="masquerade on WAN"  
add action=dst-nat chain=dstnat comment="Portforwarding to webserver http(s)" dst-address-list=!RFC1918 dst-address-type=local 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-list=LAN src-address-list=LAN_NET  

Now it's your turn. Einen Schritt nach dem anderen nicht einen und dann x überspringen, dann wird da auch was draus.

I'm out now. Bei Bedarf biete ich aber auch gerne prof. Mikrotik-Support gegen Aufwandsentschädigung.

Good Luck und guten Rutsch.
🖖

Danke - damit funktioniert es.

Und es hat sich auch herausgestellt, dass der Server wegen fehlender Routen nicht erreichbar war.

Nachdem ich diese ergänzt habe, funktioniert alles.

gelöst Frage MikroTik VPN

Mehr von deadrabbit

Hairpin-NAT mit Mikrotik Router am Telekom Glasfaseranschlussdeadrabbit - 19 Kommentare

Heiß diskutiert