OPNsense Wireguard Tunnel zu Tunnel Verbindung

Und nochmals die entscheidende Frage die du wieder nicht beantwortet hast: Macht die OPNsense NAT (IP Adress Translation) am WAN Port???
Wenn du das nicht abgeschaltet hast (Im Default ist NAT immer aktiv an der OPNsense!) dann machst du an B ja doppeltes NAT und doppeltes Firewalling. Per se nicht falsch muss man aber immer auf dem Radar haben!

Die statische Route an der FritzBox ist dann völlig sinnfrei und auch kontraproduktiv und kannst du wieder löschen.
Die OPNsense B setzt ja dann alles um auf ihre WAN Port IP, die ja eine IP aus dem lokalen LAN der FB ist. Folglich "denkt" die FritzBox alles was von der OPNsense B kommt ist etwas aus ihrem lokalen LAN. Damit ist dann eine statische Route völlig überflüssig.
Die ist nur dann sinnvoll wenn das NAT an der Firewall deaktiviert ist!!
Machst du also NAT solltest du diese Route unbedingt wieder löschen!
Grundlagen zu dieser NAT Thematik in Router Kaskaden mit doppeltem NAT wird dir in den folgenden 3 Threads explizit erklärt:
Kopplung von 2 Routern am DSL Port
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Lesen und verstehen!!

Das ist auch korrekt so!
Bahnhof??? Wieso WG Server?? 🤔 Der WG Server ist doch auf der Firewall selber?!
Hier hast du wohl was grundlegend verwechselt, oder?! Die Aussage ist etwas wirr...

Du meinst sicher das du am Regelwerk auf dem WAN Port der Firewall B dort UDP 51820 von any auf die "WAN_IP_ADDRESS" der Firewall passieren lässt, richtig??
Zusätzlich musst du drauf achten das der Haken bei "Block RFC 1918 IP networks" am WAN Port der kaskadierten OPNsense B entfernt ist, denn dein Fritzbox LAN ist ja ein RFC 1918 IP Netzwerk!

Befinden sich noch Endgeräte im lokalen LAN der FritzBox? Diese können prinzipbedingt dann durch die Firewall am WAN Port keine Endgeräte im lokalen LAN der OPNsense B erreichen und auch keine Endgeräte via VPN im lokalen LAN der OPNsense A. Das sollte dir in dem Setup klar sein.
Andersrum geht es aber. Geräte im lokalen LAN OPNsense A und B können Endgeräte im lokalen LAN FritzBox B erreichen.
Nur das du das designtechnisch auf dem Radar hast.
Details zur richtigen Wireguard Einrichtung auf der OPNsense inspesondere dem Interface Assignment des virtuellen WG Interfaces findest du u.a. auch HIER.

OK, dann die FB Route bitte nicht löschen!
Gut ist das das FB LAN dann auch nur reines Koppelnetz ist. Soweit alles erstmal richtig gemacht! 👍

Die Lösung ist dann sehr einfach, denn dann hängt alles davon ab was in den AllowedIPs definiert ist, sprich was du in den WG Tunnel routest. Und... wie dein Regelwerk am virtuellen WG Interface eingestellt wird!
Da du dazu leider keine Angaben machst wird eine genaue Hilfe sehr schwer bzw. ist dann eher Raterei. Wie sollen wir ohne dieses Regelwerk zu kennen dir ggf. Fehler aufzeigen können...?!

Aber leider alles ohne jegliche Firewall Regelwerke anzugeben bzw. das was in der WG Konfig mit den "AllowedIPs" angegeben ist und in den Tunnel gehen soll!

Du kannst oben schon sehen das du dort falsche Subnetzmasken für die internen IP Adressen agegeben hast. Damit ist das Routing dann inkorrekt. Diese müssen immer /32er Hostmasken sein. Siehe auch Wireguard Tutorial
Was etwas verwirrend ist das du dein Smartphone einmal als Server und einmal als Client definierst.

• Was ist es denn wirklich?? In der Regel arbeitet ein Smartphone immer im Client Mode (VPN Initiator) und nie als Server! Das solltest du nochmal checken.
• Ist es gewollt das du ein Gateway Redirect am Smartphone machst also ALLES in den VPN Tunnel sendest auch lokalen Internet Traffic?
• Deine interne WG Adressierung stimmt nicht! Dein Smartphone Client ist in einem völlig anderen, internen IP Netz als deine Firewalls!! Das kann man machen, müsste aber so nicht sein und ist überflüssig bzw. verkompliziert unnötig das Routing, denn der Server kann sowohl Site2Site als auch das Smartphone bedienen.
• Zudem ist die Client Adressierung falsch. Die internen Client IP hat immer die Maske des internen Netzes (/24 bei dir) nur die AllowedIPs nutzen eine /32 Hostmaske.
• Du hast wiederum vergessen welcher der beiden Firewalls die WG Server Rolle beinhaltet?!

