11.03.2025, aktualisiert um 23:55:34 Uhr

1025

Wireguardverbindung PFsense zu VServer, CG-NAT, kein Verbindungsaufbau

Hallo zusammen,

ich bekomme demnächst Glasfaser ins Haus, aber habe den leider keine öffentliche IPv4 Adresse mehr, was IPSEC VPNs, Eingehende OpenVPN Verbingungen und selbst gehostete Webseiten/Dienste nur mit Hilfsmittel realisieren lässt.

Ich habe das Konstrukt mal getestet und eine PFsense hinter meine Sophos UTM gesetzt, quasi das CG-NAT simuliert.
Leider baut die PFsense keine Wireguardverbindung auf. In den Logs der PFSense sind keine Logs von der Wireguardverbindung zu sehen und ebenfalls keine Logs in der Sophos UTM.

Mein Testaufbau:

Selbst wenn es den VServer auf den ich mich verbinden möchte garnicht geben würde, so müssten in den Logs der beiden Firewalls definitiv Eintrage zu sehen sein. Das Logging ist auf beiden Firewalls in den jeweiligen Firewallregeln aktiviert.

Hier meine Konfiguration auf der PFSense:

An was könnte das liegen? Für mich sieht es so aus, als ob die PFsense erst überhaupt keine Verbindung herzustellen versucht.

Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 671879

Url: https://administrator.de/forum/wireguardverbindung-pfsense-zu-vserver-cg-nat-kein-verbindungsaufbau-671879.html

Ausgedruckt am: 13.04.2025 um 04:04 Uhr

10 Kommentare

Neuester Kommentar

Hallo,

Zitat von @touro411:
ich bekomme demnächst Glasfaser ins Haus, aber habe den leider keine öffentliche IPv4 Adresse mehr, was IPSEC VPNs, Eingehende OpenVPN Verbingungen und selbst gehostete Webseiten/Dienste nur mit Hilfsmittel realisieren lässt.

Das Internet nutzt wie auch wohl dein gewählter ISP IPv6 und CGNAT (Carrier Grade NAT) für IPv4. Mit IPv6 ist VPN jederzeit möglich, Websites abzufragen und zu hosten, Mails zu senden und zu empfangen, sogar Telefon und auch dein Toaster funktionieren noch. Wir Zeit sich weiter zu bilden.
https://de.wikipedia.org/wiki/Carrier-grade_NAT
https://www.a10networks.com/de/glossary/what-is-carrier-grade-nat-cgn-cg ...
https://www.heise.de/ratgeber/Zugriff-auf-das-Heimnetz-trotz-CGNAT-93077 ...

https://www.computerbase.de/forum/threads/ipv6-fuer-dumme-leute.1140213/
http://www.steves-internet-guide.com/ipv6-guide/

LAN, WLAN und demzufolge auch Internet (inkl. SPAM usw.) funktioniert weiterhin, auch wenn IPv4 irgendwann in Zukunft wirklich tot sein sollte.

https://www.geeksforgeeks.org/differences-between-ipv4-and-ipv6/
https://community.fs.com/article/ipv4-vs-ipv6-whats-the-difference.html
https://www.thousandeyes.com/learning/techtorials/ipv4-vs-ipv6

Gruss,
Peter

@Pjordorf es geht ihm um eingehende Verbindungen, nicht um ausgehende.
Wenn er Zuhause einen Webserver / Mailserver hostet, können ihn einige "Kunden" nicht mehr erreichen, welche IPv6 deaktiviert haben. In größeren Firmen oder Hotels ist IPv6 grundsätzlich deaktiviert.

Zur Lösung kann ich leider nichts beitragen.

In größeren Firmen oder Hotels ist IPv6 grundsätzlich deaktiviert.

Das ist so plump und pauschal gesagt heutzutage nicht mehr richtig. Fakt ist das Unternehmen und öffentliche Hand zu Recht die IPv6 Connectivity forcieren. Ist aber hier nicht das Thema...

Wenn dein neuer Provider Anschluss ein DS-Lite Anschluss mit CG-NAT ist hast du zu mindestens mit IPv4 keinerlei Chance eine VPN Verbindung ins heimische Netz, also eingehend von außen, zu realisieren!
Das zentrale CG-NAT Gateway auf Providerseite verhindert das, so das dies technisch nicht möglich ist.
Das nur vorab...

Was aber immer geht ist den Tunnel mit IPv6 aufzubauen und im Tunnel dann IPv4 zu tunneln (oder auch beides), denn bei einem DS-Lite oder CG-NAT Anschluss hast du ja immer IPv6 Connectivity.
Das bedingt allerdings das sich dann auch dein VPN Client in einem IPv6 fähigen Netzwerk befinden muss. Alle Details dazu beschreibt das hiesige Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard

