alve89
Goto Top

Konfiguration für IPsec VPN ohne L2TP

Hallo zusammen,

da ich bisher nirgends eine Lösung für mein Problem gefunden habe, wende mich an euch.

Ich habe:
- MikroTik hap ac2 mit routerOS 7.10
- Apple Geräte
- bisher eine funktionierende VPN-Verbindung auf Basis von L2TP und IPsec
- eine sehr bescheidene Netzwerk-Geschwindigkeit, obwohl das iPhone eine 5G- und mein Router einen 50 MBit-Verbindung hat

Bzgl. der Geschwindigkeit habe ich auch diesen Vergleich gefunden: https://rickfreyconsulting.com/mikrotik-vpns/

Daher möchte ich eine einfache VPN-Verbindung nur auf Basis von IPsec zur Verfügung stellen, über die ich mich von außerhalb meines Heimnetzwerk über mein iPhone mit meinem Netzwerk verbinden kann.
Eine Hilfestellung zur Erstellung eines reinen IPsec-VPNs (ohne site-to-Site Szenario) habe ich bisher nichts gefunden - daher die Suche nach Hilfe hier.

Wie konfiguriere ich meinen Router für eine Nutzung / Bereitstellung eines nur IPsec-basierten VPN?

Ich hoffe auf eure Hilfe… danke im Voraus!

Danke und Grüße!

Content-ID: 8129210966

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

Ausgedruckt am: 22.11.2024 um 08:11 Uhr

aqui
Lösung aqui 13.08.2023 aktualisiert um 17:46:52 Uhr
Goto Top
IKEv2 VPN ist das Zauberwort. face-wink
https://forum.mikrotik.com/viewtopic.php?t=172778
https://jcutrer.com/howto/networking/mikrotik/ios-ikev2-vpn-mikrotik
Lehnt sich entsprechend an das hiesige pfSense/OPNsense IKEv2 VPN Tutorial an.
Für MT gibt es außer dem o.a. noch weitere Tutorials wenn man nach „IKEv2“ sucht. 😉
alve89
alve89 13.08.2023 um 18:15:27 Uhr
Goto Top
Danke @aqui für deine schnelle Antwort (von wem auch sonst)!
Interpretiere ich deine Nachricht dahingehend richtig, dass ein reiner IPsec-Tunnel mit routerOS nicht möglich ist? Oder ist IKEv2 eine bessere Alternative dazu (und wenn ja warum)?
aqui
aqui 13.08.2023 aktualisiert um 19:29:38 Uhr
Goto Top
Leider interpretierst du das völlig falsch. IKEv2 ist Teil von nativem IPsec.
Guckst du hier:
https://de.m.wikipedia.org/wiki/IPsec
Lesen und verstehen! 😉
alve89
alve89 14.08.2023 um 05:08:19 Uhr
Goto Top
Das habe ich mittlerweile auch rausgefunden. 😄
Worin liegt dann jedoch dahingehend der Unterschied, dass iOS beide Optionen anbietet? Gibt es nennenswerte Vor-/Nachteile (z. B. Geschwindigkeit)?

Meine ursprüngliche Frage ist zwar (zumindest teilweise) beantwortet, für eine kurze Aufklärung wäre ich dir interessehalber jedoch sehr dankbar. 😊
aqui
aqui 14.08.2023 aktualisiert um 10:39:49 Uhr
Goto Top
IKEv2 ist das modernere Verfahren. v1 bietet iOS nur noch für den Cisco Client an. IKEv2 ist auch das Verfahren was alle anderen Betriebssysteme, Smartphones usw. onboard haben. Es ist ein deutlich effizienteres Schlüsselaustausch Verfahren als das ältere IKEv2 im IPsec.
https://www.heise.de/hintergrund/Einfacher-VPN-Tunnelbau-dank-IKEv2-2700 ...
Es macht also Sinn v2 zu verwenden wenn immer möglich und Mikrotik supportet das natürlich auch wie du oben siehst! face-wink
alve89
alve89 20.03.2024 um 10:10:59 Uhr
Goto Top
Ich muss nochmal auf dieses Thema zurückkommen, da ich es gestern endlich mal geschafft habe, mich mal wieder damit auseinanderzusetzen - und der VPN-Aufbau mittels IKEv2 funktioniert nun. Ich bekomme eine IP-Adresse aus dem DHCP-Pool, soweit alles gut.

Innerhalb des privaten Netzwerks ohne VPN funktioniert alles tadellos. Innerhalb des privaten Netzwerks durch den VPN-Tunnel funktioniert es nicht:
  • Ich kann nicht auf interne Adressen zugreifen
  • * weder per IP
  • * noch per Domainname.

