Wireguard (wg-easy) nicht alle IPs erreichbar

Deine WG Konfig ist suboptimal, denn du machst ein Gateway Redirect was sämtlichen Traffic über das VPN schiebt und Performance kostet.
Deutlich besser wäre hier Split Tunneling. Das Wireguard Tutorial erklärt wie das geht und welche statische Route dafür in der FB erforderlich ist. Lesen und verstehen...
Was die Kameras anbetrifft solltest du prüfen ob die ein entsprechendes Default Gateway gesetzt haben?! Traceroute (tracert bei Winblows) ist hier dein Freund.

Grundsätzlich stellt sich die Frage warum du überflüssigerweise einen WG Server dort nutzt? Die FB ist ein VPN Router und supportet direkt einen VPN Zugang:
https://avm.de/service/vpn/uebersicht/
Ist auch Security technisch deutlich besser denn so wie oben muss du ungeschützten Internet Traffic in dein geschütztes lokales LAN leiten. Keine gute Idee wenn man einen VPN fähigen Router besitzt...
Bei einfachen China Kameras von der Stange wohl eher nicht der Fall...

Die IP vom Server ist 10.8.0.xxx
Die IP's der Kameras sind 192.168.2.xxx

Nach meinem Verständnis bedeutet das, dass der Ping aus dem Tunnel von 10.8.0.xxx kommt
Eventuell antworten die Kameras ja nur auf Anfragen aus ihrem eigenen Subnetz.
Das lässt sich vermutlich am Besten mit einem Paketmitschnitt auf dem RPI ermitteln.
Wenn da Pings zu den Kameras aus dem Tunnel kommen, aber keine Antworten von den Kameras an den Tunnel, sollte es das gewesen sein.

Gruß
Claus

Korrektur:

Die Pings kommen mit der Tunnel-IP-Adresse des Clients, also 10.8.0.2, wenn das ganz oben die Client-Config ist.

BTW:
Warum eine Netzmaske /24 für den Client?
Der hat doch für den Tunnel genau eine Adresse und kein ganzes Subnetz, also eher /32
Und wozu den PresharedKey?
Der Tunnel ist doch sowieso schon über Private-/Public-Key abgesichert
Das macht imho nur Sinn, wenn der PresharedKey mit einem Kennwort geschützt wäre, um den Zugriff auf den Tunnel auf dem Client zusätzlich abzusichern - so wie es bei OpenVPN möglich ist...
... und auch nur dann etwas nutzt, wenn man das Kennwort nicht speichert - Sicherheit vs. Komfort

Gruß
Claus

Reicht für deine Zwecke aber vollkommen aus. Beim RasPi, zumindestens bei den 2er und 3er Versionen, ist das NIC Interface über den USB Bus adaptiert. Entsprechend schwach ist der Datendurchsatz. Bei dir halbiert sich der dann auch noch, da du ja mit einem "VPN Server on the Stick" also einer einarmigen Anbindung arbeitest wo eingehender und ausgehender VPN Traffic über das gleiche Interface rennt.
In Summe wird deshalb dann wohl auch das schwache FB VPN deiner Löung überlegen sein. Sowas lohnt sich meist nur wenn man einen nicht VPN fähigen Router betreibt.
So oder so...beide Lösungen führen natürlich zum Erfolg.

Bei dir ist es lediglich deine falsche Wireguard Konfig die die korrekte Funktion verhindert. Das hiesige Wireguard Tutorial beschreibt dir im Detail wie es richtig zu machen ist.

Fehlende Rückwärts-Route in den Kameras. Entweder in den Kameras als Router für das 10.8.0.2er Netz den Raspi eintragen oder der FB (als Default Gateway für die Kameras) beibringen, das das 10.8.0.2er Netz über den Raspi zu erreichen ist.

Jein...denn das ist gar nicht nötig!
Die Kameras des TOs sind sicher nicht statisch addressiert sondern bekommen ja mit ziemlicher Sicherheit ihre IPs und Default Gateway per DHCP von der lokalen FritzBox. Damit zeigt das Default Gateway der Kameras immer auf die FritzBox. Diese sollte dann auch die Route ins interne WG IP Netz kennen.
Der TO wird sicher vergessen haben eine statische Route in das WG VPN IP Netz auf der FritzBox einzutragen. Der typische Anfängerfehler...
Ist aber hier genau beschrieben wie das einfach zu lösen ist.

