VPN Point to Site ICMP funktioniert, TCP nicht

eagle61

@micneu said in VPN Point to Site ICMP funktioniert, TCP nicht:

Und die Fritzbox kann nach meinem wissen auch nur 1 Netz über das VPN Routen.

Sie kann zumindest eine Netzt zu Netz-Verbindung und zudem noch Netz zu Client Verbindungen gleichzeitig.

Ich verwalte eine Remote FB 7490. Die hat eine permanente Netz zu Netz-Verbindung zu einer pfsense und es ist dennoch möglich noch mit einem Smartphone, Notebook etc. einen Tunnel zur FB herszustellen und pber diesen dann sogar wieder in das Netz der pfsense zu gelangen.

Allerdings will TheBlackOne
gar keine Point to Site VPN Verbindung mit Wireguard zu einer FB aufbauen, sondern Ziel ist ein OnPrem Server. Okay, scheinbar ist nun doch eine FB im Spiel.

Dann hilft das weiter:
https://v64.tech/t/anleitung-site2site-wireguard-verbindung-zwischen-pfsense-und-fritzbox/438/13
Mit dieser Anleitung und mit meiner Ergänzung in den Kommentaren am Ende hat es bei mir funktioniert und läuft seit Wochen fehlerfrei durch.
(pfsense bei mir Zuhause, FritzBox an entferntem Standort)

micneu