Ich habe zwar verschiedene Konfigurationen ausprobiert und den DNS-Server unter /ip/ipsec sowie unter /ip/dns sowie unter /ip/dhcp-server/network geändert, jedoch ohne Erfolg.

Wichtige grundlegende Infos:
  • Der Mikrotik-Router ist die 192.168.20.1,
  • mein Pi-Hole als DNS-Server ist die 192.168.20.196, dieser greift als Public-DNS-Server zu auf
  • Google und OpenDNS.
  • Die hier gegenständliche VPN-Konfiguration ist die mit vpn.ike2.xyz.

Nachfolgend die aus meiner Sicht wichtigsten Config-Auszüge:
# 2024-03-20 07:18:01 by RouterOS 7.14.1
# software id = 1758-TR55
#
# model = RBD52G-5HacD2HnD
# serial number = HCB07SRYMAG
/ip dhcp-server
add address-pool=default-dhcp disabled=yes interface=bridge lease-time=10m \
    name=defconf
add address-pool=dhcp interface=bridge_k41 lease-script=dhcp-mdns-script-k41 \
    lease-time=10m name=dhcp_k41
add address-pool=dhcp-pool-k4 interface=bridge_4 lease-script=\
    dhcp-mdns-script-k4 lease-time=10m name=dhcp_k4
add address-pool=dhcp_poolTemp interface=bridgeTemp lease-time=10m name=\
    dhcpTemp
/ip dhcp-server lease
add address=192.168.20.112 client-id=1:50:ec:50:e:41:74 mac-address=\
    50:EC:50:0E:41:74 server=dhcp_k4
/ip dhcp-server network
add address=192.168.2.0/24 dns-server=192.168.2.1 gateway=192.168.2.1
add address=192.168.10.0/24 dns-server=192.168.10.1 domain=lan.k41 gateway=\
    192.168.10.1
add address=192.168.20.0/24 dns-server=192.168.20.1 domain=lan.k4 gateway=\
    192.168.20.1

# 2024-03-20 07:14:48 by RouterOS 7.14.1
# software id = 1758-TR55
#
# model = RBD52G-5HacD2HnD
# serial number = HCB07SRYMAG
/ip dns
set allow-remote-requests=yes servers=192.168.20.196
/ip dns static
add address=192.168.10.1 comment=defconf name=router.lan
add address=192.168.20.10 comment="Manually added intercom" name=\  
    doorbell.lan.k4
add address=192.168.10.30 comment="Manually added" name=doorbell.lan.k41  
add address=192.168.20.164 comment="Manually added" name=sw02.lan.k4  
add address=192.168.20.112 name=roborock-e1.lan.k4
add address=192.168.20.153 comment=#Dynamic-DHCP-mDNS name=displayog.lan.k4 \
    ttl=10m
add address=192.168.20.111 name=roborock-e0.lan.k4 ttl=10m
add address=192.168.10.106 comment=#Dynamic-DHCP-mDNS name=\
    wt32-eth01-01-fp-frontdoor.lan.k41 ttl=10m
add address=192.168.10.129 comment=#Dynamic-DHCP-mDNS name=\
    centralcontrol.lan.k41 ttl=10m
add address=192.168.10.104 comment=#Dynamic-DHCP-mDNS name=fbprnts.lan.k41 \
    ttl=10m
add address=192.168.20.198 comment=#Dynamic-DHCP-mDNS name=sw01.lan.k4 ttl=\
    10m
add address=192.168.20.196 comment=#Dynamic-DHCP-mDNS name=homecontrol.lan.k4 \
    ttl=10m
add address=192.168.10.105 comment=#Dynamic-DHCP-mDNS name=devolo-334.lan.k41 \
    ttl=10m
add address=192.168.20.133 comment=#Dynamic-DHCP-mDNS name=\
    wt32-eth01-02-fp-frontdoor.lan.k4 ttl=10m
add address=192.168.10.108 comment=#Dynamic-DHCP-mDNS name=\
    sonoff-s20-06-entertainm-willi.lan.k41 ttl=10m
add address=192.168.20.193 comment=#Dynamic-DHCP-mDNS name=ap02.lan.k4 ttl=\
    10m
add address=192.168.20.169 comment=#Dynamic-DHCP-mDNS name=\
    Denon-AVR-S660H.lan.k4 ttl=10m
add address=192.168.20.194 comment=#Dynamic-DHCP-mDNS name=SonosZP.lan.k4 \
    ttl=10m
