Logo Azure

AZURE : Connexion d’un Fortigate On-premise à Azure

Azure

L’objectif de ce tutoriel est de connecter votre Fortigate On-Premise à Azure par le bias d’un double VPN IPSEC actif/passif. La bascule du routage se fera automatiquement vers le second tunnel par le biais du BGP.

1 – Présentation

A – Pre-requis

Création d’un ressource groupe qui regroupera un Virtual Network et deux Subnet

  • RG = RG-NETWORK-LAB-001
    • VNET = RG-NETWORK-LAB-001 / 172.10.0.0/16
      • SNET = SNET-NETWORK-LAB-001 / 172.10.100.0/24
      • SNET = GatewaySubnet : 172.10.255.0/28

Il faudra disposer d’une machine virtuel dans le subnet SNET-NETWORK-LAB-001 à des fin de tests.

Coté réseau On-Premise il faudra disposer d’un Firewall qui gère le BGP et l’IPsec. Pour se tutoriel je vais me servir d’un Forti60E.

Mon firewall dispose des interfaces suivantes :

  • IP publique FW = 78.236.xxx.xxx
  • Local network = 192.168.130.254/24
  • Loopback interface = 169.0.0.1

2 – Configuration sur Azure

A – Création du virtual network

Nous allons commencer par créer un virtual network qui va nous fournir un espace d’adressage que nous allons pouvoir découper en sous-réseaux (subnet).

Dans les services sélectionner « Virtual networks » puis « Add »

On donne un nom à notre virtual network VNET-LAB-FRCENTRAL-001 et on l’associe à notre ressource groupe RG-NETWORK-LAB-001

Création virtual network

Nous définissons ensuite un espace d’adressage ici j’ai choisi 172.10.0.0/16 et nous créons notre sous réseau SNET-NETWORK-LAB-001 / 172.10.100.0/24.

C’est dans ce sous réseau qu’il faudra déployer votre VM.

Création d'un virtual network

Une fois que c’est fait il ne nous reste plus qu’à valider.

Création d'un virtual network

B – Création du GatewaySubnet

Nous allons avoir besoin d’une GatewaySubnet pour pouvoir ensuite créer notre Virtual Network Gateway.

Il s’agit d’un sous-réseau spécifique qui contient des IPs qui servirons à notre Virtual Network Gateway. Ici elles contiendrons les IPs de peering BGP

Dans notre VNET nous allons rajouter un SNET de type GatewaySubnet pour se faire il suffit de cliquez sur « Gateway Subnet »

Création GatewaySubnet

Nous définissons un nouveau sous réseau. Azure recommande la création d’un /28 ou /27. Ici nous allons utiliser 172.10.255.0/28

Création GatewaySubnet

Il ne reste plus qu’à valider. Une fois créer voici ce que cela donne :

Création GatewaySubnet

C – Création du Virtual Network Gateway

Nous allons commencer par créer une Virtual Network Gateway. Cela va nous permettre de configurer notre VPN IPSEC site-to-site.

On sélectionne le service Virtual network gateways et on clique sur Add :

Nous allons configurer les paramètres suivants :

  • Name : VGW-FRCENTRAL-NETWORK-LAB-001
  • VIRTUAL-NETWORK : VNET-LAB-FRCENTRAL-001
  • Gateway Subnet Range : 172.10.255.0/28
  • Public IP address name : PIP-001-VGW-FRCENTRAL-NETWORK-LAB-001
  • Enable active-active mode : Enable
  • Second public IP address : PIP-002-VGW-FRCENTRAL-NETWORK-LAB-001
  • Configure BGP ASN : Enable
  • Autonomous system number (ASN) : 65515
Création virtual network gateway

Il ne nous reste plus qu’à valider :

Création virtual network gateway

La création peut prendre jusque 45 minutes.

D – Local network gateways

Nous allons maintenant passer à la création de la local network gateways qui va nous permettre de fournir les paramètres de notre Fortigate On-premise à Azure.

Pour se faire sélectionner le service Local Network Gateways

Nous allons appliquer les paramètres suivants :

  • IP Publique FW = 78.236.18.xxx
  • Local NETWORK = 192.168.130.0/24
  • Loopback interface = 169.0.0.1