Die 2te Alternative diese Thematik einfach und schnell zu lösen ist es mit einem einfachen vServer als Jumphost zu arbeiten. Der dient dann als öffentlicher VPN Server für deine Clients und leitet sie ins Heimnetz weiter.
Wie so eine einfache Lösung aussehen kann beschreibt ein Jumphost Tutorial.
Der Jumphost hat den Vorteil das er sowohl für alle bordeigenen VPN Clients aller Endgeräte und Betriebssysteme agieren kann als auch parallel für Wireguard und OpenVPN.
Er kann also quasi als eierlegende Wollmilch VPN Sau agieren wenn man mehrfachen VPN Protokollsupport möchte.

Leider fehlt oben die Wireguard Server Konfig (Responder) um einmal das Pendant zur pfSense (Initiator) zu sehen so ist es schwierig zu beurteilen WO du deinen Konfig Fehler gemacht hast. Das o.a. WG Tutorial hat alle Details dazu.
Bedenke auch das die pfSense die Routings in das WG Tunnelnetz nicht automatisch etabliert wie man es von unixoiden Servern usw. gewohnt ist! Die pfSense erzwingt da immer eine statische Route die in deinem Setup nicht zu sehen ist?! Details dazu auch HIER.

Danke für die ausführliche Antwort, werde mir das mal in Ruhe "reinziehen".

Aber müsste Wireguard nicht versuchen eine Verbindung zum VServer aufzubauen, selbst wenn kein Gateway und keine Route vorhanden sind? Ein WG Interface ist angelegt und die Firewallregeln auch...

Der Versuch muss ja stattfinden, wenn ich eine IPSec-VPN Verbindung anlege, versucht diese eine Verbindung zum Gegenüber aufzubauen, selbst wenn es den Gegenüber überhaupt nicht geben würde...

Aber müsste Wireguard nicht versuchen eine Verbindung zum VServer aufzubauen, selbst wenn kein Gateway und keine Route vorhanden sind?

Das kommt ganz darauf an WO dein Wireguard Client steht??
Steht der Client (Initiator) intern in einem lokalen LAN benötigt er logischerweise ein Default Gateway bzw. Route um via Internet Router zum vServer (Responder) zu kommen. Einzig nur der Client (Initiator) baut aktiv die Verbindung auf.

Ist der Client (Initiator) aber der Internet Router oder Firewall selber hat er ja schon ein Gateway / Route durch die bestehende Provider Verbindung.
In dem Falle ist dann natürlich kein Gateway usw. mehr erforderlich.

