Fortigate VPN Lab - IPSec, VTI, BGP - 91Sec

Latest

Learning, Sharing, Creating

Sunday, March 10, 2024

Fortigate VPN Lab - IPSec, VTI, BGP

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



Related Post: 

Diagram



 

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:
  1. 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.
  2. 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:
  1. 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.
  2. 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
  3. 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. 
  4. 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):
Policy-based IPSec Diagram


VTI is the recommended solution for creating a VPN mesh (partial or full) or when overlapping subnets are used. Such a topology is illustrated below:
VTI IPSec diagram



Create A Route Based VPN between FGs Using Wizard


From CLI, using Show System Interface ? to get DHCP IP on Port 1. Then use browser to open Web UI to log in with admin account. Password is null. 

1. Create a basic FG vpn to FG vpn


On FG1 , create tunnel FG1-FG2


Remote WAN IP on FG2



All changes on the firewall:


Policy :



Static Routes:



A New Tunnel Interface on WAN Port:




Objects and Object Groups:


VPN:







Manul Create A Route Based VPN with BGP



1 Create VPN using Custom Wizard


2 Create Security Policies Rules to allow VPN Traffic


3 Enable BGP on Tunnel Interface


4 Test



Videos

 








No comments:

Post a Comment

Banner

BANNER 728X90