Branch Fortigate use HQ Fortigate as default gateway

Far from being an expert, I' m a newbie here, but why would you change the default route? The way you manage the traffic is by creating FW policies to send the end-users requests into the VPN tunnel and that should deliver them to the HQ. The end-users dgw points at the firewall and it sends the requests via the tunnel to the other end. The only static route might still be required is from the VPN interface to the other side.

I see your problem. A FGT which has it' s default route on the other end of a tunnel cannot establish that tunnel as it won' t know how to connect to it' s ISP. The thing here is that you have to change your clients' default route, not your firewall' s. How-to: Say, the HQ subnet is 192.168.23.0/24, and the HQ' s FGT is 192.168.23.1. You configure your VPN in Interface Mode (what else) such that the remote subnet behind the tunnel is 192.168.23.0/24. The FGTs default route is either statically assigned or by the WAN protocol (PPPoE, DHCP) and points to your ISP' s gateway router. Then the clients: if the FGT is their DHCP server, in the DHCP setup you specify 192.168.23.1 as the default gateway, and let the clients request a lease anew. If your clients use static addressing then you have to insert the default route manually on each client. Now, what happens if the tunnel won' t come up? No problem on a FGT, you would install 2 default routes, one for backup with a slightly higher priority (" cost" ). On a DHCP client, not so easy. You can try to insert a backup default route on each client using " route -p add" but have to check that the metric is higher than that of the DHCP obtained default route. Hope that will do.

I would try adding a second default route on the VPN interface pointing to the HQ, with same distance, lower priority (preferred) as the first default route on branch wan interface and add dead gateway detection on the tunnel interface. For branch FGT set it' s source ip for ntp, dns, fortiguard to the wan ip address. If that didn' t work as is, add a more specific route to the HQ external IP via the wan interface. (One can' t have set a clients default gateway outside their local subnet.)

Excellent job The same distance is required to keep both default routes in the routing table (RPF check for traffic arriving on the branch FGT interface), as described here: http://kb.fortinet.com/kb/viewContent.do?externalId=FD32103 The original intention for changing the source-ip for services of the branch FGT to the WAN ip was to have it using this address. If all works now then there appears to be no need.

What about setting default route to the tunnel and remote IPSec peer host route (/32) via ISP (instead of default route). I think it should work.

I think you can' t redirect users via outside when tunnel fails with two default routes: -when you have different AD, higher AD will not be in routing table until lower AD is active -in case the same AD and different priority, lower priority is always used The issue with both options: tunnel interface is always up regardless of tunnel up/down status, so you always have route via tunnel in routing table. I was thinking about using dead gateway detection to get rid of tunnel route when tunnel is down, but it' s not possible with tunnel interface.

DPD doesn' t help. In case site-to-site VPN route is still in routing table when VPN is down, I' ve just tested it and it' s logical behavior, otherwise you couldn' t bring up the tunnel with traffic.