Création local network gateway

E – Création de la connexion.

La connexion va nous permettre d’associer à notre Virtual Network Gateway à notreLocal Network Gateway et de définir le type de connexion que nous souhaitons (Site-to-Site / VNET-to-VNET / Express Route).

Nous allons configurer les paramètres suivants :

  • Name = CN-VGW-FRCENTRAL-NETWORK-LAB-001
  • Connection type = Site-to-Site
  • Virtual network gateway = VGW-FRCENTRAL-NETWORK-
  • Local network gateway = IGW-001-FRCENTRAL-NETWORK
  • Shared key = UH5pdQRUZ7j03VO3cf3F
  • IKE Protocol = IKEv2

Ajout d'un connexion

Voici notre connexion nouvellement créée :

Ajout d'une connexion

Nous sélectionnons notre connexion et nous activons le BGP dans la partie configuration :

Activation du bgp

Dans notre connexion nous allons télécharger le fichier de configuration du tunnel pour notre Fortigate :

Téléchargement du fichier de configuration

Dans votre ressource groupe vous devriez trouver les objets suivants :

Liste des objets présents dans le ressource groupe

3 – Configuration Fortigate :

A – Création de la loopback

Sur notre Fortigate nous allons commencer par créer notre loopback. Nous montrons les peerings BGP avec Azure dessus.

En Cli : 

config system interface
    edit "LOOP_169.0.0.1"
        set vdom "root"
        set ip 169.0.0.1 255.255.255.255
        set type loopback
        set role lan
        set snmp-index 15
    next

B – Création des ipsec

Nous créons les deux tunnels IPSEC vers Azure :

Tunnel IPSEC-AZURE-A :

config vpn ipsec phase1-interface
    edit "IPSEC-AZURE"
        set interface "wan1"
        set ike-version 2
        set keylife 3600
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set localid "78.236.18.210"
        set dpd on-idle
        set dhgrp 2
        set nattraversal disable
        set remote-gw 52.143.181.95
        set psksecret ENC vPpBObGtfjBBEveSefBtwteTQ6eFZpvZqwqSUW9q/4sMlF+SkhwCP3d9wV+TQWSgdG/ZlVznh9wXJEIzI427Pwlf6hfzc5NcLQMSOAP9XqAbG3eVZ6tg6Cth1FfRR3do7veFJQgwVsfPo+whPCSoizGPZakPI/x9koJCFpLHqb+ok5tEZv+VO4ES/TlyRs+hGhxJnQ==
    next
end

config vpn ipsec phase2-interface
    edit "IPSEC-AZURE"
        set phase1name "IPSEC-AZURE"
        set proposal aes256-sha256
        set pfs disable
        set replay disable
        set keylifeseconds 3600
    next
end

Tunnel IPSEC-AZURE-B :

config vpn ipsec phase1-interface    
edit "IPSEC-AZURE-B"
        set interface "wan1"
        set ike-version 2
        set keylife 28800
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set dpd on-idle
        set dhgrp 2
        set nattraversal disable
        set remote-gw 52.143.181.104
        set psksecret ENC /rcvwb7dmlBqiVoi/fGh7GqgxnvsYF0SRXcmZa/gdJOlqdxbvtQTHiP+ip0lfD1qSXn35hyjS5hjxdkfS+Dgq/2r5XPfW7mglq/Kb/O7z/wgRB1tUV8slGdM8djaCPZ0R/gCWsfRLqhZ2yfXLSs8b2eoLuWCqdkQI2cShBB4Xu2bAnM9T/jUZhwvd6l1ahAICoXtew==
    next
end

config vpn ipsec phase2-interface
    edit "IPSEC-AZURE-B"
        set phase1name "IPSEC-AZURE-B"
        set proposal aes256-sha256
        set pfs disable
        set replay disable
        set auto-negotiate enable
        set keylifeseconds 3600
    next

Je regroupe mes interfaces VPN IPSEC dans une ZONE. Pour la gestion des règles de flux cela sera plus simple sur le long terme.

Création d'une zone sur Fortigate

Ils nous faut maintenant ajouter la règle de flux qui nous permettra de joindre notre SNET pour que les IPSEC montent :

