Fortigate Site to Site VPN Lab

In this post I will cover how to setup a basic site to site VPN using Fortigate firewalls.

Here is the topology we are working with in EVE-NG:

So the expected outcome is that Site 1 hosts can ping Site 2 hosts.

**Also the EVE-NG image for this firewall is very small and the entire process with FortiGate is extremely lightweight and intuitive. Very impressed with these firewalls overall.

Fortinet have made this very, very simple via a wizard, but there was one gotcha that I lost time on that I would like to share. (More to follow)

Follow IPsec wizard

Very very easy and won’t go into too much detail. Next, next finish style, but make sure your local and remote subnets are correct for each side of the VPN. 😉

This will do several things and points worth mentioning below:

2. Firewall Policy

It will create firewall policy for traffic to source from either direction.

3. Routing

The wizard will also add a static route as follows:

This is essentially routing traffic to the specified destinations to 192.168.68.128, which is Site 2 next hop address / VPN interface.

4. Verify

Very easy so far eh? Be sure to check your tunnel is up and Phase 1 and Phase 2 are happy:

Now for the gotcha… in my example I could never get Phase 2 to work. Eventually I managed to sort this and I missed something fairly basic! (Mismatch with remote/local subnets… that old chestnut!!) The Fortigate documentation is very good and gave me some good pointers on the CLI to troubleshoot VPNs. (Google it and you will see)

For example this command:

Site2FW # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=vpn ver=1 serial=2 192.168.68.128:0->192.168.68.127:0 tun_id=1
bound_if=3 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/512 opt0

proxyid_num=1 child_num=0 refcnt=4 ilast=3 olast=43 ad=/0
stat: rxp=26 txp=25 rxb=3520 txb=2280
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=1
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=vpn proto=0 sa=1 ref=4 serial=1
  src: 0:192.168.2.0/255.255.255.252:0 0:10.10.2.0/255.255.255.0:0
  dst: 0:10.10.1.0/255.255.255.0:0 0:192.168.1.0/255.255.255.252:0
  SA:  ref=3 options=30202 type=00 soft=0 mtu=1446 expire=42545/0B8
       seqno=1a esn=0 replaywin_lastseq=0000001b itn=0 qat=0 hash_1
  life: type=01 bytes=0/0 timeout=42927/43200
  dec: spi=ae328ba5 esp=des key=8 ff2cc9ff1a7e6191
       ah=md5 key=16 2d911cf0ea33578bfc2b8640fcf106ac
  enc: spi=eccae5c4 esp=des key=8 6d0db2ab35d4d459
       ah=md5 key=16 313ad6cd2dc73e717ed9c7e90ea12003
  dec:pkts/bytes=26/2168, enc:pkts/bytes=25/3600

Standard stuff like can we see the proxyID / interesting traffic / Security Associations etc

Now my tunnel was up and healthy with Phase 1 and Phase 2, but still no traffic would pass between Site 1 hosts and Site 2. However… The Cisco subnets / SVIs in the tunnel were working fine.. so the issue was specific to the Linux hosts in the 2 x 10.10.x.0/24 networks. (Clue that the Site networks are NOT directly connected and the networks to the Cisco switches ARE directly connected… Clue clue clue!!)

After more reading I threw a load of debugs on:

diagnose debug disable
diagnose debug reset
diagnose debug flow filter 1
diagnose debug flow filter addr 10.10.2.1
diagnose debug flow show function-name enable
diagnose debug flow show console enable
diagnose debug flow trace start 2000
diagnose debug enable

This will debug ICMP to 10.10.2.1 which is the Site 2 Linux host.

This is what I got back which told me the issue:

So as you can see we have a reverse path fail and the firewall is dropping the traffic. Simply put the firewall has no route back to the host sourcing the traffic in Site 1. 😦 So how do we fix this? Well we just need to add a route entry to each firewall:

Site 1

Site 2

Sure enough that fixed the issue! Now each hosts can ping each other with no issue.

Also bonus stuff, let’s verify the route on the firewall to the target network:

Site2FW # get router info routing-table details 10.10.1.0

Routing table for VRF=0
Routing entry for 10.10.1.0/24
  Known via "static", distance 254, metric 0
    directly connected, Null

Routing entry for 10.10.1.0/24
  Known via "static", distance 10, metric 0, best
  * 192.168.68.127, via vpn

Site 2 route to Site 1 for example with the ‘get router info routing-table details’ command. We can see this prefix is contactable via the vpn.

The last verification I did to confirm was a pcap on the outside of the firewall and sure enough we I generated the pings I could see ESP packets flow between the 2 firewalls outside interfaces. Success and all very straightforward, just don’t forget your routing basics!

CCIEME

my never ending journey to ccie

Fortigate Site to Site VPN Lab

Share this:

Related