23.09.2022

3539

DynDNS mit Mikrotik

Ich habe ein ZyXEL VMG3006-D70A als Modem an einem Mikrotik über PPPoE angeschlossen, und möchte einen Rechner im VLAN 30 über das Internet erreichbar machen.

Leider klappt das nicht.

Ich habe

/ip cloud
set ddns-enabled=yes ddns-update-interval=1m
/ip dhcp-client
add disabled=yes interface=e1_wan
/ip dhcp-server lease

und

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=8080 in-interface=e1_wan log=yes protocol=tcp to-addresses=x.x.x.x to-ports=80
/ip firewall raw

gesetzt.

ping <mikrotik-serial-no>.sn.mynetname.net:8080

zeigt "unknown host" an.

Muss ich noch etwas anderes setzen?

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

Content-ID: 4037673359

Url: https://administrator.de/contentid/4037673359

Ausgedruckt am: 13.11.2024 um 22:11 Uhr

32 Kommentare

Neuester Kommentar

Hallo,

falls das Ziel ein Windows PC ist wird wohl die lokale Firewall die ping Pakete verwerfen.

Gruß

Der TO forwardet ja lediglich nur TCP 8080, also Web Traffic. Wie sollten dann dort jemals ICMP Pakete durchgehen??
Ping nutzt ja, wie allgemein bekannt, ICMP (Type 0 u. 8) und kein TCP. Schon gar nicht Port TCP 8080. ICMP kennt auch keine Ports.
Es wird also schon daran scheitern bevor überhaupt die Winblows Firewall zuschlagen kann!! Sein Foren Nick lässt ja auch hoffen das da ein RasPi dahinter im VLAN 30 werkelt?! 😉
Hätte der TO statt Ping, ICMP ein simples Telnet (PuTTY) auf Port TCP 8080 gemacht wäre das Ganze schon etwas zielführender gewesen.

Mit DynDNS, wie deine Überschrifft suggeriert, hat das aber erstmal nur etwas im 2ten Schritt zu tun.
Deine ersten Schritte sind eine FW Regel zu erstellen die den Traffic passieren lässt (Achtung Regel Reihenfolge zählt!) und eine DST-NAT Regel die diesen Traffic dann auf den Zielhost forwardet.
Dieser WinBox Screenshot zeigt es am Beispiel von bidirektional UDP 5180 wie das einfach zu lösen ist.

Bei dir dann Regel Port TCP 8080 und DST-NAT Port TCP 80.
Damit kannst du den VLAN 30 Host dann erstmal über die WAN Port IP erreichen.

Man sollte es auch sinnvollerweise immer zuerst über die nackte WAN IP testen um sicherzustellen das FW Regel und DST-NAT sauber funktionieren.
Dann erst kommt als Kür das DynDNS was der WAN Port IP einen Hostnamen zuweist über den DynDNS Dienstleister deiner Wahl.
Mittlerweile erledigt Mikrotik sowas ja mit Bordmitteln
https://wiki.mikrotik.com/wiki/Manual:IP/Cloud

Hallo @aqui,

danke für die Info! Das mit ping war natürlich Quatsch. Ich möchte einen Raspi über Web-Interface erreichen, und zusätzlich port 22 für eine Ferndiagnose ermöglichen, was jetzt auch geht:

Ich verwende IP --> cloud und goip.de

Firewall NAT:

add action=dst-nat chain=dstnat dst-port=80 protocol=tcp to-addresses=y.y.y.y to-ports=80
add action=dst-nat chain=dstnat disabled=yes dst-port=22 protocol=tcp to-addresses=y.y.y.y to-ports=22
add action=dst-nat chain=dstnat disabled=yes dst-port=80 protocol=udp to-addresses=y.y.y.y to-ports=80

Firewall:

add action=accept chain=forward comment="accept x.goip.de from WAN to myserver" dst-address-list=myserver dst-port=22,80 in-interface-list=WAN out-interface=\  
    vlan30 protocol=tcp
