PFsense Outbound NAT (S-NAT)

Nein, das ist falsch und zeigt das du die IPsec Verbindung falsch oder in Bezug auf die OpenVPN Anbindung fehlerhaft konfiguriert hast. NAT im Tunnel ist immer kontraproduktiv.
Kollege @BiberMan hat es oben schon gesagt:
Hier musst du lediglich eine 2te Phase 2 mit dem internen OpenVPN IP Netz (10.55.66.0) dazukonfigurieren das der Traffic mit in den Tunnel geroutet wird dann kannst du dir die unnötige und überflüssige NAT Frickelkei sparen. Negativ dazu kommt das das NAT das Routing in eine Einbahnstrasse verwandelt.
Beim OpenVPN musst du zusätzlich einen Routing Eintrag in die Client Konfig bringen sofern du mit Split Tunneling statt mit einem Redirect arbeitest. Siehe dazu Beispiele im OpenVPN Tutorial.

Vielleicht auch einmal Zeit über die Ablösung des wenig performanten und skalierenden OpenVPN nachzudenken. Wenn du so oder so alles auf IPsec hast, dann ist es unsinnig noch zusätzlich mit einem 2ten separaten VPN Protokoll zu arbeiten. Zumal man mit der pfSense das in allen Betriebssystemen und Endgeräten so oder so vorhandene onboard VPN mit entweder L2TP oder IKEv2 nutzen kann und sich so den Zoo mit überflüssigen VPN Protokollen und überflüssiger Client Software ersparen kann.
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Ein Beispiel für das Setup mit 2 Phase 2 SAs findest du unter anderen hier:
PFSense mit Fritzboxen verbinden
Routingprobleme über OpenVPN auf Fritzbox
usw.

Wenn deine pfSense die 192.168.80.5/32 im LAN hat ja, so wäre es i.O.

Nein ... Du solltest hier nur eine IP nutzen die an der pfSense selbst anliegt, die pfSense hat hier IMHO eine Beschränkung. Pack da die 192.168.80.10/32 rein, dann lüppt dat sofern deine Firewall den Traffic auch durchlässt.

Gute Admins mit sauberem IP Adresskonmzept setzen üblicherweise die Default Gateway IPs auf die höchste oder niedrigste Adressen im lokalen IP Netz.
Irgendwie unlogisch denn irgendeiner muss dort vor Ort ja den Peer auf deine Firewall konfigurieren mit den SAs und dem Passwort etc.
Dem musst du lediglich sagen das er außer der .80.0 als 2te Phase 2 noch das 10.55.66.0er Netz eintragen soll und gut iss. Wo ist das Problem?

Noch pfiffiger wäre es das lokale LAN als /25 zu setzen und die 2te "obere" Hälfte als das OpenVPN Client Netz zu verwenden. Dem Administrator am anderen Ende gibst du dann einfach die /24 Maske zu dem Netz und hast dann beide mit einer einzigen SA abgedeckt.
Sollten 126 Hosts im LAN nicht reichen nimmst du zwei aufeinander folgende /24 Netze. In deinem Falle dann die .80.0 und .81.0 und verwendest das .81er als VPN Client Netz.
Dem Admin am anderen Ende gibst du dann als .80.0er Maske die /23 mit und fertig ist der Lack.
So brauchst du pfiffigerweise eben nur einen einzigen Phase 2 SA wenn man ein sinnvolles IP Adresskonzept für den VPN Betrieb gemacht hat! Gewusst wie... 😉

• Hast du denn den Traffic auf dem OpenVPN Interface der Sense überhaupt erlaubt?
• Hast du auf dem OpenVPN Client eine Route in das fremde Netz (192.168.90.0/24) aktiv?

Und wie immer ins solchen Fällen. Erst mal die Firewall durchlässig machen, erst danach einschränken und im Zweifel einfach mit tcpdump/Wireshark sniffern.

Bedenke auch das das Ziel den Traffic auch aus fremden Netzen in seiner Client-Firewall zulassen muss!
Windows bspw. blockt per Default bei den meisten Protokollen Traffic aus fremden Subnetzen.

OK
Ist klar, wir können dir aber leider nicht über die Schulter schauen .
Erst mal schauen ob Traffic überhaupt auf der Sense vom Client ankommt. Dann auch mal am Ziel-Client sniffern ob dort was ankommt. Traceroute & Co. sollte klar sein.
Es geht nicht nur um die Firewall des anderen Routers sondern auch die Firewall des Ziels selbst.

Genau die sind das bei /24er Präfixes. Historisch ist das mitnichten, das hat immer gute Address Design Gründe.
NAT bringt bekanntlich immer erhebliche Nachteile im Networking. Wenn immer möglich sollte man es vermeiden.

Normal, IPSec geht ja über das WAN-Interface raus nur halt "ipsec encapsulated" nachdem die Pakete die POSTROUTING Stage verlassen haben dafür sind ja die Phase2-Policies da, diese greifen immer erst nach dem Postrouting und sagen dem Router welche Pakete er duch den IPSec Prozess jagen soll...