19
Mikrotik input rule for l2tp vpn
Hallo,
wenn ich die letzte Input-Regel auf enable setze, dann funktioniert mein VPN nicht mehr, wegen:
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?
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?
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: 4196052255
Url: https://administrator.de/forum/mikrotik-input-rule-for-l2tp-vpn-4196052255.html
Ausgedruckt am: 22.12.2024 um 06:12 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
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
Ist doch im Mikrotik L2TP Tutorial auch explizit beschrieben so!! (Regeln 1 bis 4)
Lesen hilft! 😉
Setze also VORHER ein ALLOW für
- UDP 500
- UDP 1701
- UDP 4500
- ESP Protokoll
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!
@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
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.
Oder als WinBox Screenshot
Entsprich den Default Regeln mit NAT auf eth1.
/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
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!
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:
Mit Gateway Redirect:
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). 😉
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)
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
=========================================================================== 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
=========================================================================== 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...
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.
Anstelle des letzten "drops" verwende ich deshalb
um das etwas abzusichern.
Und bei forward und NAT habe ich
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 rawbekomme 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"
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:
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.
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:
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:
Kleine Ursache, große Wirkung! Works as designed.... 😉
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 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. 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.
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
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
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
Wow, und das am Sonntag!
Gerade am Sonntag!! 😉Ganz herzlichen Dank
Immer gerne!