add action=accept chain=forward comment="accept x.goip.de from WAN to myserver" dst-address-list=myserver dst-port=22,80 in-interface-list=WAN out-interface=\  
    vlan30 protocol=udp

Ich kann jetzt per Mobile-Netz das WEB-Interface erreichen.

Seltsamerweise funktioniert es mit 8080 nicht?

Ich kann auch in der Firewall und bei NAT die Einträge mit udp disable´n und es funktioniert trotzdem?

"chain=dstnat disabled=yes dst-port=80 protocol=udp to-addresses=y.y.y.y to-ports=80"

Seit wann nutzt HTTP denn UDP?? Ist doch genauso ein (gefährlicher) Quatsch und bohrt ein unnützes Security Loch in deine Firewall.

Seltsamerweise funktioniert es mit 8080 nicht?

Ist auch logisch, denn du hast, wie du ja selber sehen kannst, die FW Regel vergessen mit der du eingehenden TCP 8080 Traffic passieren lässt. Da du ja nur TCP 22 und 80 durchlässt wird TCP 8080 inbound am WAN weiterhin geblockt!
Works as designed...

Ich kann jetzt per Mobile-Netz das WEB-Interface erreichen.

Auch ein böses Faul was niemals der Fall sein sollte, denn das WebGUI eines Routers sollte aus guten Gründen niemals direkt im Internet exponiert werden. Dafür sollte man immer ein VPN nutzen was mit dem Mikrotik ja kein Thema ist. Weisst du ja auch alles selber...

So sähe deine korrekte Konfig aus für TCP 8080 und TCP 22

Hallo @aqui,

UDP habe ich entfernt.

Der Raspi, den ich von außen erreichen möchte, ist von einer Firma, die ein WEB-Interface mit login draufgesetzt hat. Es sind insgesamt sogar zwei Raspi´s. Ich habe keine Rechte außer über das Web-Interface.
Ich weiß nicht, ob ich das auch mit VPN machen kann.

Weiterhin funktioniert es nur, wenn ich bei den Filter Rules tcp port 80 angebe:

add action=accept chain=forward dst-address=10.10.30.xxx dst-port=80 protocol=tcp
add action=accept chain=forward dst-address=10.10.30.yyy dst-port=80 protocol=tcp

/ip firewall nat
add action=accept chain=srcnat comment="defconf: accept all that matches IPSec policy" ipsec-policy=out,ipsec  
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN  
add action=dst-nat chain=dstnat comment="Server1 access from Internet" dst-port=8080 protocol=tcp to-addresses=10.10.30.xxx to-ports=80  
add action=dst-nat chain=dstnat comment="Server1 access from Internet" dst-port=8081 protocol=tcp to-addresses=10.10.30.yyy to-ports=80  
/ip firewall raw

Ich habe IP --> Cloud aktiviert, und bei dynu.com eine Domain angelegt, zu der ich einen CNAME record angelegt habe und dort den DNS-Namen von IP cloud hinterlegt habe.
Damit erreiche ich das Web-UI mit dem domain Namen und :8080 bzw. :8081

Ich weiß nicht, ob ich das auch mit VPN machen kann.

Sogar viel besser und sicherer als mit Port Forwarding. Ganz besonders was die Kommunikation mit unverschlüsseltem HTTP betrifft wie du es ja machst.

Weiterhin funktioniert es nur, wenn ich bei den Filter Rules tcp port 80 angebe:

Das ist Unsinn, denn das o.a. Setup (WinBox Screenshot) beweist ja das Gegenteil. Es ist ein Live Setup das erlaubt den TCP 8080 Zugang von außen per Browser und Port Translation im Zugriff auf den lokalen Webserver mit TCP 80 ("to port") erlaubt! Im Webbrowser ist dann entsprechend http://<wan_ip_mikrotik>:8080 einzugeben.
Das Port Forwarding erlaubt dann auch einzig nur den externen TCP 8080 Zugriff auf den lokalen Webserver NICHT aber den Zugriff aufs Router GUI.
Zeigt also das du noch einen gravierenden Konfig Fehler irgendwo in der Mikrotik Firewall hast!!
Siehst du auch, denn dein DST-NAT muss VOR dem Port NAT kommen. Reihenfolge im Regelwerk zählt hier. Siehe auch den WinBox Screenshot oben.