Die Anmerkung oben bzgl. der Cryptokey Route bezog sich auch nur aufs Wireguard. Bei unixoiden oder Winblows Servern und Clients ist man gewohnt das die aktive Route zum Peer automatisch mitgegeben wird und aktiuv wird.
Das ist bei der pfSense nicht der Fall. Sie erzwingt das Setzen einer statischen Route bei Wireguard.
Die OPNsense z.B. hat einen Softswitch im Setup wo man das aktivieren oder deaktivieren kann. ("Disable routes". Die pfSense hat das nicht und "lernt" damit keine Peer routen automatisch.

Für eine Firewall ist das auch immer ein Vabanque Spiel, weil man in der Regel dort nicht will das die Routing Tabelle automatisch manipuliert wird was ein Sicherheitsrisiko darstellt.
Nur das du das Routen Thema beim pfSense WG Setup auf dem Radar hast!

Das Einfachste ist doch gem. o.a. Tutorial ein Strongswan auf dem vServer zu installieren und von deiner Sophos einen IPsec VPN Tunnel zu etablieren sofern die selber kein WG kann. Das erspart dir die ganze Frickelei mit einem extra Gerät was eigentlich überflüssig ist.
Auf dem vServer kannst du dann ein IKEv2 Client VPN einrichten und wenn du willst parallel auch noch WG. Dann deckt dein vServer alles ab um aufs heimische Netz zu kommen.

Das kommt ganz darauf an WO dein Wireguard Client steht??

Ich benutze auf der PFSense den Wireguard Client, also keine Linuxkiste, welche im LAN läuft.
Ich habe eine Sophos UTM, welche externe eine öffentliche IPV4-Adresse hat. Im internenen Netz 172.16.XX.XX hat die Pfsense ihr WAN Interface.

Normalerweise müsste die PFSense versuchen eine Verbindung zum VServer aufzubauen, es gibt auch keine Einträge in den Firewalllogs, in der Sophos UTM und auch nicht in der PFsense...

Moin,
Hast du auf dem wan Interface des Servers auch den Port freigegeben? In den Screenshots sehe ich nur die Regel vom WG Interface. Das würde auch erklären warum nichts ankommt und im Log steht.

Normalerweise müsste die PFSense versuchen eine Verbindung zum VServer aufzubauen

Das ist richtig!

Was steht denn in den Logs der pfSense und beim vServer??
Zeigt dir die pfSense einen Handshake an unter "Status"??
Kollege @kevsei hat es schon gesagt: Wenn dein vServer ein unixoider Server ist kannst du mit tcpdump -i eth0 port 51820 dort überhaupt eingehende Wireguard UDP Datenpakete deiner pfSense sehen? (Interface und WG Port ggf. auf deine Werte anpassen!)

Hier einmal ein Live Beispiel wie es fehlerlos rennt:

Inhaltsverzeichnis

vServer Setup

pfSense Konfiguration

Verbindungscheck pfSense und vServer

vServer Setup

[Interface]
Address = 172.20.20.254/24
PrivateKey = xyz
ListenPort = 51820

# Peer pfSense als Client (Initiator)
[Peer]
PublicKey = zyx
AllowedIPs = 172.20.20.56/32, 192.168.1.0/24

pfSense Konfiguration

Tunnel Interface

Die pfSense hat die Wireguard Tunnel IP 172.20.20.56. Das Tunnel IP Netz hat einen /24er Präfix.
Entsprechend wird in den Interface Assignments der pfSense das Wireguard Interface zunächst hinzugefügt (Add) und danach dessen IPv4 Adresse statisch gesetzt.
Den Namen sollte man zum besseren Management auch anpassen ist aber optional.
❗️Das Upstream Gateway ist optional und wird im Interface nur dann gesetzt wenn es lokale IP Netze am vServer gibt die zu erreichen sind! Ist das nicht der Fall und gibt es keine lokalen IP Netze ist kein Upstream Gateway erforderlich und bleibt auf "None".
Wie oben schon gesagt kann die pfSense diese ggf. vorhandenen lokalen IP Netze ohne eine statische Route nicht erreichen.

Peer Setup

Bei den Allowed IPs muss die vServer Tunnel IP selber immer mit einer /32 Hostmaske gesetzt sein.
Das Beispiel hier zeigt einen vServer der parallel zusätzlich zu WG noch IKEv2 VPN Clients bedient so das Wireguard und IKEv2 VPN Clients auf das pfSense IP Netz zugreifen können.
Zusätzlich hat er eine lokale Loopback Hostadresse um ihn testweise direkt pingen zu können um das IP Routing zu checken.
👉🏽 Wenn du keine lokalen Netze, Loopbacks etc. am vServer hast, entfällt das bei dir natürlich bis auf den Eintrag des Wireguard Servers selber! Der muss immer vorhanden sein!

Tunnel Setup

Firewall Regelwerk

⚠️ Wichtig hier kein Regelwerk auf dem System Interface WireGuard zu setzen, sondern ausschliesslich nur auf dem Tunnelinterface! (Beispiel hier: Scheunentorregel die alles im Tunnel erlaubt)

Verbindungscheck pfSense und vServer

root@vserver:/home/admin# wg show
interface: wg0
  public key: abc
  private key: (hidden)
  listening port: 51820

peer: zyx
  endpoint: 85.15.172.53:7885
  allowed ips: 172.20.20.56/32, 192.168.1.0/24
  latest handshake: 1 minute, 8 seconds ago
  transfer: 79.54 KiB received, 26.62 KiB sent 

root@vserver:/home/admin# ping -c 3 172.20.20.56
PING 172.20.20.56 (172.20.20.56) 56(84) bytes of data.
64 bytes from 172.20.20.56: icmp_seq=1 ttl=64 time=20.9 ms
64 bytes from 172.20.20.56: icmp_seq=2 ttl=64 time=20.8 ms
64 bytes from 172.20.20.56: icmp_seq=3 ttl=64 time=20.5 ms

--- 172.20.20.56 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 20.524/20.721/20.869/0.145 ms

root@vserver:/home/admin# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=20.4 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=20.6 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=20.9 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 20.434/20.645/20.926/0.206 ms 

Passt entsprechend zum wg show oben auf der vServer Seite!
Entsprechende Pings von Clients im lokalen pfSense LAN (192.168.1.0/24) auf die WG Server Tunnel IP 172.20.20.254 und vice versa klappen erwartungsgemäß auch.

Fazit: Works as designed!! 👍