Differences

This shows you the differences between two versions of the page.

--- informatique:fortinet:start [2024/08/01 15:36] – [Tips] OSPF MTU mismatch pteu
+++ informatique:fortinet:start [2025/10/31 11:01] (current) – [Interfaces] MSS tuning pteu
@@ Line 35: / Line 35: @@
    Processes: 20 (running=1 sleeping=99)
    [..]
+</code>
-# et quand un processus plante, prend trop de CPU ou de mémoire, on peut le killer :
+C'est un peu anxiogène d'en parler si haut dans la page, mais fortiOS laisse la possibilité aux comptes superadmin de killer les processus (cela peu éviter un redémarrage) :
-diagnose sys kill 11 <PID>
+<code bash>
+# rechercher le/s numéro/s de processus du serveur web (processus httpsd)
+diagnose sys process pidof httpsd
+
+
+
+
+# peut les killer un par un avec :
+diagnose sys kill <PID>
+# ou tuer tous les processus nommés httpsd
+fnsysctl killall httpsd
 </code>
+Par défaut le kill envoie un SIGTERM (15) qui ne laisse pas de trace dans le crash log ''diagnose debug crashlog read'' ; si on veut laisser un backtrace dans le log il faut spécifier d'envoyer un signal 11 (SIGSEGV) :
+<code bash>
+diagnose sys kill 11 <PID>
+fnsysctl killall 11 httpsd
+</code>
 =====Redémarrage=====
@@ Line 194: / Line 212: @@
 Rappel: la MTU IP est de 1500 octets par défaut. Pour la vérifier entre 2 machines, il faut lancer un PING en interdisant la fragmentation (bit "don't fragment" = 1) et en spécifiant sa taille. Pour une MTU par défaut on peut envoyer des PINGs de taille max 1472 (1500 moins les entêtes IP (20) et ICMP (8)), un seul octet de plus (1473) et on ne pourra plus l'envoyer sans fragmenter, donc cela génèrera une erreur.
 </WRAP>
+ref: [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Setting-TCP-MSS-value/ta-p/194518|Technical Tip: Setting TCP MSS value (Fortinet)]]
 <code bash>
@@ Line 549: / Line 569: @@
 </code>
-=====Sauvegarde=====
+=====Enregistrement de la configuration=====
-Il existe 3 modes de sauvegarde la conf :
+Il existe 3 modes d'__enregistrement__ de la configuration courante (la "running-config") :
   * ''automatic'' : (celui par défaut) la configuration est sauvée à chaque fois qu'on saisit mot-clé "end" à la fin d'une section
