Unable to access Server over VPN behind 2 Fortigate Firewalls; however ping is working

Question

Client -> VPN -> FG1 -> FG2 -> Server

1. Created a VPN tunnel with remote IP 10.20.30.4/32 and local ip 10.20.30.40/32
2. on FG1, NAT/VIP is established with VIP as 10.20.30.40 and server IP as 192.168.2.6

Now, client is able to ping VIP but not able to establish tcp on Port 35390 debug flow logs are:

*id=13 trace_id=1011 func=print_pkt_detail line=4307 msg="vd-root received a packet(proto=6, 10.20.30.4:46663->192.168.2.6:35390) from INTERNET-INTERFACE. flag [S], seq 186011604, ack 0, win 8192" id=13 trace_id=1011 func=init_ip_session_common line=4463 msg="allocate a new session-36c86cf8" id=13 trace_id=1011 func=vf_ip4_route_input line=1605 msg="find a route: flags=00000000 gw-192.168.2.6 via SERVER-INTERFACE" id=13 trace_id=1011 func=__iprope_tree_check line=534 msg="use addr/intf hash, len=3" id=13 trace_id=1011 func=fw_forward_handler line=537 msg="**Denied by forward policy check (policy 0)**"*

However policy is there in FG2; and through this policy only ping is working (checked the same in logs)

Unable to understand where the issue is. Please guide.

Answer 1

1. Don't use (source) NAT with VPN unless there is no other way.
2. Virtual IP is destination NAT - avoid as well
3. set according routes on the far side on each FGT, make sure the nodes use the FGT as gateway (or another gateway knowing the routes) - dynamic routing with OSPF or RIP is recommended
4. add policies on each side allowing the communication you require

Answer 2

Assuming that the debug trace is from FG2 this denotes that the traffic is dropped because the source network (rather: address) 10.20.30.4/32 is not known to FG2. The return route is missing.
Fix:
- either create a static route on FG2 pointing to FG1 for 10.20.30.4/32
or
- point the default route of FG2 to the interface on which FG1 is connected
or
- enable NAT on the outbound policy of FG1 - this will exchange the source address 10.20.30.4 to 10.20.30.xx, namely the address of the outbound interface of FG1.

The last option only fixes a configuration mistake, so the first two ones are preferable as they correct the problem and document the fact that traffic from an external subnet is coming in.