markushi
Goto Top

VPN via IKEv2: kein Zugriff auf Remote Netz

Hallo zusammen,

ich habe mir einen Debian 11 VPN Server nach diesem Tutorial eingerichtet: IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi

Die Einwahl von Windows als auch Android funktioniert und ich sehe via swantctl -T die erfolgreiche Verbindung. Jedoch kann ich nicht auf das Heimnetz zugreifen, also keine Dienste aufrufen noch eine IP anpingen. Meine swantctl sieht so aus:

connections {
  ikev2-mobile-defaults {
     unique = replace
     version = 2
     proposals = aes256-sha512-modp2048,aes256-sha256-modp2048,aes256-sha256-modp1024
     send_cert = always
     pools = pool-ipv4
     local_addrs = *********** (lokale IP des VPN Servers)
     remote_addrs = 0.0.0.0/0,::/0
         local {
         auth = pubkey
         certs = server-cert.pem
         id = fqdn:*********** (fqdn wie der Server von außen erreichbar ist)
         }
         remote {
         id = %any
         auth = eap-mschapv2
         eap_id = %any
         }
    children {
       ikev2-mobile {
          local_ts = 0.0.0.0/0
          esp_proposals = aes256-sha512,aes256-sha384,aes256-sha256,aes256-sha1
          start_action = trap
       }
     }
  }
}
pools {
  pool-ipv4 {
    addrs = 172.10.1.0/24
    dns = 172.10.1.230
    }
  }
secrets {
 eap-1 {
     id = user1
     secret = "user1pw"  
     }
 eap-2 {
     id = user2
     secret = "user2pw"  
     }
}

Das ip Forwarding ist aktiviert und im lokal device habe ich eine passende IP hinterlegt. Jemand eine Idee, woran das liegen könnte? Am Router habe ich Port 500 + 4500 tcp+udp zum VPN Server weitergeleitet.

Grüße

Content-ID: 3595223091

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

Ausgedruckt am: 21.11.2024 um 20:11 Uhr

markushi
markushi 25.10.2023 um 22:36:13 Uhr
Goto Top
Ergänzung: vom Server kann ich den eingewählten Client anpingen und vom Client kann ich auf die festgelegte IP des VPN Servers pingen. Es ist also so, als ob der Server keine anderen Pakete forwarden würde!?? Die systclt.conf habe ich aber wie beschrieben angepasst und eine Firewall (UFW) ist noch nicht aktiv am VPN Server.
7907292512
Lösung 7907292512 25.10.2023 aktualisiert um 23:07:31 Uhr
Goto Top
Wohl vergessen die statische Route auf dem Default-GW im Netz des Servers für das VPN Netz (172.10.1.0/24) zu hinterlegen.
Also am Router des Server-Netzes diese hinzufügen
NETZ 172.10.1.0
MASKE 255.255.255.0
GW [IP-DES-DEBIAN]

Des weiteren nicht die Firewall der Clients im Server Netz vergessen . Denn Winblows blockt bekanntlch bei ICMP und SMB fremde Subnetze, das muss man bei diesen in der Firewall customizen.

Gruß Sid.
markushi
markushi 25.10.2023 um 23:10:40 Uhr
Goto Top
Zitat von @7907292512:

Wohl vergessen die statische Route auf dem Default-GW im Netz des Servers für das VPN Netz (172.10.1.0/24) zu hinterlegen.
Also am Router des Server-Netzes diese hinzufügen
NETZ 172.10.1.0
MASKE 255.255.255.0
GW [IP-DES-DEBIAN]

Des weiteren nicht die Firewall der Clients im Server Netz vergessen . Denn Winblows blockt bekanntlch bei ICMP und SMB fremde Subnetze, das muss man bei diesen in der Firewall customizen.

Gruß Sid.

Mit "Router des Server-Netzes" meinst du da den DSL-Router der die Paket forwarded oder den VPN-Server selber?
Sorry, steh da grad aufm Schlauch 🤷‍♂️
markushi
markushi 25.10.2023 um 23:16:23 Uhr
Goto Top
Ich hab das Netz am Router hinterlegt, jetzt gehts!


VIELEN DANK @7907292512
7907292512
7907292512 25.10.2023 aktualisiert um 23:30:45 Uhr
Goto Top
Keine Ursache. Immer an die Rückroute der Pakete denken 😉👍.
aqui
aqui 26.10.2023 aktualisiert um 11:21:25 Uhr
Goto Top
Danke für den Hinweis. Das war ein Fehler im Tutorial der zumindestens bei einem Design mit VPN Server innerhalb des lokalen LANs leider den Hinweis auf die statische Route im Internet Router unterschlagen hatte. Ist inzwischen korrigiert. 😉
vpnstrong.

Wenn die statische Route im Internet Router auf den IP Pool bzw. internes IP Netz der VPN Clients fehlt, kann die Kommunikation mit anderen Clients im lokalen Netzwerk nicht funktionieren weil, wie Kollege @7907292512 richtig sagt, die Rückroute dann scheitert!