Wireguard Fritzbox-pfSense

Teddy

@m0nji
Achja, die lieben Standardregeln, wo ich mich nie drum gekümmert habe. Erstmal deaktiviert, hatte irgendwann mal gedacht die wären nicht löschbar, aber das waren ja nur die BOGON im WAN interface & die LOCKOUT Rule hier.

Naja, witzigerweise funktionierte aber alles, wie es sollte. Hatte bei den Regeln auch teilweise mit tagging gearbeitet, so wie es vor Jahren in zahlreichen Anleitungen zu VPN & Co. zu finden war, um den Datenverkehr zu blockieren, wenn die VPN Verbindung verloren geht.
Genau um GeoIP geht es auch, bzw. wenn man mal einen Film sehen möchte, der beim üblichen Streaminganbieter nicht im Angebot ist ;)

Aber auf die Schnelle fällt dir nicht auf, wo es kneifen könnte, dass nur manche IP Adresse im Subnet der FritzBox erreichbar sind?

m0nji

@Teddy
was sagen denn die states wenn du einen funktionierenden und einen nicht funktionierenden host anpingst? vorhin hast du mir nur eine zeile kopiert. wie ich da aber schon geschrieben habe, müssen es zwei zeilen sein. einmal das lan interface und einmal das wg interface pro ping durchlauf.
und das gleiche würde ich danach noch einmal ausführen mit deaktivierter "traffic through vpn" rule + aktivierter standard rule. du hattest jetzt nur geschrieben, dass du diese deaktiviert hast.

ich gehe auch davon aus, dass du unter den vpn --> wireguard --> peer einstellungen "Allowed IPs" 10.10.20.0/24 und 192.168.178.0/24 eingetragen hast?

so oder so muss du diese ominöse vpn rule anpassen. sie ist halt nicht sauber. das geht jetzt aber bissel über den ansatz dieser anleitung drüber hinaus

Teddy

@m0nji
Ah okay, ich dachte es wäre alles relevante gewesen.

Mit "Traffic through VPN" aktivierter Regel:
192.168.178.1, die FritzBox selbst, welche ich nicht erreiche (ping per PFSense erfolgreich, Ping & Versuch des Aufrufens der Weboberfläche von einer WindowsVM erfolglos):
WGFB icmp 10.10.20.2:32557 -> 192.168.178.1:32557 0:0 3 / 3 252 B / 252 B
WGFB icmp 192.168.3.1:15942 -> 192.168.178.1:15942 0:0 3 / 3 252 B / 252 B

192.168.178.22, einer der Repeater, der gepingt und per Oberfläche aufgerufen werden kann:
WGFB icmp 10.10.20.2:44593 -> 192.168.178.22:44593 0:0 3 / 3 252 B / 252 B
WGFB icmp 192.168.3.1:44037 -> 192.168.178.22:44037 0:0 3 / 3 252 B / 252 B

Ohne aktivierte "Traffic through VPN" Regel, default Regel aktiviert:
192.168.178.1, die FritzBox selbst, welche ich nicht erreiche (ping per PFSense erfolgreich, Ping & Versuch des Aufrufens der Weboberfläche von einer WindowsVM erfolglos):
WGFB icmp 10.10.20.2:48831 -> 192.168.178.1:48831 0:0 3 / 3 252 B / 252 B
WGFB icmp 192.168.3.1:47514 -> 192.168.178.1:47514 0:0 3 / 3 252 B / 252 B

192.168.178.22, einer der Repeater, der gepingt und per Oberfläche aufgerufen werden kann:
WGFB icmp 10.10.20.2:20226 -> 192.168.178.22:20226 0:0 3 / 3 252 B / 252 B
WGFB icmp 192.168.3.1:38182 -> 192.168.178.22:38182 0:0 3 / 3 252 B / 252 B

Allowed IP's sind eingetragen unter "Peers", genau.

Wegen der VPN Regel schaue ich aktuell. Lief wie gesagt alles problemlos im Netzwerk, bis eben auf Wireguard, was ich für's einfache Backup vom Server gerne nutzen würde.

FritzBox sieht übrigens so aus:

m0nji

@Teddy die states passen leider nicht ganz zu dem was du tust...
wenn du von einer windows vm in dem 192.168.3.x interface einen host hinter der fritzbox pingst, müsste das in etwa so aussehen

hier in meinem beispiel habe ich mit meinem notebook im "clients" interface, einen host hinter der fritzbox gepingt.

in deinem beispiel sehe ich jetzt nur jeweils einen ping vom lan und wg interface der pfsense.
also bitte noch mal die states prüfen wenn du den aufruf icmp und port 80/443 von der windows vm machst.
was ich an dieser stelle eigentlich nur sehen möchte ist, ob die verbindung tatsächlich über das lan in das wg interface übergeben wird. warum dann aber nur ein teil der verbindungen durchgehen entzieht sich meiner kenntnis. ist nicht logisch für mich.

