Fortigate VPN Lab - IPSec, VTI, BGP

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

Related Post: 

• Download and Launch Fortigate Virtual Machine in VMWare WorkStation
• Fortigate

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

Assign IP Address to Your tunnel interface. 

Please note if you are using a permanent evaluation license, your interface will be limited to only three, which also counts in your tunnel interface. If you exceeded the 3 limitation, the extra interface such as your tunnel interface, the configured ip address will be lost after a reboot. 

2 Create Security Policies Rules to allow VPN Traffic

Make sure the rules are coverning bidirection.

(Optional) Best Practice:

Create another route with the same Destination, but change the Administrative Distance to 200 and for Interface, select Blackhole. This is a best practice for route-based IPsec VPN tunnels because it ensures traffic for the remote FortiGate's subnet is not sent using the default route in the event that the IPsec tunnel goes down.

3 Enable BGP on Tunnel Interface

Configure Local BGP Options for Fortigate 1:

Local AS number:  65511

Router ID: (BGP ID) 192.168.1.1 (VTI IP)

Neighbor: Remote Peer BGP ID and Remote AS number: 192.168.1.2 65512

Broadcasting Network configuration

4 Test

Check BGP status:

• get router info bgp summary
• get router info bgp neighbors
• get router info bgp network
• get router info routing-table bgp
• get router info bgp neighbors <neighbor IP> received-routes
• get router info bgp neighbors <neighbor IP> routes
• execute router clear bgp all soft in
• diagnose ip router bgp level info
• diag ip router bgp all enable
• diag ip router bgp show
• exec router clear bgp all
• diagnose ip router bgp all disable
• diagnose debug reset

Diag

Diag BGP commands

• diagnose ip router bgp all enable
• diagnose ip router bgp level info
• diagnose debug enable

Diag VPN Tunnel commands

• diag debug enable
• diag packet sniffer
• diag debug app ike
• diag vpn tunnel list
• get vpn ike gateway <firewall name>
• get vpn ipsec tunnel name <tunnel name>

Diag BGP Traffic flow

# diagnose debug reset

# diagnose debug disable

# diagnose debug flow filter clear

# diagnose debug flow trace stop

 

# diagnose debug flow filter port 179

# diagnose debug flow show function-name enable

# diagnose debug flow trace start 454545

# diagnose debug flow show iprope enable

# diagnose debug console timestamp enable

# diagnose debug enable

 

To stop debugging.

 

# diagnose debug disable

# diagnose debug reset

# diagnose debug flow filter clear

# diagnose debug flow trace stop

Packets Capture Commands

• diag sniffer packet <interface> <'filter'> <verbose> <count> a
• <interface> can be an interface name or 'any' for all interfaces.
• <'filter'> is a very powerful filter functionality which will be described in more detail.
• <verbose> means the level of verbosity as described already.
• <count> the number of packets the sniffer reads before stopping. If there is no <count> value (or count=0), the Sniffer runs forever until stopped with <CTRL-C>.
• a – timestamps the packets with the absolute UTC time.
• l - (small letter L) timestamps the packets with LOCAL time on the unit.
• (blank/no letter) – relative to the beginning of the capture.

• diag sniffer packet port2 none 1 3
• diag sniffer packet any none 5 1
• diag sniffer packet wan1 'src 10.109.16.137 and net 172.26.48.0/20' 1 3
• diag sniffer packet wan1 'host 10.109.16.137 and host 172.26.48.0/20' 1 3
• diag sniffer packet wan1 'src 10.109.16.137 and tcp' 1 3
• diag sniffer packet wan1 'host 10.109.16.137 and host 172.26.48.21 and tcp port 80' 1 3
• diag sniffer packet any "host 10.10.10.10" 4 10
• 4 is verbose level 4
• 10 means 10 packets

Videos

 

 

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):



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:

References

•  Check Point Route Based VPN 
• https://yurisk.info/2010/03/26/fortigate-bgp-configure-and-debug/
• https://docs.fortinet.com/document/fortigate/6.2.16/cookbook/426761/site-to-site-vpn-with-overlapping-subnets