Du meinst die Regel auf der virtuellen internen VPN Schnittstelle???
Sorry, etwas präziser solltest du mit deinem Feedback schon sein, sonst muss man unnötigerweise alles immer wieder und wieder explizit nachfragen um dir gezielt helfen zu können.
Solltest du also das virtuelle interne Interface meinen lautet die Antwort JA.
Hier wäre eine any zu any Schrotschussregel erstmal zielführend.
Beachte bitte das dieses Regelwerk ausschliesslich nur auf dem virtuellen WG Interface zu setzen ist was nach dem Interface Assignment auftaucht und NICHT auf dem System generierten Interface was leer bleiben muss!
Hier am Beispiel einer pfSense mit Wireguard:

OK, dann ist der Gateway Redirect auf dem Client natürlich korrekt!

Deine WG Konfig ist als solche viel zu umständlich gedacht. Du solltest keine 2 interne WG Netze dafür definieren. Das ist überflüssig. In so einem kleinen Setup macht das keinen Sinn und es reicht ein internes WG Netz völlig.
Baue das also um auf eine simple, klassische Standard Konfig.

Hier findest du eine identische Beispielkonfig wie das genau auszusehen hat mit der Adressierung und den "AllowedIPs" und an der du dich orientieren kannst:
Wireguard Site2Site mit Roadwarrior

Ja, natürlich, es geht auch mit 2 unterschiedlichen internen WG IP Netzen. (Siehst du z.B. in diesem Thread mit einem etwas anspruchsvolleren Setup).
Du musst dann allerdings bei den Allowed IPs zusätzlich immer dann deine Client IP Adresse mit einer /32 Maske eintragen ansonsten wird das Client IP Netz nicht in den Tunnel geroutet.
Vice versa natürlich auch die beiden lokalen IP Netze beim Client.

Du merkst aber schon wie aufwändig das alles wird weil du immer diese doppelte IP WG Adressierung berücksichtigen musst die dir außer erhöhtem Konfig Aufwand sonst nichts bringt.

Ausschliesslich nur bei den "AllowedIPs" !!
Die internen Adressen die unter "Address" definiert werden haben immer ihre "normale" Netzwerk Adresse. Wie gesagt... Lies das Tutorial und die Beispiele, dort steht alles haarklein wie es richtig auszusehen hat!

Dein Beispiel ist falsch!! Bitte wirklich einmal die Tutorials und Beispiele lesen die man dir hier als Lösung postet!
Zumindestens wenn es der "AllowedIP" Parameter ist und dein internes IP Netz für die Clients das 10.1.1.0 /24 ist und das Smartphone die .1/24 hat. Bei S2S dann intern 10.2.2.0/24 und die Router jeweils intern .1 mit lokalem LAN .100.0/24 für Router 1 und intern .2. mit lokalem LAN .100.0/24 für Router 2.

• Eine /2er Subnetzmaske gibt es gar nicht!
• Für das Smartphone gilt dann: "AllowedIPs = 0.0.0.0/0" und nix anderes denn dort machst du ja Gateway Redirect
• Router 1: "AllowedIPs = 10.1.1.1/32, 10.2.2.2/32, 192.168.200.0/24"
• Router 2: "AllowedIPs = 10.1.1.1/32, 10.2.2.1/32, 192.168.100.0/24"

Eigentlich doch ganz einfach und logisch, oder?

Solltest du nur mit einem internen IP Netz arbeiten (10.2er Netz weglassen) wie empfohlen dann gilt:

• Für das Smartphone (intern 10.1.1.3 /24) gilt dann: "AllowedIPs = 0.0.0.0/0" und nix anderes denn dort machst du ja Gateway Redirect.
• Router 1: "AllowedIPs = 10.1.1.2/32, 10.1.1.3/32, 192.168.200.0/24"
• Router 2: "AllowedIPs = 10.1.1.1/32, 10.1.1.3/32, 192.168.100.0/24"

Sieht aber in den von dir geposteten Screenshots völlig anders aus!! Dort ist weit und breit nichts von any zu any zu sehen?!
Entweder hast du also die falschen Screenshots gepostet oder nutzt ein völlig falsches Regelwerk. Dann muss man sich dann auch nicht groß wundern das nix klappt.