======VPN (IPsec)======

Un tunnel IPsec ou VPN IPSec est une méthode standardisée permettant d'établir un canal sécurisé pour échanger des données entre 2 points d'un réseau IP. Il travaille au niveau 3 OSI (couche réseau) et fourni les fonctionnalités de chiffrement, confidentialité, authentification, et intégrité des données.

=====Théorie=====

Si les notions de Diffie-Hellman, AES, phase1, phase2 vous sont peu familières, un petit détour par Wikipedia permet de partir sur de bonnes bases : [[https://fr.wikipedia.org/wiki/Internet_Protocol_Security|IPSec]] et [[https://en.wikipedia.org/wiki/Internet_Key_Exchange|IKE (en)]].

Il existe 2 principes d'établissement de tunnel VPN chez Fortinet :
  * **Route-based VPN** (phase1-interface) aussi appelé **interface-based** VPN : Il créer une sous-interface réseau virtuelle ; le trafic est orienté dans le tunnel VPN en fonction de la table de routage. Une route statique avec comme nexthop l'interface tunnel encapsulera le flux dans le tunnel VPN. L'autorisation de traverser le firewall sera contrôlée par les règles de sécurité comme pour un flux standard.\\
Ce type de VPN ne montera pas s'il n'y a pas de règle de sécurité acceptant du trafic depuis et vers l'interface tunnel, et affichera le message d'erreur "ignoring ike request, no policy configured" dans un debug.
  * **Policy Based VPN** (ou **tunnel-based**) : Le trafic est orienté dans le tunnel VPN en fonction des règles de la politique de sécurité. Ces règles auront comme action "ipsec" et devront être définies de manière identique sur les deux Gateway terminant le tunnel VPN car elles participent à l'ouverture de celui-ci (Phase 2). Seul le trafic correspondant aux critères de la police sera encapsulé dans le tunnel VPN.

source : http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/Overview.109.5.html

=====Exemple de configuration=====

Cas d'un route-based VPN (site-to-site ou branch office) avec une clé secrète partagée (PSK) :
<code bash>
# configuration de la phase1 (IKE)
config vpn ipsec phase1-interface
    edit "tun-CC"
        set interface "wan1"
        set keylife 28800
        set proposal aes256-sha256
        set dhgrp 5
        set remote-gw 10.36.1.1
        set psksecret ENC <hashage PSK>
    end
# configuration de la phase2 (IPSec)
config vpn ipsec phase2-interface
    edit "tun-CC-p2"
        set phase1name "tun-CC"
        set proposal aes256-sha256
        set pfs enable
        set dhgrp 5
        set replay enable
        set auto-negotiate enable
        set keylifekbs 172800
        set keylifeseconds 1800
    next

# configuration du routage
config router static
    edit 1
        set comment "route vers le LAN du site distant"
        set device "branch_LAN"
        set dst 192.168.1.0 255.255.255.0
    next

# configuration des règles de sécurité
# tout le trafic entre le LAN distant et local est permis
config firewall policy
    edit 1
        set srcintf "tun-CC"
        set dstintf "port1"
        set srcaddr "net-branch_LAN"
        set dstaddr "net-local_LAN"
        set action accept
        set schedule "always"
        set service "ALL"
    next
    edit 2
        set srcintf "port1"
        set dstintf "tun-CC"
        set srcaddr "net-local_LAN"
        set dstaddr "net-branch_LAN"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end
</code>

Normalement un tunnel monte quand il y a du trafic dedans. Pour forcer son établissement,
<code bash>
diagnose vpn tunnel up tun-CC-p2
</code>
ou, en GUI, aller dans le menu "VPN > Monitoring > IPSec Monitor" puis clic droit sur le tunnel / "Bring up".

=====Vérifications=====

De la configuration des route-based VPN :
<code bash>
show vpn ipsec phase1-interface
show vpn ipsec phase2-interface
</code>

Voir l'état courant en CLI (en GUI on peut aller dans le sous-menu "Monitoring" du menu "VPN" ou consulter les logs dans "Log & Reports > Event log > VPN")
<code bash>
# infos détaillées sur un tunnel :
get vpn ipsec tunnel details
diagnose vpn tunnel list [ name <nom_du_tunnel> ]

get vpn ipsec tunnel summary

# afficher les drivers de chiffrement utilisés
diagnose vpn ipsec driver
# afficher la répartition du traitement IPSec sur les CPUs
diagnose vpn ipsec cpu

# 2 commandes ressemblantes affichant l'utilisation des algorithmes
# de chiffrement par mode de traitement (software-CPU / hardware-NPU (offloading))
get vpn ipsec stats crypto
diagnose vpn ipsec status

diagnose vpn tunnel stat

# afficher tous les tunnel UP (qui ont des SA)
diagnose vpn tunnel dumpsa

# coupé ou lancer le tunnel IPSec spécifié
diagnose vpn tunnel [ up | down ] phase2-itf-name

# supprimer les SAs d'un tunnel
diagnose vpn tunnel flush tunnel-name
# supprimer les SAs d'un tunnel + reseter la conf NAT-T et DPD
diagnose vpn tunnel reset tunnel-name

diagnose vpn ike errors
</code>

=====Debug/Troubleshoot=====

NB : ne pas oublier qu'un tunnel ne montera __que__ si au moins une règle de sécurité le matche, sur le firewall du Fortigate. Si ce n'est pas le cas, le Fortigate fautif se trahira en affichant :
<code bash>
2018-12-03 11:29:25 ike 3:tunnel-noob: ignoring IKE request, no policy configured
</code>

<code bash>
# état du debug
diagnose debug info

# debug IPsec dans la console
diagnose debug console
diagnose debug console timestamp en
diagnose debug application ike -1
diagnose vpn ike log-filter dst-addr4 10.10.10.1

# on lance le debug
diagnose debug enable

# pour quitter le debug, pas de ctrl+C !
diagnose debug disable

# on supprime nos filtres
diagnose debug console timestamp dis
diagnose debug application ike 0
diagnose vpn ike log-filter clear
</code>

Supprimer une SA :
<code bash>
diagnose vpn tunnel flush tun-CT-extra
</code>

Liens utiles :
  * http://cookbook.fortinet.com/ipsec-vpn-troubleshooting/


=====Divers=====

====Offloading====

[[informatique:fortinet:offloading|voir la page dédiée sur ce wiki]]

====Créer 2 tunnels vers le même host====

Dans certains cas on peut avoir besoin de créer 2 tunnels vers la même machine (et sur la même interface). On ne peut pas utiliser la même **remote-gw** (la même IP de peer) donc on doit créer un IP secondaire sur les 2 interfaces WAN.
<code bash>
# existant :
FW1:wan1,IP1 O=========tu1=========O FW2:wan2,IP2

# ce que l'on veut faire
FW1:wan1,IP1 O=========tu1=========O FW2:wan2,IP2
FW1:wan1,IP3 O=========tu2=========O FW2:wan2,IP4
</code>
Le second tunnel tu2 utilise les IPs secondaires IP3 et IP4 déclarées respectivement sur les mêmes interfaces physiques que IP1 et IP2 (sur FW1 et FW2).

Pour forcer les Forti à utiliser ces IPs secondaires pour établir le tunnel //tu2//, on doit préciser celles-ci comme **local-gw** en CLI (l'option n'existe pas en GUI) :
<code bash>
# sur FW1
config vpn ipsec phase1-interface
   edit tu2
      set local-gw IP3
      next
      
# sur FW2
config vpn ipsec phase1-interface
   edit tu2
      set local-gw IP4
      next
</code>

====Supprimer les logs "tunnel-stats"====

Le FortiAnalyzer utiliser les messages ''action=tunnel-stats'' pour afficher des statistiques sur les tunnel IPSec/SSL/etc ; si on ne se sert pas de cet outil et qu'on veut éviter de polluer nos logs, on peut les limiter ainsi :
<code bash>
config system settings
    set vpn-stats-log l2tp
    set vpn-stats-period 86400
end
</code>