add address=192.168.20.159 comment=#Dynamic-DHCP-mDNS name=SonosZP.lan.k4 \
    ttl=10m
add address=192.168.10.107 comment=#Dynamic-DHCP-mDNS name=frprnts.lan.k41 \
    ttl=10m
add address=192.168.10.111 comment=#Dynamic-DHCP-mDNS name=devolo-159.lan.k41 \
    ttl=10m
add address=192.168.10.113 comment=#Dynamic-DHCP-mDNS name=devolo-931.lan.k41 \
    ttl=10m
add address=192.168.20.142 comment=#Dynamic-DHCP-mDNS name=ap03.lan.k4 ttl=\
    10m
add address=192.168.20.137 comment=#Dynamic-DHCP-mDNS name=ap01.lan.k4 ttl=\
    10m
add address=192.168.20.127 comment=#Dynamic-DHCP-mDNS name=\
    Samsung-Washer.lan.k4 ttl=10m
add address=192.168.20.120 comment=#Dynamic-DHCP-mDNS name=\
    sonoff-s20-05.lan.k4 ttl=10m
add address=192.168.20.113 comment=#Dynamic-DHCP-mDNS name=SonosZP.lan.k4 \
    ttl=10m
add address=192.168.10.103 comment=#Dynamic-DHCP-mDNS name=\
    sonoff-s20-07-entertainm-ellen.lan.k41 ttl=10m
add address=192.168.20.191 comment=#Dynamic-DHCP-mDNS name=\
    roborock-vacuum-a15.lan.k4 ttl=10m
add address=192.168.20.166 comment=#Dynamic-DHCP-mDNS name=\
    DWS-GM02JVAA.lan.k4 ttl=10m
add address=192.168.20.184 comment=#Dynamic-DHCP-mDNS name=\
    WIZnetEFFEED.lan.k4 ttl=10m
add address=192.168.10.119 comment=#Dynamic-DHCP-mDNS name=localhost.lan.k41 \
    ttl=10m
add address=192.168.10.133 comment=#Dynamic-DHCP-mDNS name=PRINTER.lan.k41 \
    ttl=10m

# 2024-03-20 09:47:53 by RouterOS 7.14.1
# software id = 1758-TR55
#
# model = RBD52G-5HacD2HnD
# serial number = HCB07SRYMAG
/ip firewall connection tracking
set udp-timeout=10s
/ip firewall filter
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="Allow VPN from outside" \  
    connection-state=new dst-port=500,1701,4500 in-interface=pppoe-out1 log=\
    yes protocol=udp
add action=accept chain=input in-interface=pppoe-out1 log=yes protocol=\
    ipsec-esp
add action=accept chain=input comment="Allow SSH to Router from Bridge K4" \  
    dst-address=192.168.20.1 dst-port=22 in-interface=bridge_4 protocol=tcp
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=accept chain=input comment=CAP->LAN disabled=yes in-interface=\
    bridge_4 protocol=udp src-port=5246,5247
add action=accept chain=input comment=LAN->CAP disabled=yes dst-port=\
    5246,5247 in-interface=bridge_4 protocol=udp
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

# 2024-03-20 10:09:12 by RouterOS 7.14.1
# software id = 1758-TR55
#
# model = RBD52G-5HacD2HnD
# serial number = HCB07SRYMAG
/ip ipsec mode-config
add address-pool=dhcp-pool-k41-vpn name=l2tp-vpn-mode-config
add address-pool=dhcp-pool-k4-vpn name="modeconf vpn.ike2.xyz"  
/ip ipsec policy group
add name="group vpn.ike2.xyz"  
/ip ipsec profile
add dh-group=modp1024 enc-algorithm=aes-256,3des name=l2tp-vpn-peer-profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=\
    "profile vpn.ike2.xyz"  
/ip ipsec peer
add exchange-mode=ike2 name="peer 192.168.20.234 vpn.ike2.xyz" passive=yes \  
    profile="profile vpn.ike2.xyz" send-initial-contact=no  
# This entry is unreachable
add name=ipsec-vpn-peer passive=yes profile=l2tp-vpn-peer-profile
/ip ipsec proposal
add enc-algorithms=aes-256-cbc,3des name=l2tp-vpn-proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-256-gcm lifetime=8h \
    name="proposal vpn.ike2.xyz" pfs-group=none  