-  * ''manual'' si on veut forcer la sauvegarde manuelle
+  * ''manual'' : si on veut forcer l'enregistrement manuel
-  * ''revert'' on peut programmer un rollback (reboot + restauration de la conf) automatique du firewall au bout d'un timeout défini ; c'est utile si la modification risque de nous faire perdre la main et que le firewall est sur un site distant. Exemple de mise en place
+  * ''revert'' on peut programmer un rollback (reboot + restauration de la conf) automatique du firewall au bout d'un timeout défini ; c'est utile pour pallier une erreur de manip, ou si une modification risque de nous faire perdre la main sur le firewall (très utile s'il est sur un site distant). Exemple de mise en place :
 <code bash>
 config global
    config system global
-      set cfg-save revert                            # | automatic | manual
+      set cfg-save revert                    # | automatic | manual
-      set cfg-revert-timeout 300                     # on définit le timeout pour le rollback
+      set cfg-revert-timeout 300             # on définit le timeout pour le rollback
       end
 </code>
-<WRAP center round important 60%>
+<WRAP center round important 80%>
-il faut bien penser à désactiver le mode revert après la maintenance sinon il redémarrera à chaque modif (et ne la prendra pas en compte) !
+//Ça va sans dire, mais ça va mieux en le disant// : il faut bien désactiver le mode revert après la maintenance sinon le firewall redémarrera à chaque modif (et ne la prendra pas en compte) !
 </WRAP>
+=====Sauvegarde de la configuration=====
+Les fortis peuvent __sauvegarder__ leur configuration (l'enregistrer dans un fichier dédié différent de la "startup-config") pour conserver et comparer différentes révisions de celle-ci : soit lors de la déconnexion d'un administrateur, soit lors d'une mise à jour du firmware (actif par défaut sur les versions ~6 et sup.).
+<code bash>
+config global
+  config system global
+    set revision-backup-on-logout  enable # sauvegarde après déconnexion d'un admin
+    set revision-image-auto-backup enable # sauvegarde lors d'une mise à jour
+    end
+ end
+end
+</code>
+On retrouvera toutes les versions dans la webUI en cliquant sur l’icône en haut à droite : <utilisateur>/Configuration/Revisions.
 ======Routage======
@@ Line 698: / Line 731: @@
 # affiche les LSAs envoyés par ce Fortigate :
 get router info ospf database self-originate
+diagnose sniffer packet any 'proto 89' 6 0 l
+diagnose sniffer packet any 'host 224.0.0.5' 6 0 l
 get router ospf
@@ Line 845: / Line 881: @@
 ====Tips====
-A partir d'une certaine version de fortiOS (v6 peut-être ?), l’algorithme de calcul des MTUs a changé et ne tombe plus sur les mêmes valeurs que les précédentes versions. De ce fait un upgrade ou l'ajout d'un nouveau fortigate peut aboutir a des erreurs de "MTU mismatch" : ''OSPF: RECV[DD]: From X.X.X.X via itfY: MTU size is too large (1934)'') lors de l'établissement des adjacences OSPF (dont la MTU des interfaces doit être scrupuleusement la même que celle du voisin). Pour contourner ce comportement, <del>on peut</del> il faut désactiver les vérification de MTU pour les interfaces connectées aux voisins de version/MTU différente :
+===MTU mismatch===
+A partir d'une certaine version de fortiOS (v6 peut-être ?), l’algorithme de calcul des MTUs des tunnels IPSec a changé et ne tombe plus sur les mêmes valeurs que les précédentes versions. De ce fait un upgrade ou l'ajout d'un nouveau fortigate peut aboutir a des erreurs de "MTU mismatch" : ''OSPF: RECV[DD]: From X.X.X.X via itfY: MTU size is too large (1934)'') lors de l'établissement des adjacences OSPF (dont la MTU des interfaces doit être scrupuleusement la même que celle du voisin). Pour contourner ce comportement, <del>on peut</del> il faut désactiver les vérification de MTU pour les interfaces connectées aux voisins de version/MTU différente :
 <code bash>
 config router ospf
@@ Line 1193: / Line 1231: @@
     set ha-mgmt-interface "mgmt2"
     set ha-mgmt-interface-gateway 10.0.7.254
-    set override disable
+    set override disable            # ce paramètre doit être aligné sur toutes les unités du cluster
     set priority 150
     set monitor "port23" "port24"
@@ Line 1199: / Line 1237: @@
 </code>
-Normalement l'IP de management du master devient l'IP virtuelle d'admin du cluster et le backup n'est pas administrable ; pour se connecter sur le backup il fait se connecter au master d'abord, puis saisir :
+Les critères de sélection du primaire, lors d'une élection d'un cluster configuré avec le paramètre ''set override disable'' :
+  - l'unité qui possède le moins d'interface monitorée en défaut devient le primaire
+  - l'unité ayant le plus long uptime (__uniquement si la différence dépasse 5min/300s__)
+  - l'unité ayant la plus forte priorité
+  - l'unité ayant le plus haut numéro de série
+NB: lorsqu'une interface monitorée passe en d"faut, cela reset le compteur d'uptime de l'unité.
+Normalement l'IP de management du master devient l'IP virtuelle d'admin du cluster et le backup n'est plus joignable ; pour se connecter dessus il fait se connecter au master d'abord, puis saisir :
 <code bash>
-# se connecter sur le membre d'id=1 du HA à partir du master
+# se connecter sur le membre d'id=1 du HA à partir du master avec le login spécifié
-execute ha manage 1
+execute ha manage 1 <login>
 </code>
@@ Line 1227: / Line 1273: @@
 </code>
-====Vérifications====
+====Diagnostique====
+Rappel: pour obtenir un prompt sur le membre passif d'un cluster, il faut se connecter en SSH sur le membre actif, puis :
 <code bash>
-# activer/désactiver le HA
+c g
+execute ha manage <ID> <login>
+# ex: execute ha manage 1 networkadmin
+</code>
+//à réaliser en mode global si les VDOMs sont activés.//
+<code bash>
+# état du HA (état de la configuration et status)
+get system ha
+get system ha status
+# sensiblement identique à la commande précédente
+diagnose sys ha status
+</code>
+Si désynchro, détermination de la zone non synchro (également visible en GUI en plaçant le curseur sur "Not Synchronized" dans Global/System/HA.)
+<code bash>
+# détermination du VDOM (ou global) non synchro
+diagnose sys ha checksum cluster
+# pour le VDOM non synchro (ex: global), détermination de la portion de conf non synchro
+diagnose sys ha checksum show global
+[...]
+firewall.internet-service-name: 3ecf1b51cca70d08b66bfe86d8e9accc
+rule.fmwp: 00000000000000000000000000000000
+</code>
+à comparer avec la conf du membre désynchro; dans mon cas j'ai 2 portions de conf désynchro.
+Plus rapidement, si comme dans l'exemple on sait que c'est sur la partie "config global" qu'il y a un delta, on peut extraire les "conf global" des 2 membres et les comparer manuellement (dans Notepad++ avec le plugin "compare" par exemple). Penser à afficher la conf sur une seule page (sans les ''---more---''):
+<code bash>
+config system console
+    set output standard
+end
+</code>
+On peut resynchroniser la conf en saisissant manuellement les commandes manquantes sur le bon member ; si cela ne se fait pas tout seul (attendre quelques minutes quand même...), on relance le process de synchro :
+<code>
+# désactiver/activer le HA sur les 2 membres
 execute ha synchro stop
 execute ha synchro start
-# reset l'âge des membres d'un cluster (pour palier certains vieux bug..)
+diagnose sys ha checksum recalculate
-diagnose sys ha reset-uptime
 </code>
-Diagnostique :
+Si toujours KO, remonter le cluster from scratch pour resynchroniser le backup sur le primaire (pas de coupure normalement, mais présence en baie nécessaire) : [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Rebuilding-an-HA-cluster/ta-p/195429|Rebuilding an HA cluster (KB Fortinet)]]
+====Diag avancé / prise de trace====
 <code bash>
-# état du HA
+# sur le primaire
-get system ha status
+execute ha synchronize stop
-# informations détaillées
+diag debug reset
-get system ha
+diag debug enable
+diag debug console timestamp enable
+diag debug application hasync -1
+diag debug application hatalk -1
+execute ha synchronize start
-# cmdes avancées (tshoot)
+# sur le backup
-diagnose sys ha status
+diag debug reset
+diag debug enable
+execute ha synchronize stop
+diag debug console timestamp enable
+diag debug application hasync -1
+diag debug application hatalk -1
+execute ha synchronize start
+</code>
+A la fin du process (10m), désactiver le debug :
+<code bash>
+diag debug disable
+diag debug reset
+</code>
+<code bash>
+# diag avancé
 diagnose sys ha dump 1
 diagnose sys ha dump 2
@@ Line 1255: / Line 1360: @@
 diagnose sys ha showcsum 2
 diagnose sys ha showcsum 3
+# relancer le HA "brutalement"
+fnsysctl killall hasync
+fnsysctl killall hatalk
 </code>
+Liens :
+  * [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Troubleshooting-a-checksum-mismatch-in-a-FortiGate/ta-p/197551|Troubleshooting-a-checksum-mismatch-in-a-FortiGate]]
+  * [[https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-How-to-troubleshoot-HA-synchronization-issue/ta-p/193422?externalID=FD45183|How-to-troubleshoot-HA-synchronization-issue]]
+  * [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Rebuilding-an-HA-cluster/ta-p/195429|Technical Tip: Rebuilding an HA cluster]]
 ======Log / Syslog======