Du hast das leider völlig missverstanden...es ging lediglich ums VPN Grunddesign und nicht um Produkte. Die Kombination one armed VPN Server und RasPi (wenn Ver. 2 oder 3) ist eben halt unglücklich was Performance und Durchsatz angeht.
Von der Sicherheit mal gar nicht zu reden weil du über die FB Firewall so auch noch ungeschützten Internet Traffic in dein internes LAN leiten musst. Alles kein wirklich gutes VPN Design und eher Bastelei.

Nichtsdestotrotz funktioniert es aber auch und wenn du mit deinem Dacia Logan so leben kannst ist das doch auch alles OK. Beide Lösungen sind wie gesagt machbar unbd errechen das was du willst.
Wie vermutet. Ob DHCP oder Statisch ist egal, Hauptsache ein Default Gateway ist eingetragen.
Richtig, das ist sinnfrei aber genau DAS würde dir oben schon mehrfach gesagt, denn genau DAS ist falsch an deiner WG Konfig.
Du machst mit der "Allowed 0.0.0.0/0" Ein Gateway Redirect am Client was völlig unsinnig ist und auch zu der Problematik führt. Ändere das auf Split Tunneling und alles wird gut. Bitte wirklich mal das o.a. Tutorial lesen!
Das zeigt das deine Kameras kein Default Gateway haben oder das bei statischer Konfig nicht annehmen. Bei chinesischer Billigware kommt sowas schon mal vor wenn man vom DHCP abweicht. Ggf. setzt du also einmal eine Kamera testweise auf DHCP und testest das aus.
Du kannst ja auch immer die IP Adressvergabe statisch in der FB an die Mac Adresse der Kamaera binden um so eine Quasi feste IP zu bekommen.
Dann terminierst du dein VPN aber direkt auf dem Router! Mit einem internen VPN Server und Split Tunneling ist das nicht möglich.
Sehr wahrscheinlich machst du auch noch im internen VPN Tunnel NAT (IP Adress Translation) was dann nochmal gravierend die VPN Performance verschlechtert. All das sind typische Anfängerfehler beim VPN Design mit den daraus resultierenden Nachteilen. Besonders der Datensicherheit.
Aber egal...wenn du damit leben kannst OK.
Dein Problem sind die fehlenden Gateways in den Kameras oder eben die fehlende statische VPN Route in der FB. Traceroute ist, wie bereits gesagt, dein Freund.

hinkt etwas, da dein Audi(Fritte) ja quasi schon in der Garage steht.

Du wählst sozusagen, obwohl Du den Audi (in nahezu vollausstattung) in der Garage abfahrbereit hast, deinen Trabbi, der Dir zufällig zugeflogen ist.
Du kommst damit sicherlich auch an dein Ziel mit jener Rennpappe, verzichtest alledings auf mehr oder weniger aktuelle Technologien, Sicherheiten, Ausstattung und Features und vor allem: Geschwindigkeit.

Zudem hoffe ich ja, dass Du deinen Raspi vernünftig mit SSD ausgestattet hast. Oder etwas gegen den nativen Linux-logwahn machst, sonst ists bald aus mit der VPN Verbindung - ich meinte: deiner SD Karte (die relativ bald sterben wird im vgl. zur Fritte)

Aber grundsätzlich, rollen beide "Autos".

Sonst: was aqui sagt.

Grüße und viel Erfolg

Hmm,

Default Gateway?

