12
Mikrotik port forwarding über VPN
Moin moin!
Ich habe zu Hause einen Mikrotik RB4011iGS mit der neusten Betaversion 7.1beta6 damit ich WireGuard testen kann. Außerdem habe ich ein Synology NAS mit ein paar Docker Containern, die ich von außerhalb erreichen möchte wie z.B. Nextcloud.
Auf der anderen Seite habe ich eine kleine virtuelle Maschine von Hetzner.
Aufbau also wie folgt:
Hetzner VM (WG Server) --> Mikrotik Router (WG client) --> NAS
Mein Problem ist das es manchmal funktioniert und manchmal nicht, obwohl ich nichts ändere. Der Webserver auf dem NAS ist über den Browser nicht erreichbar. Zumindest erhalte ich nur "ERR_TIMED_OUT".
Die WG server config sieht wie folgt aus:
Ich leite also die Ports für einen Webserver weiter.
Auf dem Router zu Hause habe ich den Client entsprechend eingerichtet. Server 192.168.201.1 kann den Client 192.168.202.2 pingen und umgekehrt.
Auf meinem Router habe ich sonst noch folgendes:
Ich markiere also alle eingehenden Verbindungen. Damit ich diese später wieder über das wg Interface zurück Routen kann. Mittels DNAT leite ich die beiden Ports an mein NAS weiter (192.168.1.11). Alles, was die Markierung hat, setzte ich auch die routing Markierung. Mit einer statischen Route, route ich dann diesen Traffic auch wieder über den wg Tunnel. Zumindest ist das der Plan.
Wenn ich jetzt nextcloud.domain.tld (Domain hat den A Eintrag auf die VPS IP) aufrufe erhalte ich nur "ERR_TIMED_OUT". Ich sehe aber das meine MANGLE regeln "zuschlagen".
Wenn ich logging für die Regel
Aktiviere, sehe ich Folgendes:
Wenn ich das sehe, sieht das doch richtig aus. Webserver antwortet, NAT schickt das ganze wieder an das WG Interface und dann ist es doch schon wieder in der "Freien Welt" Oder sehe ich das falsch?
Kann mir jemand auf die Sprünge helfen, was ich vergesse?
Schönes Wochenende ;)
Ich habe zu Hause einen Mikrotik RB4011iGS mit der neusten Betaversion 7.1beta6 damit ich WireGuard testen kann. Außerdem habe ich ein Synology NAS mit ein paar Docker Containern, die ich von außerhalb erreichen möchte wie z.B. Nextcloud.
Auf der anderen Seite habe ich eine kleine virtuelle Maschine von Hetzner.
Aufbau also wie folgt:
Hetzner VM (WG Server) --> Mikrotik Router (WG client) --> NAS
Mein Problem ist das es manchmal funktioniert und manchmal nicht, obwohl ich nichts ändere. Der Webserver auf dem NAS ist über den Browser nicht erreichbar. Zumindest erhalte ich nur "ERR_TIMED_OUT".
Die WG server config sieht wie folgt aus:
[Interface]
Address = 192.168.201.1/24
ListenPort = 51820
PrivateKey = xxx
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
#Portforwarding
PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.201.2
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.201.2
[Peer]
PublicKey = xxx
AllowedIPs = 192.168.201.2/32Auf dem Router zu Hause habe ich den Client entsprechend eingerichtet. Server 192.168.201.1 kann den Client 192.168.202.2 pingen und umgekehrt.
Auf meinem Router habe ich sonst noch folgendes:
/ip firewall
nat add action=masquerade chain=srcnat out-interface=wg_vps
/ip firewall mangle
add action=mark-connection chain=prerouting comment="WG VPS" in-interface=wg_vps new-connection-mark=conn_wg_vps passthrough=no
add action=mark-routing chain=prerouting connection-mark=conn_wg_vps in-interface=!wg_vps passthrough=no
add action=mark-routing chain=output connection-mark=conn_wg_vps passthrough=no
/ip firewall nat
add action=dst-nat chain=dstnat comment=nas1 dst-port=80,443 in-interface=wg_vps protocol=tcp to-addresses=192.168.1.11
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=wg_vps pref-src="" routing-table=wg_vps scope=30 suppress-hw-offload=no target-scope=10 Ich markiere also alle eingehenden Verbindungen. Damit ich diese später wieder über das wg Interface zurück Routen kann. Mittels DNAT leite ich die beiden Ports an mein NAS weiter (192.168.1.11). Alles, was die Markierung hat, setzte ich auch die routing Markierung. Mit einer statischen Route, route ich dann diesen Traffic auch wieder über den wg Tunnel. Zumindest ist das der Plan.
Wenn ich jetzt nextcloud.domain.tld (Domain hat den A Eintrag auf die VPS IP) aufrufe erhalte ich nur "ERR_TIMED_OUT". Ich sehe aber das meine MANGLE regeln "zuschlagen".
Wenn ich logging für die Regel
/ip firewall mangle add action=mark-routing chain=prerouting connection-mark=conn_wg_vps in-interface=!wg_vps passthrough=noAktiviere, sehe ich Folgendes:
prerouting: in:vlan1 out:(unknown 0), src-mac 00:xx, proto TCP (ACK), 192.168.1.11:443->94.xx.xx.xx:43378, NAT (192.168.1.11:443->192.168.201.2:443)->94.xx.xx.xx:43378, len 1500Kann mir jemand auf die Sprünge helfen, was ich vergesse?
Schönes Wochenende ;)
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1155822444
Url: https://administrator.de/forum/mikrotik-port-forwarding-ueber-vpn-1155822444.html
Ausgedruckt am: 25.12.2024 um 16:12 Uhr
12 Kommentare
Neuester Kommentar
Grüße.
Doofe Frage: Wieso gibst du die IP deiner NAS nicht dem Peer (WG-Client) mit und trägst diese in die Config ein?!
Dann könntest vom VPS Server doch direkt auf die NAS IP verweisen?! Ein Reverse Proxy auf deinem VPS würde dann den Rest erledigen?!
Die Config deines Clients wäre fürs Verständnis noch super
Doofe Frage: Wieso gibst du die IP deiner NAS nicht dem Peer (WG-Client) mit und trägst diese in die Config ein?!
Dann könntest vom VPS Server doch direkt auf die NAS IP verweisen?! Ein Reverse Proxy auf deinem VPS würde dann den Rest erledigen?!
Die Config deines Clients wäre fürs Verständnis noch super
Zitat von @incisor2k:
Grüße.
Doofe Frage: Wieso gibst du die IP deiner NAS nicht dem Peer (WG-Client) mit und trägst diese in die Config ein?!
Dann könntest vom VPS Server doch direkt auf die NAS IP verweisen?! Ein Reverse Proxy auf deinem VPS würde dann den Rest erledigen?!
Die Config deines Clients wäre fürs Verständnis noch super
Grüße.
Doofe Frage: Wieso gibst du die IP deiner NAS nicht dem Peer (WG-Client) mit und trägst diese in die Config ein?!
Dann könntest vom VPS Server doch direkt auf die NAS IP verweisen?! Ein Reverse Proxy auf deinem VPS würde dann den Rest erledigen?!
Die Config deines Clients wäre fürs Verständnis noch super
Ich bin mir nicht sicher, ob ich das richtig verstehe. Warum sollte ich dem WG Client auf dem Router die gleiche IP geben wie meinem NAS?
Oder gehts darum warum ich den Client nicht auf dem NAS laufen lasse?
Synology hat leider noch keine offizielle Unterstützung für WireGuard.
Außerdem soll in Zukunft nicht alle Ports nur an die NAS gehen. Daher ist es deutlich praktischer alles an einem Ort (also im Router) zu erledigen.
WG Client:
/interface wireguard add listen-port=13232 mtu=1420 name=wg_vps private-key="xxx"
/interface wireguard peers add allowed-address=0.0.0.0/0 endpoint-address=xxx.xxx.xxx.xxx endpoint-port=51820 interface=wg_vps persistent-keepalive=5s public-key="xxx"
/ip address add address=192.168.201.2/24 interface=wg_vps network=192.168.201.0EDIT:
Übrigens: Wenn ich einen Port direkt an den Router gehen lasse funktioniert das übrigens. Habe testweise einfach den Port für Winbox versucht.
ABER wenn ich z.B. den ssh Port vom NAS erreichen will, kann ich mich zwar verbinden, aber sobald ich einen Befehl verwende wie "top" dann bleibt es hängen. Also irgendwie gehts ein bisschen ...aber nicht richtig.
Moin,
als erstes, warum machst du doppeltes NAT und routest nicht stattdessen direkt in das Client-Netz? Das kostet ja unnötig CPU Power und verlangsamt das ganze. Dafür braucht man ja nur in der Server und Client-WG Config die AllowedIPs anpassen und am Server ne Route in das Client Netz hinzufügen so dass direktes Routing in das Client-Netz (192.168.1.0/24) ohne überflüssiges NAT am Mikrotik nötig ist!
Wie dem auch sei, deine Config hat ein paar kleinere Fehler. Hier eine funktionierende Config für dein Szenario wenn du trotzdem beim Masquerading auf dem Wireguard Interface bleiben willst warum auch immer:
Hier mit der aktuellen 7.1Beta6 getestet problemlos getestet mit einem vServer bei Netcup.
/evo
als erstes, warum machst du doppeltes NAT und routest nicht stattdessen direkt in das Client-Netz? Das kostet ja unnötig CPU Power und verlangsamt das ganze. Dafür braucht man ja nur in der Server und Client-WG Config die AllowedIPs anpassen und am Server ne Route in das Client Netz hinzufügen so dass direktes Routing in das Client-Netz (192.168.1.0/24) ohne überflüssiges NAT am Mikrotik nötig ist!
Wie dem auch sei, deine Config hat ein paar kleinere Fehler. Hier eine funktionierende Config für dein Szenario wenn du trotzdem beim Masquerading auf dem Wireguard Interface bleiben willst warum auch immer:
/routing table
add disabled=no name=wireguard
/routing rule
add action=lookup disabled=no routing-mark=routing_wg_vps table=wireguard
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.201.1 routing-table=wireguard suppress-hw-offload=no
/ip firewall nat
add action=masquerade chain=srcnat comment="Masquerade Wireguard" out-interface=wg_vps
add action=dst-nat chain=dstnat comment="Forward vServer Port" dst-port=80,443 in-interface=wg_vps protocol=tcp to-addresses=192.168.1.11
/ip firewall mangle
add action=mark-connection chain=prerouting dst-port=80,443 in-interface=wg_vps new-connection-mark=conn_wg_vps passthrough=no protocol=tcp
add action=mark-routing chain=prerouting connection-mark=conn_wg_vps passthrough=no/evo
Moin,
das hat vermutlich auch dein Vorredner gemeint. Ihr habt natürlich recht, in diesem Fall könnte ich das tatsächlich so machen, wenn ich das wg Interface in mein Client Netze lege. Die Performance spielt hier keine große Rolle. Ich kann meine gesamte Bandbreite über das wg Routen. Das habe ich schon getestet (400Mbit Download/200Mbit Upload; Glasfaser).
In Zukunft kommt aber ein weiteres wg Interface dazu, wo ich die Server config nicht beeinflussen kann. Heißt, ich müsste dort eh doppeltes NAT verwenden. Dann mache ich es lieber gleich einheitlich
Der einzige Unterschied von deiner config zu meiner ist doch das du die Ports noch einmal explizit angibst bei den Mangle Regeln. Kannst du das erklären, warum das so sein sollte? Dann müsste ich die Ports ja 2x angeben.
das hat vermutlich auch dein Vorredner gemeint. Ihr habt natürlich recht, in diesem Fall könnte ich das tatsächlich so machen, wenn ich das wg Interface in mein Client Netze lege. Die Performance spielt hier keine große Rolle. Ich kann meine gesamte Bandbreite über das wg Routen. Das habe ich schon getestet (400Mbit Download/200Mbit Upload; Glasfaser).
In Zukunft kommt aber ein weiteres wg Interface dazu, wo ich die Server config nicht beeinflussen kann. Heißt, ich müsste dort eh doppeltes NAT verwenden. Dann mache ich es lieber gleich einheitlich
Der einzige Unterschied von deiner config zu meiner ist doch das du die Ports noch einmal explizit angibst bei den Mangle Regeln. Kannst du das erklären, warum das so sein sollte? Dann müsste ich die Ports ja 2x angeben.
Zitat von @EvilMoe:
Der einzige Unterschied von deiner config zu meiner ist doch das du die Ports noch einmal explizit angibst bei den Mangle Regeln.
Nö, schau mal genau hinDer einzige Unterschied von deiner config zu meiner ist doch das du die Ports noch einmal explizit angibst bei den Mangle Regeln.
Kannst du das erklären, warum das so sein sollte? Dann müsste ich die Ports ja 2x angeben.
Ist nur eine explizitere Regel bei mir um nicht sämtliche Connections ausw dem wg interface zu marken, spielt hier keine Rolle.Bei zweifeln einfach den Sniffer am Mikrotik anwerfen und in Wireshark auswerten, dann siehst du was wo fehl läuft.
Funktioniert hier wie gesagt einwandfrei.
Zitat von @149062:
Zitat von @EvilMoe:
Der einzige Unterschied von deiner config zu meiner ist doch das du die Ports noch einmal explizit angibst bei den Mangle Regeln.
Nö, schau mal genau hinDer einzige Unterschied von deiner config zu meiner ist doch das du die Ports noch einmal explizit angibst bei den Mangle Regeln.
Dann hilf mir mal auf die Sprünge bitte.
Bei der statischen Route hast du bei dem Gateway statt das Interface anzugegeben die wg Server IP angegeben.
Bei der Mangle Regel hast du das InInterface nicht drin.
Ich möchte es gerne auch verstehen, nicht einfach "abschreiben". Sieht zwar anders aus, aber ich verstehe noch nicht was das anders machen soll.
Ich habe natürlich auch eine Routing Tabelle angelegt. Diese habe ich eben einfach umbenannt und jetzt gehts auf einmal auch wieder. Das hatte ich schonmal das es ohne etwas Nennenswertes zu ändern wieder funktioniert.
EDIT: Jetzt gehts auch schon nicht mehr. Wenn ich im Gateway die IP statt das Interface nehme und das InInterface aus der Mangle Regel schmeiße gehts leider auch noch nicht
Also es scheint wohl an der Regel zu liegen:
Aber wie mache ich das dann mit den Ports die direkt an den Router gehen sollen? Das funktioniert nicht mehr. Aus diesem Grund hatte ich die Mangle Regel.
Was muss ich noch anpassen damit die Ports vom Router auch wieder übers WG Interface zurück gehen?
/ip firewall mangle add action=mark-routing chain=output connection-mark=conn_wg_vps passthrough=noAber wie mache ich das dann mit den Ports die direkt an den Router gehen sollen? Das funktioniert nicht mehr. Aus diesem Grund hatte ich die Mangle Regel.
Was muss ich noch anpassen damit die Ports vom Router auch wieder übers WG Interface zurück gehen?
Zitat von @EvilMoe:
Also es scheint wohl an der Regel zu liegen:
Also es scheint wohl an der Regel zu liegen:
> /ip firewall mangle add action=mark-routing chain=output connection-mark=conn_wg_vps passthrough=no
> Nein, das kannst du so machen, und funktioniert hier im Test ebenfalls dauerhaft problemlos. Alternativ kannst du auch am vServer ein SNAT auf die interne Wireguard ip machen dann ist das Output marken am Mikrotik überflüssig. Wie man es halt will ...
Ich tippe bei dir mal auf folgendes. Wenn der vServer sowohl per IPv4 als auch IPv6 erreichbar ist und die unkonfigurierte IPv6 Seite per FQDN angesprochen wird bleibt das verständlicherweise hängen da keine IPv6 Config vorhanden ist.
Ansonsten wie immer einfach Wireshark /traceroute /tcpdump auspacken dann siehst du wo die Pakete hängen bleiben. Ohne weitere Firewall-Config von vServer / Mikrotik kann man da hier nur raten.
Für das generelle Verständnis von Mangles & Co. ist das Packetflow Diagramm essentiell, da hier die Abfolge extrem wichtig für das Verständnis ist, du willst ja wie du sagtest auch was lernen
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Zudem sei natürlich noch gesagt das RouterOS 7 natürlich noch im Beta-Status ist. Wenn du also Zweifel an Konfigurationen hast die nicht das tun was man will, immer vorher das ganze auch an einer Release-Version testen (z.B. in einer VM). Hier zwar sinnlos da es Wireguard ja erst ab RouterOS7 gibt, aber ansonsten immer empfohlen.
So denn viel Erfolg und schönen Sonntag!
Sorry, in der Tat falsch verstanden und nun korrigiert...
Zitat von @aqui:
Im Grunde ist ein Port Forwarding immer ein einfacher Eintrag im Destination NAT Setting der Firewall und dessen Plartzierung an richtiger Reihenfolge im Ruleset.
Hier einmal am Beispiel vom WireGuard Port UDP 51820 am WAN Port ether 1:
Im Grunde ist ein Port Forwarding immer ein einfacher Eintrag im Destination NAT Setting der Firewall und dessen Plartzierung an richtiger Reihenfolge im Ruleset.
Hier einmal am Beispiel vom WireGuard Port UDP 51820 am WAN Port ether 1:
Thema komplett verfehlt ... Du solltest die Beiträge zumindest erst mal lesen 🙃
Zitat von @149062:
Nein, das kannst du so machen, und funktioniert hier im Test ebenfalls dauerhaft problemlos. Alternativ kannst du auch am vServer ein SNAT auf die interne Wireguard ip machen dann ist das Output marken am Mikrotik überflüssig. Wie man es halt will ...
Ich tippe bei dir mal auf folgendes. Wenn der vServer sowohl per IPv4 als auch IPv6 erreichbar ist und die unkonfigurierte IPv6 Seite per FQDN angesprochen wird bleibt das verständlicherweise hängen da keine IPv6 Config vorhanden ist.
Ansonsten wie immer einfach Wireshark /traceroute /tcpdump auspacken dann siehst du wo die Pakete hängen bleiben. Ohne weitere Firewall-Config von vServer / Mikrotik kann man da hier nur raten.
Für das generelle Verständnis von Mangles & Co. ist das Packetflow Diagramm essentiell, da hier die Abfolge extrem wichtig für das Verständnis ist, du willst ja wie du sagtest auch was lernen
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Zudem sei natürlich noch gesagt das RouterOS 7 natürlich noch im Beta-Status ist. Wenn du also Zweifel an Konfigurationen hast die nicht das tun was man will, immer vorher das ganze auch an einer Release-Version testen (z.B. in einer VM). Hier zwar sinnlos da es Wireguard ja erst ab RouterOS7 gibt, aber ansonsten immer empfohlen.
So denn viel Erfolg und schönen Sonntag!
Zitat von @EvilMoe:
Also es scheint wohl an der Regel zu liegen:
Also es scheint wohl an der Regel zu liegen:
>> /ip firewall mangle add action=mark-routing chain=output connection-mark=conn_wg_vps passthrough=no
>> Nein, das kannst du so machen, und funktioniert hier im Test ebenfalls dauerhaft problemlos. Alternativ kannst du auch am vServer ein SNAT auf die interne Wireguard ip machen dann ist das Output marken am Mikrotik überflüssig. Wie man es halt will ...
Ich tippe bei dir mal auf folgendes. Wenn der vServer sowohl per IPv4 als auch IPv6 erreichbar ist und die unkonfigurierte IPv6 Seite per FQDN angesprochen wird bleibt das verständlicherweise hängen da keine IPv6 Config vorhanden ist.
Ansonsten wie immer einfach Wireshark /traceroute /tcpdump auspacken dann siehst du wo die Pakete hängen bleiben. Ohne weitere Firewall-Config von vServer / Mikrotik kann man da hier nur raten.
Für das generelle Verständnis von Mangles & Co. ist das Packetflow Diagramm essentiell, da hier die Abfolge extrem wichtig für das Verständnis ist, du willst ja wie du sagtest auch was lernen
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Zudem sei natürlich noch gesagt das RouterOS 7 natürlich noch im Beta-Status ist. Wenn du also Zweifel an Konfigurationen hast die nicht das tun was man will, immer vorher das ganze auch an einer Release-Version testen (z.B. in einer VM). Hier zwar sinnlos da es Wireguard ja erst ab RouterOS7 gibt, aber ansonsten immer empfohlen.
So denn viel Erfolg und schönen Sonntag!
Moin!
Erstmal danke für deine bisherige Hilfe. Also mit SNAT auf dem WG Server funktioniert beides ohne Probleme.
Aber wenn ich das ohne SNAT machen möchte und die Regel
/ip firewall mangle add action=mark-routing chain=output connection-mark=conn_wg_vps passthrough=noIPv4 oder IPv6 kann nicht das Problem sein. Ich habe für die Domain nur einen A-Eintrag gesetzt auch, wenn der Server auch über IPv6 erreichbar ist.
Was mich ein wenig wundert ist, das die Output Regel Packete zählt (obwohl ich nicht direkt auf den Router zugreife), sobald es nicht mehr funktioniert. Also ich kann dann mit Winbox auf den Router zugreifen, aber das NAT zum Router geht nicht mehr.
Wenn ich logging aktiviere für die Regel erhalte ich sehr viele Einträge von einer IP, die mir nichts sagt:
output: in:(unknown 0) out:vlan1, proto ICMP (type 3, code 4), 192.168.1.1->192.168.1.11, NAT 148.251.184.145->(192.168.201.2->192.168.1.11), len 576Logging von "mark routing" Regel ergibt folgendes:
prerouting: in:vlan1 out:(unknown 0), src-mac 00:11:32:9b:xx:xx, proto TCP (ACK), 192.168.1.11:443->94.xx.xx.xx:41908, NAT (192.168.1.11:443->192.168.201.2:443)->94.xx.xxx.xx:41908, len 1500Traceroute zu Domain ergibt folgendes:
traceroute -T -p 443 domain.tld
traceroute to gitlab.domain.tld (195.xxx.xxx.xxx), 30 hops max, 60 byte packets
1 2.xxx.xxx.xxx (2.xxx.xxx.xxx) 2.366 ms 1.419 ms 1.368 ms
2 decix-gw.hetzner.com (80.81.192.164) 19.820 ms 19.689 ms 19.652 ms
3 core12.nbg1.hetzner.com (213.239.252.26) 4.440 ms core11.nbg1.hetzner.com (213.239.252.22) 4.475 ms core12.nbg1.hetzner.com (213.239.252.26) 4.468 ms
4 spine2.cloud1.nbg1.hetzner.com (213.239.208.222) 4.604 ms 4.562 ms spine2.cloud1.nbg1.hetzner.com (85.10.250.214) 5.059 ms
5 * * *
6 10116.your-cloud.host (116.203.160.197) 4.272 ms 3.852 ms 3.804 ms
7 domain.tld (195.xxx.xxx.xxx) 4.764 ms 4.740 ms 4.665 ms
8 domain.tld (195.xxx.xxx.xxx) 17.894 ms 18.295 ms 17.838 ms
9 domain.tld (195.xxx.xxx.xxx) 17.815 ms 17.782 ms 18.127 msWireshark kenne ich mich gar nicht aus. Was müsste ich da wie einstellen? Wie komme ich von meinem Laptop an den Traffic zwischen Router/NAS?
Zitat von @EvilMoe:
Erstmal danke für deine bisherige Hilfe. Also mit SNAT auf dem WG Server funktioniert beides ohne Probleme.
Aber wenn ich das ohne SNAT machen möchte und die Regel
Aktiviere geht, klappt das port forwarding zum NAS scheinbar nicht mehr.
Die Regel hat gar nichts mit dem Forwarding zu tun, sie markiert nur alles was vom Router selbst initiiert wird mit dem Routing-Tag. Daran kann es also definitiv nicht liegen weil es hier damit ja einwandfrei funktioniert. Aber wie gesagt hier kennt keiner deinen eingesetzten Firewall Regelsatz.Erstmal danke für deine bisherige Hilfe. Also mit SNAT auf dem WG Server funktioniert beides ohne Probleme.
Aber wenn ich das ohne SNAT machen möchte und die Regel
> /ip firewall mangle add action=mark-routing chain=output connection-mark=conn_wg_vps passthrough=no
> IPv4 oder IPv6 kann nicht das Problem sein. Ich habe für die Domain nur einen A-Eintrag gesetzt auch, wenn der Server auch über IPv6 erreichbar ist.
OK.Was mich ein wenig wundert ist, das die Output Regel Packete zählt (obwohl ich nicht direkt auf den Router zugreife), sobald es nicht mehr funktioniert. Also ich kann dann mit Winbox auf den Router zugreifen, aber das NAT zum Router geht nicht mehr.
Wenn ich logging aktiviere für die Regel erhalte ich sehr viele Einträge von einer IP, die mir nichts sagt:
ICMP leite ich vom wg Server doch gar nicht weiter. Oder kommt das von WG selbst? Aber die IP 148.251.184.145 kenne ich gar nicht.
Logging von "mark routing" Regel ergibt folgendes:
Die 94.xx.xx.xx ist meine öffentliche IP. Das sieht auch alles richtig aus. Aber trotzdem gehts nicht...
Hier kennt auch keiner deine Firewallsettings am vServer, sieht so aus als läge da was im Argen, da dein Setup hier genau so einwandfrei funktioniert.Wenn ich logging aktiviere für die Regel erhalte ich sehr viele Einträge von einer IP, die mir nichts sagt:
> output: in:(unknown 0) out:vlan1, proto ICMP (type 3, code 4), 192.168.1.1->192.168.1.11, NAT 148.251.184.145->(192.168.201.2->192.168.1.11), len 576
> Logging von "mark routing" Regel ergibt folgendes:
> prerouting: in:vlan1 out:(unknown 0), src-mac 00:11:32:9b:xx:xx, proto TCP (ACK), 192.168.1.11:443->94.xx.xx.xx:41908, NAT (192.168.1.11:443->192.168.201.2:443)->94.xx.xxx.xx:41908, len 1500
> Wireshark kenne ich mich gar nicht aus. Was müsste ich da wie einstellen? Wie komme ich von meinem Laptop an den Traffic zwischen Router/NAS?
Am Mikrotik mit dem Packet Sniffer (Tools => Packet Sniffer) den Traffic am Interface aufzeichnen, das File auf den Rechner transferieren und mit Wireshark öffnen.