Teddy

@m0nji

Mal als kurzes Update:
Ich hatte mit Site-to-Site zwischen Fritzbox und PFSense gelinde gesagt die Schnauze voll und dann eine PFSense VM auf meinem Backup ESXI Server aufgesetzt (Proxmox Umstieg kommt im Sommer).

Anschließend nach der offiziellen Anleitung von PFSense eine Site-to-Site Verbindung aufgebaut und es gab schonmal erhebliche Verbesserungen:

Die beiden TrueNAS Maschinen können sich gegenseitig erreichen und es wurden auch schon per Replication Gigabyteweise Daten hin- und hergeschoben durch den Wireguard Site-to-Site Tunnel. Tunnel funktioniert also an sich, sonst wäre das nicht möglich.

Auf dem Hauptserver habe ich drei Windows VM's:

Eine nur mit einem NIC, kann die Hosts auf dem Backupserver erreichen und aufrufen (192.168.3.0 Subnet)
Eine andere mit nur einem NIC, kann die Hosts auf dem Backupserver erreichen und aufrufen (192.168.3.0 Subnet)
Eine andere mit mehreren NIC, kann die Hosts auf dem Backupserver NICHT erreichen ((192.168.3.0 Subnet und noch u.a. 192.168.10.0, 192.168.15.0)

Nun ist natürlich die Frage, wieso können die VM's mit nur einem NIC den anderen Host erreichen, die mit mehreren nicht.

Aber schweift nun natürlich hier im FritzBox Thread ab, seit die FritzBox nicht mehr im Spiel ist...

Roundness1237

Hallo zusammen,
ich bin eben durch Zufall auf das Thema gestoßen, da ich genau das selbe Problem hatte und auch die selbe Anleitung verwendet habe.

Ich habe als Lösung das S2S-VPN zwischen PFSense und der Fritzbox mittels Wireguard an den Nagel gehangen und stattdessen auf IPSec gewechselt mithilfe dieser Anleitung von Hetzer.
Danach hatten wir keinen Probleme, beide Netzwerke zu erreichen.

https://community.hetzner.com/tutorials/connect-avm-fritzbox-to-pfsense-ipsec

Zu beachten ist, dass man noch das alte Wireguard Gateway sowie die statische Route entfernen muss, damit das IPSec funktioniert.

Mich hat es ebenfalls sehr gewundert, dass PFSense "versteckte Regeln" erstellt, sodass IPSec ohne Anpassung der WAN-Schnittstelle in der Firewall funktioniert. Vielleicht ist es genau so eine verstecke EInstellung, die die Verbindung in Wireguard zum Fritzbox-Netz nicht unterstützt.

Siehe hier "https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/firewall-rules.html"

Vielleicht hilft die Information ja jemanden :)

Liebe Grüße

alex303

Wenn auf meinen Handy Wireguard eingeschaltet ist, komme ich immer von außen in mein Netzwerk.
Es sei denn ich bin zu Hause, dann funktioniert der Zugriff auf meine Synology nicht mehr solange Wireguard eingeschaltet ist.

In den Synology Apps habe ich den Zugang mit der DynDNS Adresse eingetragen, damit es extern auch ohne VPN funktioniert, im DNS Resolver unter Host Overrides habe ich die Adresse und die IP der Synology eingetragen.

Was fehlt denn hier noch?

Gruß
Alexander

Teddy

Komische Sache mit WireGuard und der FritzBox.

Ich hatte ja entnervt aufgegeben. Alles zurück auf Basis-Einstellungen bei der FritzBox, nur den DynDNS eingerichtet (wird auch fleißig erfolgreich upgedatet von der FritzBox) und wenigstens für meinen Laptop über den FritzBox Assistenten einen Tunnel konfiguriert, Konfigurationsdatei heruntergeladen und im Wireguard importiert. Selbiges für's Smartphone, QR Code mit der Wireguard App gescannt, fertig. Lief scheinbar erstmal.

Heute, in anderen WLAN und auch per LTE versucht mich mit diesen Konfigurationsdateien zu verbinden und es werden exakt 0 Byte an Daten empfangen. Ob Android, ob Windows 11, ob WLAN, ob LTE. Und das, obwohl die Box von DeutscheGlasfaser nun in Werkseinstellungen nur mit DynDNS und den vom Assistenten konfigurierten Einstellungen in Betrieb ist. Ich hab's Gefühl da ist irgendein Bug drin. Dass sowohl mein Android, als auch mein Windows 11 falsche Einstellungen vom Assistenten bekommen haben oder durch's WLAN oder LTE Wireguard blockiert wird, kann ich jetzt ziemlich sicher ausschließen. Aber wenn nicht mal das funktioniert, lohnt es für mich nicht dort noch stundenlang herumzudoktern.

