It isn’t just static routes, it is routing combined with NAT behavior. the UDMPro only wants traffic to go in the LAN->Wan direction… with access to the LAN only provided by port forwarding or their onboard VPN termination.
Since you are willing to forgo the UDMPro NAT routing engine, we will continue in that direction. We are going to move the NAT/routing decisions from the UDMPro to the BR1.
So, create a LAN VLAN on your UDMPro for 172.16.4.0/24 no DHCP, assign the UDMPro 172.16.4.2, and connect the port to the BR1 in place of the WAN (remove all 172.16.4.? configurations from the WAN interface) . Switch the BR1 to regular routing mode, not Passthrough
Next, disable your UDMPro WANs and we want to put in a default route to 172.16.4.1 so that all outbound traffic goes via the VLAN side to the BR1… the UDMPro will not accept a static default route on the lan side… but you can add 2 routes that add up to the complete default as documented here:
https://community.ui.com/questions/UDM-Pro-add-default-route-on-LAN-interface/dff7feff-9a04-4f90-a65a-0254076931d5
You will also need to add static routes via 172.16.4.2 on the BR1 to return the 10.0.40.0/24 and 10.0.4.0/24 traffic back to the UDMpro.
Basic connectivity should now be restored. and we are now exposing direct access to the 10.0.?.? networks to the BR1.
To complete the fusionhub access you need to have a LAN network (169.254.131.0/24?) configured on the Fusion Hub… no NAT translation on either side of the PEPlink… and you should be able to ping and manage the FusionHub via its LAN IP.
The Peplink status page should show that BR1 has learned the 169.254.131.0/24 via the pepvpn and that the FusionHub status has learned 172.16.4.0/24 10.0.4.0/24 and 10.0.40.0/24.
All that is left, is adding the static routes to your VPN client when it connects, or choosing send “all traffic” via the VPN… as from this discussion"
https://forum.peplink.com/t/understanding-fusionhub-solo-remote-user-access-as-vpn/6121e3f86b1bec069000443c/