I looked at this last night but was worried because all the spokes in the doc are on the same subnet (10.1.0.0/16) which is not the case in my example. Also I have no control over the spoke routers other than to advise the downstream staff to add routing.
Can it be as simple as adding IP pool (with either NAT pool or PAT) on WAN router, and then create a policy that picks up anything from VLANB and route to VLANA?
No. They are all /24s and completely different subnets, just happen to have same 10.1 for the first 16bits.
You have to make the change on the spoke side. Otherwise how can the remote side FGT can know where to route the packet to if the dst IP is in the other side of remote? It wouldn't break anything since it currently doesn't route at all anyway. Nothing to lose.
if phase2 selectors are set to 0.0.0.0/0.0.0.0 then all you need is two policies. One that allows traffic from VPNA to B and one vice versa. Since they are on the same FGt you don't even need to add routes - they're already there.
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Several things here:
For PH2 tunnels, the tunnels will not connect if I have them set to 0.0.0.0/0 for remote and local address on FTG.
So I have 2 x separate tunnels, each with different PSK and local and remote addresses hard coded so to speak.
The tunnels work & I can ping my internal devices.
I created 2 x FW policies, one for each tunnel to reach internal devices (10.3.4.0) eg:
VPNA --> Internal
Internal --> VPNA
VPNB --> Internal
Internal --> VPNB
This works as expected.
Now for routing between VPNA and VPNB
On FTG 10.3.4.0 I created 1 x FW policy
VPNA --> VPNB
VPNB --> VPNA
On the remote routers I created a static route:
10.87.125.0 --> next hop gw
172.16.24.0 --> next hop gw
When I do a tracert from 10.87.125.11 to 172.16.24.100 request always goes out internet & not through the tunnel, no matter what IP I use as my next hop. I tried external IP for each VPN, next hop of the router ie def gw, nothing seems to work.
The two remote routers are not FTG devices.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.