@m0nji
Trotzdem tausend Dank für deine Bemühungen und Tips für die FireWall, Regeln habe ich mittlerweile überarbeitet.

m0nji

@Teddy das hat zwar jetzt nichts mehr mit pfSense zu tun und sollte eigentlich in einem eigenen Thread besprochen werden aber was mich direkt bei der Beschreibung stutzig macht ist der Umstand, dass du DeutscheGlasfaser erwähnst.
Soweit ich weiß, bietet DeutscheGlasfaser nur CGNAT an und das bedeutet, du hast keine eigene öffentliche IPv4 Adresse. Wenn du jetzt über ein fremdes WLAN oder LTE dich nach Hause verbinden möchtest, geht das ausschließlich über IPv6. Wenn dein DYNDNS nicht sauber auflöst und das fremde WLAN/LTE kein IPv6 kann, dann wirst du auch keine Verbindung mit deiner Fritzbox aufbauen können.

FSC830

Ja ich weiß, negro posting... der Thread ist schon über 1 Jahr alt.
Aber es passt dazu.

Mit einer anderen Fritzbox (7510) habe ich nun eine Site-2-Site WG Verbindung zwischen der FB und pfSense eingerichtet.
Es läuft auch alles so wie es soll, jedes Gerät kann das jeweils andere Netzwerk erreichen.
Mir ist nur eines aufgefallen:

Die WG-IP der Fritzbox antwortet nicht auf einen Ping, die LAN IP Adresse antwortet.
Ist das auf Fritzboxen allgemein so?
Wenn ich mit einem mobile Client per WG verbunden bin (zur pfSense), dann kann ich die WG IP des Peers anpingen, die FB ist der einzige Peer, bei dem der Ping ins Leere läuft.
Fritzbox Eigenart?

Gruss

Bob.Dig

@FSC830 said in Wireguard Fritzbox-pfSense:

Ist das auf Fritzboxen allgemein so?

Jau. Bei einem WG-Site2Site-Tunnel nutzt die Fritte kein Transitnetz, deswegen kannst Du auch die "WG-IP der Fritzbox" nicht pingen, sie existiert schlicht nicht. Du kannst aber die LAN-IP der Fritzbox zum Monitoring pingen.

Spacey 0

Check mal die YT Videos von "Raspberry Pi Cloud" - der hatte kürzlich was zum Thema Fritz!Box und VPN gemacht...

FSC830

Oh man, diese Fritzboxen zerren an meinen Nerven...
Der Tunnel lief nun einige Tage problemlos, seit letzter Nacht aber nicht mehr.
In der pfSense war zu sehen, daß der letzte Handshake vor etwas 12h war.
Es gab keine Änderungen der IP (würde auch per DynDNS aktualisiert).
Ich bin mir sicher, es liegt nicht an der Netgate Appliance, die mobile Clients können sich nach wie vor per WG verbinden.
Aber die Fritte will nicht mehr. Ich habe auf der pfSense den Dienst neu gestartet, auch die FB durchgestartet, nada. Der Tunnel wird nicht mehr aufgebaut .
Gibt es dazu auch Ideen, wie man den Tunnel von der FB erzwingen kann?
Was AVM macht ist einfach nur Grütze.

Gruss

P.S. Das war die Lösung: einfach seinem Ärger Luft machen , kaum hatte ich das geschrieben, war der Tunnel wieder aktiv.
Mal sehen, für wie lange... (Keep alive ist 25s)

Bob.Dig

@FSC830 WireGuardd ist in der Sense mit der neuen Version bei mir inzwischen instabiler als zuvor...

FSC830

Oh, noch instabiler? Geht das? </sarkasmus>
Ich habe FritzOS 8.02 und leider kein altes OS Image mehr.
Seit 7.50 kann man diese blöde 2FA nicht mehr abstellen, das ist zum .
Für meine 7490 speichere ich die Images immer ab, aber hier war schon alles zu spät, die hatte schon 7.57(?) als ich dazu kam.
Ich lasse jetzt aber von der pfSense Seite aus in 4h Intervallen eine Pingabfrage machen, dann sehe ich zumindest, wie lange der Tunnel etwas hält.
Könnte ich auch stündlich machen, aber erst mal reicht es mir so.

Gruss

JeGr

@Bob.Dig said in Wireguard Fritzbox-pfSense:

@FSC830 WireGuardd ist in der Sense mit der neuen Version bei mir inzwischen instabiler als zuvor...

Antworten

Ich sehe da das Problem nach wie vor nicht auf der Sense außer vllt. bei der Konfiguration, die schöner gehen würde. Aber die Config, die produziert/konfiguriert wird ist völlig im Einklang mit dem was Wireguard in seiner Doku hat. Die AVM Grütze ist da leider weit entfernt von und das ist eben völliger nonsense. Die gegängelte Setup Kiste, die die UI da macht, ist völlig unnötig. :/

@FSC830 said in Wireguard Fritzbox-pfSense:

P.S. Das war die Lösung: einfach seinem Ärger Luft machen , kaum hatte ich das geschrieben, war der Tunnel wieder aktiv.
Mal sehen, für wie lange... (Keep alive ist 25s)

Andere Alternative: Habe jetzt schon mehrfach gefunden und gelesen, dass es mehr "Freude" bringt, die Konfiguration einfach händisch zu machen, von der Fritte runterzuladen, manuell editieren, wieder hochladen und plötzlich gehen auch Dinge, die angeblich nicht gehen. Mehrere Netze, editierte allowed-ips etc. und plötzlich klappt auch der Tunnel wieder.

Ich will da die Sensen nicht in Schutz nehmen, aber der Klapperkasten von AVM ist da keinerlei Hilfe an irgendeiner Front wenn man vernünftiges VPN will. Leider :(

Was wir live im Stream während der letzten UG mal ausprobiert hatten, waren Änderungen nach der Anleitung hier:

https://znil.net/index.php?title=FritzBox_-_Site_to_Site_VPN_zu_pfSense_mit_WireGuard_ohne_Tunnel_NAT

Entgegen der Logik der Fritte wird in den pfSense Dokus überall ein sauberes Transfernetz verlangt/aufgesetzt. Nur die Fritte konfiguriert keines. Mit Konfig Edit und Upload gings dann plötzlich doch und die Sense sieht plötzlich auch oh Wunder ihr konfiguriertes Gegenstück auf der Transfer IP.

Vielleicht hilfts dem ein oder anderen weiter, allerdings wie immer Vorsicht an der Stelle vor out-of-date Howtos/Tutorials/Blogs, die alte Inhalte haben oder falsch sind, weil sich grundlegende Sachen geändert haben. Hier ist jetzt Stand Juni-2025 und wir habens einfach mal durchgespielt. Ging zuletzt zumindest :)

Cheers

Bob.Dig

@JeGr Jo, ich habe keinen einzigen Tunnel zu einer Fritte, daran kann es bei mir nicht liegen. :)

FSC830

@JeGr Genau nach dieser Anleitung habe ich den Tunnel eingerichtet, das funktionierte auf Anhieb.
Und ja, ich habe auch die Konfig der Fritte genommen, editiert und wieder hochgeladen.

Zur Zeit ist der Tunnel aber wieder weg, nachdem er seit Montag problemlos lief.
Aber: diesmal ist die Fritte unschuldig, gibt eine größere DSL Störung in der Region.
Gut, daß man das Mobil auf als Hot-Spot verwenden kann.

Gruss

Bob.Dig

@JeGr said in Wireguard Fritzbox-pfSense:

Nur die Fritte konfiguriert keines. Mit Konfig Edit und Upload gings dann plötzlich doch und die Sense sieht plötzlich auch oh Wunder ihr konfiguriertes Gegenstück auf der Transfer IP.

Es gibt nur ein mögliches Problem: Wenn die Fritte eine WireGuard-IP bekommt, dann macht sie immer NAT. Bei einer Site2Site-Verbindung will man das oft nicht und dann muss man halt darauf verzichten, ihr eine zu verpassen. Wenn man es dennoch tut, dann wird der WireGuard-Tunnel in der Fritte auch nicht mehr als S2S angezeigt, sondern als stinknormale WireGuard-Verbindung, mit NAT.

JeGr

@Bob.Dig Ich würde ja behaupten, dass für die meisten, die sich mit ner Fritte auf der anderen Seite rumschlagen müssen, NAT das kleinste Problem ist. Aber vielleicht nicht. ;)

Ich seh zwar den Grund nicht, warum die Box da meint, sie müsse dann NAT machen - das ist halt auch wieder so ein automatisch erkennen bullshit weil könnte ja jetzt für Einwahl Clients sein - aber das ist generell eben das AVM Problem egal bei welchem VPN. Dass Entscheidungen/Vermutungen getroffen werden, die an der Realität vorbei gehen. IPsec braucht nur eine Phase, wer braucht schon mehr als ein Netz. Dito Wireguard etc. Das ist halt wirklich leidiger Bullshit inzwischen.