08.10.2022

3979

Mikrotik input rule for l2tp vpn

Hallo,

wenn ich die letzte Input-Regel auf enable setze, dann funktioniert mein VPN nicht mehr, wegen:

DROPPED FORWARD forward: in:<l2tp-XXX> out:pppoe-out1, proto UDP, 10.10.1.x:59850->217.xxx.yyy.zzz:53, len 80

/ip firewall filter
add action=accept chain=input comment=L2TP/IPSec dst-port=1701 protocol=udp
add action=accept chain=input comment=L2TP/IPSec dst-port=500 protocol=udp
add action=accept chain=input comment=L2TP/IPSec dst-port=4500 protocol=udp
add action=accept chain=input comment=L2TP/IPSec protocol=ipsec-esp
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-Home  
add action=accept chain=input comment="allow local routerboard management" dst-address-list=Routerboard dst-port=80 in-interface=vlan1_default \  
    protocol=tcp
add action=drop chain=input comment="Drop input to routerboard for these ports" dst-port=21,22,23 protocol=tcp  
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN  

Nun kann ich ja keine Regel definieren mit in:<l2tp-*>, denn wenn mehrere VPN-Verbindungen gleichzeitig dran sind, gibt es weitere <l2tp-x> Einträge.

Gibt es dafür eine Lösung, oder muss ich das drop jetzt immer disabled lassen?

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

Content-ID: 4196052255

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

Ausgedruckt am: 21.11.2024 um 18:11 Uhr

19 Kommentare

Neuester Kommentar

Servus,

leg ein L2TP Interface mit dem usernames an, dann hast du ein statisches Interface für die Firewall.

LG

Es gilt im Regelwerk, wie immer bei Firewalls, "First match wins".
Setze also VORHER ein ALLOW für

UDP 500
UDP 1701
UDP 4500
ESP Protokoll

und erst dann deine DROP Regel. Dann wird ein Schuh draus weil so immer zuerst die L2TP spezifischen Komponenten passieren dürfen und alles weiter dann durch deine Drop Regel gekillt wird.
Ist doch im Mikrotik L2TP Tutorial auch explizit beschrieben so!! (Regeln 1 bis 4)
Lesen hilft! 😉

@epixcore: Ich habe versucht, eine Interface-Liste mit <l2tp-name> anzulegen, aber der wird zu unknow, wenn die VPN-Session beendet wird. Außerdem müsste ich, für den Fall dass mehrere User dasselbe VPN gleichzeitig verwenden, die Interface-Liste auf <l2tp-name-1>,<l2tp-name-2>, <l2tp-name-3>, usw. erweitern. Ok, das könnte ich auf maximal z.B. 5 begrenzen. Aber auch die werden wieder zu unknown ...

@aqui: Ich habe doch diese ALLOW-Regeln am Anfang drin stehen!

Mach dir das Leben leicht und übernehme einfach die FW Regeln der Default Konfig. Da funktioniert das alles fehlerlos. 😉

Hallo @aqui: Ich habe die Advanced Regeln von https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall verwendet.
Was ich eigentlich möchte ist, dass man über VPN nicht auf das Routerboard kommt, sondern nur lokal über VLAN 1, und dass VPN ansonsten funktioniert.

Ich bekomme ja mit der letzten drop Regel eine VPN-Verbindung. Aber ich kann den lokalen Raspi in VLAN 30 nur erreichen, wenn ich diese input Drop-Regel entferne.
Als Forward-Regel habe ich

add action=accept chain=forward comment="VPN RASPI" dst-address-list=Raspi dst-port=22,80 out-interface=vlan30 protocol=tcp  

Mit diesem Regelwerk rennt es fehlerfrei und ohne das man auf das Routerboard per VPN kommt. Weder mit SSH noch GUI oder Telnet.

/interface list
add comment=WAN-Ports name=WAN
add comment=LAN-Ports name=LAN

/interface list member
add comment="WAN/Internet List" interface=ether1 list=WAN  
add comment="Local LAN List" interface=vlan1 list=LAN  
add interface=vlan10 list=LAN
add interface=vlan20 list=LAN