/ip ipsec identity
add peer=ipsec-vpn-peer
add auth-method=digital-signature certificate=vpn.ike2.xyz generate-policy=\
    port-strict match-by=certificate mode-config="modeconf vpn.ike2.xyz" \  
    peer="peer 192.168.20.234 vpn.ike2.xyz" policy-template-group=\  
    "group vpn.ike2.xyz" remote-certificate=c1@vpn.ike2.xyz remote-id=\  
    fqdn:c1@vpn.ike2.xyz
/ip ipsec policy
add dst-address=0.0.0.0/0 proposal=l2tp-vpn-proposal src-address=0.0.0.0/0 \
    template=yes
add dst-address=192.168.20.0/24 group="group vpn.ike2.xyz" proposal=\  
    "proposal vpn.ike2.xyz" src-address=0.0.0.0/0 template=yes  

Mein Ziel ist einmal als oberste Priorität eine VPN-Verbindung mit Zugriff auf private sowie public Adressen per DNS (alle Adressen sollen über meine public Router-Adresse und nicht über meine VPN-Client-Public-IP aufgerufen werden) => ungesplitteter VPN.
Als nice-to-have wäre dann noch eine zweite Konfiguration als gesplitteter VPN, bei dem nur die privaten Adressen über den Tunnel laufen und die öffentlichen über die Public-IP des VPN-Clients.

Könntest du mir hier bitte nochmal helfen?
aqui
Lösung aqui 20.03.2024 aktualisiert um 10:29:01 Uhr
Goto Top
Warum bist du denn so gegen L2TP?? Das würde dir dein Leben mit dem Client VPN deutlich erleichtern und klappt auf Anhieb in 10 Minuten, aber nundenn...

Die IKEv2 Variante erfordert Zertifikate in einem Client VPN was du ja schon in der IKEv2 Lösung für die pfSense und OPNsense Firewall sehen kannst. (Gilt nicht für ein Site-2-Site Setup!)
Auch das musst du mit dem Mikrotik umsetzen. Es gibt 2 gute Dokus die die ToDos beschreiben und mit denen es auch fehlerlos funktioniert:
https://mum.mikrotik.com/presentations/MY19/presentation_7008_1560543676 ...
https://mum.mikrotik.com/presentations/CN19/presentation_7073_1571797375 ...
Vielleicht vergleichst du das einmal mit deinem Setup.
alve89
alve89 20.03.2024 um 12:11:46 Uhr
Goto Top
Warum bist du denn so gegen L2TP??
Weil ich die subjektive Wahrnehmung hatte, dass damit öffentliche Adressen aufgrund der Geschwindigkeiteinbußen kaum noch nutzbar sind. Die objektive Bestätigung fand ich hier: rickfreyconsulting.com/mikrotik-vpns/

Des Weiteren kann ich damit Nutzer in RouterOS nur einem einzelen Subnetz zuweisen.

Mit dieser Doku habe ich die IKEv2-Lösung gestern umgesetzt bekommen. Ich hatte jedoch die Konfiguration mit dem Subnetz 10.88.0.0/32 nicht gemacht. Das habe ich nun zwar nachgeholt, den Sinn verstehe ich jedoch nicht.
Ich kann nun zwar auf interne IP-Adressen zugreifen, jedoch nicht per Hostname. Ebenfalls kann ich keine öffentlichen Adressen per DNS aufrufen. Das Problem der gesamthaften Lösung steht noch aus. Woran könnte es nun noch liegen (evtl. in Hinblick auf den Pi-Hole)?

In dieser Dokumentation steht bezüglich meines Problems nichts, da geht es um die Erreichbarkeit des VPN-Servers (DDNS).
aqui
aqui 20.03.2024 um 12:24:37 Uhr
Goto Top
aufgrund der Geschwindigkeiteinbußen
"Geschwindigkeitseinbußen"??? Das Fundament ist doch immer IPsec und bei L2TP gleich. Ein Client L2TP nutzt ja für den Tunnel immer IPsec mit IKEv1. Die Version spielt beim Netto Durchsatz bei IPsec bekanntlich keinerlei Rolle.
Der von dir zitierte Typ redet von nativem L2TP, was aber nichts mit dem üblichen L2TP Client VPN außer der Authentisierung gemein hat denn hier wird wird der RFC 3139 umgesetzt.
Kann es sein das du hier Äpfel mit Birnen vergleichst??
auf interne IP-Adressen zugreifen, jedoch nicht per Hostname.
Das liegt daran das du sehr wahrscheinlich vergessen hast die DNS Server IP an den VPN Client zu übergeben. Fehlt das nutzt der seinen Default DNS der dann interne IPs natürlich nicht auflösen kann.
alve89
alve89 20.03.2024 aktualisiert um 12:39:26 Uhr
Goto Top
Ein Client L2TP nutzt ja für den Tunnel immer IPsec mit IKEv1
Ich meine das hier:
l2tp

