Fortigate VPN Lab – IPSec, VTI, BGP

siwei • 2024-03-10 13:57 • 好物分享

This post is to summarize the steps how to create VPN tunnels using Fortigate.

Policy Based VPN vs Route Based VPN

By default they are route based VPNs on FGTs, you should notice in the feature visibility that policy based VPNs are disabled by default. You can use all 0s in the selectors and let your routing handle what gets passed to the routed VPN tunnel interface and ultimately encrypted (most scalable option).

Encryption domains (sometime, in route bassed vpn , it can be set to 0.0.0.0/0) have a variety of names, encryption domains, IP selectors, crypto maps, Proxy IDs, etc. What they do is define which IP addresses are allowed to pass down the VPN tunnel. The main difference in the FortiGate between route based VPNs and policy based VPNs is that policy based VPNs generally use the phase 2 selectors to determine whether traffic should be forwarded down the VPN tunnel. Route based VPNs use routing to determine whether to forward the traffic into the VPN tunnel. A simple way to think of them when working with route based VPNs is that they are a final ACL for whether traffic can use the VPN. So even if you forward a packet into the VPN, if it doesn't meet the selectors, it won't forward.

As a note, you can use a route based VPN on one end, and a policy based VPN on the other end. This often happens with Cisco ASAs (policy based) to FortiGates (commonly deployed as route based). The important part is that as long as the IP selectors match, everything should work fine. ASAs crypto maps are normally narrow, so the FortiGate normally has some form of IP selector defined.

General advice on VPNs: (from https://www.reddit.com/r/fortinet/comments/13i7jdm/eli5_routebased_vs_policybased/)

Use route based VPNs. they are the default in FortiGates.
Leave the proxy IDs as 0.0.0.0/0 (unless you want to be extra super secure), because the firewall policies should control which traffic is allowed to flow.

Policy-based IPSec is the IPSec variety that most customer's are familiar with. If you haven't changed the mode to VTI, the device is building a policy-based tunnel. Policy-based IPSec has the following characteristics:

A policy is created to define "interesting traffic". Interesting traffic will be routed across the IPSec tunnel.
1. This policy should involve a Local Network (the source network) and a Remote Network (the destination network). It may also include source and destination TCP/IP ports, though this is less common.
A pseudo-interface is created for the IPSec tunnel. This interface cannot be directly interacted with - i.e. the interface cannot be referenced in the zone firewall nor in route tables.

VTI (route-based) IPSec is supported by most security appliance providers and is the default option for some. VTI does not rely on a tunnel policy to define interesting traffic. Rather, a tunnel interface is created that behaves similarly to any other non-tunnel interface. Below is a fuller description of VTI's characteristics:

IP Addressing - the tunnel interface will typically have an IP address. E.g. the tunnel interface may have an IP of 10.0.0.1/30. The peer's tunnel interface would then be 10.0.0.2/30. Users can test IP connectivity across the tunnel by pinging 10.0.0.2 from 10.0.0.1. To create an unnumbered interface, set the interface IP to 0.0.0.0.
Security - tunnel can be referenced by the zone firewall. The tunnel interface can belong to a separate security zone and policies can be defined to control traffic flows across the tunnel interface
Routing - static routes can be defined to use the tunnel interface. Dynamic routing protocols can use the tunnel interface. E.g. OSPF neighborships can be formed across the tunnel.
Diagnostics - packet captures can be performed on the tunnel interface. This can be valuable when troubleshooting traffic flows across the tunnel.

Note: https://customer.cradlepoint.com/s/article/What-is-the-difference-between-VTI-and-policy-based-IPSec

Policy-based or VTI (route-based): Which to use?
For connecting multiple sites with unique subnets in a simple hub-and-spoke VPN topology, policy-based IPSec should be sufficient. Such a topology is illustrated below (note that there is no subnet overlap in the policy-based topology):