@eagle61 so meinte ich das nicht.
du kannst unter linux/sense/windoof in der wireguard config mehrere netze angeben. das unterstützt die fritzbox nach meiner meinung nicht (habe ich so hören sagen mitbekommen, nie getestet da ich sowas nicht brauche

TheBlackOne

Hi,

diesmal habe ich dran gedacht auch die WG-Config mit hoch zu laden.
Die beiden Tunnel sind gleich konfiguriert. Sie erlauben das Netz 192.168.178.0/24 und 10.111.111.0/24.
Zur Erklärung: Im Schema steht das Heimnetz mit 192.168.1.0/24. Das war nur für das Schema. In den Konfigs ist es die 192.168.178.0/24 Die Tunnel sind "gleich" konfiguriert, daher nur die Bilder vom Tunnel zur FritzBox.

Mein Ansatz zum Problem des Routing des Fritzbox war das 10.111.111.0/24 Netz freizugeben. Ich denke auch nicht, dass es sich um ein Routingproblem handelt, da Ping und Traceroute funktionieren, oder liege ich da falsch?

Hier mal was ich mit dem Setup erreichen will bzw. warum ich mich für diesen Aufbau entschieden habe:

VPN für meine Endgeräte wenn ich unterwegs bin
- Sicherer Zugriff auf Internet
- Zugriff auf die Server Zuhause

Warum stehen die Server Zuhause?
Der Media-Server besteht aus alter Hardware mit einer großen Platte, war billiger als sich entsprechenden Speicher in der Cloud zu mieten. Der OctoPi steuert meinen 3D-Drucker, der kann nicht in die Cloud.
Einen Reverse Proxy wollte ich nicht, da damit die Server öffentlich erreichbar wären, wenn ich nichts weiter tue, oder meinst du @micneu in der Kombination mit VPN dann aber ohne den Traffic direkt zu Routen?

Ich hänge nicht an der Zwei-Tunnel Lösung. Mein erster Ansatz war, alles in einen Tunnel zu hängen, als mehrere Peers, das hat aber dazu geführt, dass niemand mehr über den Tunnel kommunizieren konnte.

Wireguard auf der Fritzbox

[Interface]
PrivateKey = PrivateKey
Address = 10.111.111.18/28
DNS = 10.111.111.2

[Peer]
PublicKey = PublicKey
AllowedIPs = 192.168.178.0/24, 10.111.111.0/24
Endpoint = 203.0.113.196:51820
PersistentKeepalive = 25

Wireguard auf dem Client

[Interface]
PrivateKey = PrivateKey
Address = 10.111.111.194/26
DNS = 10.111.111.2

[Peer]
PublicKey = PublicKey
AllowedIPs = 10.111.111.0/24, 192.168.178.0/24
Endpoint = 203.0.113.196:51821
PersistentKeepalive = 25

Bob.Dig

@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:

Wireguard auf der Fritzbox

Davon hätte ich gerne den Screenshot, denn ich dachte, die Fritzbox nutzt immer die eigene LAN-IP für WireGuard.

TheBlackOne

Die Werte in den grauen Feldern, kann man nicht anpasse. Die werden aus der Wireguard-Konfigdatei gezogen.

Bob.Dig

@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:

Die Werte in den grauen Feldern, kann man nicht anpasse. Die werden aus der Wireguard-Konfigdatei gezogen.

Ich meinte den anderen Button, also den für die WG-Config der FB selbst, nicht für den Peer. Da müsste dir auch die private IP der Fritte angezeigt werden.

TheBlackOne

Das ist alles was ich für WG an der FritzBox konfiguriert habe. Die FB ist lediglich lediglich ein Peer. Dadurch habe ich keine Probleme mit der wechselnden öffentlichen IP, da die sich immer wieder von selbst verbindet.

eagle61

@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:

Die beiden Tunnel sind gleich konfiguriert. Sie erlauben das Netz 192.168.178.0/24 und 10.111.111.0/24.

Also meines Wissens nach werden Site to Site und Roadwarrior-Tunnel unterschiedlich konfiguriert. Site to Site Tunnel sind Wireguard-Tunnel zwischen verschiedenen Netzen, also z.B. zwischen einer Fritspox und einer pfsende.

Roadwarrior-Tunnel sind Wireguard-Tunnel zwischen einem einzelnen moblen Endgerät, wie Smartphone oder Notebook von dem aus Du z.B. von einem mobile Netzwerk aus ins heimische Internet willst oder gar eingelogt in einem Hotel-Netz oder einem Cafe, sicher allen Internetverkehr (z.B. für sicheres Onlinebanking) über das heimische Netzwerk durch den WIreguard-Tunnel umleiten willst.

Ich habe und nutze beides. Das geht auch, die Konfiguration ist aber zumindest auf einer pfsense unterschiedlich.
Beides können sowohl Fritz-Boxen wie auch pfsense, entsprehcende Konfiguration vorausgesetzt und beides auch gleichzeitig.

WIllst du für einen Wireguard-Tunnel den gesamten Internetverkehr umleiten braucht es seitens der pfsense zusätzlich auch noch eine Outbound-Firewall-Rule. (Firewall / NAT / Outbound), dort dann unter Outbound NAT Mode - Hybrid Outbound NAT rule generation.
(Automatic Outbound NAT + rules below) markieren und eine Rule für das Transfernetz des Roadwarrior-Runnels anlegen.

Damit sind wir auch beim wichtigsten Punkt. FritzBoxen kennen für Wireguard (genau wie auch schon für IPSec) kein separates Transfernetz. Alle anderen Wireguard-Tunnel jedoch schon.

Daher brauchst Du für Roadwarrior-Tunnel das Transfernetz, der Tunnel zwischen FB und pfsense hat aber keines.

Seitens der pfsense benötigst Du dann auch noch Firewall-Rules unter Firewall / Rules / WireGuard. Manche Anleitungen verorten diese Rules nicht unter Firewall / Rules / WireGuard sondern unter dem Transfertunnel (z.B. Firewall / Rules / WGTUN0). Das ist meines WIssens nach aktuell aber nicht mehr der richtige Weg.

Dort musst Du dann pasende Rules anlegen, passend für die Zielrechner und Ports die du erreichen willst. Also etwa eine Regel die TCP-Port 22 erlaubt für einen Server den du vom anderen Ende des Tunnels per SSH erreichen willst (also z.B. via Roadwarrior vom Notebook aus im hinter der pfsense. Hast du dort nur eine rule die ICMP erlaubt kannst du den zwar anpingen aber hast immer noch keine Erlaubnis per ssh (weil das ist ja TCP) den SSH-Server zu erreichen.

Bob.Dig

@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:

Das ist alles was ich für WG an der FritzBox konfiguriert habe.

Das ist nicht korrekt, da der Assistent das macht. Wie gesagt, es ist der andere Button, der die Tunnel-Config auf Seite der Fritzbox anzeigt. Und da darf nur die IP der FB auftauchen, die musst Du nämlich in der Config von der anderen Seite schon dort eintragen.

TheBlackOne

Hier brauche ich glaube ich noch mal ein Auffrischung: Bisher dachte ich, wenn Ping funktioniert, dann ist zumindest bei dem Thema Routing/NAT alles passend konfiguriert und meine Probleme liegen eher bei Firewall, MTU Size etc. Irre ich mich da?

TheBlackOne

Ich hänge hier auch mal noch den die Packet Capture Ausgaben von den beiden Tunnelinterfaces auf der pfSense dran. Es wird vom VPN-Client (10.111.111.194) der Homeserver (192.168.178.40) erst gepingt und dann versucht eine https Verbindung zu Port 8096 aufzubauen.

Protokoll von "WGtoHome" das Interface der pfSense mit der Fritzbox auf der anderen Seite

10:18:29.528761 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1629, seq 1, length 64
10:18:29.544324 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1629, seq 1, length 64
10:18:30.641733 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1630, seq 1, length 64
10:18:30.657190 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1630, seq 1, length 64
10:18:31.769912 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1631, seq 1, length 64
10:18:31.785601 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1631, seq 1, length 64
10:18:38.241731 IP 10.111.111.194.42492 > 192.168.178.40.8096: tcp 0
10:18:38.248959 IP 10.111.111.194.42500 > 192.168.178.40.8096: tcp 0
10:18:38.257544 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0
10:18:38.264558 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0
10:18:39.249772 IP 10.111.111.194.42492 > 192.168.178.40.8096: tcp 0
10:18:39.249794 IP 10.111.111.194.42500 > 192.168.178.40.8096: tcp 0
10:18:39.262905 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0
10:18:39.278293 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0
10:18:41.242700 IP 10.111.111.194.42500 > 192.168.178.40.8096: tcp 0
10:18:41.242733 IP 10.111.111.194.42492 > 192.168.178.40.8096: tcp 0
10:18:41.278328 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0
10:18:41.293476 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0
10:18:45.293411 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0
10:18:45.293509 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0

Protokoll von "WGfromInternet" das Interface der pfSense mit den Tunneln zu den Endgeräten irgendwo in freier Wildbahn

10:20:37.481752 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1665, seq 1, length 64
10:20:37.497618 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1665, seq 1, length 64
10:20:38.601706 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1666, seq 1, length 64
10:20:38.617664 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1666, seq 1, length 64
10:20:39.728646 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1667, seq 1, length 64
10:20:39.744584 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1667, seq 1, length 64
10:20:44.848783 IP 10.111.111.194.47004 > 192.168.178.40.8096: tcp 0
10:20:44.848897 IP 10.111.111.194.47002 > 192.168.178.40.8096: tcp 0
10:20:45.841665 IP 10.111.111.194.47002 > 192.168.178.40.8096: tcp 0
10:20:45.849767 IP 10.111.111.194.47004 > 192.168.178.40.8096: tcp 0
10:20:48.041692 IP 10.111.111.194.47002 > 192.168.178.40.8096: tcp 0
10:20:48.041751 IP 10.111.111.194.47004 > 192.168.178.40.8096: tcp 0

Die Firewallregeln sind momentan für die Wireguard Interfaces Any Any. Auch unter Firewall / Rules / WireGuard ist erstmal Any Any konfiguriert.

viragomann

@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:

Bisher dachte ich, wenn Ping funktioniert, dann ist zumindest bei dem Thema Routing/NAT alles passend konfiguriert und meine Probleme liegen eher bei Firewall, MTU Size etc. Irre ich mich da?

Nicht so ganz. Wie du schon im Titel geschrieben hattest, sind das verschiedene Protokolle (ICMP und TCP). TCP ist anders als ICMP "stateful". D.h. die Pakete müssen den Router in einer bestimmten Abfolge passieren. Die Verbindung muss mit einem SYN Paket geöffnet werden, dann lässt der Router SYN-ACK aus der anderen Richtung durch, usw.
Bei ICMP ist das nicht relevant.

So führt beispielsweise ein asymmetrisches Routing zu einem Nicht-funktionieren von TCP. ICMP beeinträchtigt das nicht.

Asymmetrisches Routing bedeutet, dass die Pakete in der einen Richtung (Request) einen anderen Weg nehmen als in der entgegengesetzten (Respond).

In der pfSense ist ein solches Problem im Firewall Log sichtbar, wenn TCP Pakete mit anderen Flags als S oder SEC blockiert werden.
Voraussetzung ist, dass das Logging der Default Block Rule aktiviert ist.

NOCling

Bei AVM Kisten muss man doch noch NetBios über VPN zulassen für SMB Zugriff.
Nicht das hier mal wieder mehr hinter steckt als der Name vermuten lässt.
Mal einschalten und den Tunnel neu aufbauen.

TheBlackOne

@viragomann

Dein Tip war richtig, ich kann im Firewall Log die Blockaden der SYN ACK und wenig später der Resend Pakete.

x Aug 12 14:44:51	WGTOHOME	10.111.111.18:8096	10.111.111.194:38768	TCP:SA
x Aug 12 14:44:51	WGTOHOME	10.111.111.18:8096	10.111.111.194:38766	TCP:SA
.
.
.
x Aug 12 14:44:57	WGTOHOME	10.111.111.18:8096	10.111.111.194:38768	TCP:R
x Aug 12 14:44:57	WGTOHOME	10.111.111.18:8096	10.111.111.194:38766	TCP:R

Ich habe allerdings noch nicht verstanden wie ich das lösen kann. Mit Statischen Routen? Wenn ja wer ist in dem Fall der Gateway oder welchen müsste man hinzufügen?

viragomann

@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:

TCP:SA

Das ist das SYN-ACK Paket, also die Antwort auf ein initiales SYN Paket.

Das bedeutet nun, das SYN Paket hat den Server erreicht, ansonsten würde er kein SYN-ACK schicken, jedoch hat es den Router nicht passiert, der dann das SYN-ACK blockiert.
Es muss also seinen Weg zum Server gefunden haben, jedoch nicht jenen, den das SYN-ACK Paket nimmt.

Vielleicht hilft das, rauszufinden, wie es zu dem Problem kommt.
Ich habe mich nicht so weit mit deinem Setup geschäftig, dass ich da nun mehr sagen könnte.

TCP:R ist wohl eher ein Reset.

eagle61

@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:

Ich habe allerdings noch nicht verstanden wie ich das lösen kann. Mit Statischen Routen?

Ich frage mich gerade zu welchem Wireguard-Tunnel der Eintrag WGtoHOME aus deinem Bild (Status / Gateways) gehört. Bei mir sieht das ganz anders aus, Weder bei meinem Wireguard-Tunnel zur Fritz-Box noch dem WIreguard-Tunnel für mobile Geräte, wie Smartphone, Tablet und Notebooks sieht das Gateway so aus wie bei dir.

Stattdessen zeigt bei mir der Status / Gateways für das Gateway des Wireguard-Tunnels zwischen FritzBox und pfsense unter Gateway den Wert dynamic und unter Monitor keinen Eintrag.

Ich hatte dir ja bereits gestern diesen Hinweis geschickt:
https://v64.tech/t/anleitung-site2site-wireguard-verbindung-zwischen-pfsense-und-fritzbox/438/13
Mit dieser Anleitung und mit meiner Ergänzung in den Kommentaren am Ende hat es bei mir funktioniert und läuft seit Wochen fehlerfrei durch.
(pfsense bei mir Zuhause, FritzBox an entferntem Standort)

Du scheinst einen komplett anderen Ansatz zu verfolgen und offenbar ein Transfernetz zwischen pfsense und fritzbox zu haben, sofern der Eintrag zur Verbindung Fritzbox pfsense gehört.

Fritzboxen unterstützen aber kein Transfernetz, oder wenn dann nur mit ziemlichen Verrenkungen. Vielleicht solltest du daher deinen bisherigen Ansatz verwerfen und den aus der oben verlinkten Anleitung auf v64.tech verfolgen. Bei mir klappt der Ansatz von v64.tech jedenfalls ganz wunderbar und läuft stabil.

eagle61

@TheBlackOne

Zudem fällt mir auf, dass du am WAN interface eine private, also nicht öffentlich routebare IPv4-Adresse anliegen hast. 172.31.1.1

Somit hast du vor der pfsense noch einen Router, was doppeltes NAT bei IPv4 bedeutet. Auch das kann natürlich zu Routingproblemem führen.

Bob.Dig

@eagle61 said in VPN Point to Site ICMP funktioniert, TCP nicht:

Zudem fällt mir auf, dass du am WAN interface eine private, also nicht öffentlich routebare IPv4-Adresse anliegen hast. 172.31.1.1

Sind schon ein paar Merkwürdigkeiten aufgefallen.

@eagle61 Hast Du denn mit deinem Ansatz überhaupt eine IP-Adresse? Ein WireGuard-Interface braucht zwar nicht zwingend eine IP, aber es hat doch Vorteile, wenn es eine hat. Z.B. kannst Du NATen, was Du vermutlich auch musst, wenn mehr als das eine Subnet mit der Fritzbox kommunizieren können soll. Also Dein Ansatz sieht auch eher suboptimal aus.

eagle61

@Bob-Dig said in VPN Point to Site ICMP funktioniert, TCP nicht:

kannst Du NATen, was Du vermutlich auch musst, wenn mehr als das eine Subnet mit der Fritzbox kommunizieren können soll.

Mit mehr als das eine Subnet meinst du mehr als ein SUbnetz auf Seiten der pfsense, also neben dem LAN der pfsense noch andere Subnetze wie DMZ, IoT?

Ja, das geht, sogar ohne zu NATen. Das kann nur der Wireguard-Konfigurationsassist der FritzBox nicht. Manuell kann man das aber nachträglich einrichten. Wie das geht beschreibt "Biberbaer" auch in seiner Anleitung auf v64.tech. Unter Erweiterte Methode zum hinzufügen, bearbeiten oder ergänzen von Peers in der FritzBox. von Oktober 2023. WIchtig ist sein Hinweis "mindestens eine WireGuard Verbindung gespeichert zu haben" bevor man dann die Config-Datei per Hand editiert und dort die von z.B. AllowedIPs = 192.168.0.0/24 ändert auf AllowedIPs = 192.168.0.0/24,192.168.10.0/24

So habe ich es auch gemacht und kann nun alle Subnetze hinter meiner pfsense vom Netzwerk der FB aus erreichen und umgekehrt klappt es auch.

In der FB sieht das dann so aus:

Wobei der zweite Eintrag der ursprüngliche Eintrag aus dem Konfigurationsassistenten war. der erste Eintrag der von mir manuell editierte ist, über den ich nun die drei genannten Subnetze erreichen kann.

Wie man auch sehen kann habe ich nicht nur die erreichbaren Netze ergänzt, sondern auch die DNS-Adresse der pfsense verändert. Geht auch.

Bob.Dig

@eagle61 Ok, etwas sehr frickelig für meinen Geschmack. Man kann aber auch eine Config im Voraus erstellen und dann an die Fritte übergeben, mit allen Netzen.
Was dir aber noch fehlt ist z.B. gateway-monitoring.
Dafür nutzt Du auf Seite der pfSense ein Transfernetz und musst dieses natürlich der Fritte auch noch als allowed IP verklickern. Dann machst Du auf das WG Interface einfach eine IP aus dem Transfernetz. Für das Gateway kannst Du dann die IP der Fritte nutzen (Use non-local gateway aktivieren). So sollte das sauber laufen.
Ich würde vermutlich nur ein Subnet bekannt machen, das Transfernetz, und dann NATen.