/ip firewall filter
add action=accept chain=input comment="L2TP erlauben" dst-port=500 protocol=udp  
add action=accept chain=input dst-port=1701 protocol=udp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
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=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN   

Oder als WinBox Screenshot

Entsprich den Default Regeln mit NAT auf eth1.

Bitte Kommentar unten verwenden

@aqui: Vielen Dank für die Config. Genaus so habe ich es gemacht.

Die Verbindung zu dem Raspi in VLAN 30 über VPN funktioniert nur, wenn ich die Regel "drop all not coming from LAN" einmal disable, und nach der Verbindung wieder enable. Also wenn die Verbindung einmal established wurde, funktioniert es dann weiterhin. Ich verstehe das nicht, denn ich möchte ja über VPN nicht auf das routerboard, sondern auf einen Rechner im VLAN 30. Und es hilft auch nicht, wenn ich die letzte forward drop-Regel weglasse.
Auch lokal von VLAN 10 komme ich nur auf die oben beschrieben Weise auf den RASPI!

Ein Testaufbau mit 3 mal /27er VLANs funktioniert hier fehlerlos.
Das ist aber auch logisch, zumindestens für den Windows eigenen L2TP Client.
In den erweiterten IPv4 Eigenschaften des Clients kann man entweder ein Default Gateway über den L2TP Tunnel erzwingen (Gateway Redirect) oder mit Split Tunneling arbeiten.
Bei Letzterem fügt Windows immer eine klassenbasierte Route im Client hinzu!
Das Verhalten kann man auch genau beobachten: (Ausgabe gekürzt)

Mit Split Tunneling:

C:\Windows>route print -4  

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      10.99.1.254      10.99.1.148     25
     192.168.18.0    255.255.255.0     192.168.18.1    192.168.18.30     26
    192.168.18.30  255.255.255.255   Auf Verbindung     192.168.18.30    281
=========================================================================== 

Mit Gateway Redirect:

C:\Windows>route print -4 

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      10.99.1.254      10.99.1.148   4250
          0.0.0.0          0.0.0.0   Auf Verbindung     192.168.18.30     26
        10.99.1.0    255.255.255.0   Auf Verbindung       10.99.1.148   4506
=========================================================================== 

Proxy ARP ist einzig und allein nur für das VLAN 1 Interface im Mikrotik definiert!

Man sieht das zumindest Windows da noch im klassenbasierten IP Neantertal agiert und nicht CIDR orientiert ist.
192.168..x.y ist ein altes Class C Netz also mit einem /24er Prefix was dann an den VPN Client distribuiert wird wie man in der Routing Table bei aktivem Tunnel unschwer sieht. Das inkludiert in dem o.a. Falle dann auch alle 3 /27er VLANs.
Beim Redirect kommt dann eine Default Route mit besserer Metrik was dann ALLES in den Tunnel routet.
Das hat dann zumindestens bei den /27er VLANs den Effekt das, egal wie man das Client Verhalten setzt (Redirect oder Split Tunneling), hier alle 3 VLANs immer erreicht werden weil in beiden Verfahren immer alle 3 Netze inkludiert sind.

Im Falle einer /24er VLAN Adressierung ist das natürlich dann nicht mehr egal! Da werden dann /24er VLAN Netze ausschliesslich nur noch mit einem Gateway Redirect erreichbar sein! Oder....mit einer zusätzlichen statischen Route.
Hier könnte man dann den RFC 1918 172.16.0.0/12 er Block verwenden, den man dann mit einem /24er Prefix für die VLANs nutzt und Windows dann mit einer /16er Route versieht. (Class B).
Bei deinen 10er IPs ist es sogar eine /8er Router (Class A). 😉

Hm. ich habe ein iPhone als Client verwendet. Ansonsten habe ich nur Macs und Raspis im Netzwerk