Kann es sein das du hier Äpfel mit Birnen vergleichst??
Das schließe ich aufgrund meiner Kompetenz als Laie nicht aus.

Geschwindigkeitseinbußen
Die gibt es dennoch, ich konnte damit "größere" Datenmengen (Website mit Bildern) nicht mehr laden.

Und zu guter Letzt bleibt noch die Subnetz-Problematik. Aus diesem Grund fand ich die von dir vorgeschlagene IKEv2-Lösung gut, die in allen Problemen Besserung bringt (wenn doch nur das DNS noch ordentlich funktionieren würde).

Unter /ip/ipsec/mode-config definiere ich, dass das System-DNS genutzt werden soll:
ipsec.modeconfig

Unter /ip/dns definiere ich, dass der Pi-Hole als DNS genutzt werden soll:
dns

Und unter /ip/dhcp-server/networks definiere ich, dass der Router als DNS übergeben werden soll (so dass auch die internen Adressen bekannt sind):
dhcp.network


Was mache ich falsch?
aqui
aqui 20.03.2024 aktualisiert um 13:23:31 Uhr
Goto Top
Ich meine das hier:
Per se ohne die weiteren Konfigparameter zu kennen ist das erstmal natives L2TP aber in den L2TP Server Settings musst du ja bei einem L2TP Client VPN immer "IPsec" anhaken um deren Vorgabe RFC 3139 zu erfüllen! Onboard L2TP Clients supporten bekanntlich KEIN native L2TP.
ipsec
Zumindesten dann wenn du das Mikrotik L2TP Tutorial aufmerksam und genau gelesen und auch verstanden hast!!
Fazit: Äpfel mit Birnen! face-sad

Was mache ich falsch?
IKEv2 nutzt kein DHCP für die Vergabe der Client IP Adressen und DNS! Siehe dazu auch hier.
Wenn du einen aktiven Tunnel aufgebaut hast checke welche DNS Server IP dir als Client propagiert wurde mit ipconfig -all. Auf einem Smartphone nutzt du dafür die bekannten HE.NET Tools aus dem App Store.
alve89
alve89 22.03.2024 um 08:51:07 Uhr
Goto Top
Zumindesten dann wenn du das Mikrotik L2TP Tutorial aufmerksam und genau gelesen und auch verstanden hast!!
Das habe ich auch genauso gemacht. face-smile
Es hat funktioniert auch, aber eben nur unter den genannten Einschränkungen (Geschwindigkeit und Subnetzzuweisung).

Wenn du einen aktiven Tunnel aufgebaut hast checke welche DNS Server IP dir als Client propagiert wurde
Das habe ich nun gemacht:

/ip/ipsec/mode-config export hide-sensitive =>
add address-pool="pool vpn.ike2.xyz" address-prefix-length=32 name="modeconf vpn.ike2.xyz" split-include=0.0.0.0/0  
Das ergibt in den HE.NET Tools als default DNS: 192.168.20.196 (Pi-Hole):
  • Public DNS funktioniert
  • Private DNS funktioniert nicht
Das ist für mich nachvollziehbar, weil der Pi-Hole die privaten DNS-Einträge nicht kennt, da die auf dem MT befinden, und lediglich alles an Google bzw. OpenDNS schickt und die Rückgabe filtert.


add address-pool="pool vpn.ike2.xyz" address-prefix-length=32 name="modeconf vpn.ike2.xyz" split-include=0.0.0.0/0 static-dns=10.88.0.1 system-dns=no  
Das ergibt in den HE.NET Tools als default DNS: 10.88.0.1:
  • Public DNS funktioniert nicht
  • Private DNS funktioniert nicht

Konsequenz daraus:
add address-pool="pool vpn.ike2.xyz" address-prefix-length=32 name="modeconf vpn.ike2.xyz" split-include=0.0.0.0/0 static-dns=192.168.20.1 system-dns=no  
Das ergibt in den HE.NET Tools als default DNS: 192.168.20.1:
  • Public DNS funktioniert
  • Private DNS funktioniert

(Mal wieder) Danke! face-smile
aqui
aqui 22.03.2024 um 10:37:59 Uhr
Goto Top
weil der Pi-Hole die privaten DNS-Einträge nicht kennt,
Das kann man dem ja im Handumdrehen beibringen! face-wink
https://discourse.pi-hole.net/t/howto-using-pi-hole-as-lan-dns-server/53 ...
Danke!
Immer gerne! 😊