How to access client behind site connected to OVPN/OPNSense from other client?

[errellion]

Hello forum,

I'm in the process of migrating from my NetBSD router with PF and OpenVPN server to OPNSense. Everything went smooth with some tweaks here and there. I have sucessfully imported my certficates and recreated config in OpenVPN Instance and also ccd/ settings, and basically all things are working but one thing. Here is a setup and I will explain my problem after that:

OpnSense address: 10.1.78.1
OpenVPN address: 10.66.77.1
Site A network: 10.1.78.0/24
Site B network: 10.2.78.0/24
Site C network: 10.3.78.0/24
VPN network 10.66.77.0/24

There are clients in network A, B, C.
All traffic is possible between clients in: A-B, A-C, B-A, B-C, C-A, C-B.

Only thing that isn't working (and was working in original config) is that when I connect with my phone. Phone is getting address ex 10.66.77.5 and I can easly access anything in network A, ex 10.1.78.5.

However accessing anything in Site B or C is impossible.

I tried looking in logs in GUI - no traffic logged from 10.66.77.5 when reaching anything from B or C.
Tried tcpdump on OPNsense itself on ovpns1 interface no traffc logged from 10.66.77 to ex. 10.3.78.6

Tried adding NAT on LAN and OpenVPN network.
For OenVPN interface there is a rule allow any:any

On router/client on lets say site C there is proper route for 10.66.77.0/24 network pushed from server (as well as routes to site A and B which traffic works in any direction)

u-SYS-fw01$ route show
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            10.208.166.1       UGS         -        -      -  xennet0
10.1.78/24         10.66.77.1         UGS         -        -      -  tun0
10.2.78/24         10.66.77.1         UGS         -        -      -  tun0
10.3.78/24         link#2             UC          -        -      -  xennet1
10.3.78.254        link#2             UHl         -        -      -  lo0
10.66.77/24        10.66.77.1         UGS         -        -      -  tun0
10.66.77.1         10.66.77.4         UH          -        -      -  tun0
10.66.77.4         tun0               UHl         -        -      -  lo0
10.208.166/24      link#1             UC          -        -      -  xennet0
10.208.166.10      link#1             UHl         -        -      -  lo0
127/8              localhost          UGRS        -        -  33624  lo0
localhost          lo0                UHl         -        -  33624  lo0

I'm out of ideas right now :)

[errellion]

Answering my own post from June 2024, because I finally cracked this puzzle during my second migration attempt!
What was missing turned out to be hilariously simple: the push_route directive in OpenVPN configuration. I initially dismissed this option, convinced that the proper "enterprise" way was to handle this through firewall rules and NAT magic. Oh, how wrong I was!
After diving into the XML backup (because who doesn't love reading XML for fun?), I discovered that the push_route directive only contained the network where OPNsense was acting as the router. The solution? I added the other two sites' networks, and to my absolute amazement, they appeared in the GUI after importing as... wait for it... "Local Networks"!
Yes, the same "Local Networks" option that I was absolutely certain only referred to networks directly connected to OpenVPN/OPNsense. Talk about a misleading name! For those technically inclined, this setting actually generates the appropriate push_route directives in the OpenVPN configuration, enabling proper routing between VPN clients and all remote networks.
The moral of the story? Sometimes the solution isn't in adding more complex firewall rules or NAT configurations - it's in understanding that "Local Networks" isn't so local after all. Who would've thought?
For reference, the configuration that fixed everything was simply adding networks 10.2.78.0/24 and 10.3.78.0/24 to the OpenVPN instance's "Local Networks" field. This automatically generated the necessary push_route directives, and suddenly all the VPN clients could reach every network as if by magic (but actually by proper routing).
Remember folks: when in doubt, check your push_routes, and don't let naming conventions fool you!