/ip firewall filter
add action=accept chain=forward comment="TCP8080 u. SSH erlauben" dst-address=192.168.18.149 dst-port=8080 protocol=tcp  
add action=accept chain=forward dst-address=192.168.18.149 dst-port=22 protocol=tcp

/ip firewall nat
add action=dst-nat chain=dstnat comment="DST NAT TCP 22 u. 80" dst-port=8080 in-interface=ether1 protocol=tcp to-addresses=192.168.18.149 to-ports=80  
add action=dst-nat chain=dstnat dst-port=22 in-interface=ether1 protocol=tcp to-addresses=192.168.18.149 to-ports=22
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN  

(Inbound Interface "eth1" ist hier im Beispiel der WAN Port. Bei dir dann durch das PPP Interface zu ersetzen

Damit erreiche ich das Web-UI mit dem domain Namen und :8080 bzw. :8081

Wenn du damit das WebGUI des Routers meinst ist das nicht wirklich gut aus Sicherheitssicht und zeigt ein Fehlerhaftens und unsicheres Portforwarding. Wenn man einmal davon absieht das dein Portforwarding generell unsicher ist und jeder im Internet deine Daten mitlesen kann.

Immer der generelle Nachteil von ungeschütztem Port Forwarding.

Mit einem L2TP VPN Server auf dem Mikrotik arbeitest du von remote genau so als wenn du im lokalen LAN hängst und das absolut sicher, da verschlüsselt und Passwort geschützt. Bekanntlich ja der tiefere Sinn eines VPNs....

Damit erspartst du dir das Regelwerk, das DST-NAT und die unsichere HTTP Kommunikation mit deinem o.a. Setup. Ist also die deutlich bessere und sicherere Varinate als dein Port Forwarding Gefrickel.
L2TP supportet jedes übliche Betriebssystem mit einem entsprechenden onboard Client. Siehe o.a. Tutorial!

Danke @aqui. Das mit dem VPN werde ich versuchen.

Das mit 8080 geht leider immer noch nicht. Ich habe "drop"-Regeln deaktiviert, usw.
Wenn ich vor dem letzten "drop" in den Filter-Rules einen Log einbaue, sehe ich solche Ausgaben wenn ich von extern zugreife:

forward: inpppoe-out1: vlan30, proto TCP (SYN), 172.255.135.74->10.10.30.172:80, NAT 172.225.135.74:25547->(<mikrotik-IP>:8080)->10.10.30.172:80),len 60

Hier meine Firewall-EInstellungen:

/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP after RAW" protocol=icmp  
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked  
add action=accept chain=input comment="Accept all connections from vlan1_default" in-interface-list=LAN-Control  
add action=accept chain=forward comment="defconf: accept all that matches IPSec policy" ipsec-policy=in,ipsec  
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes  
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked log-prefix=established  
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid  
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN log-prefix=DROPWAN  
add action=drop chain=forward comment="defconf: drop bad forward IPs" src-address-list=no_forward_ipv4  
add action=drop chain=forward comment="defconf: drop bad forward IPs" dst-address-list=no_forward_ipv4  
add action=accept chain=forward comment="TCP8080 u. SSH erlauben" dst-address=10.10.30.172 dst-port=8080 protocol=tcp  
add action=accept chain=forward comment="TCP22 erlauben" dst-address=10.10.30.172 dst-port=22 protocol=tcp  
add action=accept chain=forward comment="accept all vlan to WAN tcp" in-interface=all-vlan log-prefix="TCP: " out-interface-list=WAN protocol=tcp  
add action=accept chain=forward comment="accept all vlan to WAN udp" in-interface=all-vlan log-prefix=UDP-WAN out-interface-list=WAN protocol=udp  
add action=accept chain=forward comment="accept all vlan to WAN icmp" in-interface=all-vlan out-interface-list=WAN protocol=icmp  
add action=accept chain=forward comment="allow vlan control to other VLANs" in-interface-list=LAN-Control out-interface=all-vlan  
add action=log chain=forward log=yes
add action=drop chain=forward log-prefix=DROPPED:
/ip firewall nat
add action=accept chain=srcnat comment="defconf: accept all that matches IPSec policy" ipsec-policy=out,ipsec  
add action=dst-nat chain=dstnat comment="forwared to Miniserver" dst-port=8080 in-interface=pppoe-out1 protocol=tcp to-addresses=10.10.30.172 to-ports=80  
add action=dst-nat chain=dstnat comment="forwared to Drop-Server" dst-port=22 in-interface=pppoe-out1 protocol=tcp to-addresses=10.10.30.172 to-ports=80  
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN  
/ip firewall raw
add action=accept chain=prerouting comment="defconf: enable for transparent firewall"  
add action=accept chain=prerouting comment="defconf: accept DHCP discover" dst-address=255.255.255.255 dst-port=67 in-interface-list=LAN protocol=udp src-address=0.0.0.0 src-port=68  
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_ipv4  
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_ipv4  
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_src_ipv4  
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_dst_ipv4  
add action=drop chain=prerouting comment="defconf: drop non global from WAN" in-interface-list=WAN src-address-list=not_global_ipv4  
add action=drop chain=prerouting comment="defconf: drop forward to local lan from WAN" dst-address=192.168.1.0/24 in-interface-list=WAN  
add action=drop chain=prerouting comment="defconf: drop local if not from default IP range" in-interface-list=LAN src-address=!192.168.1.0/24  
add action=drop chain=prerouting comment="defconf: drop bad UDP" port=0 protocol=udp  
add action=jump chain=prerouting comment="defconf: jump to ICMP chain" jump-target=icmp4 protocol=icmp  
add action=jump chain=prerouting comment="defconf: jump to TCP chain" jump-target=bad_tcp protocol=tcp  
add action=accept chain=prerouting comment="defconf: accept everything else from LAN" in-interface-list=LAN  
add action=accept chain=prerouting comment="defconf: accept everything else from WAN" in-interface-list=WAN  
add action=drop chain=prerouting comment="defconf: drop the rest"  
add action=drop chain=bad_tcp comment="defconf: TCP flag filter" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack  
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,syn
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,rst
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,!ack
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,urg
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=syn,rst
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=rst,urg
add action=drop chain=bad_tcp comment="defconf: TCP port 0 drop" port=0 protocol=tcp  
/ip firewall service-port

Das mit 8080 geht leider immer noch nicht.

Dann hast du weiter einen Fehler in deiner Firewall Konfig!
Tip: Nimm die Default Einstellungen der Firewall die RouterOS von sich aus in der Default Konfig anlegt. Damit funktioniert es auf Anhieb!

Hier ist das vollständige FW Regelwerk und NAT Setup beim funktionierenden Live System. Letztlich nur die Erweiterung der Default FW und NAT Konfig.
(WAN Port ist hier "eth1" und Router hat L2TP VPN, interner Webserver und SSH ist 192.168.18.149)

/ip firewall filter
add action=accept chain=input comment="L2TP erlauben" dst-port=1701 protocol=udp  
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=forward comment="TCP8080 u. SSH erlauben" dst-address=192.168.18.149 dst-port=8080 protocol=tcp  
add action=accept chain=forward dst-address=192.168.18.149 dst-port=22 protocol=tcp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked  
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid  
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp  
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1  
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN  
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec  
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec  
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes  
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked  
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid  
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN  