@@ Line 1377: / Line 1490: @@
   * [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Displaying-logs-via-FortiGate-s-CLI/ta-p/193027|Technical Tip: Displaying logs via FortiGate's CLI]]
+=====Tips=====
+====Supprimer des logs====
+Il n'est pas possible de supprimer une ligne de log individuelle, même pour de bonnes raisons (par ex. si elle contient par mégarde un mot de passe...). On ne peut supprimer les logs que pour toute une catégorie au minimum.
+Dans l'exemple du journal contenant un mot de passe, il faut supprimer tous les logs de la catégorie "event", depuis le VDOM de mgmt :
+<code bash>
+c v
+edit root
+# lister les catégories possibles
+execute log filter category
+Available categories:
+: traffic
+: event
+: utm-virus
+: utm-webfilter
+: utm-ips
+: utm-emailfilter
+: utm-anomaly
+: utm-voip
+: utm-dlp
+: utm-app-ctrl
+: utm-waf
+: utm-dns
+: utm-ssh
+: utm-ssl
+: utm-file-filter
+: utm-icap
+: utm-sctp-filter
+: forti-switch
+: utm-virtual-patch
+: utm-casb
+execute log filter category 1
+execute log delete
+This will delete memory event log
+Do you want to continue? (y/n)y
+</code>
 ======Mail d'alerte======
@@ Line 1385: / Line 1541: @@
 Pour tester l'envoi de mail, en CLI : ''diagnose log alertmail test''
+======VxLAN (over IPSec)======
+Le VxLAN est une encapsulation réseau permettant d'interconnecter des segments Ethernet disjoints via des réseaux IP (L3) ; il fonctionne en UDP/4789. Cela provoque un //overhead// de 50 octets (14 B (Ethernet) + 20 B (IPv4) + 8 B (UDP) + 8 B (VXLAN headers)) qu'il faut comptabiliser dans le calcul de la MTU pour éviter la fragmentation de paquets.
+Mis en place d'un VxLAN overIPSec:
+Soit le topologie suivante : 2 fortigates, interconnectés via un tunnel IPSec vpn-to-FTG1/2:
+<code bash>
+vlan5 --- FGT1_port1                           port2_FGT2 --- vlan6
+                 o========= vpn-to-FGTx =========o        192.168.5.254/24
+.1.1.1/32                  10.2.2.2/32
+</code>
+On veut interconnecter les VLANs 5 de FGT1 et 6 de FGT2 via notre VxLAN. On va configurer des VTEPs (VXLAN tunnel endpoint) et un //software-switch// (ce qui a pour inconvénient d'être traité en software càd via la CPU, et ne pourra donc pas donner d'excellentes performances: débits mesurés à seulement ~800 Mbps sur un fgt-1100E).
+Sur FGT1:
+<code bash>
+# VDOM intranet: déclaration du VxLAN
+config system vxlan
+    edit "vxlan5"
+        set interface "vpn-to-FGT2"
+        set vni 5
+        set remote-ip "10.2.2.2"
+    next
+end
+# global
+config system interface
+    edit "vlan5"
+        set vdom "intranet"
+        unset ip
+        set alias "vlan5"
+        set role lan
+        set interface "port1"
+        set vlanid 5
+    next
+end
+# pour être ajoutés au sw-itf, le vlan5 ne doit pas avoir d'IP ni appartenir à une zone
+config system switch-interface
+    edit "si5"
+        set vdom "intranet"
+        set member "vlan5" "vxlan5"
+    next
+end
+config system interface
+    edit "si5"
+        set vdom "intranet"
+        unset ip  # la passerelle 192.168.5.254/24 se situe sur FGT2
+        set type switch
+    next
+end
+</code>
+Sur FGT2:
+<code bash>
+# VDOM intranet: déclaration du VxLAN
+config system vxlan
+    edit "vxlan6"
+        set interface "vpn-to-FGT1"
+        set vni 5    # le vni doit nécessairement être le même
+        set remote-ip "10.1.1.1"
+    next
+end
+# global
+config system interface
+    edit "vlan6"
+        set vdom "intranet"
+        unset ip
+        set alias "vlan6"
+        set role lan
+        set interface "port2"
+        set vlanid 6
+    next
+end
+# pour être ajoutés au sw-itf, le vlan5 ne doit pas avoir d'IP ni appartenir à une zone
+config system switch-interface
+    edit "si6"
+        set vdom "intranet"
+        set member "vlan6" "vxlan6"
+    next
+end
+config system interface
+    edit "si6"
+        set vdom "intranet"
+        set ip 192.168.5.254/24
+        set type switch
+    next
+end
+</code>
+Sources:
+  * https://docs.fortinet.com/document/fortigate/7.4.6/administration-guide/38079/vxlan
 ======Services réseau======
@@ Line 1713: / Line 1960: @@
 diagnose debug app hatalk 255
+# Afficher les paquets fragmentés seulement (MF=1 ou avec un offset de fragmentation, mais DF=0)
+diagnose sniffer packet any '((ip[6:2] > 0) and (not ip[6] = 64))' 4 0 a
 # Afficher les paquets ICMP de type 3 code 4
-# (fragmentation nécessaire mais impossible à cause du drapeau (flag) DF)
+# (fragmentation nécessaire (MF) mais impossible à cause du drapeau (flag) DF)
 diagnose sniffer packet any 'icmp[0] = 3 and icmp[1] = 4' 4 0 l
 # alternative :
 diagnose sniffer packet any 'icmp[0:2] = 0x0304' 4 0 l
 </code>
 =====Packet capture=====
@@ Line 1737: / Line 1986: @@
 =====iperf=====
-Les fortigates intègrent un client iperf (accessible à partir du mode global), qui permet de réaliser des tests de débit entre 2 interfaces du même forti, ou avec un serveur externe.
+Les Fortigates intègrent un client iperf (accessible à partir du mode global), qui permet de réaliser des tests de débit entre 2 interfaces du même forti, ou avec un serveur externe.
 <code bash>
 conf global
@@ Line 1750: / Line 1999: @@
 diagnose traffictest run
 </code>
-Malheureusement il n'est pas possible de l'utiliser en mode serveur à partir d'autres clients que celui local.
 La plupart des options classiques d'iperf sont disponibles, on peut les afficher avec ''diagnose traffictest run -h''
+Depuis les versions 7.0 et 7.2, on peut configurer un Fortigate également en mode serveur :
+<code bash>
+# activer la fonction en mode global
+config system global
+    set speedtest-server enable
+end
+# sur l'interface d'écoute, activer le protocole "speed-test"
+config system interface
+    edit wan1
+        append allowaccess speed-test
+    next
+end
+</code>
+Par sécurité il n'est pas recommandé de laisser activé le mode serveur au-delà des tests de qualif/diagnostique.
@@ Line 2043: / Line 2308: @@
 =====Reset factory=====
+Pour effectuer un restauration d'usine (rétablir la configuration d'usine) :
 <code bash>
 execute factoryreset
