Hi,
What are the use case scenario for policy based and route based ?
if local site is policy based and remote side is route based , does it work
Thanks
Fortinet themselves recommend that no new configurations be made with policy based IPsec VPN. This according to their training is a legacy configuration
Yes, one side can be policy based and the other route based. Policy based is the old way of doing things, route based is more flexible and allows things like running dynamic routing protocols over the tunnel.
If you have overlapping subnets, policy based tunnels will get the traffic to where it needs to go.
E.g. you are hosting servers for a bunch of customers, and all customers have decided to use 192.168.1.0/24 as their LAN. Each server is only used by one customer. Policy VPN gets every customer LAN to the right server and back.
You can achieve the same with policy routing (ouch), vrf (limit has been raised to 252, yay!) or VDOMs (expensive, limited to 250).
Not that I recommend overlapping subnets. Don’t do that if you can at all avoid it.
route based is the old way??? cisco just started supporting route based on the asa’s a couple of years ago, I cant imagine fortinet recommending policy based, is so much more difficult to maintain and their whole ADVPN solution is based on route based vpns. No a vpn cant be route based on one end and policy based on another. Encryption domains have to match, in a route based vpn, encryption domain is 0.0.0.0, and routing determines what gets encyrpted and there is only one ipsec sa. In policy based, an ipsec sa is formed for each phase2 set of encryption domains and each set has to match on each end. It is also true that route based is more flexible as it allows routing protocols as well. I would only do policy based if i was forced to by an old asa.
I think there’s an use case for policy based IPsec and that’s when the firewall is operating in transparent mode, but that’s about it.
route based is the old way???
Literally nobody said that
No a vpn cant be route based on one end and policy based on another.
Yes, it can
Encryption domains have to match, in a route based vpn, encryption domain is 0.0.0.0
You can set traffic selectors to whatever you want on a route-based VPN on most firewalls, it doesn’t have to be 0.0.0.0/0, it just has to match the other end. Traffic is still forwarded over the VPN based on routing rather than policy, traffic will just get dropped if it doesn’t match the configured selectors. ASAs are the only ones I’ve encountered that don’t allow configuring traffic selectors on route based VPNs.
The encryption domain doesn’t really matter, if traffic is encrypted and sent over the tunnel based on routing decisions, it’s a route-based VPN.
Luckily (for TAC), transparent mode is not used frequently, and IPsec in transparent mode is even rarer. (I’d be sweating buckets if I had to troubleshoot TP mode IPsec)
You can set traffic selectors to whatever you want on a route-based VPN on most firewalls, it doesn’t have to be 0.0.0.0/0, it just has to match the other end.
I can one-up this: With IKEv2’s selector narrowing, you don’t even need an exact match. Some overlap is enough to get the tunnel up. 
Yes, and this makes it a lot easier to create VPNs with firewalls that require a separate SPI for each combination of subnets that you want to talk to each other (ASAs and Watchguards). Instead of creating a separate Phase 2 tunnel for every subnet pair, make it an IKEv2 tunnel and selector narrowing will take care of it.
When I first started my current job, there was an IKEv1 VPN that had 64 phase 2 tunnel that my predecessor built out manually. Presumably he didn’t understand subnetting well enough to summarize anything.