Création d'une régle de flux

Nous vérifions que les tunnel sont UP :

Affichage des 2 ipsec

C – Mise en place du routage BGP

Pour que notre interface de loopback puisse joindre les interfaces de peering créée par Azure il va falloir créer deux routes static.

Azure nous fournit les adresses ips de peering dans le fichier de configuration ou directement dans la configuration de notre Virtual Network Gateway :

Affichage configuration BGP sur Azure

Nous créons deux routes statics avec pour next-hop les VPN IPSEC Azure :

Création des routes sur Fortigate pour joindre les peer bgp Azure

Nous vérifions que depuis notre interface de loopback nous arrivons bien à joindre nos deux ip de peering bgp :

execute ping-option source 169.0.0.1

execute ping 172.10.255.4
PING 172.10.255.4 (172.10.255.4): 56 data bytes
64 bytes from 172.10.255.4: icmp_seq=0 ttl=128 time=10.1 ms


execute ping 172.10.255.5
PING 172.10.255.5 (172.10.255.5): 56 data bytes
64 bytes from 172.10.255.5: icmp_seq=0 ttl=128 time=10.3 ms

Nous allons maintenant configurer les deux sessions BPG :

  • AS local = 65510
  • router-id = 169.0.0.1
  • Nos deux neighbors Azure = 172.10.255.4 / 172.10.255.5
  • ebgp-enforce-multihop = Enable | Il faut l’activer car les neighbors n’est pas directement connecté
  • update-source = 169.0.0.1 | Les paquets seront sourcés avec l’ip de notre loopback
config router bgp
    set as 65510
    set router-id 169.0.0.1
    config neighbor
        edit "172.10.255.4"
            set ebgp-enforce-multihop enable
            set remote-as 65515
            set update-source "LOOP_169.0.0.1"
        next
        edit "172.10.255.5"
            set ebgp-enforce-multihop enable
            set remote-as 65515
            set update-source "LOOP_169.0.0.1"
        next
    end

Nous validons que nos deux sessions BGP sont montées : 

get router info bgp summary 

BGP router identifier 169.0.0.1, local AS number 65510
BGP table version is 5
2 BGP AS-PATH entries
0 BGP community entries

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

172.10.255.4    4      65515       4       4        4    0    0 00:01:32        1

172.10.255.5    4      65515       3       4        4    0    0 00:00:42        1

Nous devrions apprendre en BGP l’espace d’adressage configuré dans notre VNET (172.10.0.0) depuis nos deux neighbors 

get router info bgp neighbors 172.10.255.4 routes

BGP table version is 5, local router ID is 169.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight RouteTag Path
*> 172.10.0.0       172.10.255.4             0             0        0 65515 i <-/1>

Total number of prefixes 1

get router info bgp neighbors 172.10.255.5 routes
BGP table version is 5, local router ID is 169.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight RouteTag Path
*  172.10.0.0       172.10.255.5             0             0        0 65515 i <-/->

Total number of prefixes 1

On vérifie que la route est bien injectée dans la table de routage :

get router info routing-table bgp

Routing table for VRF=0
B       172.10.0.0/16 [20/0] via 172.10.255.4 (recursive is directly connected, IPSEC-AZURE), 00:02:55

Je peux maintenant joindre est accéder à la vm debian que j’ai créer dans mon SNET : 

ping 172.10.100.4

PING 172.10.100.4 (172.10.100.4) 56(84) bytes of data.
64 bytes from 172.10.100.4: icmp_seq=1 ttl=63 time=14.0 ms
64 bytes from 172.10.100.4: icmp_seq=2 ttl=63 time=16.6 ms
64 bytes from 172.10.100.4: icmp_seq=3 ttl=63 time=16.1 ms

ssh Ophyde@172.10.100.4
The authenticity of host '172.10.100.4 (172.10.100.4)' can't be established.
ECDSA key fingerprint is SHA256:9CZpbIQHI+FnZ0Dk7cT1XCAgDsOZPVtTVmZyK3xcJzM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.10.100.4' (ECDSA) to the list of known hosts.
Password:
Linux VM-LINUX-001 4.19.0-8-cloud-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.