This Lab is to summarize the steps how to configure BGP over IPSec on FortiGate firewalls using Custom VPN Creation Wizard.

Custom VPN creatation wizard is the most common used VPN creating wizard if you are create a tunnel between FortiGate and other verndor’s device. You can easily convert FortiGate or Cisco VPN template created tunnel to custom tunnel from Web Gui.

 

Diagram

Two Fortigate VMs. 
One is from Azure Test Drive. Another is from my own subscription.

Test Drive is not available anymore after May 2024 based on my observation. You will need to spin up another Fortigate VM in your own subscription. You can refer to this post to get a free Fortigate VM. 

Start Azure Fortigate Test Drive Environment 

1 Go to https://azuremarketplace.microsoft.com/en-us/marketplace/apps/fortinet.fortinet-fortigate?ocid=FortiGate_202105_landingpage_en-us  or https://www.fortigate-azure.com/. Choose a Test Drive, sign in and agree to the terms of use.

Note: Test Drive is not available anymore. [May 2024]

2 After system complete the provisioning, you will get a page to tell you Your Test Drive is ready. The testdrive lab will last for three hours. 

Once you complete the form, your Test Drive will start deploying. In addition to the webpage information, in a few minutes you will also get an email notification that the environment is ready. Just follow instructions in the webpage or in the email, and you will be able to access a fully provisioned and ready to use environment.


3 After three hours if you have not completed the test drive use case, you still have a chance to repeat test drive to try it again. 

4 When the Test Drive is ready click on the FortiGate link to open the GUI.

Log in to Web GUI Console using following credential:
  • username: ftnt-testdrive 
  • password: Fortinet@123

Create IPSec VPN Using Custom VPN Wizard

1 VPN Creation Wizard – Choose custom

Pre-shared Key & IKE v1 Main Mode & Phase 1 Proposal

jyfgt # show vpn ipsec phase1-interface 
config vpn ipsec phase1-interface
    edit “test-2-netsec”
        set interface “port1”
        set peertype any
        set net-device disable
        set proposal des-md5
        set remote-gw 4.6.22.13
        set psksecret ENC 4bpliSF9qNeW5gMEjnoDnIg4wba9fN2MTGI+irzrq1QXXIOmsfuQvw==
    next
end

Phase 2 Proposal

jyfgt # show vpn ipsec phase2-interface
config vpn ipsec phase2-interface
    edit “test-2-netsec”
        set phase1name “test-2-netsec”
        set proposal des-md5
    next
end

2 Complete VPN Configuration on both sides. 

3 Create bi-directional Firewall Policy rules

On NetSec site, I have to enable NAT on the rule which allows tunnel traffic to lan as show below. That is because ip forwarding was not enabled on the LAN interface.

Enable IP Forwarding on LAN interface of FGT:

4 Create static route

Based on FortiNet Doc: https://docs.fortinet.com/document/fortigate-public-cloud/6.2.0/azure-administration-guide/609353/network-interfaces-and-routes

You might also need to a route for 168.63.129.16/32 for some Azure various services. It is an optional route in most of situations. 

5 Test from Test site to Netsec site

Testing from Windows machine 10.1.1.5. 
Trying to ping from Test site to NetSec site, I have to enable NAT to make ping works to remote site. 

C:\Users\netsec>tracert 10.254.0.9
Tracing route to 10.254.0.9 over a maximum of 30 hops
1 1 ms <1 ms <1 ms 10.1.1.4
2 * * * Request timed out.
3 8 ms 7 ms 7 ms 10.254.0.9


PS C:\Users\netsec> Test-NetConnection -ComputerName 10.254.0.9 -Port 22
ComputerName : 10.254.0.9
RemoteAddress : 10.254.0.9
RemotePort : 22
InterfaceAlias : Ethernet
SourceAddress : 10.1.1.5
TcpTestSucceeded : True

Traffic log can be found from page Log & Report – Forward Traffic

Enable BGP

 BGP Diagram

