2
Hetzner Proxmox vSwitch pfSense VPN - Probleme
Moin zusammen ...
... ich stehe hier seit letzten Donnerstag (14.09.23) vor einem Phänomen, dass ich nicht verstehe.
Vielleicht sehe ich auch nur den Wald vor lauter Bäumen nicht ...
Zur Ausgangslage:
Wir betreiben bei Hetzner seit September 2022 zwei PROXMOX-Server (aktuell noch 7.4.x).
Beide befinden sich in einem Cluster.
Seit dem 07.09.23 fand zwischen den beiden Servern keine Kommunikation mehr statt.
Mit dieser /etc/network/interfaces lief es allerdings vom September '22 bis zum 07.09.23 einwandfrei:
Aufgefallen ist uns das, weil wir eine unserer Windows-VM (Ein DC mit Server 2022) neu gestartet haben und dieser aufgrund fehlenden Quorum nicht mehr startete.
Habe dann das Quorum temporär auf "1" gesetzt und die Maschine wieder gestartet.
Diese benötigte dann allerdings ewig mit "Computereinstellungen werden übernommen" und die Anmeldung mit einem AD Konto dauerte ewig, da diverse GPOs mit Diensten auf einen anderen Server verweisen, der nur via IPsec verfügbar ist.
Seitdem funktioniert auch keine AD-Replikation mehr.
Der Tunnel war allerdings aufgebaut und ping, tracert und nslookup liefen wie gewohnt durch den Tunnel.
Zur Konstellation des Netzwerks:
Wir verwenden auf diesem Cluster zwei vSwitches.
Einmal die ID 4000, auf der unser zusätzliches SubNet gerouted 167.X.Y.Z gerouted ist.
Einmal die ID 4040, das Intern mit 10.10.10.0/24 betrieben wird.
Die Router VM verwendet auf der WAN-Seite vmbr1 (ID 4000) mit einer der IPs aus dem Subnet 167.X.Y.Z, auf der LAN-Seite die IP 10.10.10.20/24.
Alle VM haben eine IP aus dem Bereich 10.10.10.0/24, so auch der DC mit der IP 10.10.10.35/24.
Die IPs aus dem 167'er Subnet sind als Virtual-IPs in der pfSense hinterlegt und via Outbound-NAT und entsprechenden Port-Forwardings (f.e. RADIUS) verfügbar.
Zu unserem weiteren Server bei Hetzner ist ein IPsec Tunnel aufgebaut, der die Netze 148.251.X.Y/28 und 10.10.10.0/24 verbindet.
Im Netz 148.251.X.Y befindet sich ein DC, mit dem die AD-Replikation lief.
Jetzt allerdings funktioniert diese nicht mehr.
Ich verstehe auch noch nicht, warum so oft die "default deny rule greift" ?!
Und der Weg durch Tunnel passt IMHO auch ...
Irgendwo ist hier bestimmt in der config noch ein Haken, wo keiner hingehört oder ich habe irgendetwas mit dem NAT verbogen oder übersehen.
Jedenfalls fehlt mir nach 4 Tagen Recherche ein weiterer Ansatz, den ich verfolgen kann.
Ich hoffe also auf einen hilfreichen Wink mit dem Zaunpfahl, wie ich die Kuh wieder vom Eis kriege.
greetz
Der Rico
... ich stehe hier seit letzten Donnerstag (14.09.23) vor einem Phänomen, dass ich nicht verstehe.
Vielleicht sehe ich auch nur den Wald vor lauter Bäumen nicht ...
Zur Ausgangslage:
Wir betreiben bei Hetzner seit September 2022 zwei PROXMOX-Server (aktuell noch 7.4.x).
Beide befinden sich in einem Cluster.
Seit dem 07.09.23 fand zwischen den beiden Servern keine Kommunikation mehr statt.
Mit dieser /etc/network/interfaces lief es allerdings vom September '22 bis zum 07.09.23 einwandfrei:
[root@pmh1 ~]$ cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!
>
source /etc/network/interfaces.d/*
>
auto lo
iface lo inet loopback
>
iface lo inet6 loopback
>
iface enp1s0 inet manual
up route add -net 157.XX.YY.64 netmask 255.255.255.192 gw 157.XX.YY.65 dev
enp1s0
hwaddress ether 00:50:56:11:22:33
# route 157.XX.YY.64/26 via 157.XX.YY.65
>
iface enp8s0 inet manual
#1 GB NIC (unused)
>
iface enp1s0.4000 inet manual
mtu 1400
#vswitch
>
auto enp1s0.4040
iface enp1s0.4040 inet manual
#vswitch intern
>
auto vmbr1
iface vmbr1 inet manual
bridge-ports enp1s0.4000
bridge-stp off
bridge-fd 0
mtu 1400
>
auto vmbr0
iface vmbr0 inet static
address 157.XX.YY.99/26
gateway 157.XX.YY.65
bridge-ports enp1s0
bridge-stp off
bridge-fd 0
hwaddress ether 00:50:56:11:22:33
#default
>
auto vmbr2
iface vmbr2 inet manual
bridge-ports enp1s0.4040
bridge-stp off
bridge-fd 0Aufgefallen ist uns das, weil wir eine unserer Windows-VM (Ein DC mit Server 2022) neu gestartet haben und dieser aufgrund fehlenden Quorum nicht mehr startete.
Habe dann das Quorum temporär auf "1" gesetzt und die Maschine wieder gestartet.
Diese benötigte dann allerdings ewig mit "Computereinstellungen werden übernommen" und die Anmeldung mit einem AD Konto dauerte ewig, da diverse GPOs mit Diensten auf einen anderen Server verweisen, der nur via IPsec verfügbar ist.
Seitdem funktioniert auch keine AD-Replikation mehr.
Der Tunnel war allerdings aufgebaut und ping, tracert und nslookup liefen wie gewohnt durch den Tunnel.
Zur Konstellation des Netzwerks:
Wir verwenden auf diesem Cluster zwei vSwitches.
Einmal die ID 4000, auf der unser zusätzliches SubNet gerouted 167.X.Y.Z gerouted ist.
Einmal die ID 4040, das Intern mit 10.10.10.0/24 betrieben wird.
Die Router VM verwendet auf der WAN-Seite vmbr1 (ID 4000) mit einer der IPs aus dem Subnet 167.X.Y.Z, auf der LAN-Seite die IP 10.10.10.20/24.
Alle VM haben eine IP aus dem Bereich 10.10.10.0/24, so auch der DC mit der IP 10.10.10.35/24.
Die IPs aus dem 167'er Subnet sind als Virtual-IPs in der pfSense hinterlegt und via Outbound-NAT und entsprechenden Port-Forwardings (f.e. RADIUS) verfügbar.
Zu unserem weiteren Server bei Hetzner ist ein IPsec Tunnel aufgebaut, der die Netze 148.251.X.Y/28 und 10.10.10.0/24 verbindet.
Im Netz 148.251.X.Y befindet sich ein DC, mit dem die AD-Replikation lief.
Jetzt allerdings funktioniert diese nicht mehr.
Ich verstehe auch noch nicht, warum so oft die "default deny rule greift" ?!
Und der Weg durch Tunnel passt IMHO auch ...
Irgendwo ist hier bestimmt in der config noch ein Haken, wo keiner hingehört oder ich habe irgendetwas mit dem NAT verbogen oder übersehen.
Jedenfalls fehlt mir nach 4 Tagen Recherche ein weiterer Ansatz, den ich verfolgen kann.
Ich hoffe also auf einen hilfreichen Wink mit dem Zaunpfahl, wie ich die Kuh wieder vom Eis kriege.
greetz
Der Rico
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: 33319656527
Url: https://administrator.de/contentid/33319656527
Printed on: April 27, 2024 at 07:04 o'clock
2 Comments
Latest comment
Moin,
wenn deine "Block Any" regel anspringt würde ich erst einmal dein Regelwerk vermuten.
Schau bei den Interface "LAN" nochmal genau hin und mach evtl. eine explizite Regel von Lan zu VPN und schau was passiert.
Aberwas genau passiert ist alles sehr schwer zu sagen ohne das genaue Regelwerk.
Gruß
wenn deine "Block Any" regel anspringt würde ich erst einmal dein Regelwerk vermuten.
Schau bei den Interface "LAN" nochmal genau hin und mach evtl. eine explizite Regel von Lan zu VPN und schau was passiert.
Aberwas genau passiert ist alles sehr schwer zu sagen ohne das genaue Regelwerk.
Gruß
Wir haben jetzt noch einmal einen neuen DC aufgesetzt i 10.10.10.0/24 ...
Bei diesem gibt es aktuell keine "deny-Einträge" ...
Aktuell vermuten wir, dass das Problem nicht an den pfSense sondern direkt am DC liegt.
Wir prüfen weiter ...
Feedback folgt ...
Bei diesem gibt es aktuell keine "deny-Einträge" ...
Aktuell vermuten wir, dass das Problem nicht an den pfSense sondern direkt am DC liegt.
Wir prüfen weiter ...
Feedback folgt ...