Ich habe ja praktisch das gleiche Setup wie der TO und hier funktioniert der Ping durch den Tunnel.
Da ich das Funktionieren verstehen wollte, habe ich auf dem WG-Server zweimal tcpdump auf die ICMP-Pakete losgelassen - einmal für eth0 und einmal für wg0.
Dann vom WG-Client einen Ping auf einen Host im LAN des WG-Servers abgesetzt und die beiden Capture-Files hinterher mit mergecap zusammen gemischt.
Wireshark sagt dann dazu:
Aus dem Tunnel kommt ein Echo-Request-Paket von der WG- an die LAN-Adresse.
Von der LAN-Adresse geht ein Echo-Request-Paket an die Zieladresse.
Von der Zieladresse kommt ein Echo-Reply-Paket an die LAN-Adresse und geht weiter an die WG-Adresse zum Absender - so weit ist der Ablauf wie von mir erwartet.
Aber es kommt direkt danach noch ein zweites Echo-Reply-Paket von der Zieladresse an das Default Gateway!

These: Die Kameras senden nur ein Echo-Reply an ihr Default Gateway - den Router.
Und wenn da keine statische Route hinterlegt ist, kann der natürlich nix damit anfangen.
Damit stimmt natürlich die Aussage, dass auf dem Router eine statische Route auf den WG-Server eingetragen sein sollte - auch wenn das eigentlich dafür gedacht war, ein ganzes Subnetz hinter dem WG-Tunnel erreichen zu können und nicht nur den Tunnel selbst.

Das würde ich allerdings nicht als typischen Anfängerfehler bezeichnen, eine sagen wir mal alternative Ping-Implementation in einem Host nicht mit der Router-Krücke behoben zu haben.

Gruß
Claus

Bedeutet dann immer das man völlig überflüssiges NAT im eigenen Netz macht und sich somit VPN Performance raubt. (iptables bzw. nftables masquerade)
Der Grund sind die vielen Anleitungen im Web für Laien die das propagieren um diese nicht mit Routing Grundlagen zu behelligen. Es ist letztlich aber immer schlechtes VPN Design und ein Performance Fresser sofern man nicht einen alten Router besitzt der keinereli statisches Routing supportet.
Viel schlimmer ist noch das das Routing dann nur in eine Richtung klappt also immer nur VOM Client zum Ziel, niemals aber umgedreht weil das die NAT Firewall verhindert.
3 triftige Gründe also warum man NAT nicht machen sollte.
Das ist Unsinn wenn der Request von der VPN Client IP kommt. Das gepingte Endgerät kann ja niemals von Geisterhand selber ICMP Traffic an Ziele schicken von denen nie etwas als Request gekommen ist.
Auch das ist eine technisch falsche Schlussfolgerung, sorry. Mit ICMP (Ping) an sich hat das gar nichts zu tun, denn dessen L3 Transport Basis ist ja auch IP.
Das Grundproblem ist eben das NAT im Tunnel.
Damit sendet der VPN Server die Client Pakete NICHT mit der eigentlichen VPN IP ans Endgerät im lokalen LAN sondern NATet sie auf seine eigene LAN IP als Absenderadresse.
Damit "sehen" dann alle anderen Endgeräte im remoten lokalen LAN einen vermeintlich lokalen Absender und bräuchten dann auch gar kein Gateway und auch keine Route. Sie "denken" auf diese Weise das der Absender sich im lokalen LAN befindet und bemerken so nicht das der in Wahrheit in einem ganz anderen IP Netz sitzt.
Folglich antworten sie direkt und der NAT/Masquerading Prozess im VPN Server rückübersetzt es dann wieder in die eigentliche Adresse.
Simpleste NAT Grundlagen also... Siehe: https://de.wikipedia.org/wiki/Netzwerkadressübersetzung

Wie bereits gesagt, all dieser Overhead ist sinnfrei wenn man sich das NAT spart und damit ist die Route dann keinesfalls eine Krücke sondern die saubere Lösung wie es sich auch IP technisch gehört. 😉
Aber gut...muss jeder selber wissen wie er zu seinem VPN Glück kommt. Ob mit oder ohne überflüssiges NAT. Beides geht und führt zum Erfolg...
Die Frage ob es bei Bandbreiten- und Laufzeit sensiblen Daten wie Video von Kameras dann NAT eine wirklich gute Idee ist?! Kann sich ja dann jeder selber beantworten... Richtige Netzwerker würden die Route bevorzugen.