Hast du da die HE.NET Tools drauf? https://apps.apple.com/de/app/he-net-network-tools/id858241710
Damit kannst du sehen was der für eine Routing Tabelle hat bei aktivem Tunnel. Ich meine das iPhone macht generell immer einen Redirect. Müsst ich aber auch mal cheken...

Ok, habe mit den HE.NET tools mal die Traceroute ermittelt:

Wenn die letzte Input-Regel "drop all not coming from LAN" aktiviert ist, wird kein HOP angezeigt, das Zahnrädchen dreht sich. Ist die Regel deaktiviert, bekomme ich diese Werte.

Und das ist dasselbe, ob ich über VPN gehe, oder per Wifi dran bin. Das iPhone ist dabei im VLAN 30.

/ip firewall filter
add action=accept chain=input comment=L2TP/IPSec dst-port=500,1701,4500 protocol=udp
add action=accept chain=input comment=L2TP/IPSec protocol=ipsec-esp
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 after RAW" protocol=icmp  
add action=accept chain=input comment="Allow vlan1 to access routerboard" in-interface=vlan1_default  
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN log=yes log-prefix=\  
    "INPUT DROPPED"  

Anstelle des letzten "drops" verwende ich deshalb

add action=drop chain=input comment="defconf: drop some ports" dst-port=22,23,80 log-prefix="INPUT DROPPED PORTS" protocol=tcp  

um das etwas abzusichern.

Und bei forward und NAT habe ich

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 \  
    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="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 tcp" in-interface=all-vlan log-prefix=UDP-WAN out-interface-list=WAN protocol=\  
    tcp
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="Raspi" dst-address-list=RaspiServer dst-port=22,80 out-interface=vlan30_heating \  
    protocol=tcp
add action=drop chain=forward log-prefix="DROPPED FORWARD"  

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN  
/ip firewall raw

bekomme ich diese Werte.

WELCHE denn?? Die Grafik ist leider nicht zu sehen.

Bitte die FAQs richtig lesen und embeddete Grafiken mit Klick auf + richtig im Kontext einbetten!!
Zurück zum Thema...

Ein finaler Test mit einem iPhone X (latest iOS) und einem älteren iPhone 8 brachte exakt das gleiche Verhalten wie bei Winblows.

iPhone L2TP Setup

Der iPhone VPN Client hat ebenso wie der Windows Client die Option Gateway Redirect oder Split Tunneling. Schalter "Gesamten Verkehr senden"

Ebenso wie der Windows Client sendet er im Split Tunnel Mode eine klassenbasierte Maske so das es auch hier mit dem /27er Prefix wieder egal ist ob man alles in den Tunnel sendet oder nur Relevantes im Split Tunnel Mode.

VLAN Ping Check

Ein Ping mit dem HE.NET Tool in alle 3 Mikrotik VLANs verläuft dann auch erfolgreich und ohne jegliche Probleme!

Fazit

Works as designed! 👍😉

Hi @aqui,

sorry, hier das Foto wenn die Input-Drop-Regel deaktiviert ist:

Auf dem iPhone habe ich bei VPN "Gesamten Verkehr senden" eingeschaltet.

Aber wie gesagt, das hat erst einmal gar nichts mit VPN zu tun, weil ich auch im WLAN-Netz vom VLAN10 den Raspi im VLAN30 nicht erreichen kann, wenn diese Input-Drop Regel aktiviert ist. Ich verstehe nicht, was das mit "input" zu tun hat, denn das sollte doch nur "forward" betreffen?

sorry, hier das Foto wenn die Input-Drop-Regel deaktiviert ist:

Warum klickst du nicht den Bearbeiten Button im Originalthread und fügst das Bild DORT im richtigen Kontext ein anstatt es logisch so auseinanderzureissen. Macht das Troubleshooting nur komplizierter...

Ich verstehe nicht, was das mit "input" zu tun hat, denn das sollte doch nur "forward" betreffen?

Da hast du allerdings Recht. Das sollte keinerlei Einfluss haben.
Auf alle Fälle ist etwas an deinem Regelwerk dann grundsätzlich falsch. Wie bereits gesagt, ich nutze das Default Regelwerk der automatischen Default Konfiguration und damit gibt es keinerlei Probleme. Weder zwischen den VLANs noch mit dem remoten Zugang zu allen VLANs. Router OS ist die Stable 7.5.