@@ Line 2213: / Line 2479: @@
 =====Auto filesystem check=====
-Après une coupure électrique les Fortigate affichent un message d'alerte invitant l'utilisateur à rebooter et réaliser un filesystem check pour contrôler l'intégrité du système de fichier. Depuis les version 6 il est possible de réaliser automatiquement ce check au démarrage , via le menu : System> Settings> Start Up, "Auto file system check" ; ou en CLI:
+Après une coupure électrique les Fortigate affichent un message d'alerte invitant l'utilisateur à rebooter et réaliser un filesystem check pour contrôler l'intégrité du système de fichier. Depuis les version 6 il est possible de [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Run-a-File-System-Check-automatically/ta-p/193298|réaliser automatiquement ce check au démarrage]], via le menu : System> Settings> Start Up, "Auto file system check" ; ou en CLI:
 <code bash>
 config system global
@@ Line 2220: / Line 2486: @@
 </code>
-C'est toutefois non-recommander car 1) ça prend du temps donc il vaut mieux le planifier en heure non ouvrée et 2) en cas d'incident électrique le courant peut ne pas être stable et donc recouper le Forti pendant son check -> dangereux.
+Ce n'est toutefois pas souhaitable car 1) ça prend du temps donc il vaut mieux le planifier en heure non ouvrée et 2) en cas d'incident électrique le courant peut ne pas être stable et donc recouper le Forti pendant son check -> dangereux.
 =====SSH sortant impossible=====