/ip firewall nat
add action=dst-nat chain=dstnat comment="DST NAT TCP 22 u. 80" dst-port=8080 in-interface=ether1 protocol=tcp to-addresses=192.168.18.149 to-ports=80  
add action=dst-nat chain=dstnat dst-port=22 in-interface=ether1 protocol=tcp to-addresses=192.168.18.149 to-ports=22
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN   

Interfaces sind dort üblicherweise in Listenform geführt.

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN 

Danke @aqui. Werde ich versuchen.

@aqui: etwas anderes: ich habe jetzt den VPN Server eingerichtet und kann mich von meinem iPhone aus über Mobilfunk verbinden. Im Browser kann ich auch das Mikrotik-UI öffnen und mich einloggen. Nur wenn ich versuche einen der Raspi‘s zu erreichen, bekomme ich keine Verbindung. Muss ich da etwas in der Firewall freigeben?

Muss ich da etwas in der Firewall freigeben?

Jein, normalerweise nicht. Der VPN Client verhält sich genau so wie ein Client im lokalen LAN Netzwerk wo die RasPis sind.
Was aber sein kann ist das du ein FW Regelwerk zw. den VLANs hast die ggf. den Zugriff verbieten.
Hier ist es jetzt wichtig zu wissen aus welchem IP Adress Pool du VPN Client IP Adressen verteilst?? Sprich auf WELCHE lokale und remote IP Adresse dein L2TP Client gebunden ist und für welches Interface du den Proxy ARP eingestellt hast?!
Leider machst du dazu keinerlei Angaben, so das eine zielführende Hilfe schwer bist unmöglich ist.

Zwischen dem L2TP Client IP Netz und dem RasPi IP Netz, sofern diese denn unterschiedlich sind, musst du in dem Falle dann dein Regelwerk prüfen sofern vorhanden.
Klar sollte auch sein das die RasPis ein Default Gateway oder eine Route auf den Mikrotik haben müssen!
Das gesamte Port Forwarding kann bei einem VPN dann natürlich entfallen und sollte man auch entfernen um keine Sicherheitslücken zu lassen!
Tip:
Installiere dir auf dem iPhone immer die HE.NET Tools! Damit kannst du dann Pings und auch andere Tests von deinem iPhone VPN Client machen.

Hallo @aqui, danke für die Hinweise!

Was mir noch bzgl. port 8080 aufgefallen ist: Unter IP Service List gibt es bei meinem Mikrotik keinen Eintrag "www 80", vielleicht war das das Problem? Es gibt in dem Dialog keinen "+" Button, kann ich den per Befehl addieren?

Zum L2TP Server setup: ich konnte zwar mit einer Firewall-Regel den VPN Zugriff auf die Raspi´s ermöglichen, trotzdem bin ich mir nicht sicher bzgl. den Angaben in Scheitern am IPsec VPN mit MikroTik:

Wichtig: Lokales LAN Interface im ARP Mode auf Proxy-ARP setzen ! 
Proxy ARP muss bei L2TP immer auf dem lokalen LAN Interface gesetzt sein, egal ob es ein Bridge, LAN (ether) oder ein VLAN Interface ist !!
Achtung: In einem VLAN Setup kommt das Proxy ARP natürlich nicht auf das Bridge Interface sondern auf das VLAN IP Interface !! 
(Das Bridge Interface gilt einzig nur wenn eine Default Konfig verwendet wird ! (Ports 2-5 via Bridge als lokales LAN))

Ich habe ein VLAN setup wie in Mikrotik VLAN Konfiguration ab RouterOS Version 6.41 beschrieben, d.h. eine br_vlan, und darunter die einzelnen VLANs.

Das ZyXEL Modem habe ich über PPOE angebunden, d.h. unter e1_wan ein vlan7_telekom, das von pppoe-out1 verwendet wird. Unter br_vlan habe ich keinen vlan7_telekom Eintrag, scheint auch so zu funktionieren.

