Hi, komme nicht weiter…
Ich habe versucht das „Projekt“ → „Hetzner Cloud - Site to Site VPN in die Hetzner Cloud“ nachzubauen, erst im Original dann abgewandelt.
→ mit der UDM.
Erstmal die @home Hardware. Ich hänge hinter der FritzBox (FRITZ!Box 5590 Fiber, kein ONT, direkt Glasfaser) so dass ich den 2,5 Gbit/s direkt an die UDM hängen kann:
Wie? Natürlich mit ??
„BREAKING NEWS: UniFi OHNE doppeltes NAT ?? Kein NAT mehr mit der Fritzbox“
(SUPER Danke für das Video, da wäre ich NIE draufgekommen).
Hetzner Cloud pfsense Server soweit Installiert, konfiguriert (einmal…. Xmal)
Aktueller Stand:
- Wenn ich auf Windows Wireguard benutze geht es.
C:\Users\stefan>ping 10.200.1.1
Ping wird ausgeführt für 10.200.1.1 mit 32 Bytes Daten:
Antwort von 10.200.1.1: Bytes=32 Zeit=34ms TTL=64
→ also okay
C:\Users\stefan>ping 10.200.1.2
Ping wird ausgeführt für 10.200.1.2 mit 32 Bytes Daten:
Antwort von 10.200.1.2: Bytes=32 Zeit<1ms TTL=128
→ also okay
pfsense: Diagnostics/Ping
PING 10.200.1.1 (10.200.1.1) from 10.200.1.1: 56 data bytes
64 bytes from 10.200.1.1: icmp_seq=0 ttl=64 time=0.186 ms
und
PING 10.200.1.2 (10.200.1.2) from 10.200.1.1: 56 data bytes
64 bytes from 10.200.1.2: icmp_seq=0 ttl=128 time=34.219 ms
→ also okay
zur Sicherheit:
pfsense: Diagnostics/Packet Capture
18:32:55.098282 IP 10.200.1.2 > 10.200.1.1: ICMP echo reply, id 5590, seq 6659, length 9
18:32:55.587181 IP 10.200.1.1 > 10.200.1.2: ICMP echo request, id 5590, seq 6660, length 9
→ also okay
–//–
Nur der Windows Rechner (172.19.19.46) selbst will nicht (fehlt Windows eine Route? Keine Ahnung)
PING 172.19.19.46 (172.19.19.46) from 10.200.1.1: 56 data bytes
— 172.19.19.46 ping statistics —
2 packets transmitted, 0 packets received, 100.0% packet loss
→ Nicht okay
Aber → Ergo die pfsense sollte okay sein.
Aber:
2. Auf der UDM bekomme ich es nicht zum laufen.
root@Dream-Machine-Pro-Max:~# ping 10.200.1.1
PING 10.200.1.1 (10.200.1.1) 56(84) bytes of data.
64 ytes from 10.200.1.1: icmp_seq=1 ttl=64 time=33.4 ms
→ also okay
root@Dream-Machine-Pro-Max:~# ping 10.200.1.2
PING 10.200.1.2 (10.200.1.2) 56(84) bytes of data.
64 bytes from 10.200.1.2: icmp_seq=1 ttl=64 time=0.089 ms
→ also okay
Die UDM kann Ihr und das pfsense gw erreichen
–//–
Also zur pfsense
PING 10.200.1.1 (10.200.1.1) from 10.200.1.1: 56 data bytes
64 bytes from 10.200.1.1: icmp_seq=0 ttl=64 time=0.189 ms
→ Pfsense .self geht auch
PING 10.200.1.2 (10.200.1.2) from 10.200.1.1: 56 data bytes
— 10.200.1.2 ping statistics —
2 packets transmitted, 0 packets received, 100.0% packet loss
→ Geht nicht. Dann brauche ich 172.19.19.1 (UDM erst gar nicht versuchen)
pfsense: Diagnostics/Packet Capture
18:45:07.297090 IP 10.200.1.1 > 10.200.1.2: ICMP echo request, id 5590, seq 8037, length 9
18:46:31.397078 IP 10.200.1.1 > 10.200.1.2: ICMP echo request, id 5590, seq 8196, length 9
also nur request…
Also die UDM macht „murks“, antwortet nicht → Ergo:
Ich habe Route eingetragen, Firewall geöffnet, aus Verzweiflung auf grouping network umgestellt
Anmerkung: Findet Ihr die wirklich gut, ich finde sie erschreckend unübersichtlich. aber anderes Thema
(in Anlehnung: „UniFi - Site to Site VPN mit Wireguard - Ausführliche Erklärung und Anleitung – Tutorial“ )
Statische Routen eingerichtet:
Wie:
10.200.0.0/16 – Hop 10.200.1.1 oder – Schnittstelle – WgPFsenseToPHagen (das wireguard VPN)
Die Routen separat eingetragen:
10.200.0.0/24 → 10.200.1.1 oder WgPFsenseToPHagen
10.200.1.0/24 → 10.200.1.1 oder WgPFsenseToPHagen
10.200.0.0/24 → 10.200.1.1 oder WgPFsenseToPHagen
Keine Ahnung pfsense zur UDM 10.200.1.2, ping geht nicht, ergo brauche ich auch nicht versuchen mein lokales Netzwerk zu erreichen
Offensichtlich gleich/ähnlich gelagertes Problem
Siehe im Forum „Probleme beim Zugriff beim Zugriff auf das Heimnetzwerk via Wireguard über einen VPS“
Offensichtlich gleich/ähnlich gelagertes Problem.
Anmerkung: Ich hänge mal 2 Bilder an
Aber Bild 1 Lösung von „Probleme beim Zugriff…“ klappt bei mir (natürlich, war ja klar) nicht.
Auch bei mir wird wireguard als External behandelt (WgPFsenseToPHagen) → nicht von „VPN PtMain“ irritieren lassen das ist ein L2TP)
Ansonsten mal die routen
root@Dream-Machine-Pro-Max:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.3.0 0.0.0.0 255.255.255.0 U 0 0 0 br3
10.10.5.0 0.0.0.0 255.255.255.0 U 0 0 0 br5
10.10.8.0 0.0.0.0 255.255.255.0 U 0 0 0 br8
10.200.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wgclt1
10.200.1.0 10.200.1.1 255.255.255.0 UG 1 0 0 wgclt1
10.200.2.0 10.200.1.1 255.255.255.0 UG 1 0 0 wgclt1
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0
192.168.19.0 0.0.0.0 255.255.255.0 U 0 0 0 eth8
und
root@Dream-Machine-Pro-Max:~# wg showconf wgclt1
[Interface]
ListenPort = 37505
PrivateKey = 2J7w key-haltPly6kxXS6jXU8=
[Peer]
PublicKey = 74RB key-halt+DatBGiZu3nE=
AllowedIPs = 0.0.0.0/0
Endpoint = 95.xx.xx.1:51820
PersistentKeepalive = 60
ForcedHandshake = 5
–//–
Die Datei .self
[Interface]
PrivateKey = 2J7 key-halt xXS6jXU8=
Address = 10.200.1.2/24
DNS = 10.200.0.2
[Peer]
PublicKey = 74 key-halt 3nE=
AllowedIPs = 10.100.0.0/24, 10.100.1.0/24, 10.100.2.0/24, 10.200.0.0/24, 10.200.1.0/24, 10.200.2.0/24, 172.19.19.0/24
Endpoint = 95.xx.xx.xx:51820
PersistentKeepalive = 25
VPN steht ja, kann also nicht/nur bedingt an der wg.conf liegen.
Ansonsten mit Address Bsp: /16 oder AllowedIPs /16 versucht.
Vielen, vieln (ne es waren noch mehr) Firewall einträgen.
Viel Text (wollte jetzt aber auch keine Infos vergessen), aber evtl. hat ja jemand eine Idee, mich hat nach 3 Tagen die UDM… Ihr wisst schon.
CU
Stefan
