.png)
Ich habe es als OpenVPN-Server (Debian) und andere Server im Azure-Netzwerk 172.20.0.0/24 konfiguriert, das über einen Site-to-Site-VPN-IPsec-Tunnel mit dem lokalen Netzwerk (10.1.0.0/24) verbunden ist.
Es wurde eine Verbindung zwischen dem Virtual Network Gateway auf Azure und dem lokalen Paloalto hergestellt. Die Netzwerkverbindung von Azure zum lokalen Netzwerk funktioniert einwandfrei:
(172.20.0.0 <------> 10.1.0.0/24).
Auf dem OpenVPN-Server wurde Point-to-Site-VPN für Clients mit dem Adressraum 172.32.128.0/17 konfiguriert. Die Kommunikation vom Client zu Azure funktioniert gut:
(172.32.128.0 <----->172.20.0.0/24)
aber ich habe dabei ein Problem, wenn ich versuche, das lokale Netzwerk (10.1.0.0/24) anzupingen.
Keine Verbindung zwischen (172.32.128.0 <- ------/-------- -> 10.1.0.0/24)
Ping 10.1.0.8 (DNS auf lokaler Site) von 172.32.128.14 (Client mit OpenVpn verbunden)
Ich habe erhalten (Anforderungstimeout): Auf dem virtuellen Netzwerkgateway Azure erfasste Pakete:
172.20.0.5 10.1.0.8 ICMP 130 Ziel nicht erreichbar (Port nicht erreichbar)
(Hier können wir statt der Adresse 172.32.128.14 die OpenVPN Azure-Schnittstelle 172.20.0.5 sehen, obwohl Masquerade deaktiviert und Routing und Paketweiterleitung aktiviert sind.) Tcpdump OpenVPN: IP 172.32.128.14 > 10.1.0.8: ICMP-Echoanforderung, ID 1, Sequenz 970, Länge 40. Der OpenVPN-Server zeigt TCPdump-Anfragen von 172.32.128.14 an 10.1.0.8, aber keine Antwort.
Außerdem kann ich bei PaloAlto (lokales Netzwerk) Anfragen von 172.32.128.14 und Antworten von 10.1.0.8 sehen, aber die Pakete erreichen das Netzwerk 172.32.128.0/17 nicht. Es sieht so aus, als ob die Pakete verloren gegangen wären, bevor sie ins Azure-Netzwerk gelangten.
Routentabelle zeigt (OpenVpn):
Standardmäßig über 172.28.1.1 dev eth0
10.1.0.0/24 über 172.28.1.1 dev eth0
172.20.0.0/24 dev eth0 proto Kernel Bereich Link src 172.20.0.5
172.32.128.0/17 über 172.32.128.2 dev tun0
172.32.128.2 dev tun0 proto Kernel Bereich Link src 172.32.128.1
172.20.0.5 ist eine OpenVPN-Schnittstelle auf Azure
Azure-Routingtabelle:
Name | Netzwerk | Nächster Hop-Typ
ToAure | 172.31.128.0/17 | 172.20.0.5
ToLocalNet | 10.1.0.0/24 | VirtualNetworkGateway
Irgendwelche Ideen, warum ich vom Client-Netz nicht ins lokale Netz komme? Vielen Dank für Ihre Hilfe!
Antwort1
Haben Sie Ihre 172.32.128.0/17 (Adressraum des Clients) im S2S-VPN zwischen Palo Alto und Azure VPN GW bekannt gegeben?