Site 1: BGP AS#: 65515 and BGP Interface IP:  192.168.168.2/32
Site 2: BGP AS#: 65512 and BGP Interface IP : 192.168.168.1/32

Add Interface IP address to the tunnel interfaces

192.168.168.1/32
192.168.168.2/32

Remote IP/Network, you will have to put in 192.168.168.2/32 as show below:

Show system interface
    edit “test-2-netsec”
        set vdom “root”
        set ip 192.168.168.1 255.255.255.255
        set type tunnel
        set remote-ip 192.168.168.2 255.255.255.255
        set snmp-index 5
        set interface “port1”
    next

Create BGP Neighbours

Enable ebgp-enforce-multihop from command line (before 7.0 verison) or from Web GUI (after 7.0 version), depending on the FortiOS version. 
jyfgt # show router bgp
config router bgp
    set as 65512
    set router-id 192.168.168.1
    config neighbor
        edit “192.168.168.2”
            set ebgp-enforce-multihop enable
            set remote-as 65515
        next
    end
    config network
        edit 1
            set prefix 10.1.1.0 255.255.255.0
        next
    end

No Static Route will be needed for remote network since BGP will learn this route and put it into routing table:

BGP Routes from Dashboard -> Network -> Widget:  Routing

Route Filtering and As-path for failover

The following configuration of Route-map and prefix-list is from Site 1: 
Basically, from site, BGP only sends out two routes: 10.254.0.0/16 and 10.111.1.0/24. 
Also, this route-map “OUT-TO-MPN” only configured on backup neighbor, not on primary bgp neighbor. The reason is the backup neighbor will receive those two bgp route with an extra path 65515. So backup bgp router will not put those received routes in active because main bgp router has same but shorter as-path routes which will make them active.
In an event of main bgp router down, those two routes received from backup bgp router will become active since those two shorter as-path routes are gone. 

NETSEC-FGT # show router route-map 
config router route-map
    edit "OUT-TO-MPN"
        config rule
            edit 1
                set match-ip-address "OUT-TO-MPN"
                set set-aspath "65515"
                unset set-ip-prefsrc
            next
        end
    next
end

NETSEC-FGT # show router prefix-list 
config router prefix-list
    edit "OUT-TO-MPN"
        set comments "PRE-PEND"
        config rule
            edit 1
                set prefix 10.254.0.0 255.255.0.0
                unset ge
                unset le
            next
            edit 2
                set prefix 10.111.1.0 255.255.255.0
                unset ge
                unset le
            next
        end
    next
end


Configure route map out OUT-TO-MPN

Final BGP configuration on Site 1’s Fortigate firewall

FGT # show router bgp
config router bgp
    set as 65515
    set router-id 10.254.0.6
    set holdtime-timer 30
    config neighbor
        edit “192.168.168.1”
            set ebgp-enforce-multihop enable
            set remote-as 65512
            set route-map-out “OUT-TO-MPN”
        next
    end
    config network
        edit 1
            set prefix 10.254.0.0 255.255.0.0
        next
        edit 2
            set prefix 10.111.1.0 255.255.255.0
        next
    end

Troubleshooting & Diag

Tunnel Interface will not be able to ping each other

jyfgt # execute ping 192.168.168.1
PING 192.168.168.1 (192.168.168.1): 56 data bytes
64 bytes from 192.168.168.1: icmp_seq=0 ttl=255 time=0.0 ms
64 bytes from 192.168.168.1: icmp_seq=1 ttl=255 time=0.0 ms
^C
— 192.168.168.1 ping statistics —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
jyfgt # execute ping 192.168.168.2
PING 192.168.168.2 (192.168.168.2): 56 data bytes
— 192.168.168.2 ping statistics —
5 packets transmitted, 0 packets received, 100% packet loss
jyfgt # 

jyfgt # get router info bgp summary 

VRF 0 BGP router identifier 192.168.168.1, local AS number 65512
BGP table version is 1
1 BGP AS-PATH entries
0 BGP community entries
Neighbor      V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.168.2 4      65515       0       0        0    0    0    never Idle       
Total number of neighbors 1

