Some OSPF/FRR Assistance please?!

[TotalGriffLock]

Hi all,

I have a problem with something I am trying to do with OSPFv2 under FRR/OPNsense and would appreciate some assistance from those who know more than I do...

Unfortunately I cannot share my configs due to the nature of the business they are installed in, but I am doing some psuedo configs and diagrams that will hopefully explain what I am trying to do.

Attached is a diagram of one of our sites running multiple OPNsense firewalls.

Some notes:
FW A has its default gateway statically defined. FW B and C learn this default route via OSPF
FWs B & C have multiple private subnets/interfaces (in the diagram these are the clouds at the bottom). They are facing 'dumb' equipment so the interfaces are configured as passive in FRR. In real life there are many more than shown on the diagram. FW B learns the routes through FW A to the networks attached to FW C, and vice versa.
FRR on FW C redistributes static routes as there are some IPSEC tunnels from here where the 3rd party on the other end does not run a routing protocol. FRR redistributes these so that FWs A and B can route to them.
The firewalls have the /30 networks defined as 'Networks' in the OSPFv2 page in OPNsense. Nothing is defined in interfaces.

Everything written above up to now works OK and as intended.

I now have to connect another 3rd party via IPSEC into FW C. This will be a routed/VTI connection. In my testing, if I make this VTI interface part of area 1.1.1.1 (and the 3rd party configures their end to also be area 1.1.1.1) they will receive every little route even though I enter area summarisation as 192.168.0.0/16. There are hundreds of routes this way and the routing table becomes unworkable. If I make this VTI interface a new area, they only get the routes that OSPF in area 1.1.1.1 considers to be external/E2, which are the default route via FW A, and the static routes defined on FW C. None of the 192.168.1.x routes are shared with the new area connecting into FW C.

I do not seem to be able to configure FRR in such a way that it sends a summary route to 192.168.0.0/16 over the new IPSEC connection in to FW C. My gut feeling from my loose understanding of OSPF is that the new connection should be treated as a new area as it is fundamentally separate and the routing information shared that way should be summarised.  But I cannot get FRR to summarise the information it exchanges with that new, separate area.

As the same OSPF process will be sharing summarised route(s) with this new area over the IPSEC/VTI interface, as well as processing internal routes for the pre-existing area, will a route-map or some other prefix-list be needed?

Cheers!