Nun die Fragen:

1. Wo muss ich das proxy-arp angeben, bei vlan7_telekom, bei e1_wan, oder br_vlan? Ich möchte später einen zusätzlichen Rechner erreichen können, der über einen layer 2 switch am Mikrotik e5_trunk hängt.

2. In der Address List sind den VLAN´s IP Adressen 10.10.x.1/24 zugeordnet, dem pppoe_out dynamisch z.B. 84.170.x.y. Muss ich für den L2TP Server einen weiteren Adressbereich hinzufügen, oder genügt es unter IP->Pool einen Eintrag "default_dhcp" mit z.B. 10.10.88.0-10.10.88.150, oder auch z.B. mit 192. irgendwas zu machen?

Ich habe ein VLAN setup wie in

Da hast du Recht, denn das L2TP Tutorial beschreibt ein Standard Setup wo die Ports über eine Bridge auf ein Bridge Interface zusammengefügt sind was die LAN IP hält. Das sieht bei dir natürlich logischerweise anders aus!
Proxy ARP wird immer auf dem korrespondierenden IP Interface definiert. Bei dir dann auf dem lokalen VLAN IP Interface. Siehe dazu hier.
Nebenbei steht es dort in großen roten Lettern auch nochmal explizit das bei einem VLAN Setup Proxy ARP auf die VLAN IP Interfaces gehört! Tutorial wirklich lesen hilft!! 😉
Das beantwortet dann deine Frage 1.

Was Frage 2 anbetrifft musst du am WAN Interface (PPP) nichts in Bezug auf L2TP einstellen. Einzig musst du dafür sorgen das dort die typischen IPsec Pakete von außen passieren dürfen auf die WAN PPP IP Adresse. Siehe Tutorial und dort die FW Regeln.
Für die L2TP Client IP Adressen im Tunnel die du unter "Secrets" und dann "Remote Address" einrichtest musst du aufpassen das diese IPs ausserhalb deines VLAN DHCP Pool Bereichs befinden. Ansonsten kann es zu Überschneidungen und Doppelnutzung kommen.
Also z.B. wenn dein VLAN 30 Proxy ARP spielt und den DHCP Poolbereich 10.10.30.10 bis .100 /24 hat dann kannst du die L2TP Adressen ab .101 aufwärts vergeben sofern diese Adresse NICHT irgendwo statisch verwendet werden! Sie sind dann exklusiv an den oder die L2TP VPN User vergeben.

Danke @aqui. Es funktioniert, mit vlan_30 = proxy_arp.

Ich musste auch noch eine forwared Regel mit out_interface = vlan_30 und dst.address = Raspi-IP setzen.

Den anderen Raspi erreiche ich noch nicht, der ist auch über eine Powerline angebunden, die kein VLAN unterstützt, deren Router aber am VLAN_30 hängt.

Kannst du den denn von einem Client erreichend er direkt im VLAN 30 liegt??
Das kann daran liegen das dein VPN Client kein Redirect macht. Das ist aber mit einem simplen Mausklick kinderleicht einzustellen.

Haken bei Default Gateway setzen, das routet dann alles in den Tunnel!

Oops, jetzt kann ich den zweiten Raspi auch erreichen, habe aber nichts geändert.

Teufelsspuk!!! 😈

Kann man sagen! Danke nochmal …

Immer gerne!
Wenns das denn nun war bitte deinen Thread dann hier auch als erledigt schliessen!

Ich hab doch noch was: Die Geräte, die am Switch hängen, sind nicht erreichbar, wenn proxy-arp am VLAN 30 eingestellt ist. Im Lease taucht neben der statischen Adresse des Switch immer wieder eine dynamische mit „offer“ und dhcp auf, die immer wieder weggeht, und dann wieder auftaucht. Muss ich beim Trunk auch proxy-arp einstellen?

