4
AWS Site-to-Site VPN mit Windows Server 2019
Hi,
ich habe eine VPN-Verbindung zwischen AWS und eine on-premises-Windows Server 2019 nach deren Anleitung halbwegs erfolgreich erstellt: https://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/customer-gateway-dev ...
ACLs und Security Groups sind korrekt eingerichtet, sodass ich direkt vom on-premises-Server auf eine EC2-Maschine bei AWS per SSH zugreifen kann. Mein Problem ist nun, wie ich von Geräten aus dem internen LAN (192.168.1.0/24) über den Windows Server in der DMZ (172.16.10.10/32) auf das verbundene AWS-Netz (10.1.0.0/16) zugreifen kann.
Ein Static Routing ist auf der Sophos UTM (Gateway der internen Clients, 192.168.1.100) aktiv: Netz 10.1.0.0/16 ist über 172.16.10.10 erreichbar.
Was funktioniert:
SSH von 172.16.10.10 (Windows Server RRAS) auf EC2 Linux-AMI (10.1.1.1/16)
Was nicht funktioniert:
SSH von 192.168.1.10 (Win10-Host mit Putty) auf EC2 Linux-AMI (10.1.1.1/16)
UTM Firewall-Log gibt nichts her, ich sehe nur bei einem Traceroute von 192.168.1.10 nach 10.1.1.1, dass Pakete korrekt an den Windows Server geroutet werden, dort aber an das Standard-Gateway (172.16.1.100) statt des VPN-Tunnels gesendet werden. Das führt zu einem Loop, weil das Standardgateway wegen der Static Route das Paket wieder zurückschickt.
Routenverfolgung zu 10.1.1.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms Sophos UTM Gateway [192.168.1.100]
2 1 ms * <1 ms 172.16.10.10
3 1 ms <1 ms <1 ms 172.16.1.100
4 1 ms * <1 ms 172.16.10.10
5 1 ms <1 ms <1 ms 172.16.1.100
Das Traceroute gibt das gleiche aus, egal ob ich auf der Defender-Firewall eine eingehende Regel aktiviere oder nicht (alles erlaubt aus 192.168.1.0/24). Das Defender-Log zeigt aber auch keine Blocked-Pakete an. Einzig Allow mit Protokolltyp 4 (Encapsulated) an die AWS-VPN-Gateway und die SSH-Verbindung an die EC2-Maschine nur vom Windows-Server selbst.
Ich kann auch nicht in Erfahrung bringen, ob man in der AWS-VPN-Konfiguration beide Remote-Netze eingeben muss oder überhaupt kann. Ich habe zumindest in der Defender Advanced Firewall bei den beidebn Tunneleinträgen das interne Netz dort hinzugefügt, wo das DMZ-Netz bereits drin war. (Verbindungssicherheitsregeln-> Eigenschaften einer Verbindung->Remotecomputer->Endpunkt 1-> Diese IP-Adressen: 172.16.0.0/16. Dort habe ich 192.168.1.0/24 hinzugefügt.
Desweiteren ist mir das Konzept des RRAS noch ein großes Rätsel. Ich sehe über Route Print keine Route in das AWS-Netz. Ist da die Defender Firewall für zuständig? Nur dort sehe ich das AWS-Netz 10.1.0.0/16.
Wie könnte ich denn überhaupt eine statische Route auf dem Windows Server einrichten, da ja kein VPN-Interface erzeugt wurde, wie ich das von Wireguard o. ä. kenne? Ach so...der Windows Server (RRAS) hat nur eine Netzwerkkarte.
Hoffe, ihr habt noch ein paar gute Tipps für mich übrig. Danke schonmal.
ich habe eine VPN-Verbindung zwischen AWS und eine on-premises-Windows Server 2019 nach deren Anleitung halbwegs erfolgreich erstellt: https://docs.aws.amazon.com/de_de/vpn/latest/s2svpn/customer-gateway-dev ...
ACLs und Security Groups sind korrekt eingerichtet, sodass ich direkt vom on-premises-Server auf eine EC2-Maschine bei AWS per SSH zugreifen kann. Mein Problem ist nun, wie ich von Geräten aus dem internen LAN (192.168.1.0/24) über den Windows Server in der DMZ (172.16.10.10/32) auf das verbundene AWS-Netz (10.1.0.0/16) zugreifen kann.
Ein Static Routing ist auf der Sophos UTM (Gateway der internen Clients, 192.168.1.100) aktiv: Netz 10.1.0.0/16 ist über 172.16.10.10 erreichbar.
Was funktioniert:
SSH von 172.16.10.10 (Windows Server RRAS) auf EC2 Linux-AMI (10.1.1.1/16)
Was nicht funktioniert:
SSH von 192.168.1.10 (Win10-Host mit Putty) auf EC2 Linux-AMI (10.1.1.1/16)
UTM Firewall-Log gibt nichts her, ich sehe nur bei einem Traceroute von 192.168.1.10 nach 10.1.1.1, dass Pakete korrekt an den Windows Server geroutet werden, dort aber an das Standard-Gateway (172.16.1.100) statt des VPN-Tunnels gesendet werden. Das führt zu einem Loop, weil das Standardgateway wegen der Static Route das Paket wieder zurückschickt.
Routenverfolgung zu 10.1.1.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms Sophos UTM Gateway [192.168.1.100]
2 1 ms * <1 ms 172.16.10.10
3 1 ms <1 ms <1 ms 172.16.1.100
4 1 ms * <1 ms 172.16.10.10
5 1 ms <1 ms <1 ms 172.16.1.100
Das Traceroute gibt das gleiche aus, egal ob ich auf der Defender-Firewall eine eingehende Regel aktiviere oder nicht (alles erlaubt aus 192.168.1.0/24). Das Defender-Log zeigt aber auch keine Blocked-Pakete an. Einzig Allow mit Protokolltyp 4 (Encapsulated) an die AWS-VPN-Gateway und die SSH-Verbindung an die EC2-Maschine nur vom Windows-Server selbst.
Ich kann auch nicht in Erfahrung bringen, ob man in der AWS-VPN-Konfiguration beide Remote-Netze eingeben muss oder überhaupt kann. Ich habe zumindest in der Defender Advanced Firewall bei den beidebn Tunneleinträgen das interne Netz dort hinzugefügt, wo das DMZ-Netz bereits drin war. (Verbindungssicherheitsregeln-> Eigenschaften einer Verbindung->Remotecomputer->Endpunkt 1-> Diese IP-Adressen: 172.16.0.0/16. Dort habe ich 192.168.1.0/24 hinzugefügt.
Desweiteren ist mir das Konzept des RRAS noch ein großes Rätsel. Ich sehe über Route Print keine Route in das AWS-Netz. Ist da die Defender Firewall für zuständig? Nur dort sehe ich das AWS-Netz 10.1.0.0/16.
Wie könnte ich denn überhaupt eine statische Route auf dem Windows Server einrichten, da ja kein VPN-Interface erzeugt wurde, wie ich das von Wireguard o. ä. kenne? Ach so...der Windows Server (RRAS) hat nur eine Netzwerkkarte.
Hoffe, ihr habt noch ein paar gute Tipps für mich übrig. Danke schonmal.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 7771369221
Url: https://administrator.de/contentid/7771369221
Printed on: May 17, 2024 at 08:05 o'clock
4 Comments
Latest comment
Leider ist die Beschreibung etwas oberflächlich denn du benennst nicht das VPN Protokoll was zum Einsatz kommt. 
Vermutlich ist es IPsec (geraten) und wie leider sehr oft der Fall hast du die 2te Phase 2 Definition mit dem 192.168.1.0/24 Netz vergessen?!
Mit der Phase 2 Definition bestimmst du bei IPsec bekanntlich welcher Traffic in den Tunnel geroutet wird. Deshalb ist auch eine statische Route auf dem VPN Router/Firewall, wie du oben schreibst, bei IPsec überflüssiger Unsinn.
Vermutlich ist es IPsec (geraten) und wie leider sehr oft der Fall hast du die 2te Phase 2 Definition mit dem 192.168.1.0/24 Netz vergessen?!
Mit der Phase 2 Definition bestimmst du bei IPsec bekanntlich welcher Traffic in den Tunnel geroutet wird. Deshalb ist auch eine statische Route auf dem VPN Router/Firewall, wie du oben schreibst, bei IPsec überflüssiger Unsinn.
LT. AWS ist das ein IPsec-Tunnel. In den Tunnel-Optionen werden für Phase 2 aber nur Verschlüsselungs-, Integritätsalgorithmen, DH-Gruppennummern und Lebensdauer angezeigt, was alles auf Standard steht.
Zus. gibt es zu dieser VPN-Verbindung bei AWS noch den Reiter "Statische Routen", wo ich das interne Netz auch nachträglich eingetragen habe (192.168.1.0/24). Ebenso auf dem Windows-RRAS in den Verbindungssicherheitsregeln als Endpunkt 1. Der muss ja schließlich den Traffic in den Tunnel schieben statt an das Standardgateway, wie ich im traceroute sehen kann.
Dass eine statische Route auf der Firewall Unsinn sein soll, halte ich allerdings für Unsinn! Die Firewall ist Standardgateway in den Clients. Die kennen doch nicht den Windows RRAS in der DMZ, den sie für den Zugriff auf EC2-Instanzen nutzen müssen.
Zus. gibt es zu dieser VPN-Verbindung bei AWS noch den Reiter "Statische Routen", wo ich das interne Netz auch nachträglich eingetragen habe (192.168.1.0/24). Ebenso auf dem Windows-RRAS in den Verbindungssicherheitsregeln als Endpunkt 1. Der muss ja schließlich den Traffic in den Tunnel schieben statt an das Standardgateway, wie ich im traceroute sehen kann.
Dass eine statische Route auf der Firewall Unsinn sein soll, halte ich allerdings für Unsinn! Die Firewall ist Standardgateway in den Clients. Die kennen doch nicht den Windows RRAS in der DMZ, den sie für den Zugriff auf EC2-Instanzen nutzen müssen.
Das ist dann schlecht, denn in den Phase 2 Attributen steht bei IPsec bekanntlich immer welche IP Netze es remote sind die in den VPN Tunnel geroutet werden. Logisch, denn diese Phase 2 Definition bestimmt immer was in den VPN Tunnel geroutet wird. Die hiesigen IPsec Site-2-Site VPN Tutorials sprechen ja da eine deutliche Sprache.
Fehlt dein 192.168.1.0/24er Netz auf der AWS Seite geht es nicht in den Tunnel und landet als unroutebares RFC 1918 IP Netz im Datenmülleimer.
Du kannst natürlich eine (überflüssige) statische Route eintragen aber die greift nicht weil der Traffic durch die fehlende P2 Definition nicht relevant ist und dann gedropt wird.
Außerdem hast du bei IPsec gar kein Gateway Interface oder IP Adresse allein aus diesem Grund kann man im IPsec schon gar keine sinnvolle Route definieren. Ist und bleibt also Unsinn. 😉
Anders sieht es aus wenn du ein Gateway Redirect machst also die Default Route (0.0.0.0/0 in der P2) auf den Tunnel umbiegst. Laut deiner o.a. Konfig ist das bei dir aber ja nicht der Fall.
Fehlt dein 192.168.1.0/24er Netz auf der AWS Seite geht es nicht in den Tunnel und landet als unroutebares RFC 1918 IP Netz im Datenmülleimer.
Dass eine statische Route auf der Firewall Unsinn sein soll, halte ich allerdings für Unsinn!
Nope, zumindestens bei IPsec ist es Unsinn, denn das bestimmt ja, wie bereits gesagt, bekanntlich die Phase 2 Definition. Was da nicht drinsteht gelangt NICHT in den Tunnel ob mit oder ohne Route.Du kannst natürlich eine (überflüssige) statische Route eintragen aber die greift nicht weil der Traffic durch die fehlende P2 Definition nicht relevant ist und dann gedropt wird.
Außerdem hast du bei IPsec gar kein Gateway Interface oder IP Adresse allein aus diesem Grund kann man im IPsec schon gar keine sinnvolle Route definieren. Ist und bleibt also Unsinn. 😉
Anders sieht es aus wenn du ein Gateway Redirect machst also die Default Route (0.0.0.0/0 in der P2) auf den Tunnel umbiegst. Laut deiner o.a. Konfig ist das bei dir aber ja nicht der Fall.
Ich glaube, wir sprechen aneinander vorbei.
Windows Server RRAS in der DMZ stellt den Tunnel zu AWS bereit. Die Sophos UTM hat u.a. drei Interface: 1. Internet, 2. LAN, 3. DMZ. Ein Client aus dem LAN ruft die interne IP der EC2-Instanz auf (10.1.1.1). Das Standardgateway auf dem Client ist die Sophos, die das Paket erreicht. Was soll die damit machen? Die kennt kein 10er-Netz. Nur der Windows-RRAS in der DMZ kennt das AWS-Netz. Wie kommt denn das Paket an den RRAS, wenn nicht über eine statische Route in der Sophos?
Nachtrag:
Eine statische Route auf dem Windows Server RRAS selbst mag ja Unsinn sein, weil IPsec Pakte aus den Netzen, die in der Phase 2 definiert sind, in den Tunnel schickt. Genau das passiert aber eben nicht! Nur Pakete vom Windows Server RRAS selbst (172.16.10.10) und eben nicht von Clients aus dem LAN (192.168.1.0/24) werden inden VPN-Tunnel weitergereicht. Leider habe ich gerade keinen anderen Client in der DMZ, um zu testen, ob er wenigstens diese weiterleitet. Ich sehe mein Problemeher darin, wo ich die Netze für Phase 2 in dem Windows Server RRAS überhaupt definiere. Ich sehe dazu nur den Eintrag in den Verbindungssicherheitsregeln in der Defender Firewall lokal auf dem Windows Server RRAS, der ja die Konfiguration aus der AWS-Vorlage eingelesen hat. Und dort, wo das für die VPN-Verbindung vorgebene Netz (DMZ, 172.16.0.0) übernommen wurde, habe ich eben zus. das LAN-Netz eingetragen, was aber so nicht funktioniert.
Windows Server RRAS in der DMZ stellt den Tunnel zu AWS bereit. Die Sophos UTM hat u.a. drei Interface: 1. Internet, 2. LAN, 3. DMZ. Ein Client aus dem LAN ruft die interne IP der EC2-Instanz auf (10.1.1.1). Das Standardgateway auf dem Client ist die Sophos, die das Paket erreicht. Was soll die damit machen? Die kennt kein 10er-Netz. Nur der Windows-RRAS in der DMZ kennt das AWS-Netz. Wie kommt denn das Paket an den RRAS, wenn nicht über eine statische Route in der Sophos?
Nachtrag:
Eine statische Route auf dem Windows Server RRAS selbst mag ja Unsinn sein, weil IPsec Pakte aus den Netzen, die in der Phase 2 definiert sind, in den Tunnel schickt. Genau das passiert aber eben nicht! Nur Pakete vom Windows Server RRAS selbst (172.16.10.10) und eben nicht von Clients aus dem LAN (192.168.1.0/24) werden inden VPN-Tunnel weitergereicht. Leider habe ich gerade keinen anderen Client in der DMZ, um zu testen, ob er wenigstens diese weiterleitet. Ich sehe mein Problemeher darin, wo ich die Netze für Phase 2 in dem Windows Server RRAS überhaupt definiere. Ich sehe dazu nur den Eintrag in den Verbindungssicherheitsregeln in der Defender Firewall lokal auf dem Windows Server RRAS, der ja die Konfiguration aus der AWS-Vorlage eingelesen hat. Und dort, wo das für die VPN-Verbindung vorgebene Netz (DMZ, 172.16.0.0) übernommen wurde, habe ich eben zus. das LAN-Netz eingetragen, was aber so nicht funktioniert.