Ok, vielen Dank. Ich muss dann wohl nochmal von vorne beginnen.

Wie immer liegt der Teufel im Detail aber eine Lösung ist kinderleicht so das der L2TP VPN Client auch den MT DNS verwendet um lokale IP Adressen in den lokalen VLANs auflösen zu können.
Ein Eintrag im Mikrotik Forum bringt einen dann auf die richtige Spur.... 😉

Fakt ist das das Default Regelwerk der Firewall (zu Recht) keine Zugriffe von außen auf lokale IP Adressen zulässt. Das gilt auch fürs VPN.
Auch wenn der L2TP Server per Default beim VPN Dialin immer den MT DNS dem VPN Client mitgibt, scheitert dann ein TCP/UDP Zugriff mit Port 53 auf den MT an dessen Firewall Regelwerk.

Man sieht es hier sehr schön an den L2TP VPN Credentials des PPP Tunnelinterfaces mit einem MT der als lokales LAN ein 192.168.18.0 /28er Netz betreibt, selber die .1 hat und dem L2TP Client über den VPN Server die .30 vergibt aus diesem Netz.

PPP-Adapter Mikrotik L2TP:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Mikrotik L2TP
   Physische Adresse . . . . . . . . :
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::3ccb:4b46:66be:a111%50(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.18.30(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.255
   Standardgateway . . . . . . . . . : 0.0.0.0
   DHCPv6-IAID . . . . . . . . . . . : 671097690
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-B5-E8-14-00-23-5A-4F-02-33
   DNS-Server  . . . . . . . . . . . : 192.168.18.1
                                       10.99.1.254
   NetBIOS über TCP/IP . . . . . . . : Aktiviert 

IP Adresse also richtig vergeben, primärer DNS Server ist der lokale MT über PPP und die .1 ist physisch pingbar. Alles eigentlich OK. Works as designed.... 😉

Allerdings scheitert die DNS Abfrage eines lokalen Hosts obwohl der richtige DNS Server angefragt wurde:

> nslookup zeropi.mikrotik.intern
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.18.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown. 

So etwas wie die o.a. fehlende Antwort des DNS Servers bei problemloser IP Erreichbarkeit weist so gut wie immer auf ein Firewall Problem hin bzw. ein falsches Regelwerk für DNS TCP/UDP 53 Daten, was hier auch der Fall ist.

Die Lösung ist, wie immer, einfach und schnell erledigt indem man DNS (TCP/UDP 53) Traffic der L2TP Clients auf die lokale IP des MT in der FW erlaubt.
Dafür legt man eine FW Adressliste an, die die Client IP Adressen enthält oder nimmt ein kleines Subnetz für die L2TP Client Adressen.

Et voila....
Schon klappt dann auch die Abfrage der lokalen Hostnamen über den VPN Tunnel:

> nslookup zeropi.mikrotik.intern
Server:  UnKnown
Address:  192.168.18.1

Nicht autorisierende Antwort:
Name:    zeropi.mikrotik.intern
Address:  192.168.18.80


> ping -n 2 zeropi.mikrotik.intern

Ping wird ausgeführt für zeropi.mikrotik.intern [192.168.18.80] mit 32 Bytes Daten:
Antwort von 192.168.18.80: Bytes=32 Zeit=1ms TTL=63
Antwort von 192.168.18.80: Bytes=32 Zeit=1ms TTL=63

Ping-Statistik für 192.168.18.80:
    Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms 

Kleine Ursache, große Wirkung! Works as designed.... 😉

Wow, und das am Sonntag!

Es funktioniert! Ich bin beim Suchen sogar mal über diesen Port 53 gestolpert, habe das dann aber nicht weiter verfolgt. Es wird ja so viel gepostet!

Ganz herzlichen Dank aqui.

Schönen Abend noch

#ArcorPi