jyfgt # get router info bgp neighbors 

VRF 0 neighbor table:
BGP neighbor is 192.168.168.2, remote AS 65515, local AS 65512, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Active
  Last read 00:02:23, hold time is 180, keepalive interval is 60 seconds
  Configured hold time is 180, keepalive interval is 60 seconds
  Received 19 messages, 0 notifications, 0 in queue
  Sent 21 messages, 1 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
 For address family: IPv4 Unicast
  BGP table version 2, neighbor version 0
  Index 1, Offset 0, Mask 0x2
  Community attribute sent to this neighbor (both)
  0 accepted prefixes, 0 prefixes in rib
  0 announced prefixes
 For address family: IPv6 Unicast
  BGP table version 1, neighbor version 0
  Index 1, Offset 0, Mask 0x2
  Community attribute sent to this neighbor (both)
  0 accepted prefixes, 0 prefixes in rib
  0 announced prefixes
 Connections established 1; dropped 1
  External BGP neighbor may be up to 255 hops away.
Egress interface: 0
Next connect timer due in 55 seconds
Last Reset: 00:01:53, due to BGP Notification sent
Notification Error Message: (Hold Timer Expired/Unspecified Error Subcode)

Understand IPSec Tunnel Interface

An IPsec tunnel interface is a Layer 3 logical interface. It supports dynamic routing. All packets including multicast packets that are routed to an IPsec tunnel interface are IPsec protected.

The IPsec tunnel interface has the following advantages:

  • Simplified configuration—The IPsec tunnel interface is easier to configure compared to using access control lists (ACLs) to identify protected packets. The IPsec tunnel interface improves network scalability and reduces maintenance costs.

  • Reduced payload—The IPsec tunnel interface requires less protocol costs and uses less bandwidth than IPsec over GRE and IPsec over L2TP, which require a GRE header or L2TP header to be added to each packet.

  • Flexible service application—You can apply a service such as NAT or QoS to packets before or after they are encrypted by IPsec. To handle packets prior to IPsec encryption, apply the service to the IPsec tunnel interface. To handle IPsec encrypted packets, apply the service to the physical outbound interface.

Operation of the IPsec tunnel interface

IPsec encapsulation and de-encapsulation occur on IPsec tunnel interfaces. Figure 53 shows how a clear text packet arriving at a router is forwarded to the IPsec tunnel interface, encapsulated, and forwarded out.

Figure 53: Encapsulation process of a clear text packet

 

  1. The router forwards a clear text packet received on the inbound interface to the forwarding module.

  2. The forwarding module looks up the routing table and, if the packet must be IPsec protected, forwards the packet to the IPsec tunnel interface. The original IP packet is encapsulated into to form a new IP packet. The source and destination of the new packet are respectively the source and destination address of the tunnel interface.

  3. The IPsec tunnel interface encapsulates the packet, and then sends the packet to the forwarding module.

  4. The forwarding module looks up the routing table again and forwards the IPsec-encrypted packet out of the physical outbound interface that is associated with the tunnel interface.

Figure 54 shows how an IPsec packet is de-encapsulated on an IPsec tunnel interface.

Figure 54: De-encapsulation process of an IPsec packet

  1. The router forwards an IPsec packet received on the inbound interface to the forwarding module.

  2. Identifying that the destination address of the packet is the tunnel interface and the protocol is AH or ESP, the forwarding module forwards the packet to the IPsec tunnel interface for de-encapsulation.

  3. The IPsec tunnel interface de-encapsulates the packet, and then delivers the resulting clear text packet back to the forwarding module.

  4. The forwarding module looks up the routing table, and then forwards the clear text packet out of the physical outbound interface associated with the tunnel interface.

Note: https://techhub.hpe.com/eginfolib/networking/docs/routers/msrv5/cg/5200-2323_security-cg/content/459369289.htm#:~:text=An%20IPsec%20tunnel%20interface%20is,tunnel%20interface%20are%20IPsec%20protected

References

By netsec

Leave a Reply