Der "Switch" ist ein externer Switch der am MT hängt wie z.B. hier beschrieben? Oder wie muss man sich das vorstellen?
Proxy ARP gibt es, wie oben schon gesagt, ausschließlich NUR auf IP Interfaces da es immer eine Layer 3 Funktion ist. Ein Trunk Port ist in der Regel immer ein Layer 2 Interface was gar nicht die Option dieser Einstellung hat. Oder wie meinst du das genau?

Ja, der Switch ist ein Netgear GS308EP, der am MT hängt, wie im Link beschrieben.
Dort habe ich auch dieselben VLAN´s eingerichtet wie am MT.
Der Switch hängt am MT an e5_trunk und hat eine statische IP Adresse. Im Lease steht:

10.10.1.197 <MAC-Adresse_Switch> dhcp1  ... e5_trunk bound

Soweit funktioniert alles. Sobald ich nun am vlan30 am MT Interface den Mode von "enabled" nach "proxy-arp" umsetze, und eine VPN-Verbindung aufbaue, erscheinen nach kurzer Zeit weitere Einträge im Lease, z.B.:

D 10.10.22.200   <MAC-Adresse_Switch>  dhcp22 ... e5_trunk  offered
D 10.10.15.200   <MAC-Adresse_Switch>  dhcp15 ... e5_trunk  offered
D 10.10.30.154   00:00:00:00:00:00     dhcp30               conflict

Diese Einträge gehen immer wieder weg und erscheinen dann neu.

Die VLAN Adressen sehen wie folgt aus:

10.1.1/24    10.10.1.0         vlan_1_default
10.11.1/24   10.10.10.0        vlan_10
10.15.1/24   10.10.15.0        vlan_15
10.22.1/24   10.10.22.0        vlan_22
10.30.1/24   10.10.30.0        vlan_30
D 10.10.31.1    10.10.31.201      <l2tp-MyName>
D 84.170.x.y    62.155.a.b        pppoe-out1

Auf was muss die local Adresse bei PPP Secret gesetzt sein? Kann die beliebig sein?

… und IP —> Cloud muss ich ja auch dafür verwenden?

Auf was muss die local Adresse bei PPP Secret gesetzt sein? Kann die beliebig sein?

Nein, die darf nicht beliebig sein. Wie du aus dem o.a. Tutorial entnehmen kannst MUSS sie immer auf die lokale IP Adresse des Proxy ARP Interfaces gesetzt sein. In deinem Falle dann das vlan30 IP Interface bzw. auf die 10.10.30.1.

Die VLAN Adressen sehen wie folgt aus:

Woher kommt dieser Output und warum haben deine VPN Clients mit einmal 10.10.31.x IP Adressen aus einem völlig fremden IP Netz was es bei dir gar nicht gibt?!

Die 10.10.31.201 habe ich als die Remote-Adresse in den Secrets genommen, bei lokaler Adresse ja fälschlicherweise die 10.10.31.1 anstatt der 10.10.30.1

Korrigiere das, dann sollte es auch fehlerfrei klappen! 😉

Es scheint jetzt zu funktionieren, aber die "offered"-Einträge im Lease erscheinen weiterhin und verschwinden wieder im Sekundentakt. Muss man das verstehen?

Ich sehe mir das mal beim hiesigen Setup....

Sorry, dein Verhalten lässt sich trotz intensiven Testens nicht reproduzieren! Weder auf einem RB4011 noch auf einem einfachen hAP Lite mit Router OS Ver. 7.5 Stable
Die Lease Einträge verhalten sich erwartungsgemäß völlig unbehelligt vom L2TP bzw. PPP VPN Dialin. Das ist auch klar, denn das eine hat mit dem anderen nichts zu tun.
Hier die WinBox Screenshots eines Live Setups mit 3 VLANs und einem VLAN Switch (Zyxel) an Port 5 eines einfachen hAP Lites. Proxy ARP ist nur auf dem VLAN1 IP Interface konfiguriert.
DHCP und Pool Setup: