Du meinst für dein Transfernetz?

Genau. Technisch mag die Begrifflichkeit aber hier nicht ganz zutreffen, weil die Fritzbox kein Transfernetz nutzt, die Sense aber irgendwie schon.

Spoiler

Hab nun das /30 durch /32 ersetzt.

Du meinst für dein Transfernetz? Für alle anderen Netze wird alles seitens der FB akzeptiert. /24 oder auch /27.

Ich z.B. nutze auch /27-Netze und weder pfsense noch FB haben damit ein Problem. Aber ich habe eben auch noch kein Transfernetz für die FB konfiguriert.

Man kann doch relativ leicht Allowed IPs hinzufügen, habe ich gerade festgestellt

Das ist ziemlich genau die Methode aus der von mir gestern verlinkten Anleitung bei v64.tech, nach der ich das auch gemacht habe. Wird dort in einem Kommentar von Oktober 2023 beschrieben.

• Einfach die "WireGuard-Einstellungen" anzeigen und exportieren.
• In der Datei die neuen Allowed IP hinzufügen und speichern.
• Die bestehende WireGuard-Verbindung in der Fritte löschen.
• Eine neue Verbindung anlegen, dabei auswählen, dass die WG-Verbindung bereits auf der Gegenstelle erstellt wurde.
• Einen Namen vergeben und die editierte Datei laden.

Solange die Fritte vor Ort gemanaget wird, ist das kein größeres Problem. Das läuft jedenfalls und damit würde ich natürlich auch kein NAT benutzen wollen bei der Site2Site-Verbindung.

MTU habe ich einfach möglichst gering gesetzt, weil ich nicht weiß, was die Fritte nutzt.

1392 ist die voreingestellte MTU der Fritte für Wireguard-Tunnel.

Kannste dir aber anzeigen lassen. Linux tracepath zeigt die an.

Spoiler

MTU habe ich einfach möglichst gering gesetzt, weil ich nicht weiß, was die Fritte nutzt.

Die Fritte selbst NATet übrigens nicht über den Tunnel. Eine Frage, die ich mir lange selbst gestellt habe, nun kenne ich die Antwort.

Wenn du der Anleitung von v64.tech abarbeitest, hast du einen wireguard tunnel der mit einer fritzbox funktioniert. ich habe ihn genau so konfiguriert und habe halt ein vpn zu dem 190er netz.

Kann man das? WOher bekommt die Fritte dann den private Key?

So wie ich das gelesen habe, erstellt Du diese WG-Config mit privatem Key und allem wie sonst außer, dass Du keine Adresse mitgibst, die setzt die Fritte automatisch, auf ihre LAN-Adresse.
Ich hatte das so auch heute probiert und ging, allerdings habe ich die Verbindung nicht getestet, da ich keine Anwendungsfall dafür habe, also die Config war nur ausgedacht. Es wurde mir aber alles passend in der Fritte angezeigt.

Man kann aber auch eine Config im Voraus erstellen und dann an die Fritte übergeben, mit allen Netzen

Kann man das? WOher bekommt die Fritte dann den private Key? Soweit ich das verstehe muss man dazu mindestens einmal eine Wireguard-Verbindung per Konfigurationsassistenten erstellen. genau deswegen darf man ja auch nicht alle erstellten Verbindungen löschen, wenn man die Vrbindung nachträglich manuell editiert. Dann löscht die Fritte nämlich alle Keys umd man fängt wieder von vorn an.

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.

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.

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.

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.

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.

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?

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.

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.

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.