@@ Line 2247: / Line 2513: @@
 </WRAP>
+=====Désactiver les upgrades automatiques=====
+Depuis la version 7.4.5 et si on les mets à jour (donc pas les //fresh install//) depuis des versions majeures antérieures (7.0, 7.2), les Fortigates se mettent à jour de leur propre chef s'ils détectent une nouvelle version de FortiOS disponible. Comme tout ce qui est forcé, masqué et impactant c'est assez malvenu ; mais on peut tout de même le désactiver :
+<code bash>
+# pour vérifier l'état de l'option
+diagnose test application forticldd 13
+Scheduled push image upgrade: no
+Scheduled Config Restore: no
+Scheduled Script Restore: no
+Automatic image upgrade: Enabled.       # <-------- l'option fautive est activée
+        New image information may be fetched.
+        Next new image info fetch scheduled at (local time) Tue Oct  7 01:34:49 2025
+        New image installation may be cancelled by the user.
+        Last new image info fetch executed at (local time) Mon Oct  6 03:36:21 2025
+# Pour la désactiver :
+c g
+config sys fortiguard
+set auto-firmware-upgrade disable
+end
+Any pending automatic patch-level firmware upgrade has been removed.
+</code>
+src: [[https://community.fortinet.com/t5/FortiGate/Technical-Tip-Auto-firmware-update-enabled-by-default-when/ta-p/306899|Auto-firmware-update enabled by default when upgrading from v7.0.X to v7.2.6]]
 ======Liens utiles======
   * [[http://docs-legacy.fortinet.com/cb/html/index.html#page/FOS_Cookbook/Install_advanced/cb_enhance_security.html|Enhancing FortiGate Security (fortinet.com)]]