Quelltext der Seite FortiGate-5.4-5.6:FAQ

FortiGate-5.4:FAQ

[[Category:Fortinet]]

  <font size="6">'''Fortinet Announced 8 X 5 <span style="color: #FF0000;">Advanced Replacement</span> Weltweit'''</font>
  
                         <font size="2">[[Fortinet:8x5AdvancedReplacement|'''Weitere Informationen finden Sie hier!''']]</font>

__TOC__

== Vorwort ==

Diese FAQ's sind für Fortinet Systeme basierend auf OS 5.4. Zu Test-Zwecken stand eine Fortigate 60D zur Verfügung!

<br/>

== Datenschutz ==

<pre>
        *********************************************************************
        *                                                                   *
        *  THIS FILE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY  *
        *      PROTECTED INFORMATION. YOU ARE PROHIBITED FROM COPYING,      *
        *    DISTRIBUTING OR OTHERWISE USING IT WITHOUT PERMISSION FROM     *
        *                   ALSO SCHWEIZ SWITZERLAND.                       *
        *                                                                   *
        *********************************************************************

"Die in diesen Artikeln enthaltenen Informationen sind vertraulich und dürfen ohne
  schriftliche Zustimmung von der Schweiz AG gegenüber Dritt-Unternehmen nicht 
                         bekannt gemacht werden"

</pre>

== FAQ ==

== Documentation ==

=== Wo findet ich die Dokumente wie Datasheets, Quick Start Guide, User Guide etc. ? ===

Ueber folgenden internen Link findet man Datasheets und Quick Start Guide betreffend Fortigate Devices:

        [[Fortinet:ProduktInfo]]

Ebenfalls lohnt es sich folgenden Link anzuschauen der "Cookbook" ähnliche Dokumente und Video's beinhaltet:

        http://community.fortinet.com/

Auf folgender Seite findet man alle orginal Dokumente betreffend Fortigate:

        http://docs.fortinet.com/fortigate/admin-guides

        '''FortiOS 5.4'''
        [[Datei:Fortios-v5.4.0-release-notes.pdf]]                                                  (FortiOS - Release Notes Version 5.4.0)
        [[Datei:Fortios-v5.4.1-release-notes.pdf]]                                                  (FortiOS - Release Notes Version 5.4.1)
        
        [[Datei:FortiOS-Upgradepath-54.pdf]]                                                        (FortiOS 5.4 Supported Upgrade Paths for Firmware)
        [[Datei:FortiGate_Managed_FortiSwitch_Matrix.pdf]]                                          (Managed FortiSwitch Compatibility Matrix)
        [[Datei:FortiOS-Compatibility-FMG-FAZ.pdf]]                                                 (Managed FortiManager/FortiAnalyzer Compatibility Matrix)
        
        [[Datei:Coop-Security-Fabric-5.4.1-Upgrade-Guide.pdf]]                                      (Cooperative Security Fabric - Upgrade Guide - FortiOS Version 5.4.1)
        
        [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]                                           (FortiOS 5.4 Feature / Platform Matrix)
        [http://help.fortinet.com/fgt/54/max-values/5-4-0/max-values.html Datei:Fortigate-Max-Values-54.pdf]                                                     (FortiOS 5.4 Max Values / Online Version http://help.fortinet.com/fgt/54/max-values/5-4-0/max-values.html)
        
        [[Datei:Fortigate-Whats-New-54.pdf]]                                                        (FortiOS 5.4 Handbook - What's New)
        [[Datei:Fortigate-cookbook-54.pdf]]                                                         (FortiOS 5.4 FortiGate Cookbook)
        [[Datei:Fortigate-CLI-Ref-54.pdf]]                                                          (FortiOS 5.4 CLI Reference)
        [[Datei:FortiOS-Log-Reference-54.pdf]]                                                      (FortiOS 5.4 FortiOS Log Reference)
                
        [[Datei:Fortigate-Handbook-54.pdf]]                                                         (FortiOS 5.4 Handbook - OS)
        [[Datei:Fortigate-Handbook-Getting-Started-54.pdf]]                                         (FortiOS 5.4 Handbook - Getting Started)
        [[Datei:Fortigate-Authentication-54.pdf]]                                                   (FortiOS 5.4 Handbook - Authentication)
        [[Datei:Fortigate-Carrier-54.pdf]]                                                          (FortiOS 5.4 Handbook - Carrier)  
        [[Datei:Fortigate-HA-54.pdf]]                                                               (FortiOS 5.4 Handbook - High Availability)
        [[Datei:fortigate-hardware-accel-54.pdf]]                                                   (FortiOS 5.4 Handbook - Hardware Acceleration)    
        [[Datei:Fortigate-IPSec-VPN-54.pdf]]                                                        (FortiOS 5.4 Handbook - IPsec VPN)
        [[Datei:Fortigate-IPv6-54.pdf]]                                                             (FortiOS 5.4 Handbook - IPv6)
        [[Datei:Fortigate-Load-Balancing-54.pdf]]                                                   (FortiOS 5.4 Handbook - Load Balancing)
        [[Datei:Fortigate-Managing-Devices-54.pdf]]                                                 (FortiOS 5.4 Handbook - Managing Devices)
        [[Datei:Fortigate-Managing-Switch-54.pdf]]                                                  (FortiOS 5.4 Handbook - Managing FortiSwitch from FortiGate)
        [[Datei:Fortigate-Optimal-Life-54.pdf]]                                                     (FortiOS 5.4 Handbook - Optimal Path Processing "Life of a Packet")
        [[Datei:Fortigate-Open-Ports-54.pdf]]                                                       (FortiOS 5.4 Handbook - Open Ports)
        [[Datei:Fortigate-PCI-DSS-Compliance-54.pdf]]                                               (FortiOS 5.4 Handbook - PCI DSS Compliance)
        [[Datei:Fortigate-SSL-VPN-54.pdf]]                                                          (FortiOS 5.4 Handbook - SSL VPN)
        [[Datei:Fortigate-Sandbox-Inspection-54.pdf]]                                               (FortiOS 5.4 Handbook - Sandbox Inspection)
        [[Datei:Fortigate-sip-54.pdf]]                                                              (FortiOS 5.4 Handbook - VoIP Solutions: SIP)
        [[Datei:Fortigate-Security-Profiles-54.pdf]]                                                (FortiOS 5.4 Handbook - Security Profiles)
        [[Datei:Fortigate-vdoms-54.pdf]]                                                            (FortiOS 5.4 Handbook - Virtual Domains (VDoms))
        [[Datei:Fortigate-WANopt-Cache-Proxy-54.pdf]]                                               (FortiOS 5.4 Handbook - WAN Optimization, Web Cache, Explicit Proxy, and WCCP)
        [[Datei:Fortigate-Wireless-54.pdf]]                                                         (FortiOS 5.4 Handbook - Deploying Wireless Networks)
        [[Datei:Fortigate-troubleshooting-54.pdf]]                                                  (FortiOS 5.4 Handbook - Troubleshooting)
        
        [[Datei:Fortios-rsso-with-win-server-2012-and-nps.pdf]]                                     (FortiGate - RSSO with Windows Server 2012 R2 and NPS)

=== Gibt es einen direkten Link auf die "Fortinet Knowledgebase" auf der die "KB Artikel" alle aufgelistet sind? ===

Die Fortinet "Knowledgebase" Artikel sind über den folgenden Link erreichbar:

        http://kb.fortinet.com/

Ueber diesen Link sieht man die verschiedenen Fortinet Produkte die man anwählen und über eine Suchfunktion für das entsprechende Produkt einen entsprechenden "KB Artikel" suchen kann. Möchte man jedoch sämtliche "KB Artikel" auflisten - vorallem die Neusten - ist dies über den Link nicht möglich. Nachfolgender Link bietet diese Möglichkeit dh. sämtliche "KB Artikel" werden aufgelistet (die Neusten zu oberst):

        http://pub.kb.fortinet.com/index/

== Hardware ==

=== Wo finde ich die Hardware Revision und Hardware Generation Informationen eines FortiGate Devices? ===

Ein FortiGate Device verfügt über eine entsprechende "Hardware Revision" und "Hardware Generation". Ueber diese Information wird ein entsprechender FortiGate Device identifiziert. Möchte man die "Hardware Revision" herausfinden einer FortiGate kann dies folgendermassen bewerkstelligt werden:

        '''Variante Device Label'''
        
        Die "Hardware Revision" wird als "label" auf der Rückseite eines FortiGate Devices aufgeführt in
        nachfolgender Form und als Strich-Code:
        
        PN: P15968-01

        '''Variante FortiOS'''
        
        Wenn man über CLI folgenden Befehl absetzt erhält man die "Hardware Revision" Information:
        
        # get system status | grep Part-Number
        System Part-Number: P15968-01

Wie schon zu Beginn erklärt wird ein Device über die "Hardware Revision" und "Hardware Generation" identifiziert. Die "Hardware Generation" kann jedoch nicht erruiert werden sei es über ein "label" noch über CLI. Wenn diese Informatione dennoch benötigt wird kann über ein Ticket die entsprechende Information der "Hardware Generation" angefragt werden. Wie ein Ticket für Fortinet eröffnet wird siehe nachfolgender Artikel:

        [[Fortinet:Support-Case]]
        
        '''NOTE''' Bei dieser "Hardware Revision" wie in unserem Beispiel gezeigt (P15968-01) handelt es sich zB um eine FG-70D. Das bedeutet: 
             Wenn eine neue "Hardware Revision" für diesen Device released wird so kann diese über eine PN Nr "P15968-01" verfügen jedoch
             als "Hardware Generation" die "2". Es kann jedoch auch sein, dass ein neue "Hardware Revision" über eine PN Nummer verfügt 
             zB "P15978-02". Somit kann anhand der PN Nummer keine Rückschlüsse gezogen werden über die nötige Information von:
             
             PN Nummer (Hardware Revision) + Hardware Generation
             
             Diese Information der "Hardware Revison" sowie "Hardware Generation" sind dann wichtig wenn es sich um einen Cluster handelt.
             Bei einem RMA Austausch achtet Fortinet darauf und übermittelt der zuständigen Stelle für den Austausch diese Informationen
             damit diese exakt die gleiche "Hardware Revision" und "Hardware Generation" dem Kunden zustellt!

=== Wo finde ich eine Uebersicht welcher FortiGate Device zB über wieviel "Memory" verfügt, ein "SOC" und/oder "NP" verbaut ist? ===

Nachfolgend eine Aufstellung die zeigt über welche Komponenten wie "SOC, NP, Memory, Storage ein FortiGate Device verfügt:

        '''NOTE''' Diese Informationen stammen aus einem Post im "Fortinet Forum" da Fortinet diese Informationen nicht komuniziert:
             
             https://forum.fortinet.com/tm.aspx?m=100451#100451
             
             Zusätzlich steht ein Dokument von Fortinet zur Verfügung die über die Hardware Schematic eines Fortinet Produktes wie zB
             CPU, RAM, Flash usw. Auskunft gibt:
             
             [[Fortinet:ProduktInfo#Fortinet_Hardware_Schematics]]

        '''LEGENDE'''
        FA = FA526id(wb) rev 1 (v4l) FortiSOC (Fortinet)
        I2 = Intel Core 2 Duo
        I3 = Intel Pentium III
        I4 = Intel Pentium 4
        IA = Intel Atom
        IC = Intel Celeron (Covington)
        II3 = Intel Core i3
        II5 = Intel Core i5
        IM = Intel Mobile
        IX = Intel Xeon
        
        CP: Content Processor
        NP: Network Processor
        SoC: System on a Chip

        [[Datei:Fortinet-821.jpg]]

        [[Datei:Fortinet-822.jpg]]

        [[Datei:Fortinet-823.jpg]]

        [[Datei:Fortinet-1611.jpg]]

        [[Datei:Fortinet-824.jpg]]

=== Was für FortiGate Devices stehen in den verschiedenen Verfügung und welche ist die Richtige? ===

Wenn für einen Kunden ein FortiGate Device installiert werden soll stellt sich die Frage welcher Device ist der Richtige? Dabei sind verschiedenen Informationen wichtig wie zB:

        - Ueber was für eine Internet Anbindung verfügt der Kunde an der ein FortiGate Device installiert werden soll?
        - Ist ein Ausbau/Wechsel der Internet Anbindung geplant und wenn ja wir diese vergrössert (Dowstream/Upstream)?
        - Wieviele User werden durch den FortiGate Device geschützt?
        - Welche UTM Features werden auf dem FortiGate Device eingesetzt (Antivirus, WebFilter, IPS usw)
        - Wird "deep inspection" eingesetzt (Aufbrechen von verschlüsseltem Traffic)?
        - Werden spezielle Interface's benötigt zB SFP+
        - Wird ein spezieller Durchsatz in einem Bereich benötigt?
        - Wo wird "logging" durchgeführt zB Disk, FortiAnalyzer usw.?

Zusätzlich stellt Fortinet die sogenannte "Produkte Matrix" zur Verfügung in der die verschiedenen Devices gegenüber gestellt werden und die verschiedenen "Durchsätze" in verschiedenen Kategorieren wie SSL-VPN, IPSec, UTM Antivirus usw. aufgelistet und gegenüber gestellt werden. Dabei ist zu beachten, dass diese "Durchsätze" als "Feature Only" Durchsatz zu verstehen sind. Dies bedeutet: Wird Antivirus mit 35 Mbps Durchsatz aufgeführt, versteht sich dieser Wert in dem Sinne, dass wenn dieser Device "nur" Antivirus Traffic erhalten würde, der Durchsatz 35 Mbps ist. Aus diesem Grund ist es unerlässlich die Produkte Matrix zu konsultieren um den richtigen Device für den Kunden auszuwählen:

        [[Fortinet:ProduktInfo#Fortinet_Produkt-Matrix]]

Zu den verschiedenen FortiGate Devices stehen jeweils die "Datasheet" zur Verfügung die nochmals detailliert über den jeweiligen FortiGate Device Auskunft gibt. Desweiteren stehen zu den "Datasheet" ebenso die "Quickstart" Guide zur Verfügung die zeigen "was" zum jeweiligen Device mitgeliefert wird sowie das Aussehen:

        [[Fortinet:ProduktInfo#FortiGate]]

Desweiteren steht für die Produkte Information der Produkt Guide zur Verfügung der jeden FortiGate Device in einer Kurzübersicht darstellt:

        [[Fortinet:ProduktInfo#Fortinet_Produkt-Guide]]

Nachfolgend als Anhaltspunkt eine Uebersicht der FortiGate Devices in den verschiedenen Kategorieren wie "Entry Level, Midsize usw.":

        [[Datei:Fortinet-1392.jpg]]

        [[Datei:Fortinet-1393.jpg]]

        [[Datei:Fortinet-1394.jpg]]

        [[Datei:Fortinet-1396.jpg]]

        [[Datei:Fortinet-1397.jpg]]

        [[Datei:Fortinet-1610.jpg]]

=== Wie kann ich auf einem FortiGate Device einen Hardwartest ausführen (Troubleshooting/HQIP Testing)? ===

Damit man den "Advanced Hardware Test" resp. HQIP Test durchführen kann, muss ein spezielles "image" das für jeden Device zur Verfügung gestellt wird, temporär geladen werden. Unter der regulären Support Seite findet man die Images über das Icon "HQIP Images" am ende der Seite. Nachfolgend der direkte Link für "HQIP Images":

        https://support.fortinet.com/Download/HQIPImages.aspx
        
        '''NOTE''' Damit man zu diesem Link gelangt muss anhand eines Support Accounts eingeloggt werden sowie damit das 
             entsprechende Image runtergeladen werden kann, muss die entsprechende Serien Nummer des Devices eingegeben
             werden. Dies muss durchgeführt werden da jeder Device identifiziert werden muss anhand der Revision und 
             Generation um das entsprechende HQIP Image zur Verfügung stellen zu können. Dies bedeutet auch: Es ist nicht
             zu empfehlen ein bestehendes Image aus einem früheren HQIP Test zu benützen um auf einem Baugleichen Device
             den Test durchzuführen da die Devices -obwohl Baugleich- sich unterscheiden können in Revision und Generation.

Auf der FortiGate wird dieses HQIP Image wie beim "staging" Prozess selber über TFTP hochgeladen.
Nachdem man das HQIP Image über TFTP geladen hat kann mit dem User "admin" eingeloggt wurde (kein Passwort) kann anhand des Befehls "diagnose hqip start" ein Script ausgeführt werden. Dieses Script führt die verschiedenen Hardware Tests aus. Der Unterschied zum regulären "staging" Prozess selber ist einzig und alleine, dass dieses Image nicht anhand "D" (Default), "B" (Backup) sondern anhand "R" (Run) installiert wird. Dies bedeutet: dieses Image wird durch "R" (Run) in den Memory Bereich temporär installiert. Der Output der Serial Console muss "geloggt" werden damit es später dem Fortinet Support übermittelt werden kann. Im "putty" wird dies für eine Session unter folgender Position konfiguriert:

        Category > Session > Logging > All Session output

Nachfolgend eine Schritt für Schritt Anleitung wie so ein HQIP Image geladen sowie das Scritp ausgeführt wird:

        -> Lade das entsprechende Image herunter (siehe Link oben; Serien Nummer des Devices muss angegeben werden)
           
        -> Benenne das File um nach "image.out" und verschiebe diese in das root Verzeichnis eines TFTP Servers. 
           Wenn kein TFTP Server vorhanden ist empfehlen wird den SolarwindsTFTP Server. Nachfolgend ein Link
           um diesen runterzuladen:
           
           SolarWinTFTP Server http://www.solarwinds.com/products/freetools/free_tftp_server.aspx
           
        -> Sofern das Web Mgmt. Interface zugänglich ist empfehlen wir vor dem Test ein ordentliches Backup der
           Konfiguration der FortiGate durchzuführen!
           
        -> Führe ueber die Serielle Console nachfolgenden Befehl aus um einen Neustart des Devices durchzuführen:
        
        # '''execute shutdown'''
                 
        -> Um das HQIP Image über den TFTP Server zu laden muss eine Workstation folgendermassen mit eine FortiGate
           verbunden werden (Beispiel: FortiGate-60D)
        
                       _____________________________
                      |       RS232 Verbindung      |
        Consolen Port |                             |
           ___________|___                          | RS232 Anschluss
          |               |                     ____|_______________
          | FortiGate 60D |   192.168.1.100/24 |                    |
          |_______________|               _____| LapTop/Workstation | --> SolarWindsTFTP Server starten 
                   |                     | NIC |____________________| --> FortiOS als image.out im C:\TFTP-Root
              WAN1 |                     |      
                   |_____________________|    
         
          '''NOTE''' Auf dem Laptop müssen sämtliche Firewall's, Endpoint Security und Netzwerkkarten deaktiviert sein und auf der LAN Netzwerkarte
               muss die IP 192.168.1.100 mit dem Subnet 255.255.255.0 konfiguriert sein (Kein DNS, kein Default Gateway nötig)!
        
        -> Oeffne über Putty eine Serielle Verbindung (Console) und achte darauf das "putty" für Log aktiviert wurde. 
           Schalte Die FortiGate ein und breche den Startprozess ab wenn folgendes erscheint:
        
        FortiGate-60D (10:49-11.12.2014)
        Ver:04000024
        Serial number: FGT60D4615013788
        CPU(00): 800MHz
        Total RAM:  2GB
        Initializing boot device...
        Initializing MAC... nplite#0
        Please wait for OS to boot, or press any key to display configuration menu
        
        '''Unterbreche den Boot-Prozess durch "Press any key"'''
                 
        [C]: Configure TFTP parameters.
        [R]: Review TFTP parameters.
        [T]: Initiate TFTP firmware transfer.
        [F]: Format boot device.
        [I]: System information.
        [B]: Boot with backup firmware and set as default.
        [Q]: Quit menu and continue to boot.
        [H]: Display this list of options.
         
        Enter C,R,T,F,I,B,Q,or H: T
         
        Please connect TFTP server to Ethernet port 'WAN1'.
         
        MAC: 08:5b:0e:d9:18:f0
         
        Connect to tftp server 192.168.1.100 ...
         
        ############################################################
        Image Received.
        Checking image... OK
        
        '''ACHTUNG Beim nächsten Menüpunkt wähle "R" dh. NICHT "D" oder "B" Speichern sondern NUR Ausführen!'''
        
        Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]?'''R'''
        Reading boot image... 1829759 bytes.
        Initializing firewall...
        
        System is starting..
         
        Test program loading(HQIP, Build1003,Dec 15 2010 19:42:45) ...
         
        You are running HQIP test program. To start testing, login as "admin" without password, and type:
        diagnose hqip start
         
        '''Logge dich nun ein anhand der obigen Informationen!'''
         
        HQIP login: '''admin'''
        Password:
        Welcome !
        
        HQIP # '''diagnose hqip start'''

Nun wird der HQIP Test ausgeführt und zwar für folgende Informationen:

         1.BIOS Integrity Check
         2.System Configuration Check 
         3.Memory test 
         4.CPU test
         5.CPU/Memory Performance Test
         6.FortiASIC Test 
         7.USB Test
         8.Boot Device Test
         9.Hard Disk Test
        10.Network Interface Controller Test
        11.NPU DDR Memory Test
        12.LED Test
        13.Reset Button Test

dh. normalerweise müssten alle Netzwerkkarten Ports angeschlossen werden. Geschieht dies nicht erscheint eine Fehlermeldung die jedoch keinen weiteren Einfluss hat auf die auszuführenden Tests, ausser der Test soll auf den Interfaces ausgeführt werden. Wenn die Netzwerkkarten Test korrekt ausgeführt werden soll müssen die Ports folgendermassen verbunden werden (Beispiel FortiGate-60D):

        [[Datei:Fortinet-1632.jpg]]

Nachfolgend ein Output eines solchen Tests für eine FG-60D (Netzwerkport gemäss Grafik oberhalb "überlistet"):

        [[Datei:hqip-output-v54.txt]]

Um die Fortigate wieder in den Orginalzustand zu versetzen führe ein Login über die Serielle Consoel durch mit dem User "admin" (kein Passwort). Danach führe folgendes aus:

        HQIP login: admin
        Password:
        Welcome !
        
        HQIP # execute reboot
        This operation will reboot the system !
        Do you want to continue? (y/n)y

Da das HQIP Image "nur" temporärer (Memory) installiert wurde sind alle Informationen nach einem Neustart betreffend diesem Image gelöscht worden. Wenn es nach dem Neustart zu Hinweise/Errors betreffend der Konfiguration kommt zB:

        System is started.
        The config file may contain errors,
        Please see details by the command 'diagnose debug config-error-log read'

Führe ein Login durch und führe folgendes aus:

        # diagnose debug config-error-log read
        >>>  "unset" "post-lang" @ root.firewall.profile-protocol-options.default.ftp:command parse error (error -61)

Oftmals ist ein einfach Neustart der Fortigate nötig um das Problem zu beheben:

        # execute reboot

=== Für eine FortiGate Device der "E" Serie existiert kein HQIP Image wie kann ich dennoch einen Hardwartest ausführen? ===

Bei der "E" Serie kann von der "Support" Seite kein seperates HQIP Image herungergeladen werden. Auf diesen Umstand wird auf der "Support" Seite auch darauf hingewiesen. Dazu steht jedoch auf der "E" Serie ein "diagnose" Kommando zur Verfügung der diese "Hardware Tests" im Stil von "HQIP" durchführt:

        # diagnose hardware test [Parameter]

Als "Parameter" kommen folgende Attribute in Frage:

        bios                    führt eine BIOS spezifische Überprüfung durch
        system                  führt eine System spezifische Überprüfung durch
        usb                     führt eine USB spezifische Überprüfung durch
        button                  führt eine button spezifische Überprüfung durch
        cpu                     führt eine CPU spezifische Überprüfung durch
        memory                  führt eine Memory spezifische Überprüfung durch
        network                 führt eine Netzwerkinterface spezifische Überprüfung durch
        disk                    führt eine disk spezifische Überprüfung durch
        led                     führt eine LED spezifische Überprüfung durch
        wifi                    führt eine Wireless spezifische Überprüfung durch
        suite                   runthe HQIP test suite
        setting                 die Testeinstellungen können auf diesen Weg geändert werden
        info                    zeigt die aktuellen Test Parameter an

Um alle "test suite" durchzuführen kann folgendes ausgeführt werden:

        # diagnose hardware test suite all

Nachfolgend ein "output" dieses Befehls basierend auf einer FG-50E:

        [[Datei:diagnose-hardware-test-suite-all.txt]]

=== Ein FortiGate Device führt unter FortiOS 5.4 selbständig einen immer wiederkehrenden Neustart aus was kann ich tun? ===

Wenn eine FortiGate selbständig immer wieder einen Neustart ausführt kann die Ursache vielfältig sein. Grundsätzlich fragt man sich was getan werden kann um herauszufinden wieso dem so ist? Eine Möglichkeit ist die Hardware zu testen anhand HQIP dh. um festzustellen ob ein Hardware Defekt vorliegt. Weitere Informationen dazu wie ein HQIP Test durchgeführt wird siehe nachfolgende Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_auf_einem_FortiGate_Device_einen_Hardwartest_ausf.C3.BChren_.28Troubleshooting.2FHQIP_Testing.29.3F]]
        [[FortiGate-5.4:FAQ#F.C3.BCr_eine_FortiGate_Device_der_.22E.22_Serie_existiert_kein_HQIP_Image_wie_kann_ich_dennoch_einen_Hardwartest_ausf.C3.BChren.3F]]

Eine andere Möglichkeit ist ist die Folgende:

        1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
        2. Erstelle eine Consolen Verbindung zur FortiGate (RS232 basierend resp. Seriell)
        3. Führe ein Login durch und gebe folgendes ein:
           
           '''Setze alle Debug Filter zurück'''
           
           # diagnose debug reset

           '''Setze einen Debug Filter für "kernel level"'''
           
           # diagnose debug kernel level 7

           '''Aktiviere für den debug "output" den "timestamp"'''
           
           # diagnose debug console timestamp enable

           '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
           
           # diagnose debug enable 

Danach muss die Verbindung aufrechterhalten werden und gewartet werden bis der selbständige Neustart des Devices ausgeführt wird. Durch den "debug" wird unter normalen Umständen in der Console aufgezeichnet was dieser Neustart ausgelöst hat. Dieser Output muss nachträglich einem Fortinet TAC Mitarbeiter (Support Ticket) übermittelt werden für das weitere Vorgehen. Unter normalen Umständen dh. ohne Neustart wird für diesen "debug" kein Output aufgezeichnet. Dieses Vorgehen kann ebenfalls benutzt werden wenn durch den Device ein "freeze" durchgeführt wird.

=== Gibt es für FortiGate Device's eine Uebersicht wie die Luftzirkulation (Airflow) in den Device's aufgebaut ist? ===

Nachfolgende Dokument zeigen für die jeweiligen FortiGate Devices wie die Luftzirkulation/Kühlung in den Devices aufgebaut ist und wie diese funktionieren:

        [[Datei:FG-100D Airflow.pdf]]
        [[Datei:FG-200D Airflow.pdf]]
        [[Datei:FG-300C Airflow.pdf]]
        [[Datei:FG-600C_800C Airflow.pdf]]
        [[Datei:FG-1000C Airflow.pdf]]
        [[Datei:FG-1500D Airflow.pdf]]
        [[Datei:Fg-3700D Airflow.pdf]]

Weitere Informationen betreffend Hardware Airflow für Fortinet Produkte finde man über folgenden Link:

        [[Fortinet:ProduktInfo#Fortinet_Hardware_Airflow]]

=== Wie kann ich unter FortiOS 5.4 die verschiedenen Hardware Informationen eines FortiGate Devices anzeigen lassen? ===

Um die detaillierten Hardware Informationen auf einem FortiGate Device aufzulisten steht der folgende Befehl zur Verfügung:

        # get hardware [cpu | memory | nic | npu | status]

Somit kann anhand der Optionen folgendes ausgeführt werden:

        # get hardware cpu
        Processor       : ARMid(wb) rev 1 (v4l)
        model name      : FortiSOC2
        BogoMIPS        : 799.53
        Features        : swp half thumb 
        
        Hardware        : FSoC2_ASIC
        Revision        : 0000
        Serial          : 0000000000000000
        Imp: 0x66 Arch: 0x5 Part: 0x726 Ver: 0x1
        Ctype: 14 DSize: 6 DASS: 8 DLEN: 32 ISize: 6 IASS: 8 ILEN: 32
        Seperated TLB: Associativity 0
        0x0005317f HUM: En Vec Base:0xffff0000 IC:En BP:Dis RomP:Dis
        SysP:En WB:En DC: En Align:En
        0x00000000 SB: Dis DB:Dis RS:Dis

        # get hardware memory
                total:    used:    free:  shared: buffers:  cached: shm:
        Mem:  1928364032 437944320 1490419712        0  2940928 154861568 140664832
        Swap:        0        0        0
        MemTotal:      1883168 kB
        MemFree:       1455488 kB
        MemShared:           0 kB
        Buffers:          2872 kB
        Cached:         151232 kB
        SwapCached:          0 kB
        Active:          74368 kB
        Inactive:        79864 kB
        HighTotal:           0 kB
        HighFree:            0 kB
        LowTotal:      1883168 kB
        LowFree:       1455488 kB
        SwapTotal:           0 kB
        SwapFree:            0 kB
         
        '''NOTE''' Weitere Befehle um detaillierte Informationen über die Memory Benutzung zu erhalten siehe nachfolgenden Artikel:
             
             [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_die_Memory_Benutzung_eines_FortiGate_Devices_anzeigen_lassen.3F]]

        # get hardware nic
        The following NICs are available:
                dmz
                internal1
                internal2
                internal3
                internal4
                internal5
                internal6
                internal7
                wan1
                wan2
        
        '''NOTE''' Um detaillierte Informationen über ein spezifisches Interface zu erhalten benütze folgenden Befehl:
             
             # get hardware nic [Name des Interfaces zB "dmz "]
             Driver Name     :Fortinet NP4Lite Driver
             Version         :1.0.0
             Admin           :up
             Current_HWaddr   08:5b:0e:47:db:57
             Permanent_HWaddr 08:5b:0e:47:db:57
             Status          :up
             Speed           :100
             Duplex          :Half
             Host Rx Pkts    :480560
             Host Rx Bytes   :104351252
             Host Tx Pkts    :468353
             Host Tx Bytes   :83937534
             Rx Pkts         :480558
             Rx Bytes        :111078750
             Tx Pkts         :468351
             Tx Bytes        :80501362
             rx_buffer_len   :2048
             Hidden          :No
             cmd_in_list     : 0
             promiscuous     : 1
             enabled 802.1x  : 0
             authorized      : 0
             mac bypass      : 0

        # get hardware npu 
        legacy    legacy
        np1       np1
        np2       np2
        np4       np4
        
        '''NOTE''' Dieser Output wird nur angezeigt sofern der entsprechende Device auf dem dieser Befehl ausgeführt wird auch einen 
             "NPU" (Networking Processing Unit) beinhaltet. Wenn es sich um einen Device mit integrierten NPU handelt dh. SoC 
             wird kein Output geliefert.

=== Was bedeuten die verschiedenen LED's Stati über die ein FortiGate Device am FrontPanel verfügt? ===

Ein FortiGate Device verfügt am FrontPanel über verschiedene LED's dh. zB High Availability, Power, Status usw. Diese können verschiedenen Stati anzeigen. Die Bedeutung der verschiedenen LED's sind im nachfolgenden Dokument anhand einer FG-30E, FG-60C sowie FG-100D beschrieben:

        [[Datei:FortiGate_LED_Specs.pdf]]

== Disk ==

=== Wie kann ich auf einer FortiGate die auf der Disk enthaltenen Daten (inkl. Boot Device) vollumfänglich (low level) löschen? ===

Ab FortiOS 5.0.5 gibt es die Möglichkeit die "Disk" (Internal) und/oder den "System Boot Device" über "low level" zu formatieren. Dies ist dann Wichtig wenn ein Device entsorgt wird oder dem Hersteller im RMA Fall zurückgesendet werden soll um so zu gewährleisen, dass sämtliche enthaltenen Daten auf der Disk gelöscht werden sollen. Bei der "low level" Formatierung werden die Spuren und Sektoren der "Disk" resp. des "System Boot Device's" mit zufälligen Daten 3 X überschrieben um so zu gewährleisten das die vorhandenen Daten komplett gelöscht werden. Ab FortiOS 5.0.5 steht für diesn Vorgang folgender Befehl zur Verfügung:

        # execute erase-disk [SYSTEM | Internal]

Wenn ein Device aus Gründen der "Security Gründen" bei einem RMA Austausch nicht dem Hersteller zurückgesendet werden kann obwohl die Möglichkeit einer "low level" Formatierung zur Verfügung steht bietet Fortinet innerhalb des "FortiCare" einen speziellen Vertrag an der es ermöglicht bei einem RMA Austausch den Device selber zu entsorgen anstelle diesen dem Hersteller zurück zu senden. Dieser Service wird "FortiCare RMA Secure Service" genannt. Weitere Informationen dazu siehe nachfolgenden Artikel:

        [[Fortinet:Support-RMA#Gibt_es_von_Fortinet_einen_.22FortiCare_Secure_RMA_Service.22.3F]]

=== Wie kann ich die Disk (Flash, SSD) eines FortiGate Device testen um zu überprüfen ob diese Fehler enthält? ===

Anhand des Befehls "diagnose disktest" kann auf einer FortiGate ab FortiOS 5.2.1 die Disk getestet werden. Dazu sollte berücksichtigt werden, dass dieser Test in einem Maitenance Fenster durchgeführt wird und nicht bei hoher Last. Um diesen Test zu benutzen muss anhand des Befehls zuerst die entsprechende Disk gewählt werden. Um die Disk's aufzulisten benutze folgenden Befehl:

        '''NOTE''' Der Test kann seine Zeit dauern dh. bei einer 60D ohne zusätzlichen Optionen dh. no Limit läuft der Test für 
             7728M ca 45 Minuten! Dies gilt für "Round 1" denn sobald diese beendet ist beginnt der Test erneut dh. "Round 2".
             Der Test kann anhand "Ctrl + C" abgebrochen werden. Wenn dies durchgeführt wird erscheint folgendes:
            
             "User interrupt! Restoring data back to disk....".

Wie schon erwähnt muss für einen Test die entsprechende Disk zuerst gewählt werden. Daraus ergiebt sich folgendes Vorgehen:

        '''Liste die vorhandenen Device's auf:'''
        
        # diagnose disktest device ?
        1    /dev/sda, size 3864MB, boot device
        2    /dev/sdb, size 7728MB

        '''Selektieren die gewünschte Disk zB /dev/sdb dh. "2":'''
        
        # diagnose disktest device 2
        Current Test Device: /dev/sdb

        '''Setze für den Test verschiedene Optionen dh.:'''
        
        # diagnose disktest [bllock | time | size]
        
        '''NOTE''' Die Optionen haben folgende Bedeutung:
             
             block       Die Blocksize für jede Lese- sowie Schreiboperation.
             time        Die Limite der Testzeit für jeden Zyklus. Standard "keine Limite".
             size        Die Limite der Testgrösse für jeden Zyklus. Standard "keine Limite".

Wenn der gewünschte Device gesetzt/gewählt wurde/ist sowie sofern notwendig die Optionen konfiguriert wurden führe den Test aus:

        # diagnose disktest run
        
        Round 1 started.
        Current Test Device: /dev/sdb
        Total size: 7728M
        Current Test Block: 4M.
        Current Time Limit: No limit
        Current Size Limit: No limit
        Time(Sec)    Size(MB)                                                 Read(MB/s) Write(MB/s)
          0.0        0(0.00%):  ..................................................  15.0   8.6
         76.0      200(2.59%):  ..................................................  15.1   8.9
        150.2      400(5.18%):  ..................................................  15.0   9.0
        224.3      600(7.76%):  ..................................................  15.0   8.9
        298.8      800(10.35%): ..................................................  15.1   8.9
        372.9     1000(12.94%): ..................................................  15.1   9.0
        446.9     1200(15.53%): ..................................................  15.1   9.0
        520.7     1400(18.12%): ..................................................  15.2   9.0
        594.4     1600(20.70%): ..................................................  15.1   9.0
        668.4     1800(23.29%): ..................................................  15.2   9.0
        742.1     2000(25.88%): ..................................................  15.3   9.0
        815.8     2200(28.47%): ..................................................  15.3   9.0
        889.5     2400(31.06%): ..................................................  15.3   8.9
        963.1     2600(33.64%): ..................................................  15.4   9.0
        1036.7    2800(36.23%): ..................................................  15.3   9.0
        1110.3    3000(38.82%): ..................................................  15.3   9.0
        1183.9    3200(41.41%): ..................................................  15.3   9.0
        1257.6    3400(44.00%): ..................................................  15.3   9.0
        1331.2    3600(46.58%): ..................................................  15.3   9.0
        1404.7    3800(49.17%): ..................................................  15.3   9.0
        1478.3    4000(51.76%): ..................................................  15.3   9.0
        1551.9    4200(54.35%): ..................................................  15.2   8.9
        1625.8    4400(56.94%): ..................................................  14.5   8.6
        1702.5    4600(59.52%): ..................................................  15.0   8.8
        1777.3    4800(62.11%): ..................................................  15.2   8.9
        1851.6    5000(64.70%): ..................................................  15.1   8.9
        1925.9    5200(67.29%): ..................................................  15.1   8.9
        2000.3    5400(69.88%): ..................................................  15.1   8.9
        2074.7    5600(72.46%): ..................................................  15.1   8.9
        2148.9    5800(75.05%): ..................................................  15.2   8.9
        2223.2    6000(77.64%): ..................................................  15.2   8.8
        2297.5    6200(80.23%): ..................................................  15.1   8.9
        2371.9    6400(82.82%): ..................................................  15.2   8.9
        2446.2    6600(85.40%): ..................................................  15.1   8.9
        2520.5    6800(87.99%): ..................................................  15.3   8.9
        2594.6    7000(90.58%): ..................................................  14.6   8.6
        2671.4    7200(93.17%): ..................................................  15.1   8.4
        2748.0    7400(95.76%): ..................................................  15.3   5.4
        2851.2    7600(98.34%): ................................
        Test Result: Passed
        Tested size: 7728MB (100.00% Coverage of whole disk)
        Time used: 2901.5 sec
        Read Speed:  15.2MB/s
        Write Speed:   8.7MB/s
        Round 1 Finished!
        
        Round 2 started.
        Current Test Device: /dev/sdb
        Total size: 7728M
        Current Test Block: 4M.
        Current Time Limit: No limit
        Current Size Limit: No limit
        Time(Sec)    Size(MB)                                                 Read(MB/s) Write(MB/s)
          0.0        0(0.00%):  ..................................................  14.7   8.4
         77.9      200(2.59%):  .............User interrupt! Restoring data back to disk...
        
        Test Result: Interrupted
        Tested size: 256MB (3.31% Coverage of whole disk)
        Time used:  99.3 sec
        Read Speed:  14.7MB/s
        Write Speed:   8.4MB/s
        Round 2 Finished!

=== Wird bei einem "unclean shutdown" auf einem FortiGate Device beim Systemstart ein "filesystem check" durchgeführt? ===

Ab der Version 5.2.x wurde diese Funktion integriert sowie zusätzlich die Möglichkeit die Disk explizit manuell zu testen. Weitere Informationen wie man einen "expliziten" Disk Test Manuell ausführt siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_die_Disk_.28Flash.2C_SSD.29_eines_FortiGate_Device_testen_um_zu_.C3.BCberpr.C3.BCfen_ob_diese_Fehler_enth.C3.A4lt.3F]]

Wie erwähnt wurde für ein "unclean shutdown" (zB Stromunterbruch) im FortiOS 5.2.x die Funktion eingebaut, dass nach einem "unclean shutdwown" während dem Start Prozess dies erkannt wird und automatisch ein "filesystem check" ausgeführt wird. Diese wird "nicht" anhand eines "expliziten" Disk Tst aufgeführt sondern ähnelt einem "fsck" das auf einem Linux System ausgeführt wird. In diesem Vorgang wird durch das System bemerkt das ein "unclean shutdown" stattgefunden hat. Dies wird ebenfalls indiziert in dem beim Start auf der Console folgendes erscheint:

        System is starting...
        Starting system maintenance...
        scanning /dev/sda2... (100%)

In vorhergehenden Versionen des FortiOS dh. zB 5.0 wurde dieser "filesystem check" beim Start des Devices durchgeführt. Solch ein "filesystem check" kann einige Zeit in Anspruch nehmen und deshalb wurde die Vorgehensweise ab der FortiOS Version 5.2.3 geändert. Dies bedeutet: Wenn ein "unclean shutdown" stattfindet ab FortiOS Version 5.2.3 wird kein "filesystem check" mehr direkt beim Neustart des Device ausgeführt sondern nur ein "system maintenace" indiziert. Sobald sich der Administrator auf dem Web Mgmt. Interface einloggt wird ein entsprechender Dialog angezeigt der durch den "unclean shutdown" ausgelöst wurde:

        [[Datei:Fortinet-1609.jpg]]

Durch diesen Dialog hat der Administrator die Möglichkeit den "filesystem check" auszuführen oder diesen auf einen späteren Zeitpunkt zu verschieben. Wird der "filesystem check" nach dem einloggen des Administrators ausgeführt so wird ein Neustart des Devices ausgeführt und dieser "filesystem check" beim Neustart ausgeführt. Wie schon erwähnt kann dieser "filesystem check" durchaus mehrere Minuten in Anspruch nehmen und der Vorgang sollte auf keinen Fall unterbrochen werden! Wird diese "filesystem check" Meldung beim einloggen auf das Web Mgmt. Interface anhand "Remind me later" auf einen späteren Zeitpunkt verschoben, wird die Meldung nach jedem Einloggen angezeigt bis dieser "filesystem check" ausgeführt wird!

== PowerSupply ==

=== Kann man für FortiGate's seperate Spare und/oder Redundante PowerSupply (RPS) beziehen? ===

Für die verschiedenen FortiGate Devices stellt Fortinet seperate "PowerSupplies" zur Verfügung. Für die grösseren Devices stehen zusätzlich für die Redundanz ebenfalls "RPS Devices" (Redundand PowerSupply) zur Verfügung. Welche Geräte kompatible sind zu den seperaten "RPS Devices" siehe nachfolgender Artikel:

        [[Fortinet:ProduktInfo#FortiRPS]]

Nachfolgende Tabelle zeigt für welchen FortiGate Device welches sperate zu beziehende "PowerSupply" bestellt werden kann:

        [[Datei:Fortinet-1081.jpg]]
        [[Datei:Fortinet-1082.jpg]]

Nachfolgend einige erfasste ALSO Schweiz Artikel betreffend "PowerSupply":

        '''ALSO Art Nr.'''    '''Hersteller SKU'''          '''Beschreibung'''
        16503530H       SP-FG20C-PA-EU          AC power adaptor with EU power plug for FG/FWF-20C series, FG/FWF-30D
        16502510H       SP-FG80-PDC             AC power adaptor - AC power adaptor for FG/FWF-80C/CM
        16501668H       SP-FG60C-PDC            AC power adaptor - AC power adaptor for FG/FWF-40C, FG/FWF-60C, FG/FWF-60D, FG-70D, FG/FWF-90D
        16502889H       SP-FG600C-PS            AC power supply - AC power supply for FG-600C, FG-600D, FG-800C, and FG-1000C
        16505060H       SP-FG1240B-PS           AC power supply - AC power supply for FG-1200D, FG-1240B, FG-1500D, FG-3040B and FG-3140B

Ebenso stehen für die FortiAP sowie FortiAP-S "PowerSupplies" zur Verfügung. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiAP:FAQ#Wo_finde_ich_eine_Uebersicht_ob_ein_FortiAP_mit_PowerAdapter_geliefert_wird_oder_PoE_unterst.C3.BCtzt.3F]] 
        [[FortiAP-S:FAQ#Wo_finde_ich_eine_Uebersicht_ob_ein_FortiAP-S_mit_PowerAdapter_geliefert_wird_oder_PoE_unterst.C3.BCtzt.3F]]
== SFP Ports ==

=== Kann ich für die SFP Ports auf einer FortiGate ebenfalls Fremdprodukte wie Cisco oder Huawai einsetzen? ===

Dies ist möglich jedoch ausgiebig vorgängig zu testen! Von unserer Seite her haben wir Tests sowie Feedback das folgende Transceiver einwandfrei funktionieren:

        '''Copper GigaBit 10/100/1000'''
        
        GLC-T=746320861579     Cisco Catalyst GigaEthernet SFP Modul 1000Base T
        02314171               Huawayi Electrical Transceiver SFP Module 1000Base T
        
        '''NOTE''' Durch Fortinet werden ebenfalls nicht eigenen Transceiver eingesetzt sondern von Fremdherstellern dh. wird ein Transceiver 
             über Fortinet bestellt, wird ein Transceiver zB von Huaway geliefert! Weitere Informationen betreffend "offizielle" SFP/SFP+ 
             Module von Fortinet sowie den Gebrauch von "nicht offiziellen" siehe folgender Artikel:
             
             [[FortiGate-5.4:FAQ#Kann_ich_f.C3.BCr_die_SFP_Ports_auf_einer_FortiGate_ebenfalls_Fremdprodukte_wie_Cisco_oder_Huawai_einsetzen.3F]]

=== Welche FortiGate Device's unterstützen SFP's und bei welchen FortiGate Devices werden SFP's mitgeliefert? ===

Nachfolgende Tabelle zeigt welche FortiGate Devices wieviele SFP's unterstützen und bei welchem FortiGate Device bereits SFP Module mitgeliefert werden:

        '''NOTE''' NIL = Not Included!
        
        [[Datei:Fortinet-1085.jpg]]
        [[Datei:Fortinet-1086.jpg]]
        [[Datei:Fortinet-2075.jpg]]

Es können für die FortiGate Devices auch Fremdprodukte als SFP's eingesetzt werden jedoch gibt es keine Gewährleistung das diese einwandfrei funktionieren. Weitere Infos siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Kann_ich_f.C3.BCr_die_SFP_Ports_auf_einer_FortiGate_ebenfalls_Fremdprodukte_wie_Cisco_oder_Huawai_einsetzen.3F]])
        
        '''NOTE''' Desweiteren ist nachfolgendes Dokument zu beachten, wenn keine "offiziellen" Tranceiver von Fortinet eingesetzt
             werden (speziell Seite 2 "3rd Party Transceivers Support"):
             
             [[Datei:Tech_Note-Transceivers_FAQs-201407-R3.pdf]] 

Basierend auf den "offiziellen" Tranceiver von Fortinet gemäss Preisliste stehen folgende SFP/SFP+ Module zur Verfügung:

        Transceiver '''LX, Long Range'''; all FortiGate models with SFP interfaces                                              ALSO SKU 16500426H  (Hersteller SKU FG-TRAN-LX)
        Transceiver '''SX, Short Range'''; all FortiGate models with SFP interfaces                                             ALSO SKU 16500428H  (Hersteller SKU FG-TRAN-SX)
        Transceiver '''Base-T''' (Copper); all FortiGate models with SFP interfaces (supports 10/100/1000)                      ALSO SKU 16500427H  (Hersteller SKU FG-TRAN-GC)
        
        10-Gig transceiver, '''short range SFP+'''; all FortiGate models with SFP+ interfaces                                   ALSO SKU 16500429H  (Hersteller SKU FG-TRAN-SFP+SR)
        10-Gig transceiver, '''short range XFP'''; all FortiGate models with XFP interfaces                                     ALSO SKU 16500430H  (Hersteller SKU FG-TRAN-XFPSR)
        10-Gig transceiver, '''SFP+, Long Range'''; all FortiGate models with SFP+ interfaces                                   ALSO SKU 16500431H  (Hersteller SKU FG-TRAN-SFP+LR)
        10-Gig transceiver, '''XFP, Long Range'''; all FortiGate models with XFP interfaces                                     ALSO SKU 16500432H  (Hersteller SKU FG-TRAN-XFPLR)
        
        40-Gig transceiver, '''QSFP+, short range'''; all FortiGate models with QSFP+ interfaces                                ALSO SKU auf Anfrage (Hersteller SKU FG-TRAN-QSFP+SR)
        40-Gig transceiver, '''QSFP+, long range'''; all FortiGate models with QSFP+ interfaces                                 ALSO SKU auf Anfrage (Hersteller SKU FG-TRAN-QSFP+LR)
        
        100-Gig transceiver, '''CFP2, short Range'''; all FortiGate models with CFP2 interfaces (10 Channel parallel fiber)     ALSO SKU auf Anfrage (Hersteller SKU FG-TRAN-CFP2-SR10)
        100-Gig transceiver, '''CFP2, long Range'''; all FortiGate models with CFP2 interfaces (only singlemode)                ALSO SKU auf Anfrage (Hersteller SKU FG-TRAN-CFP2-LR4)
        

Für eine direkte Verbindung zweier Fortigates über ein "direct attach cable" steht folgender Artikel zu Verfügung:
        
        10-Gig transceiver, '''SFP+, 10m direct attach cable'''; all FortiGate models with SFP+ and SFP/SFP+ interfaces         ALSO SKU auf Anfrage (Hersteller SKU SP-Cable-ADASFP+)      

Eine detaillierte Beschreibung der Tranceivereigenschaften befindet sich im folgenden Dokument:
        
        [[Datei:TRAN-DAT-R2-201503_web.pdf]]

=== Was sind die genauen Spezifikationen der SFP's Module die von Fortinet für die FortiGate Devices geliefert werden? ===

Im nachfolgenden Artikel wird beschrieben ob ein SFP/SFP+ Module zu einer FortiGate mitgeliefert wird und welche SFP/SFP+ Module offiziell für die FortiGate's zur Verfügung stehen:

        [[FortiGate-5.4:FAQ#Welche_FortiGate_Device.27s_unterst.C3.BCtzen_SFP.27s_und_bei_welchen_FortiGate_Devices_werden_SFP.27s_mitgeliefert.3F]]

In der nachfolgenden Tabelle werden die technischen Spezifikationen aufgelistet der SFP Module die von Fortinet für die FortiGate Devices geliefert werden:

        [[Datei:Fortinet-1087.jpg]]

        '''NOTE''' Die Informationen stammen aus einem Fortinet "Knowledgebase Artikel" und über diesen sind weitere Informationen verfügbar:
             
             http://kb.fortinet.com/kb/dynamickc.do?cmd=show&forward=nonthreadedKC&docType=kc&externalId=13823&sliceId=1

        [[Datei:Fortinet-1129.jpg]]

Nachfolgend das offizielle "Regulatory Compliance Document" betreffend SFP SX Transceiver:

        Regulatory Doc   [[Datei:Regulatory-Compliance-Document_FG-TRAN-SX_Rev_1.03.pdf]]
        Regulatory Doc   [[Datei:Regulatory-Compliance-Document_FG-TRAN-CFP2-LR4_Rev_1.00.pdf]]
        Regulatory Doc   [[Datei:Regulatory-Compliance-Document_FG-TRAN-CFP2-SR10_Rev_1.00.pdf]]

== ASIC ==

=== Was bedeutet es wenn ein FortiGate Device über eine "Hardware Acceleration für Netzwerk Ports (NP)" verfügt? ===

Wen ein Device den Traffic mit "Stateful Inspection" verarbeitet versteht man folgendes darunter: Die TCP oder UDP Headers eines Packets werden im OSI-Modell auf den Schichten drei (Netzwerklayer) und vier (Transportlayer) angeschaut. Die Verarbeitung soll nicht von Grösse oder Aufkommen des Traffics abhängig sein. Genau diese Anforderung kann aber bei verschiedenen Firewall Modellen ein Problem darstellen. Diese haben Probleme, wenn sehr viele kleine Packete verarbeitet werden müssen, weil dadurch die CPU Auslastung enorm ansteigt. Der Grund ist, dass sehr viele Headers analysiert werden müssen (Pro Packet ein Header). Das wiederum bedeutet: die Verarbeitung ist nicht von der Grösse der Packete Abhängig, sondern durch die Menge der Packete. Die "Hardware Acceleration" löst genau dieses Problem. Damit die Verarbeitung der Headers in den Schichten drei und vier im OSI-Modell beschleunigt verarbeitet werden kann, wurde der "application-specific-integraded circuit (ASIC) gebaut. Die Verarbeitung "Hardware Acceleration" wird auf den Ports durchgeführt (NP). So wird die Auslastung unabhängig von Grösse oder Menge der Packete verteilt und so wird gewährleistet, dass die Performance sensitiver Services kontinuierlich ihren Durchsatz halten können. Fortinet ist der einzige Hersteller, welcher diese ASIC Technologie auf ihren Devices integriert und ständig weiterentwickelt. Ausführliche Informationen über die ASIC Technologie findet man unter folgendem Link:

        http://de.wikipedia.org/wiki/Anwendungsspezifische_integrierte_Schaltung

Der Hauptpunkt dieser von Fortinet eingesetzten Technologie ist die Verwendung des ASIC und dessen NP "Hardware Accelerated Network Ports" um die CPU zu entlasten. Daher ist es wichtig bei solchen Devices die entsprechenden Ports richtig zu verwenden. Dies bedeutet: Für zB "synch" und/oder "mgmt" Interfaces sollten keine Ports benützt werden die über "Hardware Acceleration" verfügen da für "synch" und/oder "mgmt" Ports ohne "Hardware Acceleration" völlig ausreichend ist. Somit sollten die "Hardware Accelerated" Ports für Services oder Kommunikation genutzt werden die kontinuierliche Performance gewährleisten. Im Enterprise Bereich ist zusätzlich zu berücksichtigen, dass  verschiedenen Versionen des ASIC für spezifische Aufgaben optimiert wurden zB für IPS oder Antivirus. Eine FortiGate-100D zum Beispiel verfügt über einen ASIC, welcher extra für den IPS Bereich optimiert wurde. Die FG-100D kann somit speziell in diesem Bereich einen markant höheren Datendurchsatz erzielen, gegenüber anderen Devices. Weitere Informationen zu den einzelnen Angaben des Durchsatzes der UTM Features siehe nachfolgender Artikel:

        [[Fortinet:ProduktInfo#Fortinet_Produkt-Matrix]]

Nachfolgend ein Dokument das bildlich die Architektur der FortiGate aufzeigt:

        [[Datei:FortiASIC_TB.pdf]]

Im folgendem Dokument erklärt Fortinet wie die Hardware Acceleration funktioniert und geht auf die einzelnen Funktionen im Detail ein:

        [[Datei:fortigate-hardware-accel-54.pdf]]

== FortiOS ==

=== Welche FortiGate Devices werden vom neuen FortiOS 5.4 unterstützt resp. können anhand eines Upgrades aktualisiert werden? ===

Das neue FortiOS 5.4 Unterstützt wie nachfolgend abgebildet folgende FortiGate Devices:

        [[Datei:Fortinet-1608.jpg]]

Dies bedeutet: Nur die hier unter der Spalte "5.4" aufgeführten FortiGate Devices unterstützen FortiOS 5.4 und können somit auch anhand eines Upgrades auf FortiOS 5.4 aktualisiert werden!

=== Wie finde ich heraus ob eine bestimmte Konfiguration unter FortiOS 5.4 auf einem FortiGate Device möglich ist? ===

Wenn für einen Kunden der richtige FortiGate Device beschafft werden soll, ist es Wichtig den richtigen FortiGate Device auszuwählen. Dabei spielen in erster Linie der "throughput" ein grosse Rolle. Dieser hängt von verschiedenen Faktoren ab wie Internet Anbindung, UTM Funktionen usw. Nachfolgender Artikel gibt Auskunft über dieses Thema:

        [[FortiGate-5.4:FAQ#Was_f.C3.BCr_FortiGate_Devices_stehen_in_den_verschiedenen_Verf.C3.BCgung_und_welche_ist_die_Richtige.3F]]

Obwohl die Performance (throughput) an erster Stelle steht, stellt sich die Frage ob alle zur Verfügung stehenden Funktionen auf einem FortiOS 5.4 auf allen Devices durchgeführt werden können? Grundsätzlich stehen auf allen Devices alle FortiOS 5.4 Funktionen zur Verfügung jedoch auf kleineren Modellen sind diese aus verschiedenen Gründen limitiert oder stehen gänzlich nicht zur Verfügung. Die "Software Matrix" gibt Auskunft ob und welchen Funktionen auf einem FortiGate Device zur Verfügung stehen wie zB das "disk" Logging:

        [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]

Wenn die entsprechende FortiOS Funktion auf einem FortiGate Device zur Verfügung steht, ist jedoch dabei zu beachten, dass diese ebenfalls speziell bei kleineren Devices limitiert ist. Dies bedeutet als Beispiel: Auf allen FortiGate Devices können DHCP Server konfiguriert werden jedoch die Anzahl der DHCP Server sind speziell auf kleineren Devices limitiert. Die Information "max_values" gibt Auskunft welche Funktion eines FortiOS resp. welche Konfiguration in welcher Anzahl durchgeführt werden kann. Diese Limitierung ist eine reine "System Resourcen" Limitierung dh. auf kleineren Devices stehen weniger "System Resourcen" zur Verfügung um eine anzahl Konfiguration durchzuführen dh. zB DHCP Server. Auf einem entsprechenden FortiGate Device kann die "max_values" anhand folgenden CLI Kommandos ausgelesen werden:

        # print tablesize

Nachfolgend ein Beispiel des "output" einer FortiGate 60D:

        [[Datei:print-tablesize.txt]]

Zusätzlich stellt Fortinet diese Informationen der "max_values" anhand einer Tabelle Online sowie in einem Dokument zur Verfügung das jedoch Stand 6. Januar noch nicht zur Verfügung steht. Sobald diese Informationen durch Fortinet zur Verfügung stehen werden diese Informationen hier zur Verfügung gestellt!

=== Wie wird ein Packet unter FortiOS 5.4 auf einem FortiGate Device abgearbeitet (Life of a Packet)? ===

Wenn mit FortiOS resp. mit einer FortiGate gearbeitet wird ist es umungänglich zu wissen wie ein Packet durch das FortiOS 5.4 abgearbeitet wird. Dies bedeutet zB Wird ein Routing vor NAT durchgeführt, wann wird eine UTM Funktion angewendet usw. Nachfolgende Uebersicht zeigt wie ein Packet durch das FortiOS abgearbeitet wird sofern kein "Offloading" durchgeführt wird:

        [[Datei:Fortinet-1637.jpg]]
        
        '''NOTE''' Den Hinweis "ingress" sowie "engress" ist folgendermassen zu verstehen: "ingress" umschreibt den Vorgang was mit einem Packet 
             durchgeführt wird wenn es über ein Interface dem FortiOS übermittelt wird (TCP/IP Stack). "engress" umschreibt was mit einem
             Packet durchgeführt wird wenn ein Packet durch das FortiOS über ein Interface versendet wird!

Wenn ein Packet durch das FortiOS anhand "Offloading" abgearbeitet wird zB anhand NP6 Prozessor ist zu unterscheiden zwischen einer "neuen Session" und einer "bestehenden Session"

        '''<big>New Session</big>'''
        
        [[Datei:Fortinet-1638.jpg]]

        '''<big>Existing Session</big>'''
        
        [[Datei:Fortinet-1639.jpg]]

Die vorhegehenden Uebersichten zeigen innerhalb "UTM/NGFW" keine Details betreffend "inspection" Mode dh. wie ein Packet abgearbeitet wird im "proxy-mode" oder im "flow-mode". Dabei ist zu berücksichtigen, dass nicht jedes UTM Feature zB "Application Control" im "proxy-mode" benutzt werden kann sondern nur im "flow-mode". Weitere Informationen zum "inspection" mode unter FortiOS 5.4 siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Was_hat_sich_unter_FortiOS_5.4_betreffend_.22Security_Profiles.22_und_.22Inspection_Mode.22_grunds.C3.A4tzlich_ge.C3.A4ndert.3F]]

Nachfolgend eine Uebersicht was innerhalb der "UTM/NGFW" Funktion betreffend dieser zwei zur Verfügung stehenden "inspection" Mode durchgeführt wird:

        '''<big>Flow Based Inspection</big>'''
        
        [[Datei:Fortinet-1640.jpg]]

        '''<big>Proxy Based Inspection</big>'''
        
        [[Datei:Fortinet-1641.jpg]]

Weitere Details zu den verschiedenen Uebersichten findet man im folgenden Dokument:

        [[Datei:Fortigate-Optimal-Life-54.pdf]]

=== Welche Open Ports werden unter FortiOS 5.4 auf einem FortiGate Device per Standard benutzt? ===

Wenn ein FortiGate Device unter FortiOS 5.4 sich im Factory Reset Zustand befindet so werden verschiedenen TCP/UDP Ports durch das FortiOS für die verschiedenen Funktionen zur Verfügung gestellt um die Funktionen bereitszustellen. Nachfolgende Uebersicht zeigt diese TCP/UDP Ports. Es ist dabei folgendes zu berücksichtigen: Diese abgebildeten TCP/UDP Ports werden durch ein FortiOS 5.4 nicht per Standard zur Verfügung gestellt und sind ersichtlich. Viele dieser TCP/UDP Ports sind nur dann ersichtlich wenn die entsprechende Funktion genutzt wird:

        [[Datei:Fortinet-2044.jpg]]

== FortiGuard (FDDS) ==

=== Wie konfiguriere ich unter FortiOS 5.4 die "autoupdate" Funktion für UTM Databases? ===

Die verschiedenen lokalen Databases für die UTM Features wie zB Antivirus werden über den FortiGuard Service und Server (FDDS) auf den neusten Stand gehalten. Dabei ist die "autoupdate" Funktion für alle lokalen Databases zuständig dh. dass diese auf den neusten Stand gehalten werden. Die lokalen Databases umfassen folgende Funktionen:

        • AV Engine
        • Virus Definition
        • Extended set
        • Mobile Malware Definition
        • Attack Definitions
        • Attack Extended Definitions
        • IPS Malicious URL Database
        • Flow-based Virus Definition
        • Botnet Definitions
        • IPS Attack Engine
        • Internet-service Database Apps
        • Internet-service Database Maps
        • Botnet Domain Database
        • Vulnerability Compliance and Management
        • Modem List
        • Device and OS Identification
        • IP Geography DB
        • Certificate Bundle
        • FDS Address
        • URL White list

Die Grundvoraussetzung damit diese Databases auf den neusten Stand gebracht werden, ist eine einwandfreie Verbindung zum FortiGuard Service. Dabei ist wiederum eine Grundvoraussetzung einwandfrei funktionierende DNS Server für die DNS Auflösung der FortiGuard Server (FDDS) sowie die Erreichbarkeit über den konfigurierten FortiGuard Service Port. Die System DNS eines FortiOS kann über Mgmt. Web Interface sowie über CLI konfiguriert werden. Weitere Informationen dazu wie die System DNS unter FortiOS konfiguriert werden, siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_unter_FortiOS_5.4_auf_einer_FortiGate_die_System_DNS_Server.3F]]

        Network > DNS > Specify

Der FortiGuard Service Port ist per Standard auf Port 53 gesetzt was wiederum dem DNS Service Port entspricht. Dieser standard Port des FortiGuard Service sollte in jedem Fall auf Port 8888 umkonfiguriert werden da die Gefahr besteht, dass durch ein ISP Monitoring auf dem Port 53 der Traffic geblockt wird da es sich nicht um korrekten DNS Traffic auf Port 53 handelt sondern um "encapsulated" HTTPS Traffic. Um den FortiGuard Service Port umzukonfigurieren kann im Mgmt. Web Interface folgende Position gwählt werden:

        System > FortiGuard > FortiGuard Filtering Port > [8888 | 53]

Auf CLI kann der FortiGuard Port folgendermassen konfiguriert werden:

        # config system fortiguard
        # set port [53 | 8888 | 80]
        # end

Wenn die System DNS Server sowie der Service Port korrekt konfiguriert wurden, wird automatisch im Hintergrund eine Verbindung zum FortiGuard Service erstellt. Die verwendeten FDDS Server des FortiGuard Service können mit folgenden Befehl eingesehen werden:

        # diagnose debug rating
        Locale : english
        License : Contract
        Expiration : Tue Feb 23 08:00:00 2016
        Hostname : service.fortiguard.net
        
        -=- Server List (Tue Feb 23 02:12:28 2016) -=-
        IP Weight       RTT   Flags  TZ    Packets Curr Lost Total Lost
        69.20.236.180    0    10     -5     77200  0          42
        69.20.236.179    0    12     -5     52514  0          34
        66.117.56.42     0    32     -5     34390  0          62
        80.85.69.38     50   164      0     34430  0       11763
        208.91.112.194  81   223      D -8  42530  0        8129
        216.156.209.26 286   241     DI -8  55602  0       21555

Kommt es bei der Verbindung zum FortiGuard Service zu Problemen, kann ein Troubleshooting durchgeführt werden. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[Fortinet:FortiCare-FortiGuard#Die_Registrierung_FortiCare.2FFortiGuard_ist_auf_der_Fortigate_nicht_ersichtlich.2C_was_kann_ich_tun.3F]]

Die "autoupdate" Funktion kann auf einem FortiOS auch manuell erzwungen werden dh. im Gesamten durch folgenden Befehl:

        # execute update-now

Durch diesen Befehl werden alle laufenden Update Prozesse abgebrochen und neu initiert. Es stehen unter CLI auch spezifische Kommandos zur Verfügung um einzelne Database auf den neusten Stand zu bringen. Diese sind die Folgenden:

        # execute update-av                  Update AV engine/definitions
        # execute update-geo-ip              Update IP Geography DB
        # execute update-ips                 Update IPS engine/definitions
        # execute update-list                Download update server list
        # execute update-netscan             Update netscan object
        # execute update-src-ivs             Update src-vis object

Wenn die Databases auf den neusten Stand gebracht wurden, können die einzelnen Informatione der einzelnen Databases über Mgmt. Web Interface eingesehen werden:

        System > FortiGuard

Ueber das Mgmt. Web Interface sind nicht alle Informationen einer Database verfügbar. Detailliertere Informationen der Databases können über CLI abgerufen werden anhand nachfolgenden Befehls:

        # diagnose autoupdate [versions | status | downgrade]

Wenn die Option "status" benutzt wird so wird die aktuelle Konfiguration der "autoupdate" Funktion ausgegeben:

        # diagnose autoupdate status
        FDN availability: Tue Feb 23 16:25:33 2016
        
        Push update: disable
        Scheduled update: enable
                Update every:   6 hours at 0 minutes after the hour
        Virus definitions update: enable
        IPS definitions update: enable
        Push address override: disable
        Web proxy tunneling: disable

Durch die Option "versions" werden detaillierte Informationen aufgelistet für die einzelnen Databases. Weitere Informationen dazu siehe auch nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_die_Versions_Informationen_.C3.BCberpr.C3.BCfen.3F]]

Durch die Option "downgrade" und durch Aktivierung sowie Deaktivierung wird ermöglicht auf einer Database ein "Downgrade" durchzuführen. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_ein_Downgrade_durchf.C3.BChren.3F]]

Die "autoupdate" Funktion die anhand "diagnose autoupdate status" ausgegeben wird, ist per Standard ab FortiOS 5.2.4 auf 2 Stunden konfiguriert dh. alle 2 Stunden wird ein "autoupdate" für alle Databases durchgeführt. Diese Konfiguration kann über Mgmt. Web Interface unter folgender Position durchgeführt werden:

        System > FortiGuard > Antivirus & IPS Updates

Auf der CLI stehen zusätzliche Optionen zur Verfügung:

        # config system.autoupdate schedule
        # set status [enable | disable]
        # set frequency [every | daily | weekly; Standard every]
        # set time [Stunde/Minuten für Update Time; Standard 02:60]
        # set day [Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday]
        # end

Durch "every" und "02:60" wird somit alle 2 Stunden ein "autoupdate" der Database für die UTM Features ausgeführt. Zusätzlich kann ein "push-update" konfiguriert werden. Dies bedeutet folgendes: Obwohl ein "autoupdate" alle 2 Stunden ausgeführt wird, benachrichtigt der FortiGuard Service die "autoupdate" Funktion durch "push-udpate", dass neue Informationen für eine Database zur Verfügung stehen um diese runterzuladen. Durch diese "push-update" Information wird auf dem FortiOS ein "autoupdate" durchgeführt für die neuen Informationen, die auf FortiGuard zur Verfügung stehen. Auf dem Mgmt. Web Interface kann ein "push-update" über folgende Position konfiguriert werden:

        System > FortiGuard

        [[Datei:Fortinet-2043.jpg]]

Bei der Position "Use override push" mit der Angabe einer entsprechender "IPv4 Adresse" sowie eines TCP Ports (Standard 9443) kann ein "push-update" auf eine IPv4 Adresse sowie TCP Port eingeschränkt werden. Auf CLI wird die entsprechende Konfiguration folgendermassen durchgeführt:

        # config system.autoupdate push-update
        # set status [enable | disable]
        # set override [enable | disable]
        # set address [IPv4 Adresse des "push-update" Servers; Standard "any"]
        # set port [TCP Port des "push-update" Servers; Standard "9443"]
        # end

Die Komunikation der "push-update" Funktion ist somit eine eingehende Verbindung was durch das nachfolgende Open Ports Diagramm bestätigt wird:

        [[Datei:Fortinet-2045.jpg]]

Zusätzlich stehen über das Mgmt. Web Interface die Positionen "Improve IPS quality" sowie "Use extended IPS signature package" zur Verfügung. Durch die Position "Improve
IPS quality" werden lokale IPS Informationen zum FortiGuard Service von Fortinet übermittelt um die Qualität der IPS Signaturen Informationen zu erhöhen. Durch "Use
extended IPS signature package" werden zur "regular" Database betreffend IPS (ca. 6000 Signaturen) die "extended" Informationen (ca. 8000) geladen. Diese Konfiguration kann ebenfalls
über CLI durchgeführt werden:

        # config ips global
        # set database [regular | extended]
        # set traffic-submit [enable | disable]
        # end

=== Wie kann ich unter FortiOS 5.4 für die einzelnen UTM Databases die Versions Informationen überprüfen? ===

Auf einer FortiGate existieren etliche UTM Databases für die verschiedenen Funktionen wie IPS, Antivirus, GeoIP, Certification List usw. Diese werden 
laufend durch das FortiOS 5.4 und durch die Funktion "autoupdate" auf den neusten Stand gehalten. Die aktuelle Konfiguration der Funktion "autoupdate" kann 
folgendermassen abgerufen werden:

        # get system auto-update status
        FDN availability:  unavailable at Tue Jan  5 18:13:39 2016
        
        Push update: disable
        Scheduled update: enable
                Update every:   6 hours at 0 minutes after the hour
        Virus definitions update: enable
        IPS definitions update: enable
        Push address override: disable
        Web proxy tunneling: disable

Weitere Informationen betreffend "autoupdate" Konfiguration siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.4_die_.22autoupdate.22_Funktion_f.C3.BCr_UTM_Databases.3F]]

Ein Update der verschiedenen UTM Databases kann auch manuell ausgeführt werden mit folgenden Befehl:

        # execute update-now

Ebenso stehen folgende Befehle zur Verfügung um spezifische Databases auf den neusten Stand zu bringen:

        # execute update-av                  Update AV engine/definitions
        # execute update-geo-ip              Update IP Geography DB
        # execute update-ips                 Update IPS engine/definitions
        # execute update-list                Download update server list
        # execute update-netscan             Update netscan object
        # execute update-src-ivs             Update src-vis object

Nachdem die UTM Databases auf den neusten Stand gebracht wurden, können die verschiedenen detaillierten Informationen der Databases durch folgende Befehl abgerufen werden:

        # get system auto-update version
        
        AV Engine
        ---------
        Version: 5.00227
        Contract Expiry Date: n/a
        Last Updated using manual update on Tue Dec  8 10:57:00 2015
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Virus Definitions
        ---------
        Version: 16.00560
        Contract Expiry Date: n/a
        Last Updated using manual update on Fri Oct 19 08:31:00 2012
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Extended set
        ---------
        Version: 1.00000
        Contract Expiry Date: n/a
        Last Updated using manual update on Wed Oct 17 15:46:00 2012
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Mobile Malware Definitions
        ---------
        Version: 0.00000
        Contract Expiry Date: n/a
        Last Updated using manual update on Mon Jan  1 00:00:00 2001
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Attack Definitions
        ---------
        Version: 6.00741
        Contract Expiry Date: n/a
        Last Updated using manual update on Tue Dec  1 02:30:00 2015
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Attack Extended Definitions
        ---------
        Version: 0.00000
        Contract Expiry Date: n/a
        Last Updated using manual update on Mon Jan  1 00:00:00 2001
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        IPS Malicious URL Database
        ---------
        Version: 1.00001
        Contract Expiry Date: n/a
        Last Updated using manual update on Thu Jan  1 01:01:00 2015
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Flow-based Virus Definitions
        ---------
        Version: 1.00123
        Contract Expiry Date: n/a
        Last Updated using manual update on Tue Jul 21 14:19:00 2015
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Botnet Definitions
        ---------
        Version: 1.00000
        Contract Expiry Date: n/a
        Last Updated using manual update on Mon May 28 22:51:00 2012
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        IPS Attack Engine
        ---------
        Version: 3.00156
        Contract Expiry Date: n/a
        Last Updated using manual update on Thu Dec 10 13:40:00 2015
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Internet-service Database Apps
        ---------
        Version: 2.00662
        Contract Expiry Date: n/a
        Last Updated using manual update on Tue Nov 17 11:56:00 2015
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Internet-service Database Maps
        ---------
        Version: 0.00000
        Contract Expiry Date: n/a
        Last Updated using manual update on Mon Jan  1 00:00:00 2001
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Botnet Domain Database
        ---------
        Version: 0.00000
        Contract Expiry Date: n/a
        Last Updated using manual update on Mon Jan  1 00:00:00 2001
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        Vulnerability Compliance and Management
        ---------
        Version: 1.00297-L
        Contract Expiry Date: n/a
        Last Updated using manual update on Fri Dec  4 19:31:00 2015
        Last Update Attempt: n/a
        Result: Updates Installed
        
        Modem List
        ---------
        Version: 0.000
        
        Device and OS Identification
        ---------
        Version: 1.00040
        Contract Expiry Date: n/a
        Last Updated using manual update on Tue Jan  5 17:26:00 2016
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed
        
        IP Geography DB
        ---------
        Version: 1.044
        Contract Expiry Date: n/a
        Last Update Date: Wed Dec  2 22:57:32 2015
        
        
        Certificate Bundle
        ---------
        Version: 1.00001
        Last Update Date: Wed Nov  4 16:07:00 2015
        
        
        FDS Address
        ---------
        
        
        
        URL White list
        ---------
        Version: 0.00000
        Contract Expiry Date: n/a
        Last Updated using manual update on Mon Jan  1 00:00:00 2001
        Last Update Attempt: Tue Jan  5 12:33:50 2016
        Result: Updates Installed

=== Wie kann ich unter FortiOS 5.4 für die einzelnen UTM Databases ein Downgrade durchführen? ===

Wenn zB für eine Antivirus Database ein "Dowgrade" durchgeführt werden soll, kann dies über die Option "downgrade" für "autoupdate" aktiviert werden:

        # diagnose autoupdate downgrade [enable | disable]

Danach kann manuell über folgenden Link eine entsprechende Version einer Database runtergeladen werden:

        https://support.fortinet.com/Download/AvNidsDownload.aspx

Nachdem die entsprechende Database Version runtergeladen wurde und da die Option "downgrade" aktiviert wurde, kann über das Mgmt. Web Interface ein "Downgrade" vollzogen werden:

        System > FortiGuard

Da ein "Downgrade" vorübergehender Natur ist sollt die Option "downgrade" nachträglich für ein Update wiederum Deaktiviert werden und ein Update für eine spezifische Database oder Gesamthaft durchgeführt werden:

        # execute update-now                 Update now
        # execute update-av                  Update AV engine/definitions
        # execute update-geo-ip              Update IP Geography DB
        # execute update-ips                 Update IPS engine/definitions
        # execute update-list                Download update server list
        # execute update-netscan             Update netscan object
        # execute update-src-ivs             Update src-vis object

=== Wie kann ich unter FortiOS 5.4 für die "autoupdate" Funktion der UTM Databases einen Explizit Proxy konfigurieren? ===

Ein FortiOS resp. ein FortiGate Device benutzt um deren UTM Databases auf den neusten Stand zu bringen die "autoupdate" Funktion. Weitere Informationen zu dieser "autoupdate" Funktion siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.4_die_.22autoupdate.22_Funktion_f.C3.BCr_UTM_Databases.3F]]

Diese "autoupdate" Funktion benützt keine Explizit Proxy Konfiguration sondern ist Transparent. Dies bedeutet: Soll die "autoupdate" Funktion über einen Explizit Proxy durchgeführt werden so muss dies über CLI konfiguriert werden! Bei dieser Explizit Proxy Konfiguration für "autoupdate" ist folgendes zu berücksichtigen: Der Username und Passwort der benutzt wird um sich beim Explizit Proxy anzumelden ist Optional. Das FortiOS benutzt um sich zum Explizit Proxy zu verbinden die HTTP CONNECT Methode nach RFC 2616. Diese Methode wird im Allgemeinen benutzt um SSL Traffic zu "tunneln". Aus diesem Grund muss auf dem Explizit Proxy kontrolliert werden ob dies erlaubt ist da dieser Vorgang im normal Fall über den Explizit Proxy verhindert wird. Es sollte ebenfalls kontrolliert werden welche Ports freigegeben sind auf dem Explizit Proxy um das Internet zu erreichen. Unter normalen Umständen sofern keine Einschränkungen auf dem Explizit Proxy implementiert sind wären dies die Priviligierten Ports dh. 1-1024. Die FortiOS "autoupdate" Funktion benutzt den Port TCP-8890 was wiederum keinem Priviligierter Port entspricht. Aus diesem Grund muss dieser nicht Priviligierter Port auf dem Explizit Proxy Funktion freigeschaltet werden damit das Fortinet Distribution Network (FDN) erreichbar ist.

        # config system autoupdate tunneling
        # set status [enable | disable]
        # set address [Gebe die entsprechende IPv4 Adresse oder FQDN des Explizit Proxy an]
        # set port [Gebe den entsprechenden Proxy Port an zB "8080"]
        # set username [Optional gebe für die Anmeldung an den Explizit Proxy einen Usernamen an]
        # set password [Gebe für die Anmeldung an den Explizit Proxy sofern ein Username definiert wurde ein entsprechendes Passwort an]
        # end

== FortiCloud ==

=== Wo finde ich Informationen über die Funktion "FortiCloud" und dessen Gebrauch im Zusammenhang mit einem FortiGate Device? ===

Weitere detailliert Informationen zur FortiCloud im Allgemeinen findet man unter folgenden Artikel:

        [[FortiCloud:FAQ]]

== FortiSandbox ==

=== Wo finde ich weitere Informationen zur Funktion sowie Produkt FortiSandbox? ===

Weitere Informationen zur Funktion sowie Produkt FortiSandbox siehe nachfolgender Artikel:

        [[FortiSandbox:FAQ]]

Untenstehende Präsentation enthält eine Live Demo zum Thema Advanced Thread Protection mit FortiSandbox als FortiGate Erweiterung:

        [[Datei:40Minutes-Extending_the_Firewall_with_FortiSandbox-1_0.pptx]]

Das untenstehende Dokument enthält einen Workshop wie man einen FortiMail und eine FortiGate in die FortiSandbox einbindet.

        [[Datei:FortiSandbox-Positioning.pdf]]

== FortiExplorer ==

=== Wo finde ich Informationen über den "FortiExplorer" und dessen Gebrauch im Zusammenhang mit einem FortiGate Device? ===

Weitere detailliert Informationen zum FortiExplorer im Allgemeinen findet man unter folgenden Artikel:

        [[FortiExplorer:FAQ]]

=== Wie kann ich unter FortiOS 5.4 den Zugriff über FortiExplorer auf einen FortiGate Device deaktivieren? ===

Der Zugriff für den FortiExplorer auf einen FortiGate Device kann deaktiviert werden. Weitere Informationen findet man unter folgenden Artikel:

        [[FortiGate-5.4:FAQ#Kann_ich_auf_einer_FortiGate_den_Seriellen_Consolen_Port_.28RS-232.29_deaktivieren.3F]]

== USB Port ==

=== Was ist unter FortiOS 5.4 beim Benützen eines USB Sticks an eine Fortigate zu berücksichtigen? ===

Wenn über eine FortiOS ein USB Stick formatiert wird so wird dieser im "FAT" Format formatiert! Um den USB Stick über das FortiOS zu formatiert führe auf der CLI folgendes aus:

        # execute usb-disk format
        This operation will ERASE all data in USB disk!
        Do you want to continue? (y/n)'''y'''
        
        Format USB disk /dev/sdc1 ...
        Create file system on /dev/sdc1 ...

Danach kann der USB Stick benützt werden um zB ein Backup auf den USB Stick zu spielen. Möchte man den USB Stick vorbereiten dh. nicht über das FortiOS formatieren sondern zB unter Windows 7/10 kann folgendes ausgeführt werden:

        --> Verbinde den USB Stick mit der Workstation und verifizieren den zugewiesenen Laufwerksbuchstaben!
        
        --> Danach öffne eine DOS Box dh. wähle:
        
            Windows 7  = Start > Programme/Dateien durchsuchen > cmd
            Windows 10 = Windows durchsuchen > cmd
            
        --> Danach gebe in der DOS Box folgendes ein:
            
            format [Laufwerks Name zB "F"]: /FS:FAT /V:[Name des USB Sticks/Laufwerk zB "FortiGate"]
            Legen Sie eine neue Diskette in Laufwerk D: ein,
            und drücken Sie die EINGABETASTE.
            Der Typ des Dateisystems ist EXFAT.
            Das neue Dateisystem ist FAT.
            Überprüfung von 1009.4 MB
            Die Dateizuordnungstabelle (FAT) wird initialisiert...
            Formatieren beendet.
                1009.1 MB Speicherplatz auf dem Datenträger insgesamt.
                1009.1 MB sind verfügbar.
            
                   16'384 Bytes in jeder Zuordnungseinheit
                   64'585 Zuordnungseinheiten auf dem Datenträger verfügbar
            
                       16 Bits in jedem FAT-Datensatz.
            
            Volumeseriennummer : 4E6E-9DDF

=== Kann ich unter FortiOS 5.4 ein "image" sowie Konfiguration eines FortiGate Devices über USB Stick komplett automatisieren? ===

Eine Automatisierung einer Installation eines FortiGate Devices mit einer entsprechenden Konfiguration lässt sich über USB Stick komplett automatisieren. Die zuständigen Konfigurationspunkte über Mgmt. Web Interface sind die Folgenden:

        System > Advanced > USB Auto-Install

        [[Datei:Fortinet-1648.jpg]]

Die Konfiguration kann ebenfalls über CLI durchgeführt werden:

        # config system auto-install
        # set auto-install-config [enable oder disable]
        # set auto-install-image [enable oder disable]  
        # set default-config-file [File Name]
        # set default-image-file [File Name]
        # end

Die Voraussetzung damit über einen USB Stick diese "USB Auto-Install" Funktion genutzt werden kann ist ein korrekt formatierter USB Stick. Weitere Informationen dazu siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_beim_Ben.C3.BCtzen_eines_USB_Sticks_an_eine_Fortigate_zu_ber.C3.BCcksichtigen.3F]]

Wenn die Funktion des "USB Auto-Install" aktiviert wurde für das "image" und/oder "config" File und der USB Stick entsprechend korrekt formatiert wurde kann in das Root Verzeichnis des USB Stick ein entsprechendes "image" eines FortiOS sowie die entsprechende Konfiguration eines FortiGate Devices basierend auf "image" des FortiOS auf den USB Stick gespeichert werden. Dabei müssen die Filenamen des "image" sowie der Konfiguration übereinstimmen mit der Konfiguration resp. Definition des "default-image-file" sowie "default-config-file"! Wenn nun der USB Stick an die FortiGate angeschlossen wird und der FortiGate Device eingeschaltet wird oder ein Neustart ausgeführt wird, wird folgendes durchgeführt:

        1ter Neustart = Die Funktion "USB Auto-Install" überprüft ob in der aktiven Partition das FortiOS installiert ist gemäss dem 
                        "image" File auf dem USB Stick! Ist dies nicht der Fall wird in der nicht aktiven Partition das FortiOS installiert
                        anhand des "image" Files auf dem USB Stick! Nach der Installation wird ein Neustart ausgeführt. Ist die aktive 
                        Partition identisch mit dem "image" File auf dem USB Stick wird 2ter Neustart Ueberprüfung ausgeführt! 

        2ter Neustart = Nach der Installation des "images" auf dem USB Stick oder bei Uebereinstimmung der aktiven Partition mit dem
                        "image" wird Ueberprüft ob die Konfiguration in der aktiven Partition übereinstimmt mit dem Konfigurtionsfile
                        auf dem USB Stick. Ist das nicht der Fall wird ein Restore durchgeführt anhand des Konfigurationsfile auf dem
                        USB Stick. Ist die Konfiguration auf dem USB Stick gleich der Konfiguration in der aktiven Partition wird keine
                        Aenderung durchgeführt und der Neustart regulär fortgesetzt!

Es empfiehlt sich den Vorgang bei einem Test über den Console Port (RS232) mitzuverfolgen damit allfällige Fehlermeldungen über die Console mitverfolgt werden können. Mit dieser Funktion kann somit ein FortiGate Device mit einem entsprechenden "image" sowie mit einer eigenen Konfiguration komplett automatisiert werden. Dabei ist jedoch folgendes zu berücksichtigen: Durch die Funktion "USB Auto-Install" wird ein FortiGate Device nicht von Grundauf neu installiert dh. zB der "boot device" wird nicht neu formatiert usw. Wie ein FortiGate Device von Grundauf neu installiert (staging) wird siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_ein_FortiGate_Device_von_Grundauf_mit_einem_entsprechenden_FortiOS_installieren_.28staging.29.3F]]

== Consolen Port ==

=== Was für ein Kabel (Converter) benötige ich für den Consolen Anschluss (Seriell RS-232) auf einer FortiGate? ===

Eine Fortinet kann über Consolen Port, SSH, Telnet, HTTP, HTTPS Administriert werden. Bei Problemen oder für das initial Setup ist der Consolen Port unablässlich. Dabei handelt es sich beim Consolen Port über eine RS232 Schnittstelle. Die heutigen Workstation und/oder Laptops werden jedoch nicht mehr mit einem RS232 Anschluss ausgeliefert. Aus diesem Grund muss auf einen Converter zurückgegriffen werden. Bei diesen Convertern handelt es sich meistens um "USB to RS232 Converter". Dieses sind jedoch nicht unproblematisch dh. je nach Betriebssystem, Consolen Anschluss usw. kann es zu Problemen kommen dh. die Kompatibilität zu den verschiedenen Consolen Anschlüssen dh. vers. Hersteller und Geräten ist eine kompatibilitäts Frage! Der nachfolgende Artikel bietet eine "sehr hohe" Kompatibilität zu vers. Herstellern und hat den Vorteil, dass unter Windows 7/8 KEIN Treiber installiert werden muss (ab Windows 7 SP1). Wichtig bei der Installation ist nur das man das Gerät anschliesst und nachträglich einen Neustart ausführt. Ebenfalls wird der "FTDI Chip" basierende "USB to RS232 Converter" nur dann korrekt erkannt wenn dieser beim Start des Laptop korrekt angeschlossen ist (Immer den gleichen Anschluss benützen am Laptop). Nach der korrekten Erkennung des "USB to RS232 Converter" kann im entsprechenden Eintrag im Gerätemanager der Anschluss auf "Com1" umgestellt werden (per Standard ist Com3 gesetzt). Alle anderen Einstellungen sollten/können auf Standard belassen werden. Nachfolgend einige Informationen betreffend dieses "USB to RS232 Converter":

        [[Datei:Fortinet-619.jpg]]

        '''Technische Daten''' 
        
        Hersteller:    EXSYS (https://www.exsys.ch/index.php?page=product&info=393)
        Produkte-Nr:   EX-1301-2 
        ALSO-Nr:       [[https://ivis.also.ch/ivis/mao/DefaultShort.aspx?view=ShopArtikelDetail&artikelNr=17500313H&tab=0| 17500313H]]
        Anschlüsse:    1 x A-Stecker Upstream, 1 x 9 Pin D-SUB Seriell Stecker
        Datenblatt:    [[Datei:EX-1301-2-Datenblatt.pdf]]
        Handbuch:      [[Datei:EX-1301-2-Handbuch.pdf]]
        Unterstützung: Win98SE/ME/XP/CE/2000/2003/Vista/Win7 und Linux (MacOS X)
        Driver:        [[Datei:EX-1301-2.zip]]
        Driver Link:   https://www.exsys.ch/index.php?page=product&info=393
        
        Beschreibung:  Das USB 1.1 zu RS-232 Kabel stellt eine Serielle RS-232 High Performance UART 16C550 Ausgang zur Verfügung. 
                       Er ist entwickelt worden um einen weiteren Seriellen Ausgang für PC, kleine Workstation oder Server über 
                       den USB 1.1 oder 2.0 Bus zu erweitern.
        
                       '''NOTE''' Beim EX-1301-2 wird "kein" RS232-to-RJ45 Kabel mitgeliefert. Diese kann unter folgender
                            ALSO-Nr bezogen werden:
                            
                            [[https://ivis.also.ch/ivis/mao/DefaultShort.aspx?view=ShopArtikelDetail&artikelNr=16502947H&tab=0| 16502947H]]

Nachfolgendes Dokument zeigt wie auf einem MacOSx basierend auf diesem "USB to RS232 Converter" Adapter konfigiguriert wird inkl. der Konfiguration eines TFTP Servers. Dieses Dokument wurde durch einen Kunden zur Verfügung gestellt:

        [[Datei:RS232-USB-Converter-TFTP-Server-Konfig-MacOSx.pdf]]

Weitere Informationen zur genauen Pin-Belegung betreffend Fortinet Appliance und dem Seriellen Consolen Port siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_sieht_die_PIN-Belegung_der_Seriellen_Consolen_.28RS-232_.2F_DB9_.2F_RJ-45_.2F_AUX.29_auf_einem_FortiGate_Device_aus.3F]]

=== Wie sieht die PIN-Belegung der Seriellen Consolen (RS-232 / DB9 / RJ-45 / AUX) auf einem FortiGate Device aus? ===

Nachfolgend die technischen Informationen über die Pin-Belegung der Seriellen Console der Fortinet Produkte wie FortiGate, FortiAnalyzer, FortiManager sowie FortiMail:

        '''NOTE''' Einige FortiGate Devices haben einen RS-232 DB9 Konsolen Verbindung und andere haben eine RJ-45 Verbindung 
             (wie zB A Modelle). Ebenso existieren Modelle mit einem AUX Port. Alle diese Varianten benützen die gleiche
             Serielle Pin-Belegung!
             
             [[Datei:Fortinet-1083.jpg]]

=== Kann ich auf einer FortiGate den Seriellen Consolen Port (RS-232) deaktivieren? ===

Wenn man zB verhindern möchte, dass in einem Datacenter usw. über den Seriellen Console Port unerlaubt zugegriffen wird, kann dieser ab FortiOS 5.0 mit folgenden Befehl deaktiviert werden:

        # config system console
        # set login disable
        # end
        
        '''NOTE''' Dieses Kommando steht ab FortiOS 5.0 zur Verfügung und deaktiviert unter FortiOS 5.0 den "Seriellen Consolen" Port
             sowie den "USB" Port für den FortiExplorer. Ab FortiOS 5.2 wurde dieses Kommando erweitert dh. durch den hier gezeigten
             Befehl wird ab FortiOS 5.2 nur der "Consolen Port" deaktiviert und der "USB" Port muss sofern gewünscht seperat deaktiviert
             werden:
             
             # config system console
             # set fortiexplorer disable
             # end

== Web Gui ==

=== Unter FortiOS 5.4 ist der Hostname auf der Login Page ersichtlich wie kann ich diesen aktivieren/deaktivieren? ===

Wenn man über das Web Mgmt. Interface einer FortiGate unter FortiOS 5.4 einloggt dann kann es sein das die Login Seite den "Hostnamen" des FortiGate Devices zeigt:

        [[Datei:Fortinet-1614.jpg]]

Möchte man diesen "Hostnamen" über die Login Page aktivieren resp. deaktivieren kann folgendes ausgeführt werden:

        # config system global
        # set gui-display-hostname [enable | disable] 
        # end

=== Unter FortiOS 5.4 kann ich zwar "Dashboards" sowie "Widgets" einblenden jedoch nicht mehr eigenen konfigurieren? ===

Unter FortiOS 5.4 fällt einem auf das keine zusätzlichen Dashboard's mehr erstellt werden können dh. es stehen über Mgmt. Web Interface folgende Konfigurationspunkte zur Verfügung:

        [[Datei:Fortinet-1628.jpg]]

Durch "Add Widget" kann ein zusätzliches "Widget" eingeblendet werden:

        [[Datei:Fortinet-1629.jpg]]

Möchte man nun ein zusätzliches "Dashboard" und/oder ein zusätzliches "Widget" über CLI konfigurieren ist dies nicht mehr möglich da folgende Befehle nicht mehr exisiteren:

        # config system admin
        # edit [Name des Administrators zB "admin"]
        # config dashboard-tabs
        # end

        # config system admin
        # edit [Name des Administrators zB "admin"]
        # config dashboard
        # edit 0
        # set widget-type app-usage
        # set widget-type storage
        # set widget-type protocol-usage
        # set widget-type device-os-dist "Deivce/
        # next
        # end

Somit steht unter FortiOS 5.4 nur das per Standard existierende "Dashbaord" zur Verfügung sowie die zur Verfügung stehenden "Widgets" die unter "Add Widgets" hinzugefügt werden können. Möchte man die Standard Konfiguration betreffend "Dashboard" wiederherstellen kann der Menüpunkt "Reset Dashboard" ausgeführt werden oder man kann unter CLI folgendes durchführen:

        # diagnose sys dashboard reset

Durch diesen Befehl und/oder durch Ausführen von "Reset Dashboard" führt das System folgendes durch für den eingeloggten "Administratore" zB "admin":

        # config system admin
        # edit "admin"
        # config dashboard
        # edit 1
        # set column 1
        # end
        # end
        # config system admin
        # edit "admin"
        # config dashboard
        # edit 2
        # set widget-type licinfo
        # set column 1
        # end
        # end
        # config system admin
        # edit "admin"
        # config dashboard
        # edit 3
        # set widget-type jsconsole
        # set column 1
        # end
        # end
        # config system admin
        # edit "admin"
        # config dashboard
        # edit 4
        # set widget-type sysres
        # set column 2
        # end
        # end
        # config system admin
        # edit "admin"
        # config dashboard
        # edit 5
        # set widget-type alert
        # set column 2
        # set top-n 10
        # end
        # end

=== Unter FortiOS 5.4 sehe ich über das Web Gui nicht alle Features wie kann ich diese aktivieren/deaktivieren? ===

Wenn man unter FortiOS 5.4 auf dem Web Mgmt. Interface einloggt kann es sein, dass nicht alle Features resp. Menüpunkte angezeigt werden. Ein Beispiel ist zB die "Local In Policy". Auf dem Web Mgmt. Interface stehen diese Features zur Verfügung um diese zu aktivieren resp. zu deaktiveren:

        System > Feature Select

        [[Datei:Fortinet-1613.jpg]]

Neu unter FortiOS 5.4 können die einzelnen Features VDOM basierend aktiviert resp. deaktiviert werden. Aus diesem Grund befinden sich die Gui Optionen nicht mehr unter "system global" sondern wurden verschoben in "system settings" denn "system settings" kann per VDOM konfiguriert werden. Wenn die Features über CLI konfiguriert werden, liegt der Vorteil darin das unter CLI einige zusätzliche Features zur Verfügung stehen die über Web Mgmt. Interface nicht zur Verfügung stehen. Um die verschiedenen Features im Gui Bereich aufzulisten kann folgender Befehl benutzt werden:

        # config system settings
        # get | grep gui
        gui-default-policy-columns:
        gui-icap            : disable 
        gui-implicit-policy : enable 
        gui-dns-database    : enable 
        gui-load-balance    : disable 
        gui-multicast-policy: enable 
        gui-dos-policy      : enable 
        gui-object-colors   : disable 
        gui-replacement-message-groups: enable 
        gui-voip-profile    : enable 
        gui-ap-profile      : enable 
        gui-dynamic-profile-display: disable 
        gui-ipsec-manual-key: disable 
        gui-local-in-policy : enable 
        gui-explicit-proxy  : enable 
        gui-dynamic-routing : enable 
        gui-dlp             : enable 
        gui-sslvpn-personal-bookmarks: enable 
        gui-sslvpn-realms   : enable 
        gui-policy-based-ipsec: enable 
        gui-threat-weight   : enable 
        gui-multiple-utm-profiles: enable 
        gui-spamfilter      : enable 
        gui-application-control: enable 
        gui-casi            : enable 
        gui-ips             : enable 
        gui-endpoint-control: enable 
        gui-dhcp-advanced   : enable 
        gui-vpn             : enable 
        gui-wireless-controller: enable 
        gui-switch-controller: enable 
        gui-fortiap-split-tunneling: enable 
        gui-webfilter-advanced: enable 
        gui-traffic-shaping : enable 
        gui-wan-load-balancing: enable 
        gui-antivirus       : enable 
        gui-webfilter       : enable 
        gui-dnsfilter       : enable 
        gui-waf-profile     : enable 
        gui-fortiextender-controller: disable 
        gui-advanced-policy : disable 
        gui-allow-unnamed-policy: enable 
        gui-email-collection: enable 
        gui-domain-ip-reputation: enable 
        gui-multiple-interface-policy: enable
        # set [Gebe die gewünschte Gui Option an] [enable | disable]

Einige Features befinden sich nachwivor unter "system global" und diese Features können nicht per VDOM konfiguriert werden sondern sind nur unter Global verfügbar:

        # config system global
        # get | grep gui
        gui-certificates    : enable 
        gui-custom-language : enable 
        gui-device-latitude : 
        gui-device-longitude: 
        gui-display-hostname: enable 
        gui-ipv6            : disable 
        gui-lines-per-page  : 50
        gui-theme           : green 
        gui-wireless-opensecurity: enable
        # set [Gebe die gewünschte Gui Option an] [enable | disable]
        # end

=== Kann man auf einer FortiGate unter FortiOS 5.4 die Spalten innerhalb der "IPv4 Policy" konfigurieren? ===

Wenn man auf einer FortiGate unter FortiOS 5.4 eine Firewall Policy Rule erstellt dh. unter dem Menüpunkt "IPv4 Policy" dann werden nach der Erstellung der Firewall Policy Rule diese innerhalb verschiedener Spalten angezeigt. Diese Spalten können zwar im Browser verändert dh. zusätzliche Spalten hinzgefügt und gelöscht werden, jedoch diese Konfiguration ist nicht "persistent" dh. wenn der Browser Cache gelöscht wird geht die Konfiguration die über den Browser durchgeführt wurde verloren. Ueber die CLI sind diese Spalten der Firewall Policy Rule dh. für den Menüpunkt "IPv4 Policy" konfigurierbar und "persistent". Dazu führe folgendes aus:

        '''NOTE''' Die Konfiguration unter zB FortiOS 5.2 für die "gui-default-policy-columns" geht bei einem Upgrade auf
             FortiOS 5.4 verloren. Der Grund ist die verschiedenen zur Verfügung stehenden Optionen wie zB "count"
             existieren nicht mehr. Anstelle von "count" wird "hit_count" benutzt und aus diesem Grund wird die 
             Konfiguration nach einem Upgrade auf "unset" gesetzt was wiederum bedeutet auf FortiOS 5.4 "Standard"!

        # config system settings
        # set gui-default-policy-columns ?
        *name                    Column name.
        #                        Seq #.
        name                     Name.
        policyid                 Policy ID.
        srcintf                  Source.
        dstintf                  Destination.
        srcaddr                  Source Address.
        dstaddr                  Destination.
        schedule                 Schedule.
        service                  Service.
        action                   Action.
        logtraffic               Log.
        nat                      NAT.
        status                   Status.
        bytes                    Bytes.
        packets                  Packets.
        session                  Sessions.
        last_used                Last Used.
        first_used               First Used.
        hit_count                Hit Count.
        profile                  Security Profiles.
        av-profile               AV.
        spamfilter-profile       Email Filter.
        webfilter-profile        Web Filter.
        application-list         Application Control.
        ips-sensor               IPS.
        dlp-sensor               DLP.
        icap-profile             ICAP Profile.
        voip-profile             VoIP Profile.
        profile-protocol-options Proxy Options.
        ssl-ssh-profile          SSL Inspection.
        vpntunnel                VPN Tunnel.
        comments                 Comments.
        source                   Source.
        users                    Users.
        groups                   Groups.
        devices                  Devices.
        profile-group            Profile Group.
        traffic-shaper           Traffic Shapers.
        per-ip-shaper            Per-IP Traffic Shaper.
        endpoint-compliance      Endpoint Compliance.

Aus den zur Verfügung stehenden Optionen kann somit folgendes als Beispiel ausgeführt werden:

        # set gui-default-policy-columns "#" "policyid" "srcintf" "dstintf" "srcaddr" "dstaddr" "schedule" "service" "groups" "action" "profile" "logtraffic" "nat" "bytes" "hit_count"
        # end

        '''NOTE''' bei der Konfiguration muss berücksichtig werden das die "Sequenz" dh. "#" definiert werden muss. Zusätzlich muss "name" ebenfalls
             definiert werden sofern das Feature "gui-allow-unnamed-policy" nicht aktiviert ist was wiederum bedeutet, dass dieses Feature
             innerhalb eine Firewall Policy erzwingt jeder Firewall Policy Rule einen Namen zu vergeben!

== Upgrade ==

=== Soll ich (Stand Juni 2016) ein Upgrade auf FortiOS 5.4.1 durchführen? ===

Bei der momentanen FortiOS 5.4.1 Version ist zu beachten, dass es sich um den ersten Patch nach dem "General Availlibility Release" handelt. Wie aus den "Release Notes" von 5.4.1 zu entnehmen ist existieren noch etliche "known issues" (6 Seiten). Ebenso stehen momentan noch nicht alle Informationen zur Verfügung betreffend den neuen Features und Funktionen. Aus diesem Grund empfehlen wir diesen Release nicht für einen "Produktiven Einsatz" da dieser Release aus unsere Sicht nicht "stable" ist. Für Testgeräte oder Laborgeräte ist es aber eine gute Sache sich mit dem neuen Release vertraut zu machen und sich in den neuen Release einzuarbeiten. Man kann sich mit dem neuen Menu Design vertraut machen und die neuen Features auf Herz Niere testen. Dabei ist jedoch die Kompatibilität zu anderen Devices wie zB FortiAnalyzer, FortiManager sowie Forti Access Point zu berücksichtigen, die in den "Release Notes" von FortiOS 5.4.1 explizit erwähnt werden.

        [[Datei:fortios-v5.4.0-release-notes.pdf]]
        [[Datei:fortios-v5.4.1-release-notes.pdf]]
        
        [[Datei:Coop-Security-Fabric-5.4.1-Upgrade-Guide.pdf]]

Desweiteren weisen wir daraufhin, dass es die "Central-NAT" Table Funktion nicht mehr existiert. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_f.C3.BCr_eine_.22Firewall_Policy_Rule.22_existiert_die_Position_.22Central-NAT.22_nicht_mehr_was_ist_zu_beachten.3F]]

Es ist zu erwarten, dass neue Devices wie zB eine FG-30E, FG-50E mit dem neuen FortiOS 5.4.0 ausgeliefert werden. Speziell zu erwähnen ist, dass die FG-5xE nur mit FortiOS 5.4.x betrieben werden kann da dieser Device über einen speziellen Chip verfügt, der nur mit der FortiOS 5.4.x Version kompatibel ist. Dabei ist zu beachten, dass speziell bei der FWF-5XE Serie einige gravierende Inkompatibilitäten auftraten und deshalb es dringend empfohlen ist FortiOS 5.4.1 zu benutze. Aus diesem Grund und nach Möglichkeit empfehlen wir neue Devices von Grund auf neu zu "stagen". Wie ein Staging von Grundauf durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_ein_FortiGate_Device_von_Grundauf_mit_einem_entsprechenden_FortiOS_installieren_.28staging.29.3F]]

== Backup / Restore ==

=== Wie kann ich unter FortiOS 5.4 auf einem FortiGate Device ein Backup/Restore durchführen? ===

Wenn ein Backup auf einem FortiGate Device manuell durchgeführt wird kann dies über Mgmt. Web Interface durchgeführt werden. Wie ein Backup manuell über USB Stick durchgeführt wird siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einem_FortiGate_Device_ein_Backup.2FRestore_.C3.BCber_einen_USB_Stick_durchf.C3.BChren.3F]]

Um das Backup über das Web Mgmt. Interface durchzuführen wähle folgendes:

        Dashboard > Backup

        [[Datei:Fortinet-1642.jpg]] 

        [[Datei:Fortinet-1646.jpg]]

Wenn die Funktion "Encryption" definiert wird muss ein entsprechendes Passwort definiert werden. Anhand dieses Passwort wird das File AES256 verschlüsselt. Wenn dies durchgeführt wird muss folgendes berücksichtigt werden: Geht das definierte Passwort verloren kann kein Restore durchgeführt werden. Auch Fortinet ist nicht in der Lage dieses verchlüsselte Backup anhand des Passwortes zu entschlüsseln somit ist das entsprechende Backup File nutzlos. Wenn anhand eines Backups ein manueller Restore durchgeführt werden möchte ist folgendes zu berücksichtigen:

        •  Ein Restore kann nur dann durchgeführt werden wenn der FortiGate Device über das gleiche FortiOS verfügt wie das Backup File!
           
        •  Ein Restore kann nur dann durchgeführt werden wenn die Harware Konfiguration identisch ist wie das des Backup File (zB Interface/Switch Mode)!
           
        •  Ein Restore basierend auf einem Backup eines grösseren FortiGate Devices kann nicht verwendet werden für einen anderen kleineren
           FortiGate Device (not supported)!
           
        •  Ein Restore basierend auf einem Backup File eines anderen kleineren FortiGate Devices kann nur dann durchgeführt werden wenn der 
           Header des Restore Files = dem Header des anderen grösseren FortiGate Devices entspricht. Dabei sind folgende Zeilen im Restore
           File zu ersetzen:
           
           #config-version=FGT60D-5.04-FW-build1011-151221:opmode=0:vdom=0:user=admin
           #conf_file_ver=0
           #buildno=1011

Ein Restore wird folgendermassen durchgeführt:

        Dashboard > Restore

        [[Datei:Fortinet-1644.jpg]] 

        [[Datei:Fortinet-1647.jpg]]

Durch den Restore wird in jedem Fall ein Neustart des Devices ausgelöst! Es ist Empfohlen den Neustart über den Consolen Port (RS232) mitzuverfolgen um allfällige Fehlermeldungen zu erhalten. Wenn dies nicht möglich ist sollte nach Neustart des FortiGate Devices auf der CLI folgender Befehl benutzt werden um allfällige Fehlermeldungen zu eruieren:

        # diagnose debug config-error-log read

Dieses "crashlog" kann ebenfalls zurückgesetzt resp. gelöscht werden. Dies wird folgendermassen durchgeführt:

        # diagnose debug config-error-log clear

=== Wie kann ich unter FortiOS 5.4 auf einem FortiGate Device ein Backup/Restore über einen USB Stick durchführen? ===

Wenn anhand eines USB Sticks ein Backup durchgeführt wird über Mgmt. Web Interface kann über die Position "USB" innerhalb der Backup Funktion das Backup direkt auf den USB Stick gespeichert werden. Wenn ein Backup auf der CLI durchgeführt wird und das Backup auf den USB Stick gespeichert werden soll kann dies ebefalls durchgeführt werden. Voraussetzung damit dies durchgeführt werden kann ist ein korrekt formatierter USB Stick. Weitere Informatioenn wie dieser Formatiert werden kann siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_beim_Ben.C3.BCtzen_eines_USB_Sticks_an_eine_Fortigate_zu_ber.C3.BCcksichtigen.3F]]

Um ein Backup über USB Stick und über Mgmt. Web Interface durchzuführen führe folgendes aus:

        Dashboard > Backup > USB Disk

        [[Datei:Fortinet-1642.jpg]]

        [[Datei:Fortinet-1643.jpg]]

Wenn ein Backup über CLI durchgeführt werden soll kann folgendes ausgeführt werden:

        # execute backup ["config" oder "full-config"] usb [Name des Backup Files] [Optional Passwort um das File zu verschlüsseln]
        Please wait...
        
        Copy config full-config-backup to USB disk ...
        Copy config file to USB disk OK.
        Setting timestamp
        
        '''NOTE''' Die Option "config" steht im Zusammenhang mit der VDOM Funktion dh. ist VDOM aktiviert auf einer FortiGate kann anhand "config"
             für eine spezifische VDOM ein Backup durchgeführt werden!

Um das Backup File auf dem USB Stick zu verifizieren das über CLI oder Mgmt. Interface gespeichert wurde kann der Inhalt des USB Sticks ausgelesen werden:

        # execute usb-disk list
        2016-01-06 14:00:56     <DIR>           System Volume Information
        2016-01-06 21:11:08         431082      full-config-backup

Wird erneut ein Backup über denselben USB Stick dh. über Mgmt. Web Interface oder über CLI mit demselben Namen durchgführt wird das vorhandene File überschrieben. Dies bedeutet: Es gibt keine Funktion die es erlaubt zB anhand der Zeit/Datum das File variable zu benennen so das dieses nicht überschrieben wird! Zum Kommando "execute usb-disk" stehen folgende Optionen zusätzlich zur Verfügung:

        # execute usb-disk ?
        delete    Delete file from the USB disk.
        eject     Eject the USB disk.
        format    Format the USB disk.
        list      Display the contents of the USB disk.
        rename    Rename file in the USB disk.

Wenn ein Restore anhand eines USB Sticks über Mgmt. Web Interface durchgeführt werden soll muss als Voraussetzung der USB korrekt erkannt werden resp. korrekt formatiert sein. Danach kann folgendes durchgeführt werden:

        Dashboard > Restore > USB Disk

        [[Datei:Fortinet-1644.jpg]]

        [[Datei:Fortinet-1645.jpg]]

Ein Restore über CLI anhand eines USB Sticks wobei auch hier die Voraussetzung ist das der USB Stick korrekt erkannt sowie formatiert wurde, wird folgendermassen ausgeführt:

        # execute restore config usb [File Name der "config" zB "full-config-backup"

== Firmware ==

=== Wie kann ich ein FortiGate Device von Grundauf mit einem entsprechenden FortiOS installieren (staging)? ===

Wenn ein FortiGate Device von Fortinet ausgeliefert wird, kann dieser FortiGate Device auf irgend einem FortiOS basieren! Grundsätzlich werden immer die neusten FortiOS Versionen durch Fortinet vorinstalliert. Wenn es sich um ein neu lanciertes Modell eines FortiGate Devices handelt, basieren diese oft auf einem sogenannten "Branche Release". Ein "Branche Release" ist eine Vorabversion eine "GA" Releases (General Availibility). Aus diesem Grund Empfehlen wird bei jedem FortiGate Device ein "staging" durchzuführen mit dem FortiOS der Wahl. Dabei spielt es keine Rolle welcher FortiOS auf dem FortiGate Device existiert oder welche Konfiguration usw. vorhanden ist, denn durch ein "staging" wird der FortiGate Device von Grundauf neu installiert und sämtliche Konfiguration sowie das bestehende FortiOS gehen dabei verloren. Somit sollte jeder FortiGate Device in diesem Sinne aufgesetzt werden. Absolute Voraussetzung für ein "staging" ist eine korrekte Verbindung von der entsprechenden Workstation zum "Consolen Port" (RS232) des FortiGate Devices. Dies bedeutet: 

        8 bits 
        no parity 
        1 stop bit 
        9600 baud (the FortiGate-300 uses 115,000 baud) 
        Flow Control = None 

Die heutigen Laptop/Workstation verfügen in den seltensten Fällen einen "RS-232" Port somit muss mit einem entsprechenden Device zB "USB Konverter" gearbeitet werden. Wir empfehlen den "EX-1301-2" USB Konverter der sich durch eine hohe Kompatibilität auszeichnet. Weitere detaillierte Informationen betreffend "Consolen Port" resp. RS-232 Console findet man im folgenden Artikel:

        [[FortiGate-5.4:FAQ#Was_f.C3.BCr_ein_Kabel_.28Converter.29_ben.C3.B6tige_ich_f.C3.BCr_den_Consolen_Anschluss_.28Seriell_RS-232.29_auf_einer_FortiGate.3F]]

Beim "staging" Prozess überträgt das Bios des FortiGate Devices das entsprechende FortiOS von einem TFTP Server auf den FortiGate Device um diesen nachträglich zu installieren. Aus diesem Grund muss auf der entsprechende Workstation die verbunden ist mit dem FortiGate Device ein TFTP Server installiert werden. Wir empfehlen folgenden TFTP Server der frei erhältlich ist:

        http://www.solarwinds.com/downloads/    (Abschnitt: Free Trial Downloads > TFTP Server & SFTP/SCP Server > DOWNLOAD FREE Tool > Free TFTP Server > DOWNLOAD NOW)

Für den "Solarwinds TFTP Server" muss eine Standard Installation durchgeführt werden. Nach der Installation steht im Startmenü "SolarWinds TFTP Server" zur Verfügung und innerhalb dieses Menüs "TFTP Server". Starte den TFTP Server anhand dieses Menüeintrages. Danach wähle:

        File > Configure > Start

Der TFTP Server wird gestartet und dies wird auch unter der Position "Status" als "Started" angezeigt. Nun bestätige durch "OK" das "Configure" Fenster und sobald dies geschieht "initial" wird der TFTP Server gestoppt. Der Grund dafür ist der Folgende: Beim ersten Start des TFTP Servers wird das "TFTP Server Root Directory" angelegt und der Server gestoppt. Per Standard befindet sich das "TFTP Server Root Directory unter folgenden Verzeichnis "C:\TFTP-Root". Kontrolliere kurz ob dieses Verzeichnis angelegt wurde sowie starte den TFTP Server abermals und kontrolliere dessen Status:

        File > Configure > Start [Kontrolliere den Status "Started"]

Nun muss in das "TFTP Server Root Direktory" das entsprechende FortiOS Image kopiert werden. Benenne dieses FortiOS Image um in "image.out". Als nächsten Schritt konfiguriere die Netzwerkkarte der entsprechende Workstation die mit dem FortiGate Device über "Consolen Port" verbunden ist mit folgender IPv4 Adresse und Subnet Maske sowie deaktiviere sämtlichen anderen Netzwerkkarten wie zB für WLAN:

        192.168.1.188
        255.255.255.0
        
        '''NOTE''' Die IPv4 Adresse des TFTP Servers resp. der Netzwerkkarte der entsprechenden Workstation kann für die verschiedenen
             Modelle des FortiGate Devices varieren. Bei "staging" Prozess kann diese jedoch eruiert werden!

Die Konfiguration der Netzwerkkarte benötigt keinen "Default Gateway" sowie DNS Server. Achte darauf, dass auf der entsprechenden Workstation sämtliche Firewall, Endpoint Security usw. deaktiviert wurden damit die Anfrage des FortiGate Devices für die Uebertragung des FortiOS Image zum TFTP Server erlaubt wird. Aus diesen Ausführung ergiebt sich folgende Konstellation:

                       _____________________________
                      |       RS232 Verbindung      |
        Consolen Port |                             |
           ___________|___                          | RS-232 Anschluss
          |               |                     ____|_______________
          | FortiGate 50E |   192.168.1.100/24 |                    |
          |_______________|               _____| LapTop/Workstation | --> SolarWindsTFTP Server Status "Started" 
                   |                     | NIC |____________________| --> FortiOS als "image.out" im C:\TFTP-Root
              WAN1 |                     |                            --> Fireweall, Endpoint Security deaktiviert!
                   |_____________________|
        
        '''NOTE''' Als Verbindung von WAN1 zur Netzwerkkarte der entsprechenden Workstation benütze ein normales RJ-45 Kabel. Der entsprechende
             Netzwerk Port in unserem Beispiel "WAN1" ist abhängig vom FortiGate Device. Der entsprechende zu benützende Port wird während
             dem "staging" Prozess aufgelistet!

Nun muss der FortiGate Device neu gestartet werden (execute restart) oder ein "power-on" ausgeführt werden. Sobald der FortiGate Device startet muss auf folgende Meldung geachtet werden um den Start Prozess abzubrechen und um in das Bios des FortiGate Devices zu gelangen:

        Please wait for OS to boot, or press any key to display configuration menu..

        FortiGate-50E (12:55-08.13.2015)
        Ver:05000011
        Serial number: FGT50E3U15000635
        CPU(00): 1600MHz
        Total RAM: 2GB
        Initializing boot device...
        Initializing MAC... egiga1
        '''Please wait for OS to boot, or press any key to display configuration menu..'''

Wenn der Start Prozess mit "press any key...." abgebrochen wurde wird folgendes Menü angzeigt:

        [C]: Configure TFTP parameters.
        [R]: Review TFTP parameters.
        [T]: Initiate TFTP firmware transfer.
        [F]: Format boot device.
        [I]: System information.
        [B]: Boot with backup firmware and set as default.
        [Q]: Quit menu and continue to boot.
        [H]: Display this list of options.

Nun kann für den TFTP "staging" Prozess anhand "[R]: Review TFTP parameters." die vorgegebenen Konfiguration eingesehen werden. Möchte man diese Konfiguration verändern kann dies anhand "[C]: Configure TFTP parameters." durchgeführt werden. Dabei ist zu beachten das diese Veränderung "persistens" ist und zukünftig für jeden "staging" Prozess betreffend TFTP Parameter für diesen FortiGate Device gilt:

        Enter C,R,T,F,I,B,Q,or H: '''R'''
        
        Image download port:    WAN1
        DHCP status:            Disabled
        Local VLAN ID:          <NULL>
        Local IP address:       192.168.1.188
        Local subnet mask:      255.255.255.0
        Local gateway:          192.168.1.254
        TFTP server IP address: 192.168.1.168
        Firmware file name:     image.out

Führe folgende Kontrolle durch betreffend der Konfiguration des "staging" Prozesses:

        • Ist das RJ-45 Kabel am korrekten Netzwerk Port der FortiGate angeschlossen (Beispiel: WAN1)
        • Wurde die korrekte IPv4 Adresse sowie Subent Maske auf der Netzwerkkarte der entsprechenden Workstation konfiguriert
        • Ist der TFTP Server gestartet und befindet sich im "TFTP Server Root Directory" (C:\TFTP-Root) das entsprechende Image des FortiOS als File "image.out"

Als nächsten Schritt muss der "boot device" neu formatiert werden. Dabei wird die Boot Partition gelöscht und neu angelegt. Sämtliche vorhandenen Daten/Informainen gehen dabei verloren. Wähle die Postion "[F]: Format boot device.":

        Enter C,R,T,F,I,B,Q,or H: '''F'''
        It will erase data in boot device. Continue? [yes/no]: '''yes'''
        Formatting............................ Done.

Nun um den "staging" Prozess zu starten führe die Position "[T]: Initiate TFTP firmware transfer." aus:
 
        Enter C,R,T,F,I,B,Q,or H: '''T'''

Nun wird der "staging" Prozess durchgeführt. Achte dabei auf den "TFTP Server" resp. dessen Console in der ein Transfer des Files bestätigt wird! Auf dem FortiGate Device wird eine korrekte Uebertragung folgendermassen angezeigt:

        Please connect TFTP server to Ethernet port 'WAN1'.
        
        MAC: 90:6c:ac:13:80:10
        
        Connect to tftp server 192.168.1.168 ...
        
        #############################################################
        Image Received.
        Checking image... OK
        Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]? '''D'''
        
Wenn "D" für "default" ausgeführt wird so wird das FortiOS in die Partition installiert und diese "active" gesetzt und somit beim nächsten Neustart des Devices benutzt. Wird "B" für "backup" gwählt wird die Partition nicht "active" gesetzt und somit beim nächsten Neustart nicht benutzt. Wenn "R" für "run" ausgeführt wird so wird das FortiOS in den Memory Bereich installiert dh. nach einem Neustart des Devices steht diese Installation nicht mehr zur Verfügung da durch den ausgeführten Neustart der Memory Bereich gelöscht wird! Für ein "staging" speziell wenn der "boot device" Formatiert wird ist immer "D" zu wählen für "default".
        
        Programming the boot device now.
        ....................................
        .............................................................
        .............................................................
        ...............................................................
        ...
        
        Booting OS...
        
        Reading boot image... 2800640 bytes.
        Initializing firewall...
        
        System is starting...
        
        FGT50E3U15000635 login: 

Das FortiOS ist nun grundsätzlich installiert. Als nächsten Schritt sollte die "disk" eines FortiGate Devices formatiert werden. Bei kleineren FortiGate Devices steht die "disk" für ein "Logging" nicht mehr zur Verfügung. Dennoch sollte die "disk" Formatiert werden da ein FortiOS für viele Funktionen diese "disk" benutzt wird zB DHCP Lease File, Caching Informationen usw. Steht die "disk" nicht zur Verfügung da diese nicht Formatiert wurde, werden diese Informationen in den Memory Bereich geschrieben was das Memory zusätzlich belastet oder stehen teilweise gänzlich nicht zur Verfügung. Um sich Initial nach einem "staging" auf einem FortiGate Device einzuloggen benütze folgende Login Informationen:

        User: admin
        Password: [Kein Passwort]

Nun kann die "disk" formatiert werden mit folgenden Befehl:

        # execute formatdisk
       Log disk is /dev/sdb4
       Formatting this storage will erase all data on it, including
         Logs, quarantine files;
         WanOpt caches;
       and requires the unit to reboot.
       Do you want to continue (y/n) '''y'''

Nach dem Formatieren der "disk" wird ein Neustart ausgeführt! Dieser Befehl "execute formatlogdisk" kann auf neueren FortiGate Modellen wie zB eine FG-50E nicht ausgeführt werden. Der Grund ist der Folgende: Diese FortiGate Modelle verfügen zwar über eine "disk" jedoch die "disk" wird als Subsystem im Flash Bereich angelegt (MTD; Memory Technology Device). Die "MTD" Technology ist Bestandteil des Linux Kernels resp. des FortiOS Kernels. Um festzustellen ob das FortiGate Modell über eine "MTD" Implementation verfügt kann folgender Befehl ausgeführt werden:

        # fnsysctl df -h
        Filesystem                 Size       Used  Available Use% Mounted on
        rootfs                   123.9M      53.6M      70.2M  43% /
        /dev/root                123.9M      53.6M      70.2M  43% /
        none                       1.5G       1.5M       1.4G   0% /tmp
        none                       1.5G          0       1.5G   0% /dev/shm
        none                       1.5G      16.9M       1.4G   1% /dev/cmdb
        '''/dev/mtd5                 18.0M       6.6M      11.3M  37% /data'''
        '''/dev/mtd7                 30.0M       2.3M      27.6M   8% /data2'''

Bei den Verzeichnissen "/data" sowie "/data2" die als "/dev/mtd*" indiziert werden und somit als "MTD" Subsysteme gelten, handelt es sich effektiv um die "disk". Diese "disk" resp. das "MTD Subsystem" wird anhand eines Files das in den Flash Bereich kopiert wird angelegt. Dabei muss berücksichtigt werden, dass alle Informationen der "disk" verloren gehen. Somit FortiGate Modelle die anhand dieser "MTD Subsystem" Technology verfügen resp. anhand dieser eine "disk" dargestellt wird können Informationen nicht "persistent" speichern dh. nach einem Neustart gehen alle Informationen verloren! Für ein "MTD" Subsystem wird auf einer FortiGate-50E 128 MB alloziert. Als nächster Schritt im "staging" Prozess sollten die Interface's auf dem internal Switch aufgebrochen werden. Um dies durchzuführen muss unterschieden werden zwischen folgenden Möglichkeiten

        • Der FortiGate Device verfügt über einen internene Hardware "Switch Controller"!
        • Der FortiGate Device verfügt über keinen internene Software "Switch Controller"!
        • Auf dem FortiGate Device kann kein "Interface Mode" durchgeführt werden!
        
          '''NOTE''' Ob ein FortiGate Device unter FortiOS 5.4 über einen "Switch Controller" verfügt kann über die "Software Matrix" die Fortinet
               zur Verfügung stellt eruiert werden:
               
               [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]

Um ein FortiGate Device für den Interface Mode zu versetzen müssen die Abhängigkeiten auf den Interface aufgelöst werden. Diese Abhängigkeiten bestehen im Zusammenhang mit der Firewall Policy sowie mit dem DHCP Server. Um diese zu löschen führe folgendes auf der CLI aus:

        # config system dhcp server
        # del 1
        # end

        # config system firewall policy
        # del 1
        # end
 
Danach muss für "Hardware" resp. "Software" Switch Controller folgendes ausgeführt werden:

        '''Hardware Switch Controller'''
        
        # config system virtual-switch
        # get
        == [ lan ]
        name: lan    
        # del lan
        # get
        # end
        
        # execute reboot

        '''Software Switch Controller'''
        
        # config system global
        # set internal-switch-mode interface
        # end
        changing switch mode will reboot the system!
        Do you want to continue? (y/n) '''y'''

Durch das Aufbrechen des internen Swichtes gehen sämtliche Konfigurationen auf den Interfaces für den "internen" Switch verloren dh. nach dem ausgeführten Neustart sind auf den Interfaces für den internen Switch die nun einzeln verfügbar sind keine IP Adressen mehr konfiguriert. Um auf einen Zugriff über Mgmt. Interfaces des FortiGate Devices zu gewährleisten muss folgendes auf einem entsprechenden Interface ausgeführt werden:

        '''Verifiziere die einzelnen Interface Namen'''
        
        # show system interface

        '''Konfiguriere ein entsprechendes Interface'''
        
        # config system interface
        # edit [Name des Interface zB "internal1"]
        # set ip [IPv4 Adresse plus Subnet Maske zB "192.168.1.99 255.255.255.0]
        # set allowaccess [http | https | ssh | telnet | ping]
        # end

Wenn "http" sowie "https" aktiviert werden wird per Standard ein "redirect" auf "https" durchgeführt. Möchte man dies verhindern kann folgendes zusätzlich ausgeführt werden:

        # config system global
        # set admin-https-redirect [enable | disable]
        # end

Der "staging" Prozess ist abgeschlossen und der FortiGate Device kann in Betrieb genommen werden!

=== Wie kann ich auf einem FortiGate Device für FortiOS 5.4 ein manuelles Firmware Upgrade durchführen? ===

Wenn auf einem FortiGate Device ein Upgrade anhand eines FortiOS Version durchgeführt werden soll, muss verifiziert werden welche Schritte vollzogen werden müssen. Dies bedeutet: Anhand des "Upgrade Path" Dokument von Fortinet muss verifiziert werden, welche "Upgrade Schritte" (Upgrade Path) durchgeführt werden müssen. Werden diese "Upgrade Schritte" nicht eingehalten werden, wird zwar ein Upgrade durchgeführt jedoch die Konfiguration - da die "Upgrade Schritte" nicht eingehalten werden - wird Korrupt. Der Grund ist der Folgende: Wenn ein Upgrade durchgeführt wird so werden im Hintergrund Scripts angewendet um die Konfiguration auf den neusten Stand zu bringen. Diese Scripts gehen von einem FortiOS Version aus gemäss "Upgrade Path". Stimmt diese FortiOS Version nicht überein, kommt des zu Script Fehlern und somit zu Konfigurationsfehlern. Im nachfolgenden Dokument werden diese "Upgrade Path's" abgebildet:

        [[Datei:FortiOS-Upgradepath-54.pdf]]

Wenn ein FortiGate Device über FortiGuard korrekt registriert wurde, wird über die FortiCare Funktion auf dem FortiGate Device eine Meldung ausgegeben, dass eine neue FortiOS Version zur Verfügung steht und ein Upgrade durchgeführt werden kann! Dabei ist es möglich direkt diese Meldung/Information zu benutzen um in einem oder mehreren Schritten über FortiGuard ein Upgrade durchzuführen. Dabei ist jedoch folgendes zu berücksichtigen: Unter FortiOS 5.4 im Gegensatz zu früheren Versionen, wird eine upgrade Möglichkeit evaluiert dh. Ueber diese neue Funktion werden nur Versionen angeboten, die im Zusammenhang mit dem Upgrade Path durchgeführt werden können. Wir empfehlen diese Funktion nicht zu benützen und den Upgrade Hinweis als Hinweis für ein mögliches Upgrade zu benutzen und anhand des Upgrade Paths zu kontrollieren welcher Upgrade Path Möglichkeiten zur Verfügung stehen. Ein entsprechendes FortiOS Image für ein Upgrade über FortiGuard runterzuladen wird von unserer Seite her nicht empfohlen. Ein FortiOS Image für ein mögliches Upgrade sollte regulär über die Support Seite von Fortinet runtergeladen werden um anhand diese kontrolliert und manuell ein Upgrade auf dem Mgmt. Web Interface der FortiGate durchzuführen. Ein "Upgrade" kann manuell über Mgmt. Web Interface durchgeführt werden oder über CLI anhand eines TFTP Servers der sich im lokalen Netzwerk befindet und anhand diesem ein entsprechendes FortiOS Image auf den FortiGate Device hochgeladen wird damit anhand diesem später über Mgmt. Web Interface ein Upgrade ausgeführt werden kann. Ausgangslage für ein "Upgrade" ist das entsprechende FortiOS Image das über die Support Seite von Fortinet für jeden FortiGate Device zur Verfügung gestellt wird. Um ein entsprechendes FortiOS Image runterzuladen muss über die Support Seite von Fortinet in dem ein entsprechender Device registriert wurde eingeloggt werden:

        https://support.fortinet.com

Logge dich auf der "Support Seite" ein anhand des Usernamens und Passwortes. Danach wähle unter "Download" die Position "Firmware Images":

        [[Datei:Fortinet-1651.jpg]]

Nun kann im "Scrollbalken" das entsprechende "Product" gewählt werden zB "FortiGate":

        [[Datei:Fortinet-1652.jpg]]

Nachdem das "Product" gewählt wurde wählt man "Download". Danach öffnet sich über den Browser der "FTP" Download Server und es kann die entsprechende Version gewählt werden:

        [[Datei:Fortinet-1653.jpg]]

Wenn man im entsprechenden Verzeichnis der entsprecheneen FortiOS Version ist, kann für das entsprechende FortiGate Modell das FortiOS Image runtergeladen werden:

        [[Datei:Fortinet-1654.jpg]]
        
        '''NOTE''' Fortinet begrenzt den Download zu Beginn auf 2 gleichzeitige Downloads. Dies bedeutet: Zu Beginn können zwei Files/Images
             gleichzeitig runtergeladen werden danach können nur noch einzelne Files runtergeladen werden!

Sobald das entsprechende FortiOS Image runtergeladen wurde, kann über Mgmt. Web Interface oder CLI ein Upgrade durchgeführt werden. Dabei ist zu empfehlen vor dem Ausführen des Upgrade ein "Backup" der Konfiguration durchzuführen. Weitere Informationen dazu wie ein "Backup" durchgeführt wird siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einem_FortiGate_Device_ein_Backup.2FRestore_durchf.C3.BChren.3F]]

Wenn ein Upgrade über CLI durchgeführt werden soll anhand eines zur Verfügung stehenden "TFTP" Servers im lokalen Netz und ausgehend davon das sich das entsprechende FortiOS Image im "Root Verzeichnis" des "TFTP" Servers befindet, kann folgendes ausgeführt werden:

        # execute restore image tftp [Name des Images] [IPv4 Adresse des TFTP Servers]
        This operation will replace the current firmware version!
        Do you want to continue? (y/n) '''y'''

        '''NOTE''' Es kann auch ein Upload des Images über einen FTP Server, USB usw. durchgeführt werden:
             
             # execute restore image [tftp, ftp usb, flash, management-station] 

Um ein Upgrade über Mgmt. Web Interface durchzuführen kann folgendes gewählt werden:

        Dashboard > System Information > Firmware Version: > Update > Upload Firmware > Upload Firmware

        [[Datei:Fortinet-1655.jpg]]

        [[Datei:Fortinet-1656.jpg]]

        [[Datei:Fortinet-1657.jpg]]

Ein "Upgrade" wird mit der Position "Upgrade" ausgelöst. Dabei ist folgendes zu berücksichtigen: Das entsprechende FortiOS Image wird in seiner Konsistenz sowie für den entsprechenden FortiGate Device überprüft dh. ob das entsprechende FortiOS Image mit dem entsprechenden FortiGate Device übereinstimmt. Es wird jedoch kein "Validierung" durchgeführt dh. ob das entsprechende FortiOS Image ein Image gemäss "Upgrade Path" ist und angewendet werden kann. Somit ist theoretischerweise ein "Downgrade" über die "Upgrade" Funktion möglich jedoch absolut nicht zu empfehlen. Wenn der "Upgrade" Prozess bestätigt wurde kann es durchaus einige Minuten dauern bis der Vorgang abgeschlossen wurde. Es ist nicht zu empfehlen diesen "Vorgang" abzubrechen. Der "Upgrade" Prozess sollte auf der Mgmt. Console (RS-232) mitverfolgt werden sofern dies überhaupt möglich ist. Der Abschluss eines "Upgrade" Vorgangs wird mit einem Neustart des Devices abgeschlossen. Dieser Neustart sollte sofern möglich auf der Mgmt. Console mitverfolgt werden da allfällige Fehlermeldungen nur in dieser Console direkt ausgegeben werden. Ist dies nicht möglich sollte nach einem Neustart des Devices folgendes Log konsultiert werden um allfällige Fehlermeldungen zu verfifzieren:

        # diagnose debug config-error-log read

Dieses "config-error-log" kann nach Verifizierung ebenfalls zurückgesetzt resp. gelöscht werden:

        # diagnose debug config-error-log clear

Wenn es nachdem Neustart des Devices oder auch in einem späteren Zeitpunkt zu Problemen kommt und ein "Roll-Back" zur vorherigen FortiOS Version soll initiert werden, kann dies anhand der Backup Partition durchgeführt werden. Wie dies durchzuführen ist und was dabei beachtet werden muss siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_f.C3.BCr_einen_FortiGate_Device_nach_einem_FortiOS_5.4_Update_einen_.22Roll-Back.22_initieren.3F]]

=== Wie kann ich für einen FortiGate Device nach einem FortiOS 5.4 Update einen "Roll-Back" initieren? ===

Wenn man ein Firmware Update durchführt sei es über Mgmt. Web Interface oder über CLI wird automatisch die aktuelle laufenden Partition deaktivert und eine zweite Partition mit dem neuen FortiOS aktiviert. Dies bedeutet: Ein FortiGate Device stellt für die FortiOS Installation/Update zwei Partitionen zur Verfügung. Dabei spielt es keine Rolle ob die aktive Partition die "primary" oder die "secondary" ist. Bei einem Update wird die "nicht aktive" Partition benutzt/gelöscht und darin die neue Version des FortiOS installiert. Für die "aktive" Partition dh. Ausgangslage des Upgrade werden keine Modifikationen durchgführt. Nachdem die neue Version des FortiOS in der "nicht aktiven" Partition installiert wurde, wird von der "aktiven" Partition ein reguläres Backup gezogen. Dieses Backup wird in der "nicht aktiven" Partition als Restore importiert sowie anhand Scripts diese Konfiguration auf den neusten Stand gebracht. Nachdem dies erfolgreich durchgeführt wurde, wird die "nicht aktive" Partition aktiviert und die "aktive" Partition deaktiviert. Danach wird ein Neustart des FortiGate Devices ausgeführt. Um auf dem FortiGate Device alle Partitionen aufzulisten benütze folgendes Kommando:
        
        # diagnose sys flash list
        Partition  Image                                     TotalSize(KB)  Used(KB)  Use%  Active
        1          FGT60D-5.02-FW-build701-151203                   253871     32491   13%  No    
        2          FGT60D-5.04-FW-build1011-151221                  253871     36706   14%  Yes   
        3          ETDB-1.00000                                    3368360    105720    3%  No    
        Image build at Dec 21 2015 23:25:26 for b1011

In diesem Beispiel sieht man das ein Upgrade durchgeführt wurde von "5.02" auf "5.04". Die Partition von "5.04" wurde aktiviert (Active Yes). Um nun ein "Roll-Back" initiert dh. die Partition von "5.02" zu aktivieren kann folgendes durchgeführt werden:

        # execute set-next-reboot [secondary | primary]

In unserem Beispiel würden wir für Partition "1" primary wählen. Wenn ein "Roll-Back" initiert wird ist folgendes zu berücksichtigen: Von FortiOS Version zu FortiOS Version unterscheiden sich die Datenbankeinträge betreffend Log dh. Tabellen kommen dazu und/oder Tabellen werden gelöscht. Bei einem Upgrade führen die entsprechenden Scripts beim Import des Restore diese Modifikation durch. Bei einem Downgrade wird dies nicht durchgeführt. Somit, wenn ein Downgrade durchgeführt wird kann es nach dem Neustart betreffend diesen Datenbank Einträgen zu Problemen kommen. Diese Datenbankeinträge befinden sich auf der lokalen "disk". Wird diese "disk" vorgängig formatiert dh. vor dem Downgrade wird beim Neustart die entsprechende Datenbank neu mit den korrekten Einträgen erstellt. Es muss jedoch berücksichtigt werden, dass alle Informationen bei einer Formatierung der "disk" verloren gehen dh. Log und Report. Verfügt der entsprechende FortiGate Device nicht über eine "disk" dh. diese wird im "memory" angelegt anhand "MTD" so wird diese bei einem Neustart jedesmal neu erstellt. Aus diesen Gründen ist es dringend empfohlen vor einem Downgrade resp. bevor ein Neustart ausgeführt wird die "disk" zu formatieren:

        # execute formatlogdisk
        Log disk is /dev/sdb4
        Formatting this storage will erase all data on it, including
          Logs, quarantine files;
          WanOpt caches;
        and requires the unit to reboot.
        Do you want to continue (y/n) '''y'''

Wenn nachträglich wieder die Ausgangspartition aktiviert werden soll kann die entsprechende Partition aktiviert werden sowie die "disk" abermals formatiert werden.

=== Wo finde ich einen Ueberblick über die zur Verfügung stehenden FortiOS Versionen im Allgemeinen? ===

Nun ein FortiOS Release wird bezeichnet durch seinen Release Bezeichnung dh. "GA" (General Availibility) oder "MR" (Master Release) plus die Versions Nummer zB MR3. Die Patch Level werden bezeichnet mit der entsprechenden Nummerierung dh. zB P2 usw. Dahinter steht eigentlich eine Build Nummer dh. zB Build 0228 was wiederum unter FortiOS 5 Patch 4 also P4 entspricht. Also stehen Patch Nummern im Zusammenhang mit Build Nummern. Welcher Patch Level über welche Build Nummer verfügt sieht man in der unten aufgeführten Aufstellung:

     '''FortiOS 5'''
     [[Datei:Fortinet-1649.jpg]]

     '''FortiOS 4'''
     [[Datei:Fortinet-1650.jpg]]

Diese Informationen stammen aus "Fortinet Forum" und werden dort auch auf den neusten Stand gehalten. Weitere detaillierte Information betreffend tieferen Version wie FortiOS 3 kann diesem Fortinet Forum Post entnommen werden:

        https://forum.fortinet.com/tm.aspx?m=86591

== 3G/4G Modem ==

=== Welche 3G/4G USB Modem's kann ich unter FortiOS 5.4 für eine FortiGate Device benutzen (Kompatibilität)? ===

Ein FortiGate Device kann unter FortiOS 5.4 mit einem 3G/4G USB Modem ausgerüstet werden dh. zusätzlich zu einer regulären Verbindung zB PPPoE als "failover" Variante (Dual-ISP) oder als reguläre Hauptverbindung für den Internet Access. Der Hersteller Fortinet stellt keine 3G/4G USB Modem zur Verfügung jedoch eine Kompatibilitäts-Liste in der 3G/4G USB Modems aufgelistet sind die unterstützt werden. Dabei ist folgendes zu beachten: Bei der Kompatibilitäts-Liste werden 3G/4G USB Modems basierend auf deren Orginal Firmware aufgeführt die Kompatibel sind mit einem FortiGate Device. Somit ist darauf zu achten, dass 3G/4G USB Modems betrieben werden mit der orginal Firmware des Herstellers und nicht mit modifizierten Firmware des ISP der diese 3G/4G USB Modems zu Verfügung stellt! Fortinet stellt ein Dokument zur Verfügung in dem die kompatiblen 3G/4G USB Modems aufgelistet sind:

        [[Datei:Fgt-modem-matrix.pdf]]

Um die aktuelle Kompatibilitäts-Liste betreffend 3G/4G USB Modems auf einem FortiGate Device unter FortiOS 5.4 auszulesen, muss der entsprechende Menüpunkt im Web Mgmt. Interface aktiviert werden. Dies wird durchgführt in dem die "modem" Funktion generell aktiviert wird:

        # config sys modem
        # set status [enable | disable]
        # end

Danach steht über Web Mgmt. Interface ein entsprechender Menüpunkt "Modem" unter folgender Position zur Verfügung und die Kompatibilitäts-Liste kann über diese eingesehen werden:

        Network > Modem > External Modem > Modem > Configure Modem

        [[Datei:Fortinet-2118.jpg]]

        [[Datei:Fortinet-2119.jpg]]

Per Standard steht auf einem FortiOS 5.4 die "Modem List" in der Version 1.040 zur Verfügung. Dies kann mit nachfolgenden Befehl ebenfalls über CLI kontrolliert werden:

        # get system auto-update version

Durch diesen Befehl werden sämtliche Informationen angezeigt betreffend den einzelnen UTM Datenbanken sowie Listen inkl. der "Modem List":

        Modem List
        ---------
        Version: 1.040

Um diese Liste auf den neusten Stand zu bringen kann im Web Mgmt. Interface die Position "FortiGuard" benutzt werden oder mit folgenden Befehl auf der CLI erzwungen werden:

        # execute update-now

Durch diesen Befehl in der CLI werden alle Informationen auf den neusten Stand gebracht und somit steht die neuste Kompatibilitäts-Liste für 3G/4G USB Modems ebenfalls zur Verfügung und kann über Web Mgmt. Interface eingesehen werden.

=== Gibt es zur 3G/4G USB Modem Installation unter FortiOS 5.4 eine Alternative für eine FortiGate Device? ===

Im nachfolgenden Artikel wird erklärt welche Voraussetzungen gelten, wenn mit 3G/4G USB Modems unter FortiOS 5.4 gearbeitet wird:

        [[FortiGate-5.4:FAQ#Welche_3G.2F4G_USB_Modem.27s_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_Device_benutzen_.28Kompatibilit.C3.A4t.29.3F]]

Somit liegt das Problem an den 3G/4G USB Modems die durch die ISP Provider mit speziellen Firmware modifiziert wurden und somit obwohl in der Kompatibilitäts-Liste aufgeführt unter FortiOS nicht mehr richtig erkannt werden. Die 3G/4G USB Modems so zu modifzieren damit diese über die orginal Firmware verfügen ist zwar technisch möglich, jedoch nicht immer einfach und ohne "Unlock Code" basierend aus der IMEI Nummer nicht möglich. Um die ganze Problematik zu umgehen wäre es einfach einen Device zur Verfügung zu haben, in dem einfach eine SimCard eingesetzt würde. Seit April 2016 ist dies möglich, denn Fortinet stellt mit dem FortiExtender 40D genau diese Möglichkeit zur Verfügung. Weitere Informatione zum FortiExtender 40D siehe nachfolgender Artikel:

        [[Fortinet:ProduktInfo#FortiExtender]]

Dabei handelt es sich beim FortiExtender um folgendes: Ein FortiExtender 40D ist ein Device in dem eine SimCard eingesetzt werden kann und über RJ-45 an die FortiGate Device über ein Segment zB "wan1" verbunden wird. Ein FortiExtender komuniziert/verbindet sich ähnlich wie ein Forti Access Point (CAPWAP) zum FortiGate Device. Dies bedeutet: Damit ein FortiExtender Device sich über ein entsprechendes Segment zB "wan1" Interface zur FortiGate verbinden kann, muss auf der einen Seite der Wireless Controller des FortiGate Devices aktiviert sein sowie die Funktion des FortiExtender Controllers. Zusätzlich muss auf dem entsprechenden Interface dh. zB "wan1" CAPWAP (UDP-5246) aktiviert werden, damit der FortiExtender zum Wireless Controller der FortiGate komunizieren kann. Nachträglich kann der FortiExtender Authorisiert werden und steht danach als Interface zur Verfügung. Wie ein Konfiguration/Einbindung eines FortiExtenders durchgeführt wird siehe nachfolgender Artikel:

        [[Datei:Setting-up-an-Internet-connection-through-a-FortiGate-unit-using-a-3G-4G-modem-and-a-FortiExtender.pdf]]

Eine andere Alternative wäre zB "D-Link model DWM-221". Bei diesem Gerät handelt es sich um einen USB Modem bei dem es möglich ist direkt eine entsprechende SimCard zu benutzen. Weitere Informationen siehe nachfolgender Link Menüposition "Specifications":

        http://www.dlink.com/de/de/support/product/dwm-221-4g-lte-usb-adapter

Fortinet hat für dieses Modell ein KB Artikel erstellt:

        http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD38795&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=83877243&stateId=0 0 83879118

Darin wird folgendes beschrieben:

        # config system 3g-modem custom
        # edit [Definiere einen entsprechenden Integer zB "1"]
        # set vendor "D-Link"
        # set model "DWM-221"
        # set vendor-id 2001
        # set product-id 7e19
        # next
        # end

        # config system modem
        # set status enable
        # set pin-init "AT+CPIN=\"[Definiere den entsprechenden PIN für die SIMCard]\"" 
        # set auto-dial enable
        # set idle-timer 1
        # set redial 10
        # set wireless-port 2
        # set phone1 "*99#"
        # set username1 "[Definiere einen entsprechenden Usernamen]" 
        # set passwd1 "[Definiere das entsprechende Passwort für den Usernamen]" 
        # set extra-init1 "at+cgdcont=1,\"IP\",\"[Definiere das entsprechende Passwort]\"" 
        # set altmode disable
        # set distance 11
        # end

In der Schweiz wird für eine 3G/4G Verbindung kein "Username" und "Passwort" benützt. Somit sollten diese Positionen mit "unset unsername1" sowie "unset passwd1" zurück gesetzt werden. Um für diese Verbindung resp. "3g-modem custom" ein Troubleshooting durchzuführen benütze folgendes:

        1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
        2. Erstelle eine SSH Verbindung zur FortiGate
        3. Führe ein Login durch und gebe folgendes ein:
           
           '''Setze alle Debug Filter zurück'''
           
           # diagnose debug reset

           '''Setze einen Debug Filter für "modemd sowie ppp"'''
           
           # diagnose debug application modemd -1 
           # diagnose debug app ppp -1

           '''Aktiviere für den debug "output" den "timestamp"'''
           
           # diagnose debug console timestamp enable

           '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
           
           # diagnose debug enable

Nachdem das Troubleshooting erfolgreich durchgeführt wurde setze alle Filter zurück sowie deaktiviere den Debug Mode:

        # diagnose debug disable
        # diagnose debug reset

=== Wie kann ich ein 3G/4G USB Modem unter FortiOS 5.4 für eine FortiGate Device manuell konfigurieren? ===

Ausgehend davon das ein entsprechendes 3G/4G USB Modem auf der Kompatibilitäts-Liste erscheint, jedoch dieses manuell konfiguriert werden soll und nicht anhand des existierenden Kompatibilitäts-Listen Eintrag kann dies durchgeführt werden. Voraussetzung dafür sind folgende Informationen die es zur einer manuellen Konfiguration benötigt:

        • Vendor
        • Model
        • Vendor ID (Hex)
        • Product ID (Hex)
        • Init String
        • USB Modem dial-out port

Diese Informationen können durch den Hersteller eines 3G/4G USB Modem zur Verfügung gestellt werden oder über das FortiOS direkt ausgelesen werden. Ein 3G/4G "nicht" Hot-Swap dh. das 3G/4G USB Modem muss beim Start des FortiGate Devices angeschlossen sein um dieses durch die FortiGate einwandfrei zu erkennen und eine manuelle Konfiguration durchzuführen. Auch nach einer einwandfreier Erkennung nach einem Start des FortiGate Devices darf das 3G/4G USB Modem nicht aus- und wieder eingesteckt werden dh. das Funktioneren eines 3G/4G USB Modems unter einer FortiGate wird nur dann gewährleistet, wenn das 3G/4G USB Modem beim Start einer FortiGate am Device angeschlossen ist. Die vorhergehenden Informationen die zur einer manuellen Konfiguration eines 3G/4G USB Modems notwendig sind, können wie schon erwähnt auch nachträglich über folgenden Befehl ausgelesen werden:

        # fnsysctl cat /proc/bus/usb/devices

Durch diesen Befehl werden sämtliche Informationen aufgelistet betreffend USB Devices. Ausgehend davon das das 3G/4G USB Modem nach dem Start im FortiOS korrekt erkannt wurde wird dieses mit folgenden Informationen aufgelistet:

        P:  Vendor=0f3d ProdID=68aa Rev= 0.06
        S:  Manufacturer=Sierra Wireless, Incorporated
        S:  Product=AirCard 320U

Anhand dieser Informationen kann nun das 3G/4G USB Modem manuell Konfiguriert werden wobei zu berücksichtigen ist, dass der "init-string" nur durch den Hersteller zur Verfügung gestellt werden kann:

        # config system 3g-modem custom
        # edit [Vergebe einen entsprechenden Integer zB "1"]
        # set vendor [Vergebe den entsprechenden "vendor" Namen zB "Sierra Wireless"]
        # set model [Vergebe den Namen des entsprechenden Modells zB "320U"]
        # set vendor-id [Vergebe in Hex die entsprechende "vendor-id" zB "0f3d"]
        # set product-id [Vergebe in Hex die ensprechende "product-id" zB "68aa"]
        # set init-string ["init-string" des Herstellers]
        # end

Nun steht dieses "3g-modem custom" 3G/4G USB Modem für die Verwendung zur Verfügung. Als nächstes müssen die verschiedenen Optionen für das Modem im FortiOS konfiguriert werden. Dazu gehört der "dial-out port" des 3G/4G USB Modems. Dieser "dial-out port" wird mit folgendem Befehl konfiguriert:

        # config system modem
        # set wireless-port [0 | 1 | 2; Standard 0]
        # end

Um den Port zu testen/verifizieren kann folgendes durchgeführt werden:

        # diagnose sys modem com /0

Wenn der Port zB "0" korrekt ist wird folgendes ausgegeben:

        Serial port: /dev/0

Wenn der Port zB "0" nicht korrekt ist, wird folgendes ausgegeben:

        Can not open modem device ‘/dev/0’ : Broken pipe

Danach können die verschiedenen Optionen für die Funktion "Modem" konfiguriert werden:

        # config system modem
        # set status [enable | disable]
        # set pin-init [Setze AT Kommando für PIN]
        # set network-init [Setzt den "Network Operation" AT command zB "AT+COPS=<mode>,[<format>,<oper>[,<AcT>]]"; Standard 0 = Auto / 1 = Manuell]
        # set lockdown-lac [Erlaubt nur LAC "local area code"; Standard null]
        # set mode [redudant | standalone]
        # set auto-dial [enable | disable]
        # set dial-on-demand [enable | disable]
        # set idle-timer [Nur bei "mode standalone"; Setzt Idel; Standard 5 Minuten]
        # set redial [Maximaler Wählvorgang 1-10; Standard null]
        # set reset [Definiere den "reset" 0-10]
        # set holddown-timer [Nur zu benutzen für Fallback 1 - 60 Sekunden; Standard 60]
        # set connect_timeout [Definiere das Timeout in Sekunden 30 - 255; Standard 90]
        # set wireless-port [TTY Port für 3G/4G USB Modems; Standard 0 = Default]
        # set dont-send-CR1 [enable | disable]
        # set dial-cmd1 [Definiere sofern notwendig ein "dial-cmd"]
        # set username1 [Username dial-up Konto]
        # set passwd1 [Passwort dial-up Konto]
        # set extra-init1, extra-init2, extra-init3 [Extra Init String des Modem]
        # set peer_modem1 [actiontec | ascendTNT | generic]
        # set ppp-echo-request1 [disable | enable]
        # set authtype1 [pap chap mschap mschapv2]
        # set dont-send-CR2 [enable | disable]
        # set dial-cmd2 [Definiere sofern notwendig ein "dial-cmd"]
        # set username2 [Username dial-up Konto]
        # set passwd2 [Passwort dial-up Konto]
        # set extra-init2 [Extra Init String des Modem]
        # set peer_modem2 [actiontec | ascendTNT | generic]
        # set ppp-echo-request2 [disable | enable]
        # set authtype2 [pap chap mschap mschapv2]
        # set dont-send-CR3 [enable | disable]
        # set dial-cmd3 [Definiere sofern notwendig ein "dial-cmd"]
        # set username3 [Username dial-up Konto]
        # set passwd3 [Passwort dial-up Konto]
        # set extra-init3 [Extra Init String des Modem]
        # set peer_modem3 [actiontec | ascendTNT | generic]
        # set ppp-echo-request3 [disable | enable]
        # set authtype3 [pap chap mschap mschapv2]
        # set distance [Definiere die Routing "distance"; Standard 10]
        # set priority [Definiere die Routing "priority"; Standard 0]
        # end

Um das Modem zu Erkennen resp. zu Testen stehen verschiedenen Kommandos zur Verfügung:

        # diagnose sys modem detect
        modem is attached.
        dialtone is detected.

        # diagnose sys modem external-modem
        External modem vendor: Sierra Wireless
        External modem model : 320U

        # diagnose sys modem history
        Date&Time     Duration     IP Recv'd     Sent     Total     Status

Um ein Wählen des Modems auszulösen (Nur für Standalone "mode") führe folgendes durch:

        # execute modem dial

Um ein Aufhängen des Modems auszulösen (Nur für Standalone "mode") führe folgendes durch:

        # execute modem hangup

Das nachfolgende Kommando sendet dem Modem Deamon ein Signal. Dadurch wird der Modem Deamon gezwungen seinene Status/Konfiguration neu zu evaluieren. Wenn das 3G/4G USB Modem nicht verbunden ist wird ein "redial" ausgelöst. Wenn das 3G/4G Modem verbunden ist wird ein Aufhängen durchgeführt:

        # execute modem trigger

Zusätzlich kann für den Modem Deamon ein Debug durchgeführt werden dh. führe folgendes aus:

        '''Setze alle Debug Filter zurück'''
        
        # diagnose debug reset

        '''Setze einen Debug Filter für die Applikation "modemd"
        
        # diagnose debug console time enable 
        # diagnose debug application modemd -1 

        '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug enable 

Um den Debug Modus zu beenden und alle Filter zurück zu setzen führe folgendes aus: 

        # diagnose debug disable
        # diagnose debug reset

=== Auf was muss ich bei einer "Dual-ISP" Konfiguration für ein 3G/4G USB Modem unter FortiOS 5.4 achten? ===

Wenn eine Dual-ISP Konfiguration basierend auf einem "failover" Device anhand 3G/4G USB Modem durchgeführt wird, muss darauf geachtet werden das die "dynamic-gateway" Option im Routing für den Default Gateway für das "dynamische Interface" (Modem) aktiviert wird. Da für ein Modem ein "dynamisches Interface" benutzt wird und obwohl das Statische Routing konfiguriert wird, wird die Routing Tabelle nicht auf den neusten Stand gebracht durch die "Link Monitoring" Funktion. In so einem Fall muss der FortiGate mitgeteilt werden, dass für dieses "dynamische Interface" ein ""dynamic-gateway"" gilt und somit die nötige Route/Gateway in die Routing Tabelle automatisch eingetragen wird. Dies wird der FortiGate mit folgendem CLI Kommando mitgeteilt: 

       # config router static 
       # edit [Gebe einen entsprechenden Integer an zB "1"] 
       # set device [Gebe das "dynamische Interface" an für das Modem]
       # set dst 0.0.0.0 0.0.0.0
       # set distance [Gebe die entsprechende "distance" an zB "10"]
       # set priority [Gebe die entsprechende "priority" an zB "0"]
       # dynamic-gateway [enable  | disable]
       # next 
       # end 

Damit diese Konfiguration betreffend "dynamic-gateway" durchgeführt werden kann, muss das entsprechende "dynamische Interface" aktiv sein!

== DNS ==

=== Wie konfiguriere unter FortiOS 5.4 auf einer FortiGate die System DNS Server? ===

Eine FortiGate benützt für verschiedenen Funktionen einwandfreie und schnell antwortende DNS Server. Sind diese nicht erreichbar oder antworten nicht dementsprechend beeinflusst dies verschiedenen Dienst der FortiGate wie zB das WebFiltering. Um die System DNS Server einer FortiGate zu konfigurieren kann das Mgmt. Web Interface benutzt werden. Die Konfiguration findet man unter folgenden Menüpunkt:

        Network > DNS > Specifiy

        [[Datei:Fortinet-1631.jpg]]

Per Standard sind auf jeder FortiGate die "FortiGuard" DNS Server definiert. Die FortiGuard DNS Server ist ein Service innerhalb "FortiGuard" resp. es muss mind. "FortiCare" lizensiert werden damit die "FortiGuard DNS Server" benutzt werden können. Es ist grundsätzlich nicht empfohlen diesen Dienst zu benutzen sondern die ISP DNS Server zu konfigurieren. Um die Konfiguration der DNS Server über CLI durchzuführen führe folgendes aus:

        # config system dns
        # set primary [IPv4 Adresse des DNS 1 Serves]
        # set secondary [IPv4 Adresse des DNS 2 Servers]
        # set domain [Lokale Domaine "optional"]
        # set cache-notfound-response [enable | disable]
        # set dns-cache-limit [Maximum Einträge die im Cache verbleiben; Standard 5000]
        # set dns-cache-ttl [Maximum Zeit in der ein DNS Eintrag im Cache vebleibt; Standard 1800]
        # set source-ip [Source IP die benutzt werden soll für die DNS Anfrage]
        # end
        
        '''NOTE''' Die Option "cache-notfound-response" ist ein Log Relevanter Eintrag dh. wird ein DNS Eintrag nicht im Cache 
             gefunden wird dem Log "NOTFOUND" hinzugefügt!

=== Wie kann ich auf einer FortiGate unter FortiOS 5.4 den DNS Cache löschen, DNS Statistik auflisten usw.? ===

Wenn auf einer FortiGate die DNS Server konfiguriert wurden stehen für diesen DNS Dienst auf der FortiGate verschiedenen Optionen zur Verfügung um diese zu manipulieren dh. zB neu zu starten. Nachfolgender Befehl zeigt wie die verschiedenen Option die zur Verfügung stehen aufgelistet werden:

        # diagnose test application dnsproxy
        1. Clear DNS cache
        2. Show stats
        3. Dump DNS setting
        4. Reload FQDN
        5. Requery FQDN
        6. Dump FQDN
        7. Dump DNS cache
        8. Dump DNS DB
        9. Reload DNS DB
        10. Dump secure DNS policy/profile
        11. Reload Secure DNS setting
        12. Show Hostname cache
        13. Clear Hostname cache
        14. DNS debug bit mask

Anhand dieser Optionen lässt sich zB der DNS Cache des DNS Dienstes löschen:

        # diagnose test application dnsproxy 1

Nachfolgend den Befehl um den DNS Statistik aufzulisten:

        # diagnose test application dnsproxy 2

=== Kann ich auf einer FortiGate unter FortiOS 5.4 eine bestimmte "DNS Anfrage" umschreiben (translation)? ===

Wenn in einer bestimmten Umgebung eine "DNS Anfrage" anderst beantwortet werden soll als in einer anderen Umgebung spricht man von einem "Split DNS Server" dh. dieser beantwortet Anfragen von bestimmten "Source Adressen" anderst als von anderen "Source Adressen". Dies wird dann genutzt wenn "Interne" Informationen und "Externe" kollidieren. Beispiel: Wenn ein User als Mail Server "mail.mydomain.ch" konfiguriert hat so wird dieser Mail Server ausserhalb des "Office" als "Public IP" aufgelöst also zB "212.59.153.125". Benutzt der User den Mail Server im "Office" und im Office existiert "kein" Interner DNS Server so wird "mail.mydomain.ch" abermals als "Public IP" aufgelöst. Der Nachteil ist - obwohl sich der User und Mail Server im gleichen Segment befindet - wird der Traffic von "mail.mydomain.ch" - da dieser mit der Public IP aufgelöst wird - zur Firewall gesendet. Der Grund ist Routing bedingt dh. "212.59.153.125" befindet sich nicht im internen Netz, also wird der Traffic über den Default Gateway des Users zur Firewall gesendet. Die richtige Lösung für dieses Problem ist ein "Split DNS" Server dh. wenn ein interner DNS Server vorhanden ist so wird ein "Forwarder" für "mydomain.ch" konfiguriert und für "mail.mydomain.ch" die IP Adresse zB "192.168.1.100" konfiguriert, denn diese stellt die interne Adresse von "mail.mydomian.ch" dar. Ist kein interner DNS Server vorhanden kann die "Split DNS" Server Funktion auf einer FortiGate benutzt werden. Kann man aus irgendwelchen Gründen kein "Split DNS" Server konfigurieren kann die Funktion "dnstranslation" benutzt werden. Diese Funktion steht im Zusammenhang mit dem "Session-Helper". Um eine "dnstranslation" zu konfigurieren muss die CLI benutzt werden. In unserem Beispiel gehen wir von folgender Konstellation aus:

        Mail Server FQDN mail.mydomain.ch
        Mail Server Public IP 212.59.153.125
        Mail Server Internal IP 192.168.1.100

Als nächstes muss kontrolliert werden ob für DNS (udp) ein entsprechender "session-helper" existiert:

        # show system session-helper
        edit 13
        set name dns-udp
        set port 53
        set protocol 17

Ist der "session-helper" für DNS (udp) nicht vorhanden konfiguriere diesen folgendermassen:
        
        # config system session-helper
        # edit [Wähle einen Integer zB 20]
        # set name dns-udp
        # set port 53
        # set protocol 17
        # end
        
        '''NOTE''' Weitere Informationen über die Option "protocol" siehe nachfolgender Artikel:
             
             [[Allgemein:Assigned-Internet-Protocol-Numbers-RFC]]

Als nächstes kann die Funktion "dnstranslation" konfiguriert werden anhand dieser wir gemäss unserem Beispiel eine entsprechende Antwort des DNS Servers auf "mail.mydomain.ch" mit der IPv4 Adresse von "212.59.153.125" umschreiben (translate) auf die interne IPv4 Adresse "192.168.1.100":

        # config firewall dnstranslation
        # edit [Gebe einen Integer an zB "1"]
        # set dst [IPv4 Internal Adresse von mail.mydomain.ch "192.168.1.100"]
        # set netmask [Netmask für mail.mydomain.ch "255.255.255.255"]
        # set src [IPv4 Public Adresse von mail.mydomain.ch "212.59.153.125"]
        # end

Die Anfrage an den Public DNS Server sowie dessen Antwort werden folgendermassen auf der FortiGate abgearbeitet:

        Anfrage = User --> nslookup mail.mydomain.ch --> Anfrage an Public DNS Server --> FortiGate Policy Allow --> Public DNS Server Anfrage "mail.mydomain.ch"
        Antwort = Public DNS Server Antwort mail.mydomain.ch --> 212.59.153.125 --> FortiGate "Session-Helper" --> "dnstranslation" Funktion = 192.168.1.100 --> User
        
        '''NOTE''' Wie hier in diesem Beispiel gezeigt kann die Funktion anhand "nslookup" getestet werden und somit verifiziert werden 
             ob die "dnstranslation" korrekt funktioniert!

In diesem Sinne kann jede DNS Anfrage die über die FortiGate läuft umgeschrieben werden (translate). Natürlich ist diese Funktion nicht "nur" auf Public DNS Server beschränkt sondern nur auf Port 53 DNS (udp). Dies bedeutet diese Funktion "dnstranslation" kann ebenfalls für temporaere Umleitungen im internen Bereich benutzt werden!

== DDNS ==

=== Wie konfiguriere unter FortiOS 5.4 auf einer FortiGate den "DDNS" Server Dienst basierend auf FortiGuard? ===

Grundsätzlich steht die Konfiguration eines DDNS (Dynamic Domain Name System) auf einer FortiGate über Mgmt. Web Interface unter folgender Position zur Verfügung:

        Network > DNS > Use FortiGuard Servers

        [[Datei:Fortinet-1630.jpg]]

Wie aus der Abbildung ersichtlich wird mit einer Meldung daraufhingewiesen, dass der "FortiGuard Service" nicht erreichbar ist dh. bei diesem "DDNS" Dienst handelt es sich um einen FortiGuard Service und muss somit Lizensiert werden. Der "DDNS" Dienst von "FortiGuard Service" ist enthalten in der "FortiCare" Lizensierung. Weitere Informationen dazu welche Dienste in "FortiCare" enthalten sind siehe nachfolgenden Artikel:

        [[Fortinet:FortiCare-FortiGuard#Wenn_ich_.22nur.22_DDNS_.28Dynamic_DNS.29.2C_GeoIP.2C_NTP_und_DNS_Service_von_FortiGuard_benutze_was_muss_ich_im_Minimum_lizensieren.3F]]

Die "DDNS" Konfiguration über Mgmt. Interface lässt sich nur dann konfigurieren wenn der "FortiGuard Service" erreichbar ist resp. verfügbar. Nichts desto trotz kann die Konfiguration auch über CLI durchgeführt werden, unabhängig ob der "FortiGuard Service" erreichbar ist oder nicht. Die Konfiguration wird folgendermassen durchgeführt:

        # config system ddns
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set ddns-server FortiGuardDDNS
        # set ddns-domain [Zu verwendeter Hostname plus DDNS Dienst zB "myhost.fortidyndns.com"]
        # set use-public-ip [enable | disable]
        # set monitor-interface [Angabe des entpsrechenden Interface's für den Hostnamen zB "wan1"]
        # set bound-ip [Definition IPv4 Adresse wenn "use-public-ip" aktiviert wurde]
        # end

        '''NOTE''' Unter normalen Umständen ist "use-public-ip" nicht zu aktivieren dh. durch die Definition von "monitor-interface" wird der 
             definiert "Hostname" resp. "ddns-domain" auf das definiert Interface gebunden und dessen IPv4 Adresse. Dabei spielt es keine
             Rolle ob die IPv4 Adresse "statisch" und/oder "dynamisch" konfiguriert wurde. Möchte man über den "DDNS" Service eine "public" 
             IPv4 Adresse konfiguriert die zwar im Subnet des definierten Interfaces enthalten ist jedoch nicht direkt auf dem Interface 
             konfiguriert wurde, kann durch Aktivierung der Option "use-public-ip" diese anhand "bound-ip" definiert werden!

=== Kann ich auf einer FortiGate unter FortiOS 5.4 einen "DDNS" Server Dienst wie zB "dyndns" konfigurieren? ===

Neben den "FortiGuardDDNS" Service kann auf einer FortiGate weitere "DDNS" Dienste konfiguriert werden. Diese sind die Folgenden:

        dyndns.org        members.dyndns.org and dnsalias.com
        dyns.net          www.dyns.net
        ods.org           ods.org
        tzo.com           rh.tzo.com
        vavic.com         Peanut Hull
        dipdns.net        dipdnsserver.dipdns.com
        now.net.cn        ip.todayisp.com
        dhs.org           members.dhs.org
        easydns.com       members.easydns.com
        genericDDNS       Generic DDNS based on RFC2136.

Die Konfiguration muss jedoch über CLI durchgeführt werden und steht über Mgmt. Interface nicht zur Verfügung:

        # config system ddns
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set ddns-server [dyndns.org | dyns.net | ods.org | tzo.com | vavic.com | dipdns.net | now.net.cn | dhs.org | easydns.com | genericDDNS]
        # set ddns-domain [Zu verwendeter Hostname plus DDNS Dienst zB "myhost.fortidyndns.com"]
        # set ddns-auth [disable | tsig]
        # set ddns-keyname [DDNS Key Name]
        # set ddns-key [DDNS Update Key (base 64 encoded)]
        # set ddns-username [Gebe einen DDSN Usernamen an]
        # set ddns-password [Gebe einen DDSN Passwort an]
        # set use-public-ip [enable | disable]
        # set monitor-interface [Angabe des entpsrechenden Interface's für den Hostnamen zB "wan1"]
        # set bound-ip [Definition IPv4 Adresse wenn "use-public-ip" aktiviert wurde]
        # set ddns-ttl [TTL in Sekunden; Standard 300]
        # end
        
        '''NOTE''' Unter normalen Umständen ist "use-public-ip" nicht zu aktivieren dh. durch die Definition von "monitor-interface" wird der 
             definiert "Hostname" resp. "ddns-domain" auf das definiert Interface gebunden und dessen IPv4 Adresse. Dabei spielt es keine
             Rolle ob die IPv4 Adresse "statisch" und/oder "dynamisch" konfiguriert wurde. Möchte man über den "DDNS" Service eine "public" 
             IPv4 Adresse konfiguriert die zwar im Subnet des definierten Interfaces enthalten ist jedoch nicht direkt auf dem Interface 
             konfiguriert wurde, kann durch Aktivierung der Option "use-public-ip" diese anhand "bound-ip" definiert werden!

Durch die Konfiguration eines "DDNS" Server resp. "genericDDNS" wird ermöglicht einen eigenen "DDNS" Server zu betreiben. Dabei ist jedoch zur berücksichtigen, das auf dem installierten "DDNS" Server "clear-text" Passwörter erlaubt werden da der "DDNS" Dienst auf der FortiGate keine "verschlüsselten" Passwörter unterstützt. Kommt es nachträglich zu Problemen mit dem "DDNS" Dienst kann dieser anhand eines Troubleshooting verifiziert werden. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einer_FortiGate_Verbindungsprobleme_f.C3.BCr_den_.22DDNS.22_Dienst_verifizieren.3F]]

=== Wie kann ich unter FortiOS 5.4 auf einer FortiGate Verbindungsprobleme für den "DDNS" Dienst verifizieren? ===

Um ein Troubleshooting auf einer FortiGate betreffend "DDNS" Dienst durchzuführen muss folgendes auf der CLI durchgeführt werden:

        '''Setze alle Debug Filter zurück'''
        
        # diagnose debug reset

        '''Setze einen Debug Filter für die Applikation "ddnscd"'''
        
        # diagnose debug console time enable 
        # diagnose debug application ddnscd -1 

        '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug enable 

Um den Debug Modus zu beenden und alle Filter zurück zu setzen führe folgendes aus:

        # diagnose debug disable
        # diagnose debug reset

Wenn der "DDNS" Service/Verbindung nicht zu stande kommt dh. zB. falscher Domain Name, Passwort etc. wird durch die FortiGate alle 300 Sekunden (5 Minuten) eine neue Verbindung aufgebaut! Wenn eine Verbindug erfolgreich war wird diese nach 2'592'000 Sekunden (30 Tage) erneut überprüft. Somit sollte der Debug Befehl mind 10 - 15 Minuten laufen um überhaupt Informationen aufzuzeichnen! Wenn der "output" des Debug an den Support weitergeleitet wird, sollten die Passwörter im "output" des Debug entfernt werden da in der "DDNS" Verbindung das Passwort für den "DDNS" Dienst "clear-text" übermittelt wird!

=== Was muss bei einem "Hardware Ausstausch" betreffend "DDNS Name" auf einer FortiGate berücksichtigt werden? ===

Wenn eine "DDNS" Name über einen "DDNS" Dienst registriert wird, ist dieser "Einmalig" und kann nicht zweimal beim gleichen "DDNS" Dienst vergeben werden! Wenn es nun zu einem Hardware Austausch kommt muss folgender berücksichtigt werden: Der "DDNS" Name muss auf der alten Hardware resp. FortiGate deaktiviert werden sei es über Mgmt. Web Interface oder über CLI:
        
        Network > DNS > Use FortiGuard Servers > [Deaktivier "FortiGuardDDNS" Position]

        # config system ddns
        # del [Gebe den entsprechenden Integer an zB "1"]
        # end

Durch das Deaktivieren des "DDNS" Dienstes auf der FortiGate resp. "DDNS" Name wird dieser De-Registriert beim entsprechenden "DDNS" Dienst. Wenn die "alte" FortiGate Hardware nicht mehr zur Verfügung steht zB weil Defekt muss bei Fortinet für den "FortiGuardDDNS" Dienst ein Ticket eröffnet um den "DDNS" Name für die alte Hardware zu De-Registrieren. Dabei ist Wichtig im entsprechenden Ticket die "alte" Serien Nummer des alten FortiGate Devices aufzuführen, den entsprechenden "DDNS" Namen sowie die neue Seriene Nummer des FortiGate Devices. Wird nicht "FortiGuardDDNS" Dienst genutzt sondern ein anderer Dienst wie zB. "dyndns.org", muss eine entsprechende Anfrage an diesen Dienst gesetellt werden für die De-Registrierung des "DDNS" Namens!

== DHCP ==

=== Wie kann ich unter FortiOS 5.4 für ein Interface auf einer FortiGate einen "DHCP Server" Konfigurieren? ===

Wenn ein DHCP Server unter FortiOS 5.4 konfiguriert werden soll, kann dies entweder über Mgmt. Web Interface durchgeführt werden oder unter CLI. Wenn der DHCP Server über Mgmt. Web Interface konfiguriert wird, kann nachfolgende Option aktiviert werden um den "dhcp-advanced" Mode für den DHCP Server zu benutzen. Durch diesen "dhcp-advanced" Mode werden über das Mgmt. Web Interface mehr Optionen/Möglichkeiten aufgelistet um den DHCP Server zu konfigurieren:

        # config system settings
        # set gui-dhcp-advanced [enable | disable]
        # end 

Um einen DHCP Server über Mgmt. Web Interface zu konfigurieren gehe folgendermassen vor:

        Network > Interfaces > [Wähle das entsprechende Interface] > Edit

        [[Datei:Fortinet-1660.jpg]]

        [[Datei:Fortinet-1661.jpg]]

Innerhalb des Interfaces kann der "DHCP Server" aktiviert werden. Wird dies durchgeführt erscheinen die verschiedenen Optionen die unter Mgmt. Web Interface zur Verfügung stehen. Dabei ist folgendes zu beachten:

        '''Address Range'''
        
        Unter "Address Range" muss der DHCP Bereich definiert werden. Der Bereich muss sich innerhalb der "Netmask" befinden der definierten IP für
        das Interface das konfiguriert wird. Es sollte bei diesem DHCP Bereich darauf geachtet werden reguläre "Netmask" zu verwenden und nicht
        frei gewählte IP Bereiche obwohl dies möglich ist! Zum "Address Range" muss die entsprechende "Netmask" definiert werden die analog der IP
        sein muss die für das Interface verwendet wurde! Betreffend regulären "Netmask's" siehe auch nachfolgenden Artikel:
        
        [[Allgemein:CIDR-Block-SubnetMask-Tabelle]]

        '''Default Gateway'''
        
        Unter diesem Punkt wird der "Default Gateway" definiert für den DHCP Bereich. Unter normalen Umständen entspricht der "Default Gateway" der
        IP die für das Interface konfiguriert wurde! Wenn dem nicht so ist kann unter "Specify" eine entsprechende IP definiert werden!

        '''DNS Server'''
        
        Unter diesem Punkt werden die DNS Server definiert die über den DHCP Server einer Workstation vergeben werden. Dazu können über die Position
        "Same as System DNS" die definierten DNS Server unter "Network > DNS" herangezogen werden oder wenn die "DNS Database" Funktion benutzt wird
        kann "Same as Interface IP" benutzt werden. Zusätzlich lässt sich eine entsprechende IP eines DNS Servers über "Specify" definieren. Zustätzliche
        DNS IP's lassen sich über CLI konfigurieren. Betreffend "Same as System DNS" Konfiguration siehe auch nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_konfiguriere_unter_FortiOS_5.4_auf_einer_FortiGate_die_System_DNS_Server.3F]]

        '''Mode'''
        
        Wähle ob es sich um einen regulären DHCP "Server" oder "Relay" handelt! Wird "Relay" gewählt muss die entsprechende IP Adresse des DHCP Servers
        definiert werden!

        '''NTP Server'''
        
        Unter dieser Position kann ein NTP Server definiert werden dh. entweder "local" sofern die "NTP" Funktion benutzt wird oder "Same as System NTP"
        sofern der definierte NTP Server für das System benutzt werden soll. Zusätzlich kann unter "Specify" ein NTP Server defniert werden! Weitere 
        Informationen betreffend "local" resp. "Same as System NTP" siehe auch nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_auf_einer_FortiGate_die_NTP_Zeitsynchronisierung_aktiviren_und_konfigurieren.3F]]

        '''Next Bootstrap Server'''
        
        Sofern ein "Bootstrap" Server benutzt wird kann dieser hier mit einer entsprechenden IP definiert werden!

        '''Additional DHCP Options'''
        
        Unter dieser Position können "DHCP Optionen" hinterlegt werden wie zB die "lease" Time. Wie eine "DHCP Option" manuell konfiguriert wird siehe 
        auch nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_und_f.C3.BCr_einen_DHCP_Server_eine_.22DHCP_Option.22_konfigurieren.3F]]

        '''MAC Reservation + Access Control'''
        
        Unter dieser Position kann eine "MAC Reservation + Access Control" konfiguriert werden. Dies bedeutet: Per Standard ist ein DHCP Server unter 
        FortiOS 5.4 im "assign" Mode. Somit wird jede DHCP Anfrage vom DHCP Server beantwortet unabhängig davon ob eine "MAC Reservation + Access Control"
        konfiguriert wurde. Wird der DHCP Server auf "block" gesetzt so werden nur DHCP Anfragen beantwortet von Devices die mit deren "MAC Adressen" unter
        "MAC Reservation + Access Control" eingetragen sind. Alle anderen DHCP Anfragen werden geblockt! Weitere Informationen siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_und_f.C3.BCr_einen_DHCP_Server_eine_.22MAC_Reservation_.2B_Access_Control.22_Konfigurieren.3F]]

        '''Type'''
        
        Ein DHCP Server kann auf "Regular" oder "IPSec" gesetzt werden. Unter normalen Umständen wird "Regular" benutzt. Möchte man im Zusammenhang mit einem
        "Dial-up VPN" (Client2Site) nicht den in der Phase-1 des VPN's "mode-config" benutzen kann auf dem "IPSec Interface" des "Dial-Up VPN's" ein DHCP Server
        konfiguriert werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:
        
        [[FortiClient:FAQ#Wie_kann_ich_einem_VPN_Client_f.C3.BCr_IPSec_Client2Site_VPN_Verbindung_eine_Fixe_IP_zuweisen.2Fkonfigurieren.3F]]

Wenn ein "DHCP Server" auf einem entsprechenden Interface konfiguriert resp. aktiviert wurde sind die vergebenen IP Adressen des DHCP Servers resp. "lease" über folgende Position ersichtlich:

        Monitor > DHCP Monitor

        [[Datei:Fortinet-1662.jpg]]

Aus diesem "DHCP Monitor" können direkt für den entsprechenden Eintrag eine "IP Reservation" durchgeführt werden oder den "lease" Eintrag löschen (Revoke). Kommt es im Zusammenhang mit einem DHCP Server zu Problemen kann ein Troubleshooting durchgeführt werden. Weitere Informationen dazu wie dies durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einem_FortiGate_Device_f.C3.BCr_einen_.22DHCP_Server.22_ein_Troubleshooting_.28debug.29_durchf.C3.BChren.3F]]

Wie schon erwähnt kann der "DHCP Server" ebenfalls auf CLI konfiguriert werden. Der Vorteil dabei ist, dass zusätzliche Optionen zur Verfügung stehen die innerhalb des Mgmt. Web Interface nicht zur Verfügung stehen. Um einen "DHCP Server" über CLI zu konfigurieren, muss folgendes durchgeführt werden:

        # config system dhcp server
        # edit [Setze einen entsprechenden Integer zB "1"]
        # set description [Definiere einen entsprechenden Kommentar für DHCP Server]
        # set status [disable | enable]
        # set lease-time [Setze die entsprechende "lease" Zeit; Standard 604800]
        # set mac-acl-default-action [assign | block]
        # set forticlient-on-net-status [disable | enable]
        # set dns-service [local | default | specify]
        # set dns-server1 [IPv4-Adresse für DNS Server 1]
        # set dns-server2 [IPv4-Adresse für DNS Server 2]
        # set dns-server3 [IPv4-Adresse für DNS Server 3]
        # set wifi-ac1 [IPv4-Adresse für Wireless Controller 1]
        # set wifi-ac2 [IPv4-Adresse für Wireless Controller 2]
        # set wifi-ac3 [IPv4-Adresse für Wireless Controller 3]
        # set ntp-service [local | default | specify]
        # set ntp-server1 [IPv4-Adresse für NTP Time Server 1]
        # set ntp-server2 [IPv4-Adresse für NTP Time Server 1]
        # set ntp-server3 [IPv4-Adresse für NTP Time Server 1]
        # set domain [Setze eine entsprechende Domain zB "local.intra"]
        # set wins-server1 [IPv4-Adresse für Win Server 1]
        # set wins-server2 [IPv4-Adresse für Win Server 1]
        # set default-gateway [IPv4-Adresse für Default Gateway]
        # set next-server <IPv4-Adresse für Bootstrap Server]
        # set netmask [IPv4-Netmask für DHCP Server IP Range]
        # set interface [Name des Interface für den DHCP Server zB "internal"]
        # config ip-range
        # edit [Setze einen entsprechenden Integer zB "1"]
        # set start-ip [IPv4 Start Adresse für den DHCP Bereich]
        # set end-ip [IPv4 End Adresse für den DHCP Bereich]
        # end
        # set timezone-option [disable | default | specify]
        # set timezone [01 | 02 | 03 | 04 | 05 | 81 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 74 | 14 | 77 | 15 | 16 | 17 | 18 | 19 | 20 | 75 | 21 | 22 | 23 | 24 | 80 | 79 | 25 | 26 | 27 | 28 | 78 | 29 | 30 | 31 | 85 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 83 | 84 | 40 | 41 | 42 | 43 | 39 | 44 | 46 | 47 | 51 | 48 | 45 | 49 | 50 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 62 | 63 | 61 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 00 | 82 | 73 | 86 | 76]
        # set tftp-server [FQDN oder IPv4 Adresse des TFTP Servers]
        # set filename [Name des Boot Files]
        # set option1 [Option Code] [Option Hexadecimal Character]
        # set option2 [Option Code] [Option Hexadecimal Character]
        # set option3 [Option Code] [Option Hexadecimal Character]
        # set option4 [Option Code] [Option Hexadecimal Character]
        # set option5 [Option Code] [Option Hexadecimal Character]
        # set option6 [Option Code] [Option Hexadecimal Character]
        # set server-type [regular | ipsec]
        # set conflicted-ip-timeout [Timeout bei Konflikten in Sekunden; 60 - 8640000; Standard 1800]
        # set ipsec-lease-hold [DHCP "lease-out" Zeit in Sekunden nachdem IPSec Tunnel down; Standard 60 ; 0 = forcedexpiry]
        # set auto-configuration [disable | enable]
        # set ddns-update [disable | enable]
        # set ddns-server-ip [IPv4-Adresse DDNS Server IP]
        # set ddns-zone [DDNS Domaine zB "local.intra"]
        # set ddns-auth [disable | tsig]
        # set ddns-keyname [DDNS Update Key Name]
        # set ddns-key [DDNS Update Key base 64]
        # set ddns-ttl [DDNS Timeout in Sekunden; Standard 300]
        # set vci-match [disable | enable]
        # config vci-string
        # edit <name_str>
        # set vci-string [VCI String]
        # end
        # config exclude-range
        # edit [Setze einen entsprechenden Integer zB "1"]
        # set start-ip [Definition der IPv4 Start Adresse für den DHCP Exclude Bereich]
        # set end-ip [Definition der IPv4 End Adresse für den DHCP Exclude Bereich]
        # end
        # config reserved-Adresse 
        # edit [Setze einen entsprechenden Integer zB "1"]
        # set ip [IPv4-Adresse für IP Reservation]
        # set mac [MAC-Adresse Defintion für IP Reservation]
        # set action [assign | block | reserved]
        # end
        # end

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device und für einen DHCP Server eine "DHCP Option" Konfigurieren? ===

Wenn unter FortiOS 5.4 ein DHCP Server konfiguriert wird kann innerhalb des DHCP Server's eine bestimmte "DHCP Option" konfiguriert werden. Dies bedeutet: Durch diese "DHCP Optionen" werden einem Device über den DHCP Server bestimmte Anweisungen/Informationen mitgegeben. Grundlegende Informationen wie zB NTP Server, Wins Server sowie Wireless Controller müssen nicht über "DHCP Optionen" konfiguriert werden da diese innerhalb des DHCP Server's konfiguriert werden könnnen. Welche Optionen innerhalb des DHCP Servers zur Verfügung stehen siehe auch nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_Interface_auf_einer_FortiGate_einen_.22DHCP_Server.22_konfigurieren.3F]]

Soll für einen DHCP Server eine spezifische Information als "DHCP Option" konfiguriert werden muss folgendes berücksichtigt werden:

        Eine "DHCP Option" kann nur in "Hexadecimalen" Charakter konfiguriert werden. Dies bedeutet: Eine IP kann nicht als IP konfiguriert werden
        innerhalb einer "DHCP Option" sondern muss von "Decimal" in "Hexadecimal" umgerechnet und so abgebildet/konfiguriert werden. Diese Umrechnung
        wird für jedes "octed" von Links nach Rechts ausgeführt. Nachfolgend ein Beispiel anhand der IP Adresse "192.168.3.1":
        
        192 = C0
        168 = A8
          3 = 03
          1 = 01
        
        Somit ergiebt sich als "Hexadecimale" Charakter folgendes:
        
        Hex = '''C0A80301'''
        
        Für die Umrechnung von "Decimal" auf "Hexadecimal" kann zB folgende Seite benutzt werden:
        
        http://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html

Nachdem die "Hexadecimalen" Charakter umgerechnet wurden kann der DHCP Server mit dem entsprechenden "DHCP Option" konfiguriert werden. Dabei ist betreffend "DHCP Option" folgende Seiten zu berücksichtigen die Auskunft geben welche "DHCP Option" existieren und welche Funktionen diese übernehmen:

        http://www.networksorcery.com/enp/protocol/bootp/options.htm

Um die Konfiguration einer "DHCP Option" durchzuführen gebe auf der CLI folgendes ein:

        # config system dhcp server 
        # edit 1
        # set option1 [Option Code] [Option Hexadecimal Character]
        # set option2 [Option Code] [Option Hexadecimal Character]
        # set option3 [Option Code] [Option Hexadecimal Character]
        # set option4 [Option Code] [Option Hexadecimal Character]
        # set option5 [Option Code] [Option Hexadecimal Character]
        # set option6 [Option Code] [Option Hexadecimal Character]
        # end

Die "DHCP Option" kann ebenfalls über Mgmt. Web Interface durchgeführt werden sofern der "dhcp-advanced" Mode benutzt wird:

        # config system settings
        # set gui-dhcp-advanced [enable | disable]
        # end

Somit ergiebt sich für unser Beispiel folgende Konfiguration wenn zB die IP als "Call Server IP" (129) Option konfiguriert werden soll:

        # config system dhcp server 
        # edit 1
        # set option1 129 C0A80301
        # end

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device und für einen DHCP Server eine "MAC Reservation + Access Control" Konfigurieren? ===

Wenn unter FortiOS 5.4 ein DHCP Server konfiguriert wird kann innerhalb dieses DHCP Servers eine "MAC Reservation + Access Control" Konfiguriert werden. Für Informationen wie ein DHCP Server unter FortiOS 5.4 konfiguriert wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_Interface_auf_einer_FortiGate_einen_.22DHCP_Server.22_konfigurieren.3F]]

Innherhalb dieses DHCP Servers ist es möglich eine "MAC Reservation + Access Control" zu konfigurieren dh. Eine definierte IPv4 Adresse wird einer definiterten MAC Adresse zugewiesen. Dabei ist es möglich für diese Definition ein "assign", "block" sowie "reserved" zu konfigurieren. Um diese Konfiguration durchzuführen führe folgendes aus:

        # config system dhcp server
        # edit [Gebe den entsprechenden Integer an des bestehenden DHCP Servers zB "1"]
        # config reserved-address
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set ip [IPv4 Adresse zB "10.10.10.55"]
        # set mac [Mac Adresse in Form "00:09:0F:30:CA:4F"]
        # set action [assign | block | reserved]
        # end
        # end

Die Konfiguration einer "MAC Reservation + Access Control" kann ebenfalls über Mgmt. Web Interface durchgeführt werden. Dazu führe folgendes aus:

        Network > Interfaces > [Wähle das entsprechende Interface] > Edit

        [[Datei:Fortinet-1661.jpg]]

Zusätzlich kann eine "MAC Reservation" ebenfalls über den "DHCP Monitor" direkt konfiguriert werden sofern dem Device über den DHCP Server auf der FortiGate eine IP Adresse zugewiesen worden ist:

        Monitor > DHCP Monitor [Markiere den entsprechenden Eintrag im DHCP Monitor] > [Rechte Maustaste] > [Revoke lease | Create/Edit IP Reservation]

        [[Datei:Fortinet-1662.jpg]]

Diese Konfiguration steht ebenfalls im Zusammenhang mit dem Standard Mode eines DHCP Servers. Dies bedeutet: Per Standard ist ein DHCP Server auf einer FortiGate im "assign" Mode. Somit wird jede DHCP Anfrage eines Devices mit einer Zuweisung einer IP Adresse beantwortet! Steht der DHCP Server auf "block" Mode werden keine IP Adressen den Devices zugewiessen ausser der entsprechende Device wurde unter "reserved-address" mit dessen MAC Adresse konfiguriert! Diese Modi werden folgendermassen konfiguriert:

        # config system dhcp server
        # edit [Gebe den entsprechenden Integer an des bestehenden DHCP Servers zB "1"]
        # set mac-acl-default-action [assign | block]
        # end

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device und für einen DHCP Server einen DHCP "lease" auflisten und/oder löschen? ===

Wenn unter FortiOS 5.4 ein DHCP Server konfiguriert wurde können die verschiedenen "lease" die den Devices über den DHCP Server zugewiesen worden sind über Mgmt. Web Intrface eingesehen werden. Dazu steht der "DHCP Monitor" zur Verfügung den man unter folgender Position findet:

        Monitor > DHCP Monitor

        [[Datei:Fortinet-1662.jpg]]

In diesem "DHCP Monitor" können durch das markieren des entsprechenden Eintrages und mit einem "Rechten Mausklick" anhand "Revoke lease" eine zugewiesenen IP Adresse für den entsprechenden markierten Eintrag gelöscht werden sowie über "Create/Edit IP Reservation" eine IP Reservierung für einen entsprechenden markierten Eintrag/Device durchgeführt werden. Diese Konfiguration kann ebenfalls über CLI durchgeführt werden. Dazu stehen folgende Befehle zur Verfügung:

        # execute dhcp lease-list
        dmz
          IP                    MAC-Address             Hostname                VCI                     Expiry
          198.18.3.2            08:5b:0e:a3:97:a6                       FortiAP-FAP24D          Tue Jan 26 03:54:00 2016
          198.18.3.3            08:5b:0e:5d:f7:0c                       FortiAP-FP221C          Tue Jan 26 03:53:43 2016
        fortinet4intern
          IP                    MAC-Address             Hostname                VCI                     Expiry
          198.18.2.2            94:65:9c:74:47:c6       DESKTOP-HSEH6HM         MSFT 5.0                Tue Jan 26 18:45:49 2016

Um eine entsprechenden "lease" zu löschen muss anhand der IP Adresse für den entsprechenden Eintrag dies definiert werden dh.:

        # execute dhcp lease-clear 198.18.2.2

Um alle "lease" zu löschen kann folgendes ausgeführt werden:

        # execute dhcp lease-clear all

=== Wie kann ich unter FortiOS 5.4 auf einem FortiGate Device für einen "DHCP Server" ein Troubleshooting (debug) durchführen? ===

Wenn unter FortiOS 5.4 ein DHCP Server konfiguriert wird und es nachträglich zu Problemen kommt zB weil einem Device keine IP Adresse über den DHCP Server zugewiesen wird kann anhand eines "debug" ein Troubleshooting durchgeführt werden. Dabei ist jedoch Wichtig zu wissen wie ein DHCP Server funktioniert und was dessen Grundlagen sind. Weitere Informationen zu den Grundlagen eines DHCP Servers siehe nachfolgender Link:

        https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

Um nun ein "debug" für ein DHCP Server durchzuführen führe folgendes aus:

        '''Verbinde dich anhand SSH zum FortiGate Device'''
        
        Ein "debug" kann innerhalb einer SSH Session sehr viele Informationen enthalten. Damit die Informationen für einen spätere Analyse zur
        Verfügung stehen sollte der "output" des "debug" in ein Log File geschrieben werden. Wenn anhand "putty" eine SSH Verbindung zur FortiGate
        etabliert wird kann vorgängig so ein Log File über folgende Position innerhalb der "putty" Konfiguration aktiviert/konfiguriert werden:
        
        Category > Session > Logging > All Session output

        '''Setze den "debug" Filter zurück:'''
        
        # diagnose debug reset

        '''Setze einen neuen "debug" Filter:'''
        
        # diagnose debug application dhcps -1

        '''Kontrolliere den "debug" Filter:'''
        
        # diagnose debug info
        debug output:           disable
        console timestamp:      disable
        console no user log message:    disable
        '''dhcps debug level:      -1 (0xffffffff)'''
        CLI debug level:        3

        '''Aktiviere den "debug" Modus:'''
        
        # diagnose debug enable

Nun kann über den Device eine zB "ipconfig /renew" durchgeführt werden und in der SSH Verbindung wird folgender "output" angezeigt:

        --------------- output diagnose debug application dhcps -1 ---------------
        
        [debug]calling handler[fortinet4intern]
        [debug]locate_network prhtype(1) pihtype(1)
        [debug]find_lease(): packet contains preferred client IP, cip.s_addr is 198.18.2.2
        [debug]find_lease(): leaving function with lease set
        [debug]find_lease(): the lease's IP is 198.18.2.2
        [note]DHCPREQUEST for 198.18.2.2 from 94:65:9c:74:47:c6 via fortinet4intern(ethernet)
        [debug]deled ip 198.18.2.2 mac 94:65:9c:74:47:c6 in vd root
        [debug]added ip 198.18.2.2 mac 94:65:9c:74:47:c6 in vd root
        [debug]packet length 300
        [debug]op = 1  htype = 1  hlen = 6  hops = 0
        [debug]xid = 28257ef  secs = 0  flags = 0
        [debug]ciaddr = 198.18.2.2
        [debug]yiaddr = 0.0.0.0
        [debug]siaddr = 0.0.0.0
        [debug]giaddr = 0.0.0.0
        [debug]chaddr = 94:65:9c:74:47:c6
        [debug]filename = 
        [debug]server_name = 
        [debug]  host-name = "DESKTOP-HSEH6HM"
        [debug]  dhcp-message-type = 3
        [debug]  dhcp-parameter-request-list = 1,3,6,15,31,33,43,44,46,47,121,249,252
        [debug]  dhcp-class-identifier = "MSFT 5.0"
        [debug]  dhcp-client-identifier = 1:94:65:9c:74:47:c6
        [debug]
        [pkt]000: 01 01 06 00 ef 57 82 02  00 00 00 00 c6 12 02 02
        [pkt]010: 00 00 00 00 00 00 00 00  00 00 00 00 94 65 9c 74
        [pkt]020: 47 c6 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]080: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]090: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0e0: 00 00 00 00 00 00 00 00  00 00 00 00 63 82 53 63
        [pkt]0f0: 35 01 03 3d 07 01 94 65  9c 74 47 c6 0c 0f 44 45
        [pkt]100: 53 4b 54 4f 50 2d 48 53  45 48 36 48 4d 3c 08 4d
        [pkt]110: 53 46 54 20 35 2e 30 37  0d 01 03 06 0f 1f 21 2b
        [pkt]120: 2c 2e 2f 79 f9 fc ff 00  00 00 00 00
        [note]DHCPACK on 198.18.2.2 to 94:65:9c:74:47:c6 via fortinet4intern(ethernet)
        [pkt]000: 02 01 06 00 ef 57 82 02  00 00 00 00 c6 12 02 02
        [pkt]010: c6 12 02 02 00 00 00 00  00 00 00 00 94 65 9c 74
        [pkt]020: 47 c6 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]080: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]090: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        [pkt]0e0: 00 00 00 00 00 00 00 00  00 00 00 00 63 82 53 63
        [pkt]0f0: 35 01 05 36 04 c6 12 02  01 33 04 00 09 3a 80 01
        [pkt]100: 04 ff ff ff 80 03 04 c6  12 02 01 06 04 c6 12 02
        [pkt]110: 01 0f 0b 6c 6f 63 61 6c  2e 69 6e 74 72 61 3a 04
        [pkt]120: 00 04 9d 40 3b 04 00 08  13 30 02 04 00 00 0e 10
        [pkt]130: 2a 04 c6 12 02 01 e0 10  46 47 54 36 30 44 34 36
        [pkt]140: 31 33 30 34 38 30 31 37  ff
        [debug]sending on fortinet4intern(ethernet)
        [debug]sending using lpf_dhcpd_send_packet
        [warn]start dumping leases
        
        [warn]finished dumping dynamic ipmacs
        [warn]finished dumping all leases
        
        --------------- output diagnose debug application dhcps -1 ---------------

Nachdem der "output" generiert wurde kann der "debug" Mode wieder deaktiviert werden:

        '''Deaktiviere den "debug" Modus:'''
        
        # diagnose debug disable

        '''Setze den "debug" Filter zurück:'''
        
        # diagnose debug reset

        '''Kontrolliere den "debug" Filter:'''
        
        # diagnose debug info
        debug output:           disable
        console timestamp:      disable
        console no user log message:    disable
        CLI debug level:        3

Wenn für den entsprechenden "debug" Filter kein "output" geliefert wird muss davon ausgegangen werden, dass die DHCP Anfrage des Device den DHCP Server nicht erreicht. Um dies zu verfifzieren kann anhand des "sniffer" Kommandos dies überprüft werden:

        # diagnose sniffer packet [Name des entsprechenden Interfaces zB "internal"] 'port 67 and 68' 3

=== Wie kann ich unter FortiOS 5.4 auf einem FortiGate Device einen "DHCP Server" stoppen und neu starten? ===

Auf einem FortiOS steht für das Neustarten eines Services/Deamons der folgende Befehl auf der CLI zur Verfügung:

        # diagnose test application [Service/Deamon] 99

Um herauszufinden, welche Service/Deamon zur Verfügung stehen für dieses Kommando kann folgendes ausgeführt werden:

        # diagnose test application ?

Unter diesem Befehl werden anhand "?" alle zur Verfügung stehenden Service/Deamon aufgelistet. Dabei fällt einem auf, dass es für einen "DHCP Server" IPv4 keinen entsprechenden Eintrag existiert ausser für den "DHCP Relay". Somit gibt es keine Möglichkeit über diesen Befehl ein DHCP Server neu zu starten. Wenn dies dennoch durchgeführt werden soll, können nachfolgende Befehle benutzt werden wobei zu berücksichtigen ist, dass nicht ein einzelner "DHCP Server" dh. für ein spezifisches Interfaces neu gestartet wird sondern der "DHCP Server" für alle Interfaces. Aus diesem Grund sind die Auswirkungen eines Neustart des "DHCP Servers" auf einer FortiGate zu berücksichtigen:

        '''Verifiziere für den DHCP Server unter welcher PID Nummer der Service/Deamon aktiv ist'''
        
        # fnsysctl more /var/run/dhcpd.pid
        28850

        '''Führe einen Neustart durch des DHCP Servers anhand der PID Nummer und Syskill Level 9'''
        
        # diagnose sys kill 9 28850

        '''Verifiziere nach einigen Sekunden ob der Neustart für den DHCP Server durchgeführt wurde'''
        
        # fnsysctl more /var/run/dhcpd.pid
        28879

Der Neustart des DHCP Servers wurde erfolgreich ausgeführt das dem DHCP Server eine neue PID Nummer zugewiesen wurde!

== ARP ==

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device "ARP" Einträge auflisten, hinzufügen und löschen? ===

Wenn auf einem FortiOS 5.4 "ARP" Einträge aufgelistet werden sollen kann nachfolgender Befehl auf der CLI benutzt werden:

        # get system arp 
        Address           Age(min)   Hardware Addr      Interface
        198.18.2.2        0          94:65:9c:74:47:c6 fortinet4intern
        198.18.3.2        0          08:5b:0e:a3:97:a6 dmz
        198.18.3.3        1          08:5b:0e:5d:f7:0c dmz
        193.193.135.65    0          00:90:0b:3b:d6:c2 wan1

Die Position "Age(min)" im hier gezeigtem "output" zeigt die Zeit in Minuten an die verstrichen ist seit kein Traffic mehr für den entsprechenden "ARP" Eintrag stattgefunden hat. Wenn für ein entsprechender "ARP" Eintrag kein Traffic stattgefunden für eine vordefinierte Zeit wir dieser "ARP" Eintrag auf "age out" gesetzt. Eine weitere Möglichkeit "ARP" Einträge mit deren Details aufzulisten ist das folgende Kommando:

        # diagnose ip arp list
        index=64 ifname=root 0.0.0.0 00:00:00:00:00:00 state=00000040 use=191755492 confirm=191761492 update=191755492 ref=3
        index=7 ifname=internal1 198.18.0.90 state=00000020 use=196 confirm=191760290 update=496 ref=2
        index=66 ifname=fortinet4intern 198.18.2.2 94:65:9c:74:47:c6 state=00000002 use=138 confirm=132 update=2184 ref=3
        index=4 ifname=dmz 198.18.3.2 08:5b:0e:a3:97:a6 state=00000002 use=553 confirm=483 update=483 ref=2
        index=4 ifname=dmz 198.18.3.3 08:5b:0e:5d:f7:0c state=00000002 use=138 confirm=1655 update=1655 ref=3
        index=5 ifname=wan1 193.193.135.65 00:90:0b:3b:d6:c2 state=00000002 use=27 confirm=679 update=679 ref=4

Wenn sehr viele "ARP" Einträge auf verschiednene Interface's exisiteren und man einen spezifischen Eintrag sucht sollte im Zusammenhang mit dem "diagnose" Kommando "grep" benutzt werden:

        # diagnose ip arp list | grep 198.18.3.2
        index=4 ifname=dmz 198.18.3.2 08:5b:0e:a3:97:a6 state=00000002 use=553 confirm=483 update=483 ref=2

Weitere Informationen dazu wie "grep" benutzt wird siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Kann_ich_unter_FortiOS_5.4_Linux.2FUnix_basierenden_Befehl_.22grep.22_auf_der_Kommandozeile_ben.C3.BCtzen.3F]]

Anhand dieses Kommando "diagnose" lässt sich ein "ARP" Eintrag "temporär" hinzufügen oder löschen dh. Das hinzufügen eines "ARP" Eintrages anhand des "diagnose" Kommandos ist nicht "persistent". Dies bedeutet: wird ein Neustart des FortiGate Devices ausgeführt geht diese Konfiguration verloren:

        '''Füge einen "ARP" Eintrag "temporaer" hinzu'''
        
        # diagnose ip arp add [Interface Name zB "internal"] [IPv4 Adresse für den ARP Eintrag] [MAC Adresse für den ARP Eintrag XX:XX:XX:XX:XX:XX]

        '''Lösche einen "ARP" Eintrag'''
        
        # diagnose ip arp delete [Interface Name zB "internal"] [IPv4 Adresse für den ARP Eintrag]

Möchtem man jedoch einen permanenten "ARP" Eintrag konfigurieren der auch nach einem Neustart des FortiGate Devices aktiv bleibt, muss diese Konfiguration anhand der "arp-table" durchgeführt werden. Dies wird folgendermassen konfiguriert:

        # config system arp-table 
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set interface [Name des Interface zB "wan1"]
        # set ip [IPv4 Adresse für den ARP Eintrag]
        # set mac [MAC Adresse für den ARP Eintrag zB für "wan1"]
        # end

Um die entsprechende MAC Adresse eines Interfaces zu eruieren kann folgendes benutzt werden:

        # diagnose hardware deviceinfo nic
        The following NICs are available:
                dmz
                internal1
                internal2
                internal3
                internal4
                internal5
                internal6
                internal7
                wan1
                wan2

        # diagnose hardware deviceinfo nic wan1
        Driver Name     :Fortinet NP4Lite Driver
        Version         :1.0.0
        Admin           :up
        Current_HWaddr   08:5b:0e:47:db:58
        Permanent_HWaddr 08:5b:0e:47:db:58
        Status          :up
        Speed           :100
        Duplex          :Half
        Host Rx Pkts    :11371
        Host Rx Bytes   :835610
        Host Tx Pkts    :16174
        Host Tx Bytes   :2043274
        Rx Pkts         :11370
        Rx Bytes        :994717
        Tx Pkts         :16168
        Tx Bytes        :1883038
        rx_buffer_len   :2048
        Hidden          :No
        cmd_in_list     : 0
        promiscuous     : 1
        enabled 802.1x  : 0
        authorized      : 0
        mac bypass      : 0

Wenn die "ARP" Informationen auf den neusten Stand gebracht werden sollen so muss ein "flush" ausgeführt werden. Dies bedeutet: All "dynamischen" ARP Einträge werden gelöscht und neu durch "who-as" gelernt. Somit wird gewährleistet das nicht mehr verbundene Devices aus der "ARP" Table gelöscht werden. Um ein "flush" durchzuführen gebe auf der CLI folgendes ein:

        # execute clear system arp table

Wenn dies durchgeführt wird kann über das "sniffer" Kommando das neu lernen der "ARP" Einträge mitverfolgt werden:

        # diagnose sniffer packet any arp
        interfaces=[any]
        filters=[arp]
        0.682098 arp who-has 198.18.3.3 tell 198.18.3.1
        0.682251 arp reply 198.18.3.3 is-at 8:5b:e:5d:f7:c

=== Was ist unter FortiOS 5.4 der Unterschied  zwischen den Funktionen "system arp-table" und "proxy-arp? ===

Wenn unter FortiOS 5.4 auf dem externen Interface zB "wan1" ein public IP Range konfiguriert wird, sei es über statische und/oder dynamischer Konfiguration und zu diesem konfigurierten public IP Range eine neuer public IP Range dazu konfiguriert werden soll, hat man verschiedenen Möglichkeiten dies zu erreichen. Eine Möglichkeit ist, den neuen public IP Range auf dem externen Interface als "Secondary Interface" zu konfigurieren. Dadurch wird der neue public IP Range auf dem Secondary Interface zur MAC Adresse des Interface hinzugefügt auf dem die "Secondary Interface" Konfiguration durchgeführt wird. Eine andere Möglichkeit ist ein VIP Objekt zu erstellen. Durch die Konfiguration eines VIP Objekts wird durch die Option "arp-reply enable" auf Layer 4 ein entsprechender ARP Eintrag durchgeführt anhand der MAC Adresse für das Interface das im VIP Objekt konfiguriert wird. Da dieser ARP Eintrag auf Layer 4 durch "arp-reply enable" konfiguriert wird, ist dieser ARP Eintrag auf Layer 3 anhand des Kommandos "get system arp" nicht ersichtlich. Wiederum eine andere Möglichkeit ist ein statischer ARP Eintrag zu erstellen in der "system arp-table". Alle diese Möglichkeiten haben als Ziel anhand MAC Adressen den zusätzlichen public IP Range auf dem entsprechenden Interface zu binden. Wenn jedoch der neue public IP Range nicht auf dem externen Interface verwendet wird sondern zB auf dem "dmz" Interface für eine Public IP Adressierung der Server, muss dem externen Interface mitgeteilt werden, dass dieses "dmz" Interface für diesen neuen IP Range zuständig ist. Dies da dieser public IP Range auf das externe Interface zB "wan1" geroutet wird. Wird dies mit einem statischen ARP Eintrag in der "system arp-table" auf dem externen Interface durchgeführt, wird der Traffic nicht auf das "dmz" Interface weitergeleitet da das FortiOS davon ausgeht, dass sich der neue public IP Range auf dem externen Interface zB "wan1" befindet. In so einem Fall wird ein "system proxy-arp" erstellt dh. es wird dem FortiOS durch einen "system proxy-arp" Konfiguration mitgeteilt, dass die Zuständigkeit einer oder mehrer public IP/s sich nicht mehr auf dem externe Interface befindet zB "wan1" sondern auf dem "dmz" Interface. Dies bedeutet: Das FortiOS nimmt den/die neue/n public IP Range/s auf dem externen Interface an und leitet diesen an das Interface weiter gemäss der Konfiguration "system proxy-arp". Diese Art der Implementierung wird auch "IP Adresse zu MAC Adress Translation" genannt! Um einen "system proxy-arp" zu konfigurieren muss über CLI folgendes durchgeführt werden:

        # config system proxy-arp
        # set interface [Namen des Externes Interface zB "wan1"]
        # set ip [Public IPv4 Adresse des Servers im DMZ]
        # set end-ip [Public IPv4 End Adresse des Servers im DMZ]
        # end

Unter FortiOS 5.4 kann anhand der Option "end-ip" die End Adresse des Public IP Ranges definiert werden. Diese steht im Zusammenhang mit der Option "ip" dh. Wird nur die Iption "ip" benutzt so gilt nur diese Konfiguration einer IPv4 Adresse. Wird "end-ip" definiert gilt die Option "ip" als Start Adresse des IPv4 Adress Definition.

== Routing ==

=== Wie wird unter FortiOS 5.4 auf einer FortiGate ein Routing Tabelle "lookup" durchgeführt und wie wird das "Routing" abgearbeitet? ===

Dieser Artikel beschreibt wie ein FortiOS 5.4 für einen FortiGate das "Routing" abarbeitet sowie selektiert dh. welches Routing zuerst greift wie zB Cache, Policy Routen usw. Wenn verschiedenen Routing's benützt werden dh. zB Policy Route (Layer 4), Distance (Layer 3) ist es Wichtig zu wissen, wie ein Routing abgearbeitet wird! Nachfolgend eine Liste "top to down" wie ein FortiOS ein Routing generell abarbeitet: 

       0) Routing Cache
       1) Policy Route
       2) Longest Match
       3) Distance
       4) Priority
       5) Metric (Dynamisches Routing)
       6) ECMP (Equal Cost Multiple Path)
       
       '''NOTE''' Ein FortiOS resp. Eine FortiGate im "Transparent Mode" aggiert wie eine Bridge und leitet den Traffic im Layer-2 weiter dh. Ethernet
            Packete werden basierend auf deren "MAC Adressen" abgearbeitet und "nicht" anhand deren IP's. Es findet deshalb kein "Routing" statt 
            und Routen sind nicht konfigurierbar ausser für das Mgmt. Interface der "Transparent" Firewall resp. vdom!

Wie der "cache" eines Routing eingesehen werden kann sowie auf den neusten Stand gebracht wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_den_Routing_.22cache.22_auflisten_und_aktualisieren.3F]]

Nachfolgendes Diagramm zeigt wie ein "lookup" im Zusammenhang mit den verschiedenen "Routing Tabellen" durchgeführt wird:

        [[Datei:Fortinet-1604.jpg]]

Dieses Diagramm zeigt auf das verschiedenen "Routing Tabellen" existieren die für die verschiedenen eingesetzten Routing Technologien wie Policy Route, Cache, Statische Route usw. entscheidend sind. Die Informationen dieser "Routing Tabellen" spielen somit eine entscheidende Rolle ob ein Routing selektiert wird oder nicht! Nachfolgende Artikel zeigen auf wie die Informationen dieser "Routing Tabellen" ausgelsesen und/oder modifiziert werden können:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_die_Routing_Tabelle_.22routing-table.22_auflisten.3F]]
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_das_Routing_im_.22kernel.22_auflisten.3F]]
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_das_Routing_f.C3.BCr_.22policy_routing.22_auflisten.3F]]
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_die_Routing_Protokolle_.22protocols.22_auflisten.3F]]

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device die Routing Tabelle "routing-table" auflisten? ===

Wenn unter FortiOS 5.4 für einen FortiGate Device die Routing Tabelle eingesehen werden möchte muss unterschieden werden zwischen dem Kommando das alle Einträge in der Routing Tabelle auflistet dh. aktive und inaktive Routing Tabelle Einträge und dem Kommando das nur aktive Routing Tabellen Einträge auflistet. Im Mgmt. Web Interface siehe man die Routing Tabelle für alle aktiven Einträge unter folgender Position:

        Monitor > Routing Monitor

        [[Datei:Fortinet-1663.jpg]]

Anhand der Position "Route Loookup" kann für ein/e entsprechender IPv4 Adresse herausgefunden werden ob ein Routing existiert resp. welches Routing benützt wird. Nach Eingave der "Destination" und "Search" wird aufgelistet welcher Routing Eintrag für die eingegebenen "Destination" benützt wird. Diese Routing Tabelle listet alle aktiven Routing Einträge auf dh. wenn zB ein IPSec Site2Site VPN nicht aktiv ist wird der entsprechende Routing Eintrag nicht aufglistet. Das Gleiche gilt für ein IPSec Client2Site (Dial-Up) denn der entsprechenden Routing Eintrag für ein Client2Site VPN IP Pool existiert im Layer 4 des VPN Deamons und wird nur aktiviert wenn eine aktive Verbindung existiert (FIB). Somit ist ein Routing für Client2Site VPN unter Layer 3 im Routing Monitor nicht ersichtlich. Um den Routing Eintrag für eine Client2Site Verbindung einzusehen bei aktiver Verbindung, kann folgendes CLI Kommando benutzt werden:

        # diagnose vpn ike routes list

Um auf CLI nur die "aktiven" Routing Eintraege aufzulisten kann folgendes Kommando benutzt werden:

        # get router info routing-table all
        Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
               O - OSPF, IA - OSPF inter area
               N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
               E1 - OSPF external type 1, E2 - OSPF external type 2
               i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
               * - candidate default
        
        S*      0.0.0.0/0 [10/0] via 193.193.135.65, wan1
        C       193.193.135.64/27 is directly connected, wan1
        C       198.18.0.0/24 is directly connected, internal1
        S       198.18.1.0/25 [10/0] is directly connected, ssl.root
        C       198.18.2.0/25 is directly connected, fortinet4intern
        C       198.18.2.128/25 is directly connected, fortinet4guest
        C       198.18.3.0/24 is directly connected, dmz

Um "alle" Routing Einträge in der Routing Tabelle in der CLI aufzulisten sei es "aktiv" oder "inaktiv" kann folgendes Kommando benutzt werden:

        # get router info routing-table database
        Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
               O - OSPF, IA - OSPF inter area
               N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
               E1 - OSPF external type 1, E2 - OSPF external type 2
               i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
               > - selected route, * - FIB route, p - stale info
        
        S    *> 0.0.0.0/0 [10/0] via 193.193.135.65, wan1
        C    *> 193.193.135.64/27 is directly connected, wan1
        C    *> 198.18.0.0/24 is directly connected, internal1
        S    *> 198.18.1.0/25 [10/0] is directly connected, ssl.root
        C    *> 198.18.2.0/25 is directly connected, fortinet4intern
        C    *> 198.18.2.128/25 is directly connected, fortinet4guest
        C    *> 198.18.3.0/24 is directly connected, dmz

Desweiteren steht für das Kommando "get router info routing-table" folgende zusätzlichen Optionen zur Verfügung:

        details      show routing table details information
        all          show all routing table entries
        rip          show rip routing table
        ospf         show ospf routing table
        bgp          show bgp routing table
        isis         show isis routing table
        static       show static routing table
        connected    show connected routing table
        database     show routing information base

Wenn die Routing Tabelle modifziert wird dh. durch statisches Routing Einträge oder IPv4 Adressen mit deren Netmask verändert werden, muss die Routing Tabelle auf den neuesten Stand gebracht werden. Dies wird folgendermassen durchgeführt:

        # execute router restart

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device den Routing "cache" auflisten und aktualisieren? ===

Wenn auf einem FortiOS 5.4 auf einem FortiGate Device mit Routing gearbeitet wird muss berücksichtigt werden, dass für ein Routing ein "cache" angelegt wird dh. wird ein Routing Eintrag zB statische Route konfiguriert, wird für deren Gebrauch im Hintergrund sobald diese benutzt wird ein "cache" angelegt. Dadurch muss das FortiOS nicht für jedes Routing die Routing Table konsultieren, sondern sofern ein entsprechender Eintrag existiert, werden die Informationen aus dem "cache" herangezogen. Um den "cache" des Routing einzusehen benutze auf der CLI folgendes Kommando:

        # diagnose ip rtcache list
        
        family=02 tab=254 vf=0 type=02 tos=0 flag=80000200
        0.0.0.0@0->198.18.0.1@64(root) gwy=0.0.0.0 prefsrc=198.18.0.1
        ci: ref=1 lastused=1 expire=0 err=00000000 used=819 br=0 pmtu=16436
        
        family=02 tab=254 vf=0 type=03 tos=0 flag=90000200
        193.193.135.65@5(wan1)->193.193.135.95@64(root) gwy=0.0.0.0 prefsrc=0.0.0.0
        ci: ref=1 lastused=220 expire=0 err=00000000 used=5 br=0 pmtu=1492
        
        family=02 tab=254 vf=0 type=02 tos=0 flag=80000200
        193.193.135.65@5(wan1)->193.193.135.66@64(root) gwy=0.0.0.0 prefsrc=193.193.135.66
        ci: ref=3 lastused=0 expire=0 err=00000000 used=348 br=0 pmtu=1492
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        198.18.3.1@0->198.18.3.3@4(dmz) gwy=0.0.0.0 prefsrc=0.0.0.0
        ci: ref=1 lastused=8 expire=0 err=00000000 used=952 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=03 tos=0 flag=90000200
        0.0.0.0@66(fortinet4intern)->255.255.255.255@64(root) gwy=0.0.0.0 prefsrc=198.18.2.1
        ci: ref=1 lastused=282 expire=0 err=00000000 used=0 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        0.0.0.0@0->193.193.135.65@5(wan1) gwy=0.0.0.0 prefsrc=193.193.135.66
        ci: ref=1 lastused=0 expire=0 err=00000000 used=2109 br=0 pmtu=1492
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        0.0.0.0@0->193.193.135.65@5(wan1) gwy=0.0.0.0 prefsrc=193.193.135.66
        ci: ref=1 lastused=0 expire=0 err=00000000 used=8022 br=0 pmtu=1492
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        0.0.0.0@0->198.18.3.3@4(dmz) gwy=0.0.0.0 prefsrc=198.18.3.1
        ci: ref=1 lastused=4 expire=0 err=00000000 used=59 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=03 tos=0 flag=90000200
        198.18.2.2@66(fortinet4intern)->198.18.2.127@64(root) gwy=0.0.0.0 prefsrc=0.0.0.0
        ci: ref=1 lastused=135 expire=0 err=00000000 used=61 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        198.18.2.1@0->198.18.2.2@66(fortinet4intern) gwy=0.0.0.0 prefsrc=0.0.0.0
        ci: ref=1 lastused=48 expire=0 err=00000000 used=22 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        0.0.0.0@0->198.18.0.90@7(internal1) gwy=0.0.0.0 prefsrc=198.18.0.1
        ci: ref=1 lastused=3 expire=0 err=00000000 used=491 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=02 tos=0 flag=80000200
        198.18.3.2@4(dmz)->198.18.3.1@64(root) gwy=0.0.0.0 prefsrc=198.18.3.1
        ci: ref=3 lastused=13 expire=0 err=00000000 used=572 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=02 tos=0 flag=80000200
        198.18.2.2@66(fortinet4intern)->198.18.2.1@64(root) gwy=0.0.0.0 prefsrc=198.18.2.1
        ci: ref=10 lastused=0 expire=0 err=00000000 used=20 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        198.18.3.1@0->198.18.3.2@4(dmz) gwy=0.0.0.0 prefsrc=0.0.0.0
        ci: ref=1 lastused=13 expire=0 err=00000000 used=660 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
        198.18.0.1@0->198.18.0.90@7(internal1) gwy=0.0.0.0 prefsrc=0.0.0.0
        ci: ref=1 lastused=1 expire=-2395 err=00000000 used=440 br=0 pmtu=1500
        
        family=02 tab=254 vf=0 type=02 tos=0 flag=80000200
        198.18.3.3@4(dmz)->198.18.3.1@64(root) gwy=0.0.0.0 prefsrc=198.18.3.1
        ci: ref=3 lastused=4 expire=0 err=00000000 used=1 br=0 pmtu=1500

Es ist nicht möglich diesen "cache" direkt zu verändern dh. zB einzelne Einträge zu löschen usw. Wenn der "cache" gelöscht werden soll resp. aktualisiert werden soll kann folgendes CLI Kommando benützt werden das ebenfalls die Routing Informationen sei es in der Routing Table und/oder im Kernel auf den neusten Stand bringt:

        # execute router restart

Aus diesem Grund ist es dringend empfohlen nach jeder Routing Aenderungen diesen Befehl abzusetzen um zu gewährleisten das alle Routing Informationen alle Routing Tabellen auf den neusten Stand gebracht werden.

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device das Routing im "kernel" auflisten? ===

Die Routing Einträge die auf einem FortiOS konfiguriert werden sind im "kernel" ersichtlich dh. wenn eine neue Session etabliert wird, so wird im "kernel" für diese Session ein entsprechender Routing Eintrag erstellt. Dieses "kernel" Routing wird somit auch "Forwarding Information Base Table" genannt. Einige Routing Einträge werden nur dann erstellt wenn diese Funktion benutzt wird zB SSL-VPN. Nur wenn die entsprechende Funktion benutzt wird wie zB SSL-VPN, wird ein entsprechender "kernel" Routing Eintrag geschrieben. Diese Funktion wird auch als FIB (Forwarding Information Base) bezeichnet. Gleichzeitig wird ebenfalls für jede aktive Route zB für aktive Interfaces ein entsprechender Eintrag dem "kernel" hinzugefügt. Um diese existieren Einträge aufzulisten kann in der CLI folgendes Kommando benutzt werden:

        # get router info kernel
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.64/27 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.128/25 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.0/25 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.0/24 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.0/24 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.129/32 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.128/32 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.255.255.255/32 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.1/32 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.1/32 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.0/32 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.0/32 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.66/32 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.255/32 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.64/32 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.95/32 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.127/32 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.1/32 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.0/32 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.255/32 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.255/32 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/32 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/8 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)

Möchte man diese Routing Einträge im "kernel" konfigurieren dh. Einträge hinzufügen, löschen oder verifizieren kann nachfolgendes CLI Kommando benutzt werden:

        # diagnose ip route list
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.64/27 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->198.18.1.0/25 pref=0.0.0.0 gwy=0.0.0.0 dev=65(ssl.root)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.128/25 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.0/25 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.0/24 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.0/24 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0 gwy=193.193.135.65 dev=5(wan1)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.129/32 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.128/32 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.255.255.255/32 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.1/32 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.1/32 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.0/32 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.0/32 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.66/32 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.255/32 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.64/32 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->193.193.135.95/32 pref=193.193.135.66 gwy=0.0.0.0 dev=5(wan1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.127/32 pref=198.18.2.1 gwy=0.0.0.0 dev=66(fortinet4intern)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.1/32 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.3.0/32 pref=198.18.3.1 gwy=0.0.0.0 dev=4(dmz)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.0.255/32 pref=198.18.0.1 gwy=0.0.0.0 dev=7(internal1)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->198.18.2.255/32 pref=198.18.2.129 gwy=0.0.0.0 dev=67(fortinet4guest)
        tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/32 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)
        tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/8 pref=127.0.0.1 gwy=0.0.0.0 dev=64(root)

Für die Konfiguration dh. auflisten, verifizieren, hinzufügen und löschen stehen folgende Optionen zur Verfügung:

        list      List routing table.
        add       Add static route.
        delete    Delete static route.
        verify    Verify static route.

Somit möchte man zB ein IPv4 Adresse verifzieren dh. ob ein entsprechender "kernel" Routing Eintrag existiert kann folgendes durchgeführt werden:

        # diagnose ip route verify [Interface Name zB "internal"] [IPv4 Adresse mit Netmask zB "192.168.1.0 255.255.255.0"] [IPv4 Adresse Nexthop zB "192.168.1.1"] [Route Distance "1-255"] [Priority "0-4294967295]

Zusätzlich kann anstelle von "ip" ebenfalls "address" benutzt werden dh.:

        # diagnose ip address list
        IP=198.18.3.1->198.18.3.1/255.255.255.0 index=4 devname=dmz
        IP=193.193.135.66->193.193.135.66/255.255.255.224 index=5 devname=wan1
        IP=198.18.0.1->198.18.0.1/255.255.255.0 index=7 devname=internal1
        IP=127.0.0.1->127.0.0.1/255.0.0.0 index=64 devname=root
        IP=198.18.2.1->198.18.2.1/255.255.255.128 index=66 devname=fortinet4intern
        IP=198.18.2.129->198.18.2.129/255.255.255.128 index=67 devname=fortinet4guest
        IP=127.0.0.1->127.0.0.1/255.0.0.0 index=71 devname=vsys_ha
        IP=127.0.0.1->127.0.0.1/255.0.0.0 index=73 devname=vsys_fgfm

Zu diesem Kommando stehen folgende Optionen zur Verfügung:

        list      List IP addresses.
        add       Add IP address.
        delete    Delete IP address.

Um die "kernel" Routing Einträge auf den nuesten Stand zu bringen dh. zu aktualisieren führe auf der CLI folgendes aus:

        # execute router restart

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device das Routing für "policy routing" auflisten? ===

Unter FortiOS 5.4 kann mit "policy routing" gearbeitet werden dh. Policy Routing ist "Layer 4" basierend und wird vor einer statischen Route abgearbeitet. Policy Routen selber werden über das Mgmt. Web Interface konfiguriert unter folgender Position:

        Network > Policy Routes

Werden unter dieser Position "Policy Routes" konfiguriert gilt für die Reihenfolge "top down first match wins". Dies bedeutet: Durch die Konfiguration von "Policy Routes" wird die "Policy-based route" Tabelle angelegt und herangezogen um das Routing im generellen abzuarbeiten. Diese "Policy-based route" Tabelle kann über folgendes CLI Kommando eingesehen werden:

        # diagnose firewall proute list
        list route policy info(vf=root):
        id=2 flags=0x0 tos=0x00 tos_mask=0x00 protocol=6 sport=1:65535 iif=7 dport=1-65535 oif=4 gwy=0.0.0.0 
        source wildcard(1): 198.18.0.0/255.255.255.0 
        destination wildcard(1): 192.168.1.0/255.255.255.0 
        id=1 flags=0x0 tos=0x00 tos_mask=0x00 protocol=6 sport=1:65535 iif=7 dport=1-65535 oif=4 gwy=0.0.0.0 
        source wildcard(1): 198.18.0.0/255.255.255.0 
        destination wildcard(1): 192.168.0.0/255.255.255.0 

Dieser "output" listet die "Policy Routes" auf wie diese unter "Network > Policy Routes" aufgelistet werden dh. die vergebene "id" für die "Policy Routes" ist kein Indikator welche "Policy Route" für "top down" benutzt wird sondern wie schon erwähnt gilt auch hier in diesem "output" für die Abarbeitung "top down first match wins".

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device die Routing Protokolle "protocols" auflisten? ===

Ein FortiOS 5.4 untersützt ein FortiGate Device folgende Routing Protokolle:

       BGP (Border Gateway Protocoll)
       OSPF (Open Shortest Path First)
       RIP (Routing Information Protocoll)
       IS-IS (Intermeditate System to Intermediate System)
       
Im Zusammenhang mit OSPF und BGP wird BFD unterstützt (Bi-Directional Forwarding Detection)! Um detailliert Informationen über diese einzelnen Routing Protokolle aufzulisten kann nachfolgendes Kommando in der CLI benutzt werden:

        # get router info protocols 
        Routing Protocol is "rip"
          Sending updates every 30 seconds with +/-50%
          Timeout after 180 seconds, garbage collect after 120 seconds
          Outgoing update filter list for all interface is not set
          Incoming update filter list for all interface is not set
          Default redistribution metric is 1
          Redistributing:
          Default version control: send version 2, receive version 2 
            Interface        Send  Recv   Key-chain
          Routing for Networks:
          Routing Information Sources:
            Gateway          Distance  Last Update  Bad Packets  Bad Routes
          Distance: (default is 120)
        
        Routing Protocol is "ospf 0"
          Invalid after 0 seconds, hold down 0, flushed after 0
          Outgoing update filter list for all interfaces is
          Incoming update filter list for all interfaces is
          Redistributing: 
          Routing for Networks:
          Routing Information Sources:
            Gateway         Distance      Last Update
          Distance: (default is 110)
            Address         Mask            Distance List
        
        Routing Protocol is "isis"
          System ID: 0000.0000.0000
          Area addr: Non-configured
          IS type: level-1-2
          Number of Neighbors: 0

=== Wie kann ich unter FortiOS 5.4 ein "backhole" Routing Eintrag erstellen und für was wird diese "blackhole" Routing benützt? ===

Wenn unter FortiOS eine Session etabliert wird so wird im Hintergrund eine Routing Tabelle abhängiger Routing Eintrag geschrieben. Dies bedeutet: Wenn zB eine IPSec VPN Site2site Verbindung aktiv ist, wird gemäss statischer Route für diese Session ein Routing Eintrag geschrieben. Ist dieses IPSec VPN Site2Site nicht aktiv da der IPSec VPN Tunnel "down" ist und wird in diesem Moment eine Session etabliert, kann der entsprechende statische Routing Eintrag für das Routing nicht herangezogen werden da dieses nicht aktiv ist. Somit greift die nächste aktive Route in der Routing Tabelle was wiederum dem Default Gateway Routing Eintrag entspricht. Wird in diesem Sinne eine Session etabliert wird für die Destination des IPSec VPN ein Routing Eintrag geschrieben über den Default Gateway. Ein konkretes Beispiel: Wenn eine VPN Verbindung auf "wan1" konfiguriert wurde sowie ein "destination" IP Range "10.10.10.0/24" als statische Route für die VPN Verbindung (IPSec Interface), sieht man in der Routing Tabelle einen entsprechenden Routing Eintrag sofern das VPN aktiv ist! Wenn nun die VPN Verbindung deaktiviert wird/ist (Interface IPSec "administrative down" oder VPN Verbindung auf "down" da der IPSec VPN Tunnel nicht etabliert werden kann), wird der statische Routing Eintrag für das IPSec Interface "10.10.10.0/24" deaktiviert resp. aus der Routing Tabelle entfernt. Wird zu/in diesem Zeitpunkt eine Session aufgebaut für die IPSec VPN destination "10.10.10.0/24", wird dieser Request über den Default Gateway gesendet da die statische Route für "10.10.10.0/24" aus der Routing Tabelle entfernt wurde. Wenn die VPN Verbindung wiederum aktiviert wird/ist, wird die statische Route "10.10.10.0/24" zwar wiederum in die Routing Tabelle eingetragen, jedoch nicht benutzt da eine existierende Session existiert die für "10.10.10.0/24" den Default Gateway benutzt und diese als Routing Eingetragen wurde. Dieser Zustand bleibt solange bestehen bis die Session nicht mehr aktiv ist oder manuell beendet wird. Ein "refresh" der Routing Tabelle anhand "execute router restart" löst dieses Problem nicht da die Session dadurch nicht beendet wird. Somit kann zwar die entsprechende Session "manuell" gelöscht werden, jedoch ist dies ein manueller Eingriff. Um solche Situationen zu verhindern, kann eine "blackhole" Routing implementiert werden! Dies bedeutet folgendes: Es wird eine "blackhole" Route für "10.10.10.0/24" eingetragen mit der "distance 20". Da alle Routen auf einem FortiOS per Standard eine Disctance "10" benützen ist diese Route mit der "distance 20" die schlechtet Route als die Standard Route und wird somit nicht benützt. Wird die IPSec VPN Verbindung deaktiviert benutzt "10.10.10.0/24" diese "blackhole" Route da diese in zweiter Priorität (distance 20) greift. Auch wenn existierende Sessions bestehen benützen diese sofort die effektive Route da diese mit einer kleineren Distance konfiguriert wurde (distance 10) und somit zur schlechteren Route zurück greifen. Somit kommt man zum folgenden Schluss: Provilaktisch könnte auf jeder Firewall für die "private" IP's "blackhole" Routen angelegt werden um falsches Routing vorzubeugen und somit soche Situationen vorzubeugen! Um einen "blackhole" Routing Eintrag zu erstellen kann das Mgmt. Web Interface oder die CLI benutzt werden. Wenn über Mgmt. Web Interface ein "blackhole" Route konfiguriert werden soll wähle folgendes:

        Network > Static Routes > Create New

        [[Datei:Fortinet-1664.jpg]]

Wenn über CLI eine "blackhole" Route konfiguriert werden soll muss folgendes durchgeführt werden:

        # config router static
        # edit [Gebe eine entsprechende Sequenz ein zB "1"]
        # set blackhole [enable | disable]
        # set distance [Setze die entsprechende "distance" wobei diese höher sein muss als die reguläre Route]
        # set dst [IPv4 Adresse mit Netmask für Destination zB "192.168.0.0/24"]
        # end

Grundsätzlich wäre es somit Möglich für jede Firewall Installation betreffend private IP Range eine "blackhole" Route zu setzen um solche Situationen zu verhindern:

        10.0.0.0    bis 10.255.255.255       10.0.0.0/8 
        172.16.0.0  bis 172.31.255.255       172.16.0.0/12 
        192.168.0.0 bis 192.168.255.255      192.168.0.0/16

Weitere Informationen betreffend Privat IP Bereich siehe auch:

        https://de.wikipedia.org/wiki/Private_IP-Adresse

=== Was bedeutet "strict-src-check" unter FortiOS 5.4 auf einer FortiGate im Zusammenhang mit "Antispoofing" und "Routing"? ===

Ausgangslage für ein "Antispoofing" ist das folgende CLI Kommando:

        # config system settings
        # set strict-src-check [enable | disable]
        # end

Das Kommando "strict-src-check" bezeichnet die Funktion "Strict Reverse Path Forwarding" und diese Funktion steht im Zusammenhang mit Antispoofing und Routing resp. Wenn "strict-src-check" deaktiviert ist, wird diese Konfiguration als "loose" bezeichnet. Ist "strict-src-check" akiviert wird die Konfiguration als "strict" bezeichnet. Die Standard Konfiguration für ein FortiOS ist "strict-src-check disable" (loose) und schützt uns vor:

        • IP Spoofing Attacks
        
        • Kontrolliert die Source IP Adressen der Packete (Dies bedeutet: IP Packete werden dem FortiOS aus einem bestimmten Segment in ein
          bestimmtes Segment obwohl die Source IP aus einem anderen auf dem FortiOS konfigurierten Segment stammt. In diesem Fall werden die
          IP Packet werworfen da der Path zurück zur Source IP nicht möglich ist! Desweiteren: IP Packete werden dem FortiOS weitergeleitet
          von einer Source IP die nicht der Routing Konfiguration entspricht. Wenn durch ein bestimmter Routing Eintrag auf dem FortiOS ein 
          bestimmter IP Range in ein bestimmtes Segment sendet jedoch dieser IP Range über ein anderes Segment dem FortiOS weitergeleitet 
          wird so wird das IP Packet verworfen. Dies gilt für statisches Routing, RIP, OSPF, und BGP! Solche IP Packete werden durch das 
          FortiOS "silently" verworfen dh. ohne Log Eintrag. Weitere Informationen dazu siehe nachfolgender Knowledge Base Artikel:
          
          http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30543&languageId=

Die Funktion "strict-src-check" ist per Standard auf "loose" (disabled) gesetzt um grundsätzlich AntiSpoofing zu verhindern! Dies bedeutet: Wenn "loose" gesetzt ist (disabled), ist man betreffend "Antispoofing" zwischen den "Internen Segmenten" geschützt für "Spoofing Attacken" dh. zB. DMZ-to-LAN etc. Potentiell wäre es jedoch möglich, vom "Internet Segment" her anhand privater IP eine "IP Spoofing Attacke" durchzuführen. Dies wird jedoch verhindert da der ISP unter normalen Umständen verhindert, dass private IP's im Internet Segment geroutet werden. Aus diesem Grund ist die Standard Einstellung von "strict-src-check disabled" (loose) für Perimeter Firewall ausreichend kann jedoch auch auf "strict-src-check enabled" (strict) gesetzt werden um dem Umstand von "IP Spoofing Attacken" anhand private IP's über das Internet Segment entgegenzutreten. Wird eine FortiGate Firewall als "LAN Firewall" eingesetzt, sollte die Option "strict-src-check enabled" benutzt werden um "strict" Mode zu benutzen da auf allen Interfaces ein Routing von private IP's potentiell möglich ist. Desweiteren gibt es Situationen in denen ein "Asymetrisches Routing" implementiert werden muss (Datacenter). Solche Implementationen sollte jedoch möglichst verhindert werden! Wenn jedoch ein "Asymetrisches Routing" implementiert werden muss und die Auswirkungen bekannt sind, ist es nicht empfohlen "strict-src-check disable" (loose) zu benutzen. Somit sollte/muss für ein "Asymetrisches Routing" der "strict-src-check enable" (strict) verwendet werden. Die "strict-src-check" Funktion sollte in einem "Asymentrisches Routing" nur dann deaktiviert werden dh. "loose" um Netzwerkprobleme/Routing zu verifizieren resp. zu eruieren. Dies bedeutet: Für eine "Asymetrisches Routing" sollte per Standard folgendes konfiguriert werden:

        # config system settings
        # set strict-src-check enable
        # end
        
        # config system settings
        # set asymroute enable
        # end

=== Wie kann ich unter FortiOS 5.4 die BFD (Bi-Directional Forwarding Detection) Funktion auf einem Interface aktivieren? ===

Die Bi-Directional Forwarding Detection (BFD) Funktion wird per Standard über die "system settings" Konfiguration gesteuert. Dies bedeutet: Für ein Interface ist die "bfd" Option per Standard auf "global" konfiguriert. Um die Option "bfd" unter "system settings" zu konfigurieren führe folgendes aus:

        # config system settings
        # set bfd [enable | disable]
        # end

Wird die "bfd" Option unter "system settings" aktiviert (Per Standard Deaktiviert), wird die entsprechende Konfiguration für die Interfaces herangezogen:

        # config system interface
        # edit [Name des entsprechenden Interfaces zB "internal1"]
        # set bfd [global | enable | disable]
        # end

Wird somit unter "system settings" die Option "bfd" aktiviert, sollte für alle Interfaces auf diesen "bfd" nicht benützt werden soll, diese Option Deaktiviert werden! Die BFD Funktion kann ebenfalls innerhalb OSPF Routing Protokolls sowie Interface aktiviert werden:

        # config router ospf
        # set bfd [enable | disable]
        # config ospf-interface
        # edit [Name des entsprechenden Interfaces zB "internal1"]
        # set bfd [global | enable | disable]
        # next
        # end
        # end

Nachdem BFD auf zB zwei Interfaces aktiviert wurde, kann durch folgenden Befehl der Status für BFD für diese Interfaces abgefragt werden:

        # get router info bfd neighbor
        OurAddress        NeighAddress        State        Interface         LDesc/RDesc

== Policy Routing ==

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device eine Dual ISP Konfiguration erstellen anhand Policy Routing? ===

Wenn unter FortiOS 5.4 eine Konfiguration durchgeführt werden soll anhand zwei zur Verfügung stehender ISP Verbindungen muss Grundlegend von zwei Scenarien
ausgegangen werden:

        • Active-Passive (Nur eine ISP Verbindung Active und zweite ISP Verbindung Passive für Failover)
        • Active-Active  (Beide ISP Verbindungen sind Active und stehen für Failover zur Verfügung)

Wenn eine Active-Passive Konfiguration durchgeführt wird so kann dies anhand der "distance" durchgeführt werden. Dies bedeutet: In der Routing Konfiguration werden unterschiedliche "distance" für die Routing Einträge des Default Gateways der ISP's konfiguriert. Der Default Gateway Routing Eintrag mit dem höheren Wert für "distance" (zB distnace 20) wird aus der Routing Tabelle entfernt und somit verbleibt nur ein Default Gateway Eintrag (zb distance 10). Dadurch wird ein Active-Passive Scenario konfiguriert. Wir empfehlen jedoch eine Active-Active Konfiguration da diese über mehr Flexibilität verfügt. In so einem Fall wird die "distance" beider Default Gateways mit gleichen Wert konfiguriert (zB distnace 10). Somit existieren beide Default Gateways in der Routing Tabelle und sind Gleichwertig (Equal Cost Multipathing). Da beide ISP Verbindungen Gleichwertig sind, kann nun über ein Policy Routing entschieden werden welcher Traffic über welchen ISP gesendet wird. Dabei steht jeweils die zusätzliche ISP Verbindung sofern gewünscht als Failover zur Verfügung. Im nachfolgenden Beispiel wird Schritt für Schritt aufgezeigt wie eine Active-Active Konfiguration anhand zwei zur Verfügung stehender ISP durchgeführt wird. In dieser Schritt für Schritt Anleitung werden einige zusätzliche Menüpositionen resp. Features benutzt, die nicht per Standard auf einem Mgmt. Web Interface einer FortiGate aktiviert sind. Somit müssen diese Menüpositionen resp. Features aktiviert werden. Weitere Informationen wie diese Menüposition oder Features aktiviert werden siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

Für diese Schritt für Schritt Anleitung gehen wir von folgender Situation aus:

         _________________________                  ___________                                                ___________ 
        |                         |     198.18.3.1 |           |212.59.153.114/29           212.59.153.113/29 |           |                __________
        | DMZ Env. 198.18.3.0/24  |------DMZ-------|           |------ wan2 ----------------------------------| Router I  |---------------|          |
        |_________________________|                |           | (DHCP Konfiguration VDSL                     |___________|               |          |
         _________________________                 | FORTGATE  |                                               ___________                | Internet |
        |                         |     198.18.0.1 |           |193.193.135.66/27           193.193.135.65/27 |           |               |          |
        | LAN Env. 198.18.0.0/24  |----- LAN ------|           |------ wan1 ----------------------------------| Router II |---------------|__________|
        |_________________________|                |___________| (Manuelle Konfiguration)                     |___________|

Bei der Konfiguration der ISP Verbindung muss auf folgendes geachtet werden: Wenn eine ISP Verbindung anhand eine statische resp. manuelle IPv4 Konfiguration durchgeführt wird, muss der Default Gateway zusätzlich als statische Route konfiguriert werden. Dabei spielt die "distance" eine entscheidende Rolle dh. diese muss über den gleichen Wert verfügen wie zweite ISP Verbindung. Wenn eine ISP Verbindung anhand einer dynamischen Konfiguration durchgeführt wird dh. PPPoE oder DHCP, dann muss die entsprechende "distance" nicht in der Routing Tabelle für ein statisches Routing konfiguriert werden, sondern innerhalb des Interface Konfiguration damit später die dynamisch zugewiesenen Default Gateways des ISP mit der entsprechender "distance" in die Routing Tabelle eingetragen wird. Per Standard gilt auf einem FortiOS folgende Werte betreffend Routing:

        • distance 10
        • priority 0

Konfiguriere die Interfaces für die zwei ISP Verbindungen:

        Network > Interfaces > [Markiere den Eintrag "wan1"] > Edit 

        [[Datei:Fortinet-2082.jpg]]

        Network > Interfaces > [Markiere den Eintrag "wan2"] > Edit 

        [[Datei:Fortinet-2083.jpg]]

Für die "wan2" Konfiguration die dynamisch durchgeführt wurde dh. anhand DHCP wurde die "distance" explizit auf den Wert 10 gesetzt. Somit wird der Default Gateway anhand "Retrieve default gateway from server" vom ISP zugewiesen und in die Routing Tabelle mit dem Wert "distance 10" eingetragen. Zusätzlich ist es Wichtig bei einer dynamischen ISP Konfiguration des Interface, dass die Position "Override Internal DNS" nicht aktiviert ist damit die System DNS Konfiguration des FortiOS nicht überschrieben wird. Für "wan1" wurde eine manuelle resp. statische Konfiguration durchgeführt. Somit muss der Default Gateway anhand einer statischen Route mit der richtigen "distance 10" in die Routing Tabelle eingetragen werden:

        Network > Static Routes

        [[Datei:Fortinet-2084.jpg]]

Wenn beide ISP Verbindungen aktiv sind, muss nun das Routing kontrolliert werden dh. beide Default Gateways müssen in der Routing Tabelle mit gleicher "distance 10" und "priority 0" erscheinen. Die Information über die "Distance" sowie "Metric" muss jedoch über die zusätzlichen Spalten eingeblendet werden damit diese ersichtlich sind dh. führe folgendes durch:

        Monitor > Routing Monitor > [Rechte Maustaste auf Spalte] > [Wähle "Distance" sowie "Metric"] > Apply

        [[Datei:Fortinet-2085.jpg]]

Danach können die Routing Einträge der ISP kontrolliert werden dh. das beide Gleichwertig sind sprich über die gleiche "distance" und "priority" vefügen:

        Monitor > Routing Monitor

        [[Datei:Fortinet-2086.jpg]]

Diese Kontrolle kann ebenfalls in der CLI anhand des folgende Kommandos durchgeführt werden. Dabei ist jedoch zu berücksichtigen, dass dieses Kommando nur die "aktiven" Routing Einträge der Routing Tabelle auflistet und nicht die nicht aktiven:

        # get router info routing-table all
        Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
               O - OSPF, IA - OSPF inter area
               N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
               E1 - OSPF external type 1, E2 - OSPF external type 2
               i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
               * - candidate default
        
        S*      '''0.0.0.0/0 [10/0] via 193.193.135.65, wan1'''
                          '''[10/0] via 212.59.153.113, wan2'''
        C       193.193.135.64/27 is directly connected, wan1
        C       198.18.0.0/24 is directly connected, internal1
        S       198.18.1.0/25 [10/0] is directly connected, ssl.root
        C       198.18.2.0/25 is directly connected, fortinet4intern
        C       198.18.2.128/25 is directly connected, fortinet4guest
        C       198.18.3.0/24 is directly connected, dmz
        C       212.59.153.112/29 is directly connected, wan2 

Um alle Routing Einträge aus der Routing Tabelle egal ob diese "aktiv" sind oder nicht aufzulisten kann folgender Befehl in der CLI benutzt werden:

        # get router info routing-table database
        Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
               O - OSPF, IA - OSPF inter area
               N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
               E1 - OSPF external type 1, E2 - OSPF external type 2
               i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
               > - selected route, * - FIB route, p - stale info
        
        S    *> '''0.0.0.0/0 [10/0] via 193.193.135.65, wan1'''
             *>           '''[10/0] via 212.59.153.113, wan2'''
        C    *> 193.193.135.64/27 is directly connected, wan1
        C    *> 198.18.0.0/24 is directly connected, internal1
        S    *> 198.18.1.0/25 [10/0] is directly connected, ssl.root
        C    *> 198.18.2.0/25 is directly connected, fortinet4intern
        C    *> 198.18.2.128/25 is directly connected, fortinet4guest
        C    *> 198.18.3.0/24 is directly connected, dmz
        C    *> 212.59.153.112/29 is directly connected, wan2

Somit gilt für diese zwei ISP Konfigurationen die wir durchgeführt haben ECMP (Equal Cost Multipathing; Source IP Based). Wieso ECMP benutzt wird in der aktuellen Konfiguration siehe 
nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_wird_unter_FortiOS_5.4_auf_einer_FortiGate_ein_Routing_Tabelle_.22lookup.22_durchgef.C3.BChrt_und_wie_wird_das_.22Routing.22_abgearbeitet.3F]]

Als nächsten Schritt muessen die zwei ISP Verbindungen überwacht werden damit dem FortiOS mitgeteilt wird, wenn eine ISP Verbindung nicht mehr zur Verfügung steht. Dies kann anhand Link Monitor konfiguriert werden. Wird durch Link Monitoring festgestellt das eine ISP Verbindung nicht mehr zur Verfügung steht, wird der entsprechende Default Gateway Eintrag aus der Routing Tabelle entfernt und somit wird der gesamte verbleibende Traffic über den verbleibende ISP Verbindung resp. Default Gateway gesendet. Unter FortiOS 5.4 GA Release steht der Menüpunkt für die Link Monitoring Konfiguration nicht mehr zur Verfügung. Aus diesem Grund muss diese Konfiguration über CLI durchgeführt werden:

        # config system link-monitor
        # edit [Name für den Link Monitor zB "wan1"]
        # set srcintf [Name des Interfaces zB "wan1"]
        # set server [Name des Servers für Ueberwachung zB "8.8.8.8"]
        # set protocol ping 
        # set gateway-ip 0.0.0.0
        # set source-ip 0.0.0.0
        # set interval 5
        # set timeout 1
        # set failtime 5
        # set recoverytime 5
        # set ha-priority 1
        # set update-cascade-interface disable 
        # set update-static-route enable 
        # set status enable 
        # end

        # edit [Name für den Link Monitor zB "wan2"]
        # set srcintf [Name des Interfaces zB "wan2"]
        # set server [Name des Servers für Ueberwachung zB "8.8.4.4"]
        # set protocol ping 
        # set gateway-ip 0.0.0.0
        # set source-ip 0.0.0.0
        # set interval 5
        # set timeout 1
        # set failtime 5
        # set recoverytime 5
        # set ha-priority 1
        # set update-cascade-interface disable 
        # set update-static-route enable 
        # set status enable 
        # end

Zur Ueberwachung der ISP Links im Link Monitoring wird ein IPv4 Adresse definiert. In unserem Beispiel "8.8.8.8" sowie "8.8.4.4". Diese IPv4 Adressen stelle die öffentlichen Google DNS Server dar und sollten in produktiven Umgebungen nicht genutzt werden. Dies bedeutet: Ziel ist es zu verifizieren ob die ISP Verbindung inkl. Backbone des ISP Routing technisch zur Verfügung steht. Somit sollte ein Ping Server gewählt werden, der durch den Backbone des ISP Providers erreichbar ist. Ist dieser Ping Server nicht mehr erreichbar, wird durch den Link Monitor für das entsprechende Interface durch die Option "update-static-route" der Routing Eintrag für den Default Gateway in der Routing Tabelle entfernt. Die konfigurierten Link Monitore können über folgende Position mit deren Status eingesehen werden:

        Monitor > WAN Link Monitor

        [[Datei:Fortinet-2087.jpg]]

Wie schon erwähnt gilt in der momentanen Konfiguration ECMP dh. es gilt Routing technisch gesehen folgendes:

       0) Routing Cache
       1) Policy Route
       2) Longest Match
       3) Distance
       4) Priority
       5) Metric (Dynamisches Routing)
       6) ECMP (Equal Cost Multiple Path)

Um den Routing Cache zu erneuern kann folgender Befehl abgesetzt werden:

        # execute router restart

Da ECMP per Standard auf "Source-IP Based" gesetzt ist, wird der Traffic momentan Source IP Based basierend zwischen diesen beiden ISP Verbindungen verteilt. Um dies zu verhindern können nun "Policy Routen" konfiguriert werden um durch diese Explizit den Traffic über "wan1" oder "wan2" zu senden. Diese "Policy Routen" können unter folgender Position konfiguriert werden:

        Network > Policy Routes

In dieser "Policy Route" resp. Tabelle gilt "top down first match wins"! Bei der Konfiguration einer "Policy Route" ist jedoch folgendes zu berücksichtigen: In der "Policy Route" steht unter der Position Protocol "ANY" zur Verfügung. Diese Funktion "ANY" unter Protocol sollte nicht benutzt werden. Wird die Position "ANY" dennoch benutzt, wird der entsprechende Traffic in jedem Fall unweigerlich über das konfigurierte Interface gesendet ohne Ausnahme. Somit existiert zB ein "dmz" ist dieses für die definierte Source nicht mehr erreichbar! Möchte man zB das der gesamte Traffic für TCP und/oder UDP über "wan1" gesendet wird muss folgende "Policy Routen" konfiguriert werden:

        Network > Policy Routes > Create New > Protocol TCP

        [[Datei:Fortinet-2088.jpg]]

        Network > Policy Routes > Create New > Protocol UDP

        [[Datei:Fortinet-2089.jpg]]

Somit wird durch diese zwei konfigurierten "Policy Routen" sätmlicher LAN (internal1) Traffic für TCP und UDP für die Destination Ports 1-65535 über "wan1" gesendet. Die "Destination address / mask" 0.0.0.0/0.0.0.0 indiziert dabei alle Destinationen. Wird die Konfiguration betreffend "Gateway Address" mit 0.0.0.0 konfiguriert, wird in der Routing Tabelle für das definierte Outgoing Interface der entsprechende Routing Eintrag resp. Default Gateway IPv4 Adresse herangezogen. Die momentane Konfiguration umfasst somit zwei "Policy Routen":

        Network > Policy Routes

        [[Datei:Fortinet-2090.jpg]]

Soll nun eine spezifisches Protokoll zB VoIP (UDP 5060) über "wan2" gesendet werden muss eine neue "Policy Route" konfiguriert werden:

        Network > Policy Routes > Create New > Protocol UDP

        [[Datei:Fortinet-2091.jpg]]

Wie schon erwähnt gilt in dieser Tabelle der Policy Routen "top down first match wins". Somit muss nun diese neu erstellte "Policy Route" für VoIP vor den bereites bestehenden gesetzt werden da ansonsten die bereits bestehende UDP basierende "Policy Route" für alle UDP Port 1-65535 greift. Die einzelnen "Policy Routen" können mit der Maus per "drag & drop" so arrangiert werden wie gewünscht:

        Network > Policy Routes

        [[Datei:Fortinet-2092.jpg]]

Betreffend Routing ist desweiteren folgendes zu berücksichtigen: Existiert für einen spezifischen Traffic keine "Policy Route" dh. zB für ein "dmz", wird das reguläre Routing (Layer 3) entsprechend dem Traffic verarbeitet! Dies kann als Beispiel anhand einer "dmz" IPv4 Adresse unter folgender Position verifziert werden:

        Monitor > Routing Monitor

        [[Datei:Fortinet-2093.jpg]]

        [[Datei:Fortinet-2094.jpg]]

Anhand "198.18.3.5" wird nun in der Routing Tabelle ein Lookup durchgeführt and aufgezeigt über welchen Routing Eintrag diese IPv4 Adresse gesendet wird:

        [[Datei:Fortinet-2095.jpg]]

Als nächsten Schritt muss nun der entsprechende Traffic auf der Firewall anhand "Firewall Policy Rules" auf "wan1" und/oder "wan2" erlaubt werden:

        Policy & Objects > IPv4 Policy > Create New

        [[Datei:Fortinet-2096.jpg]]

Soll ein spezifischer Traffic bei einem Failover nicht erlaubt werden, kann für das entsprechende Failover Outgoing Interface eine "Explizit Deny" Firewall Policy konfiguriert werden. Als Beispiel: Wenn VoIP regulär über "wan2" gesendet wird jedoch verhindert werden soll, dass VoIP in einem Failover Scenario über "wan1" gesendet wird, kann folgende "Firewall Policy Rule" konfiguriert werden:

        Policy & Objects > IPv4 Policy > Create New

        [[Datei:Fortinet-2097.jpg]]

Als letzten Schritt muss folgendes beachtet werden: Der System DNS Server der konfiguriert wird, muss ISP unabhängig sein! Dies bedeutet: Wird ein DNS Server auf dem FortiOS konfiguriert einer ISP Verbindung zB "wan1" kann dieser zwar für diese ISP Verbindung zB "wan1" benutzt werden, funktioniert jedoch für "wan2" nicht da dies durch den "wan2" ISP verhindert wird. Somit stellt sich die Frage: Was für DNS Server zu konfigurieren sind? Die Lösung die in jedem Falle funktioniert, ist ein interner DNS Server der anhand der "root server" konfiguriert wurde und somit als Caching Server figuriert. Dies bedeutet: Für einen Domain Controller wird eine lokale Domaine konfiguriert. Alle DNS Anfragen die nicht für die lokale Domaine bestimmt sind werden diesen "root server" für eine DNS Auflösung weitergeleitet. Um dies auf einem Domain Controller zu konfigurieren führe folgendes aus:

        Domain Controller > DNS > Local Domain Controller > [Rechte Maustaste] > Eigenschaften

        [[Datei:Fortinet-2098.jpg]]

Es darf unter normalen Umständen kein Eintrag unter "Weiterleitung" existieren. Ist kein Eintrag vorhanden, werden die Anfragen an die "Stammhinweise" weitergeleitet. Diese "Stammhinweise" stellen die "root server" dar die von jeder IPv4 Source benutzt werden können:

        [[Datei:Fortinet-2099.jpg]]

Nun muss dem FortiOS mitgeteilt werden, dass dieser interne DNS Server auf dem Domain Controller benutzt werden soll. Wie die System DNS Server eines FortiOS konfiguriert werden siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_unter_FortiOS_5.4_auf_einer_FortiGate_die_System_DNS_Server.3F]]

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device das Routing für "policy routing" auflisten? ===

Unter FortiOS 5.4 kann mit "policy routing" gearbeitet werden dh. Policy Routing ist "Layer 4" basierend und wird vor einer statischen Route abgearbeitet. Policy Routen selber werden über das Mgmt. Web Interface konfiguriert unter folgender Position:

        Network > Policy Routes

Werden unter dieser Position "Policy Routes" konfiguriert gilt für die Reihenfolge "top down first match wins". Dies bedeutet: Durch die Konfiguration von "Policy Routes" wird die "Policy-based route" Tabelle angelegt und herangezogen um das Routing im generellen abzuarbeiten. Diese "Policy-based route" Tabelle kann über folgendes CLI Kommando eingesehen werden:

        # diagnose firewall proute list
        list route policy info(vf=root):
        id=2 flags=0x0 tos=0x00 tos_mask=0x00 protocol=6 sport=1:65535 iif=7 dport=1-65535 oif=4 gwy=0.0.0.0 
        source wildcard(1): 198.18.0.0/255.255.255.0 
        destination wildcard(1): 192.168.1.0/255.255.255.0 
        id=1 flags=0x0 tos=0x00 tos_mask=0x00 protocol=6 sport=1:65535 iif=7 dport=1-65535 oif=4 gwy=0.0.0.0 
        source wildcard(1): 198.18.0.0/255.255.255.0 
        destination wildcard(1): 192.168.0.0/255.255.255.0 

Dieser "output" listet die "Policy Routes" auf wie diese unter "Network > Policy Routes" aufgelistet werden dh. die vergebene "id" für die "Policy Routes" ist kein Indikator welche "Policy Route" für "top down" benutzt wird sondern wie schon erwähnt gilt auch hier in diesem "output" für die Abarbeitung "top down first match wins".

== Email Service ==

=== Wie kann ich unter FortiOS 5.4 für eine FortiGate den "Email Service" konfigurieren? ===

Unter FortiOS 5.4 bezeichnet die "Email Service" Funktion die Konfiguration eines SMTP Servers. Dieser wird auf einem FortiOS benutzt um verschiedene Funktionen zu ermöglichen wie zB:

        • Alert Email
        • Two-Facto Authentication
        • Wireless Guest-Provisioning 

Der "Email Service" kann über Mgmt. Web Interface konfiguriert werden. Dies wird folgendermassen durchgeführt:

        System > Advanced > Email Service

        [[Datei:Fortinet-1670.jpg]]

Der "Email Service" ermöglicht es eine Verschlüsselung für den SMTP Server zu konfigurieren dh. SMTPS (SSL/TLS Port 465) oder STARTTLS (SMTP + TLS Port 587). Die Konfiguration kann ebenfalls über CLI durchgeführt werden:

        # config system email-server
        # set reply-to [Absender Email Adresse]
        # set server [FQDN SMTP Server]
        # set port [Gebe einen entsprechenden Port an zB "25"]
        # set source-ip [Optional gebe eine Source IPv4 Adresse an für den Absender der SMTP Nachricht]
        # set source-ip6 [Optional gebe eine Source IPv6 Adresse an für den Absender der SMTP Nachricht]
        # set authentication [enable | disable]
        # set username [Username für die Authentifizierung]
        # set password [Passwort für die Authentifizierung]
        # set validate-server [enable| disable]
        # set security [none | smtps | starttls]
        # end

=== Wie kann ich unter FortiOS 5.4 für eine FortiGate die Funktion "alertemail" konfigurieren? ===

Auf einem FortiOS 5.4 kann über die Funktion "alertemail" eine Alarmierung anhand Email Nachrichten konfiguriert werden. Damit das entsprechende Kommando "alertemail" unter FortiOS zur Verfügung steht, muss Minimum der "Email Service" konfiguriert werden dh. ein entsprechender SMTP Server. Wird diese Funktion des "Email Service" nicht konfiguriert, steht die Funktion resp. das Kommando "alertemail" nicht zur Verfügung. Weitere Informationen zu der Konfiguration des "Email Service" siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]

Je nach "log" Device stehen nicht alle Optionen unter "alertemail" zur Verfügung da viele dieser Optionen ein "disk" Logging voraussetzen! Für die Konfiguration der Funktion "alertemail" stehen folgende Optionen zur Verfügung:

        # config alertemail setting
        # set username [Gebe eine entsprechende Email Adresse an als Absender zB "noreply@mydomain.ch"]
        # set mailto1 [Gebe eine entsprechende Email Adresse1 an als Empfänger zB "user@mydomain.ch"]
        # set mailto2 [Gebe eine entsprechende Email Adresse1 an als Empfänger zB "user@mydomain.ch"]
        # set mailto3 [Gebe eine entsprechende Email Adresse1 an als Empfänger zB "user@mydomain.ch"]
        # set filter-mode [category | threshold]
        # set email-interval [Gebe einen Interval an zwischen den Emails zB "5"]
        # set IPS-logs [enable | disable]
        # set firewall-authentication-failure-logs [enable | disable]
        # set HA-logs [enable | disable]
        # set IPsec-errors-logs [enable | disable]
        # set FDS-update-logs [enable | disable]
        # set PPP-errors-logs [enable | disable]
        # set sslvpn-authentication-errors-logs [enable | disable]
        # set antivirus-logs [enable | disable]
        # set webfilter-logs [enable | disable]
        # set configuration-changes-logs [enable | disable]
        # set violation-traffic-logs [enable | disable]
        # set admin-login-logs [enable | disable]
        # set FDS-license-expiring-warning [enable | disable]
        # set log-disk-usage-warning [enable | disable]
        # set fortiguard-log-quota-warning [enable | disable]
        # set amc-interface-bypass-mode [enable | disable]
        # set FIPS-CC-errors [enable | disable]
        # set FDS-license-expiring-days [Gebe Anzahl Tage an bevor FDS (FortiGuard) abläuft zB "15+]
        # set local-disk-usage [Gebe in % an wann eine Nachricht für "diskusage" gesendet werden soll zB "75"]
        # set emergency-interval [Gebe einen entsprechenden Interval ein zB "1"]
        # set alert-interval [Gebe einen entsprechenden Interval ein zB "2"]
        # set critical-interval [Gebe einen entsprechenden Interval ein zB "3"]
        # set error-interval [Gebe einen entsprechenden Interval ein zB "5"]
        # set warning-interval [Gebe einen entsprechenden Interval ein zB "10"]
        # set notification-interval [Gebe einen entsprechenden Interval ein zB "20"]
        # set information-interval [Gebe einen entsprechenden Interval ein zB "30"]
        # set debug-interval [Gebe einen entsprechenden Interval ein zB "60"]
        # set severity [emergency | alert | critical | error | warning | notification | information | debug]
        # end

== SMS Service ==

=== Wie kann ich unter FortiOS 5.4 auf einer FortiGate einen SMS Service/Provider konfigurieren? ===

Wenn auf einer FortiGate eine Two-Factor Authentication konfiguriert werden soll basierend auf ODA (On-Demand Authentication) muss ein entsprechender SMS Service resp. Provider konfiguriert werden. Per Standard steht auf einer FortiGate ein FortiGuard SMS Provider zur Verfügung jedoch ist dieser FortiGuard SMS Provider nicht in FortiCare und/oder FortiGuard enthalten. Bei diesem FortiGuard SMS Provider handelt es sich um den Amerikanischen SMS Provider Clickatell. Dieser SMS Service über FortiGuard wird von unserer Seite nicht empfohlen und anstelle dessen sollte ein lokaler SMS Provider gewählt werden. Dabei ist zu beachten, dass der gewählt SMS Provider einen SMS Versandt über EMail unterstützt da die FortiGate kein SMS Versandt über HTTP/S get und post unterstützt. Von userer Seite her können folgende SMS Provider empfohlen werden:

        • Swisscom (@sms.ip-plus.net)
        • Dolphin (https://www.dolphin.ch/dolphin-systems/)
        • Truesenses (http://www.truesenses.com/)

Da der SMS Versand über den Email Service durchgeführt wird, gilt die Konfiguration eines Email Service als Voraussetzung für die Konfiguration eines SMS Service. Wie der Email Service zu konfigurieren ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]

Danach sind die Voraussetzungen gegeben einen SMS Service resp. Provider auf der FortiGate zu konfigurieren. Die Konfiguration kann über CLI durchgeführt werden:

        # config system sms-server
        # edit [Name des Service/Provider zB "swisscom"]
        # set mail-server [FQDN des Mail Server für SMS Versandt zB "sms.ip-plus.net"]
        # end

Wird ein User lokal erfasst und diesem über SMS eine Two-Factor Authentifizierung aktiviert muss für diesen User eine entsprechende Mobile Nummer definiert werden. Wird über einen Service auf der FortiGate eine Two-Factor Authentifizierung ausgelöst so wird im Hintergrund über den definierten SMS Service/Provider der für die Mobiel Nummer konfiguriert wurde ein Email generiert in folgender Form:

        [Land][Vorwahl][Mobile Nummer]@[FQDN des Mail Server für SMS Versandt]

== FortiView ==

=== In FortiView unter FortiOS 5.4 werden "unbekannte Applikationen" sowie "lokaler Traffic" nicht aufgelistet? ===

Unter der Voraussetzung das ein "logging" auf einer FortiGate korrekt konfiguriert wurde fällt einem auf, dass "unbekannte Applikationen" sowie "lokaler Traffic" nicht unter FortiView aufgelistet werden. Dies bedeutet: Wird "Application Control" benutzt und eine FortiGate kann eine Applikation nicht "identifizieren" fehlt dieser "Traffic" per Standard unter FortiView. Möchte man diese "unbekannten Applikationen" dennoch auflisten kann dies durch folgende Konfiguration durchgeführt werden:

        # config log gui-display
        # set fortiview-unscanned-apps [enable | disable]
        # end

Ebenso wird der "lokale Traffic" einer FortiGate dh. initiert durch den Device selber wie zB DNS, FortiGuard usw. nicht unter FortiView aufgelistet. Möchte man diesen "lokalen Traffic" auflisten so kann dies folgendermassen Konfiguriert werden:

        # config log gui-display
        # set fortiview-local-traffic [enable | disable]
        # end

Diese Konfiguration kann auch über Mgmt. Web Interface durchgeführt werden unter folgender Position:

        [[Datei:Fortinet-1626.jpg]]

        [[Datei:Fortinet-1627.jpg]]

== Prozesse ==

=== Wie kann ich unter FortiOS 5.4 die Prozesse die auf einer FortiGate existieren auflisten? ===

Auf einer FortiGate existieren unzählige von Prozesse und Dienste die zuständige sind um die verschiedenen Aufgaben einer Firewall durchzuführen. Um die Prozesse aufzulisten kann folgendes Kommando benutzt werden:

        # diagnose sys top [refresh_time_sec] [number_of_lines]

Somit möchte man einfach die "top" 20 Prozesse (Standard) auflisten kann der vorhergende Befehl benutzt werden ohne Optionen von "refresh_time_sec" sowie "number_of_lines":

        # diagnose sys top
        Run Time:  1 days, 5 hours and 23 minutes
        1U, 2N, 0S, 97I; 1839T, 1421F
                 miglogd       55      S       3.1     1.3
                  newcli     2136      R <     0.5     0.8
               ipsengine      114      S <     0.0     3.8
                  httpsd      119      S       0.0     1.9
                  httpsd      162      S       0.0     1.9
                 cmdbsvr       38      S       0.0     1.4
                 pyfcgid     2090      S       0.0     1.4
                 pyfcgid     2092      S       0.0     1.3
                 pyfcgid     2094      S       0.0     1.3
                 pyfcgid     2093      S       0.0     1.3
               ipshelper       69      S <     0.0     1.2
                 sslvpnd       73      S       0.0     1.2
                  httpsd       57      R       0.0     1.1
                  httpsd      118      S       0.0     1.0
                  cw_acd      108      S       0.0     0.9
               forticron       66      S       0.0     0.9
                     wad       99      S       0.0     0.8
                   fgfmd      107      S       0.0     0.8
               scanunitd      110      S <     0.0     0.8
                  newcli     2086      S <     0.0     0.8

Um den Befehl resp. die Funktion zu beenden benütze "Ctrl + C". Wenn Prozesse untersucht/beobachtet werden sollen dh. ob diese viele Resourcen beanspruchen etc. kann anhand "refresh_time_sec" und "number_of_lines" der Befehl erweitert werden. Dies bedeutet: Nachfolgendes Beispiel zeigt wie der Befehl ausgeführt wird und zwar mit einer "refresh_time_sec" von 5 Sekunden und "number_of_lines" von 10 was wiederum heisst, es werden nur die Top 10 Prozesse/Dienste aufgelistet: 

        # diagnose sys top 5 10
        Run Time:  1 days, 5 hours and 27 minutes
        0U, 2N, 0S, 98I; 1839T, 1421F
                 miglogd       55      S       2.9     1.3
                  newcli     2141      R <     0.5     0.8
               ipsengine      114      S <     0.0     3.8
                  httpsd      119      S       0.0     1.9
                  httpsd      162      S       0.0     1.9
                 cmdbsvr       38      S       0.0     1.4
                 pyfcgid     2090      S       0.0     1.4
                 pyfcgid     2092      S       0.0     1.3
                 pyfcgid     2094      S       0.0     1.3
                 pyfcgid     2093      S       0.0     1.3

Der nachfolgende Abschnitt was die verschiedenen Positionen in der Auflistung der Prozesse für eine Bedeutung haben um die Informationen korrekt zu intepretieren:

        [[Datei:Fortinet-307.jpg]]

Zusätzlich ist folgendes zu beachten: Die Prozesse werden mit verschiedenen "Status" aufgelistet:
             
        S     Sleeping
        R     Running
        D     Do not disturb
        Z     Zombie

"R" und "S" Status Informationen eines Prozesses sind normal. Das ein Prozess in den Status "D" wechselt kann für kurze Zeit vorkommen. Bleibt der Status jedoch für längere Zeit im Status "D" ist dies ein Indiz das dieser Prozess nicht korrekt arbeitet. Ein Status "Z" für einen Prozess ist klar ein Indiz das dieser Prozess nicht korrekt läuft. Ein Prozess im Status "Z" kann nicht mit "kill" beendet werden dh. um diesen Prozess zu beenden ist ein Neustart des Devices notwendig!

=== Wie kann ich unter FortiOS 5.4 die Prozesse die auf einer FortiGate existieren nach Memory Benützung auflisten? ===

Eine weitere Möglichkeit um die Prozesse aufzulisten wäre:

        # diagnose sys top-summary -h
        Usage: top.py [options]
        
        Options:
          -n LINES, --num=LINES
                                Number of top processes to show (20 by default)
          -i INTERVAL, --interval=INTERVAL
                                Update interval, in seconds (1 by default)
          -s SORT, --sort=SORT  Sort mode: [cpu_percent (default)|mem|fds|pid]
          -d, --dump            Dump stats to the files
          -h, --help            show this help message and exit

Anhand dieser Optionen kann folgender Befehl abgesetzt werden um mit "-s mem" die Prozess nach Memory Benützung zu sortieren und alle 60 Sekunden "-i 60" einen Refresh durchzuführen sowie mit "-n 10" die Top 10 Prozesse aufzulisten:

        # diagnose sys top-summary '-s mem -i 60 -n 10'
        
           CPU [||||||||||||||||||||||||||||||||||||||||] 100.0%
           Mem [||||||||                                ]  22.0%   421M/1839M
           Processes: 10 (running=3 sleeping=85)
           
           PID      RSS   CPU% ^MEM%   FDS     TIME+  NAME
         * 60       83M    0.0  4.5    38  00:29.40  ipsmonitor [x3]
           57       50M    0.0  2.7    19  02:10.82  httpsd [x4]
           38       27M    0.0  1.5    13  01:14.17  cmdbsvr
           2090     26M    0.0  1.4    13  00:01.31  pyfcgid [x4]
           55       24M    0.0  1.3    25  37:23.73  miglogd
           73       22M    0.0  1.2    31  00:01.40  sslvpnd
           2086     19M    0.0  1.1    12  00:01.26  newcli [x2]
           108      17M    0.0  1.0    34  01:04.20  cw_acd
           66       17M    0.0  0.9    21  00:00.25  forticron
           84       15M    0.0  0.9    51  00:02.47  wad [x2]
           
           '''NOTE''' die Angabe "-s mem" indiziert die Spalte "MEM%" dh. sollen die Prozess nach "CPU%" Auslastung sortiert werden kann
                anstelle von "-s mem" die Angabe "-s cpu" benützt werden!

=== Welche Prozesse existieren auf einer FortiGate nach deren Namen und welche Aufgaben haben diese? ===

Auf einer FortiGate existieren unzählige Prozesse die für verschiedenen Aufgaben zuständig sind. Diese könne zB anhand "diagnose sys top 5 99" eingesehen werden. Viele Prozesse existieren nur dann wenn eine entsprechende Konfigurtion durchgeführt wird. Andere existieren nur dann wenn ein bestimmte FortiGate Modell benutzt wird wie zB PoE (Power over Ethernet). Wiederum Andere existieren und sind mit dem Stauts "idle" versehen da die Funktion deaktiviert wurde wie zB Wirless Controller "cw_acd". Nachfolgend eine Auflistung der bekannten Prozess und einer Kurzbeschreibung dieser. Dabei ist zu beachten das diese Liste nicht eine FortiOS 5.4 basierende Liste ist sondern einfach alle bekannte Prozesse für ein FortiOS auflistet:

        • pptpd                         Deamon für pptp Server
        • pptpcd                        Deamon für pptp Client
        • l2tpd                         Deamon für l2tp Server
        • l2tpcd                        Deamon für l2tp Client
        • ipldbd                        Deamon für ipldbd
        • vsd                           Virtual Server Deamon
        • acd                           Aggregation Controller Deamon
        • src-vis                       Source Visibility Deamon
        • pppoed                        Deamon für pppoe
        • ddnscd                        DDNS Client Deamon
        • urlfilter                     URL Filter Deamon
        • ntpd                          Zeitserver NTP Deamon
        • sshd                          SSH Server Deamon
        • tftpd                         TFTP Deamon
        • telnetd                       Telnet Deamon
        • authd                         Authentication Deamon
        • fssod                         Fortinet Single Sign-On (FSSO) Deamon
        • quard                         Quarantine Deamon
        • rtmon                         Realtime Monitor Deamon (Ping Server Deamon)
        • radvd                         Router Advertise (adv) Deamon
        • alertemail                    Alertmail Deamon
        • dnsproxy                      DNS Proxy Deamon
        • sflowd                        Deamon für sflow Protokoll
        • nat64d                        NAT64 Deamon
        • radiusd                       Radius Deamon
        • notifd                        Notification Deamon (Nur Carrier Version)
        • gtpgkd                        Deamon für gtp (Nur Carrier Version)
        • mass_mmsd                     Mass MMS Deamon (Nur Carrier Version)
        • alarmd                        Alarm Deamon
        • wpad_client                   Port Access Client Deamon (Atheros WiFi)         
        • wpad                          Port Access Entitiy Demon (Prism54 wifi)
        • eap_proxy                     Extended Protocol Authentication (epa) Proxy Deamon
        • modemd                        Modem Deamon
        • dialinsvr                     Dial-In Server Deamon
        • cardmgr                       PCMCIA Card Manager Deamon
        • getty aux                     Daemon für agetty AUX
        • pppoatmd                      PPP over ATM Deamon
        • adsl_mon                      ADSL Monitor Deamon
        • httpclid                      HTTP Client Deamon
        • sessionsync                   Session sync Deamon
        • fgfmd                         FortiGate to FortiManager Komunikations Deamon         
        • wccpd                         WCCP Protokoll Deamon
        • garpd                         VIP Gratuitous ARP Deamon
        • cw_acd                        CAPWAP Wireless Controller Access Deamon
        • wpad_ac                       WPA Access Deamon
        • cw_wtpd                       CAPWAP WTP Deamon
        • cw_stad                       CAPWAP sta Deamon
        • fortilinkd                    fortilink Deamon
        • cu_acd                        Deamon für cputp Access Deamon
        • swctrl_authd                  Deamon für hostswd Authentication Deamon
        • vrrpd                         VRRP Deamon
        • usbmuxd                       USBmux Deamon

        • initXXXXXXXXXXX               Ueberwacht und startet andere Prozesse
        • zebos_launcher                Zebos Launcher Deamon
        • hp_api                        HP API Deamon
        • cmdbsvr                       Update Prozess Deamon, AutoConfig Deamon
        • uploadd                       Upload Demaon 
        • adsl2plus                     ADSL2Plus Deamon
        • sqldb                         SQL Datenbank Deamon
        • reportd                       Reporting Deamon
        • sql_logd                      SQL Log Deamon 
        • miglogd                       Logging Deamon
        • chlbd                         Chassis Loadbalancing Deamonchassis loadbalance daemon)
        • haocd                         Chassis Cluster HA Deamon
        • chassis5000d                  Chassis 5000 Daemon
        • chassisd [IPv4 Adresse]       Chassis Deamon
        • kmiglogd                      Kernel Log Deamon
        • httpsd                        HTTPS Deamon
        • pyfcgid                       Python Konfig Deamon
        • sslvpnd                       SSL VPN Deamon
        • info_sslvpnd                  SSL VPN Info Deamon
        • smbcd                         SMB (Samba) Client Deamon
        • lcdapp                        LCD Panel Control Deamon
        • proxyd                        Proxy Deamon
        • imd                           Instante Messaging (IM) Proxy Deamon
        • wad_launcher                  WAN Acceleration Proxy Deamon
        • wad                           WAN Acceleration Explizit Proxy Deamon (MAPI RPC)
        • wad_diskd                     WAN Acceleration Disk Deamon
        • dlpfingerprint                DLP Fingerprinting Deamon
        • dlpfpcache                    DLP Fingerprinting Cache Deamon
        • scanunitd                     Scanunit Deamon
        • getty                         Console/Telnet Verbindungen
        • mingetty tty1                 Terminal mingetty tty1 Deamon
        • mingetty tty2                 Terminal mingetty tty2 Deamon
        • iked                          VPN IPSec IKE Deamon
        • ipsmonitor                    IPS Monitor Deamon
        • updated                       Update Deamon
        • merged_daemons                Merge Deamon        
        • fclicense                     FortiClient License Deamon
        • amc_monitor                   AMC Monitor Deamon
        • forticron                     CRL Update Deamon
        • bypass_monitor                Bypass Monitor Deamon
        • fdsmgmtd                      FortiGuard Management Deamon
        • fds_msg                       FortiGuard Message Deamon
        • snmpd                         SNMP Deamon
        • dhcpd                         DHCP Server Deamon
        • dhcpcd                        DHCP Client Deamon
        • dhcprd                        DHCP Relay Deamon
        • hatalk                        High Availibility (HA) Protokoll Modul
        • haysnc                        High Availibility (HA) Synchronisierungs Modul
        • harelay                       High Availibility (HA) Relay Modul für TCP

        • fsd                           Forti-Start Deamon
        • proxyacceptor                 Proxy Acceptor Deamon
        • proxyworker                   Proxy Worker Deamon
        • sslacceptor                   SSL Acceptor Deamon
        • sslworker                     SSL Worker Deamon
        • imd                           IM Deamons
        • fcnacd                        FortiClient NAC (Network Access Control) Deamon
        • stpd_name                     Spanning Tree Protokoll Deamon
        • wiredapd                      Wired AP 802.1x Port basierender Authentication Deamon
        • confsynchbd                   Deamon conf-sync für Heartbeat
        • confsyncd                     Deamon conf-sync 
        • poed                          Power over Ethernet Deamon
        • cbp                           CBP Deamon
        • nsm                           Routing FIB Update
        • imi                           Routing Abhängiger Deamon
        • bgpd                          BGP Deamon
        • ospfd                         OSPF Deamon
        • ospf6d                        OSPF Version 3 Deamon
        • pim6d                         PIM Multicast IPv6 Deamon
        • pimd                          PIM Multicast Deamon
        • pdmd                          PIM Dense Mode Deamon
        • ripd                          RIP Deamon
        • ripngd                        RIP IPv6 Deamon
        • netscan                       Netscan Deamon
        • dhcp6s                        DHCP Server IPv6 Deamon
        • dhcp6r                        DHCP Relay IPv6 Deamon
        • dhcp6c                        DHCP Client IPv6 Deamon
        • lted                          USB LTE Deamon
        • newcli                        Deamon für die Ausführung von CLI Kommandos (SSH, Telnet)
        • vpd                           VPN Policy Deamon (Ueberprüft welcher Traffic zu welcher Policy gehört)
        • rlogd                         Syslog Deamon

== System ==
=== Wie kann ich für einen FortiGate Device unter FortiOS 5.4 ein "factoryreset" ausführen und was ist dabei zu beachten? ===

Ein FortiGate Device kann über den "Hardware Reset" Button sowie über die FortiOS CLI in den "factoryreset" Zustand versetzt werden. Bei grösseren FortiGate Devices steht der "Hardware Reset" Button nicht zur Verfügung und ein "factoryreset" muss für diese FortiGate Devices über die CLI durchgeführt werden. Kleinere Devices wie zB FortiGate-60D verfügen über einen "Hardware Reset" Button wie die nachfolgende Abbildung zeigt:

        [[Datei:Fortinet-10.jpg]]

Dabei ist zu berücksichtigen, dass es auf der CLI zwei "factoryreset" zur Verfügung stehen dh.:

        factoryreset          Die gesamte Konfiguration des FortiOS wird in den Auslieferzustand zurück gesetzt!
        factoryreset2         Die gesamte Konfiguration des FortiOS wird in den Auslieferzustand zurück gesetzt exkl. Interface Konfiguration, VDOM Konfiguration, System Settings swowie Statische Routen!

Ueber den "Hardware Reset" Button kann nur ein "factoryreset" durchgeführt werden. Dieser wird folgendermassen durchgeführt:

        Drücke den "Hardware Reset" Button und auf der Mgmt. Console erscheint folgendes:
           
        Reset button has been disabled, please press the button during the first 30 seconds when the box is back to normal after a power-cycle.
           
        Diese Meldung indiziert, dass ein Neustart des Devices ausgeführt werden muss um ein "factoryreset" auszuführen. Dies bedeutet: Sobald
        ein Neustart des Devices ausgeführt wird dh. regulär anhand "execute reboot" oder "power-off" muss der "Hardware Reset" Button nach 
        erscheinen des "Login" erneut innerhalb von 30 Sekunden gedrückt werden! Danach wird ein "factoryreset" durchgeführt und abermals ein
        Neustart ausgeführt! Es erscheint folgende Meldung auf der Mgmt. Console:
        
        System is resetting to factory default......
        
        Eine direkte Ausführung eines "factoryreset" ohne Neustart des FortiGate Devices ist aus Sicherheitsgründen nicht möglich! 

Möchte man diesen "Hardware Reset" Button deaktivieren dh. dass dieser Vorgang über den "Hardware Reset" Button nicht mehr möglich ist kann über folgende Kommando in der CLI erreicht werden:

        # config system global
        # set admin-reset-button [enable | disable]
        # end

Wird der "Hardware Reset" Button über "system global" deaktiviert und der "Hardware Reset" Button wird dennoch benutzt erscheint auf der Mgmt. Console folgendes:

        Reset button has been disabled, please use 'config system global' to enable the reset button.

Ein "factoryreset" kann auch über Mgmt. Web Interface durchgeführt werden. Dazu wähle folgendes:

        Dashboard > System Information > System Configuration > Revisions > Restore Factory Defaults

        [[Datei:Fortinet-1658.jpg]]

        [[Datei:Fortinet-1659.jpg]]

Wie schon erwähnt kann ein FortiGate Device auch über CLI in den "factoryreset" Zustand versetzt werden. Dabei liegt der Vorteil darin das auch ein "factoryrest2" ausgeführt werden kann:

        # execute [factoryreset | factoryreset2]

Wenn ein "factoryreset" durchgeführt wird sei es über Mgmt. Web Interface und/oder CLI gelten folgende Default Werte:

        Web Mgmt. Interface IP 192.168.1.99/24 (internal und/oder lan)

        [[Datei:Fortinet-23.jpg]]

Dabei ist jedoch zu berücksichtigen das diese Werte betreffend Interface von Modell zu Modell sich unterscheiden können. Ein Beispiel wäre eine FortiGate-100D dh. die Default IP 192.168.1.99 für den Mgmt. Web Interface Zugriff ist auf dem "MGM" Interface konfiguriert. Wenn dies eruiert werden soll kann folgender Befehl über Mgmt. Console benützt werden:

        # show system interface

Für den Zugriff selber auf die IP 192.168.1.99 ist der Befehl "allowaccess" zuständig dh. um auf der Default IP den Zugriff zu erweitern/modifizieren kann folgendes ausgeführt werden:

        # config system interface
        # edit [Name des Interfaces zB "internal"]
        # set allowaccess [ping | https | ssh | snmp | http | telnet | fgfm | radius-acct | probe-response | capwap]
        # end

Per Standard ist auf der Default IP 192.168.1.99 folgendes gesetzt:

        ping https ssh http fgfm capwap

Dabei ist zu berücksichtigen das unter "system global" der "redirect" von "http" auf "https" per Default gesetzt ist:

        # config system global
        # set admin-https-redirect [enable | disable]
        # end

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device eine komplette Uebersicht erhalten über den Systemstatus? ===

Für jeden FortiGate Device existiert ein Kommando das einen "TAC Repport" generiert dh. dieses einzelne Kommando führt verschiedenen Script's aus. Wenn das Kommando ausgeführt wird dauert es einige Minuten bis alle Scripts ausgeführt wurden. Die enthaltenen Informationen sind Vielschichtig und Detailliert und umfassen sämtliche Informationen des Systems inkl. Auslastung, FortiGuard Informationen, UMT Feature Informationen usw. Bevor das Kommando ausgeführt wird muss umbedingt darauf geachtet werden, dass der Session "output" zB über "putty" als "Lokales Log" angelegt wird. Um den Bericht auszulösen führe folgendes aus:

       1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
       2. Erstelle eine Consolen Verbindung oder eine SSH Verbindung zur FortiGate
       3. Führe ein Login durch und gebe folgendes ein:

        # execute tac report

Nachfolgend ein Beispiel-output einer FG-60D (Test System):

        '''FortiOS 5.4'''
        [[Datei:tac-report-54.txt]]

Es ist "Sinnvoll" diesen Report bei der Ticket Eröffnung seitens Fortinet beizulegen da sehr viele relevante System Informationen aus diesem Report durch den TAC Mitarbeiter ausgelesen werden können!

=== Wie kann ich den Systemstatus unter FortiOS 5.4 für einen FortiGate Device anzeigen lassen? ===

Mit dem folgendem Befehl kann in der CLI der Systemstatus angezeigt werden:

        # get system status
        Version: FortiGate-60D v5.4.0,build1011,151221 (GA)
        Virus-DB: 16.00560(2012-10-19 08:31)
        Extended DB: 1.00000(2012-10-17 15:46)
        IPS-DB: 6.00741(2015-12-01 02:30)
        IPS-ETDB: 0.00000(2001-01-01 00:00)
        Serial-Number: FGT60D4613048017
        IPS Malicious URL Database: 1.00001(2015-01-01 01:01) 
        Botnet DB: 1.00000(2012-05-28 22:51) 
        BIOS version: 04000024 
        System Part-Number: P14482-03 
        Log hard disk: Not available
        Hostname: FGT60-customer
        Operation Mode: NAT
        Current virtual domain: root
        Max number of virtual domains: 10
        Virtual domains status: 1 in NAT mode, 0 in TP mode 
        Virtual domain configuration: disable 
        FIPS-CC mode: disable 
        Current HA mode: standalone 
        Branch point: 1011 
        Release Version Information: GA 
        System time: Wed Dec 30 05:56:44 2015

Um spezifische Komponenten oder Informationen aus dem "output" anzeigen zu lassen, kann der "grep" Befehl verwendet werden:

        # get system status | grep [Suchbegriff zB Hostname]
        Hostname: FGT60D-customer

Weiterführende Informationen zum "grep" Befehl gibt es im folgenden Artikel:

             [[FortiGate-5.4:FAQ#Kann_ich_unter_FortiOS_5.4_Linux.2FUnix_basierenden_Befehl_.22grep.22_auf_der_Kommandozeile_ben.C3.BCtzen.3F]]

=== Wie kann ich die durchschnittliche Auslastung der System Resourcen unter FortiOS 5.4 für einen FortiGate Device anzeigen lassen? ===

Mit dem nachfolgendem Befehl kann der Systemstatus Angezeigt werden. Es werden die durchschnittlichen Werte der Auslastung angezeigt:

        # get system performance status
        CPU states: 0% user 0% system 0% nice 100% idle
        CPU0 states: 0% user 0% system 0% nice 100% idle 
        Memory states: 14% used 
        Average network usage: 0 kbps in 1 minute, 0 kbps in 10 minutes, 0 kbps in 30 minutes 
        Average sessions: 0 sessions in 1 minute, 0 sessions in 10 minutes, 0 sessions in 30 minutes 
        Average session setup rate: 0 sessions per second in last 1 minute, 0 sessions per second in last 10 minutes, 0 sessions per second in last 30 minutes 
        Virus caught: 0 total in 1 minute 
        IPS attacks blocked: 0 total in 1 minute
        Uptime: 7 days,  0 hours,  50 minutes

Es wird eine Übersicht über die Memory und CPU und Netzwerk Auslastung angezeigt. Die Positionen "session"  zeigt der Durchschnitt der erstellten Sessions. Eine Durchschnittliche Übersicht über IPS Attacken und Antivirus aktionen wird ebenfalls angezeigt. Zusätzlich bietet dieser Befehl anhand "statistic" die einzelnen Packete aufzulisten in verschiedenen Kategorieren wie Browsing, DNS, E-Mail usw.:

        # get system performance firewall statistics 
        getting traffic statistics...
        Browsing: 5274 packets, 5427882 bytes
        DNS: 2794370 packets, 186719827 bytes
        E-Mail: 0 packets, 0 bytes
        FTP: 0 packets, 0 bytes
        Gaming: 0 packets, 0 bytes
        IM: 0 packets, 0 bytes
        Newsgroups: 0 packets, 0 bytes
        P2P: 0 packets, 0 bytes
        Streaming: 0 packets, 0 bytes
        TFTP: 0 packets, 0 bytes
        VoIP: 0 packets, 0 bytes
        Generic TCP: 469961 packets, 59577991 bytes
        Generic UDP: 1159442 packets, 277885944 bytes
        Generic ICMP: 0 packets, 0 bytes
        Generic IP: 953916 packets, 100714754 bytes

Diese "packets" werden wiederum in verschienen Grössen verarbeitet dh. MTU Size. Anhand der Option "packet-distribution" kann die Packet Grösse aufgelistet werden was wiederum Hinweise liefert ob sehr viele "kleine" Packete verarbeitet werden:

        # get system performance firewall packet-distribution 
        getting packet distribution statistics...
        0 bytes - 63 bytes: 693856 packets
        64 bytes - 127 bytes: 2545743 packets
        128 bytes - 255 bytes: 268296 packets
        256 bytes - 383 bytes: 39045 packets
        384 bytes - 511 bytes: 2530 packets
        512 bytes - 767 bytes: 20023 packets
        768 bytes - 1023 bytes: 6460 packets
        1024 bytes - 1279 bytes: 12164 packets
        1280 bytes - 1500 bytes: 12383 packets
         > 1500 bytes: 0 packets

Eine weitere Möglichkeit noch detailliertere Informationen aufzulisten betreffend Resourcen usw. ist der "TAC Report". Wie dieser zu erstellen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_eine_komplette_Uebersicht_erhalten_.C3.BCber_den_Systemstatus.3F]]

=== Was ist betreffend Memory im Zusammenhang mit 32/64bit auf einem FortiGate Device unter FortiOS 5.4 zu berücksichtigen? ===

Um die Benutzung des Memory auf einer FortiGate zu verstehen muss dessen Architektur verstanden werden. Nachfolgend die Abbildung der Architektur einer FortiGate in Kurzübersicht:

        [[Datei:Fortinet-1414.jpg]]

Das Kernstück resp. das Herzstück eines FortiGate Devices ist dessen Kernel. In diesem werden die wichtigsten sowie basis Entscheidungen getroffen für zB Routing, Offloading von Sessions zum NPU usw. Als Basis einer FortiGate Architektur steht die Hardware. Der Device Treiber verbindet den Kernel mit der Hardware. Alles was sich oberhalb des Kernels befindet ist der sogenannte "User space". Verschiedene Applikationen sowie Deamons benützen diesen Bereich. Wenn eine FortiGate Memory benötigt führt sie dies aus 5 veschiedenen Gründen durch:

        Kernel memory/slabs
        System I/O cache
        Buffers
        Shared memory
        Process memory

Alles Oberhalb des "User space" steht einem Administrator zur Verfügung um die Konfiguration durchzuführen dh. über Mgmt. Web Interface oder zB CLI. Im Memory Bereich muss Grundsätzlich zwischen 32bit sowie 64bit unterschieden werden:

        '''<big>32bit mit mehr als 1 GB Memory:</big>'''
        
        [[Datei:Fortinet-1415.jpg]]
        
        Bei einem FortiGate Modell basierend auf 32bit und mit mehr als 1 GB Memory, kann der Kernel nicht direkt
        auf das Memory zugreifen. Der einzige Bereich auf den der Kernel direkten Zugriff hat ist das sogenannte
        "low memory". Der Bereich der für das "paging" benutzt wird ist das "high memory". Durch den nachfolgenden
        Befehl wird folgendes ausgegeben:
        
        # diagnose hardware sysinfo memory
        Total low memory (LowTotal)
        Free low memory (LowFree)
        Total high memory (HighTotal)
        Free high memory (HighFree)
        Total system memory (MemTotal = LowTotal + HighTotal)
        Total free memory (MemFree = LowFree + HighFree)

        '''<big>64bit oder weniger 1 GB Memory:</big>'''
        
        [[Datei:Fortinet-1416.jpg]]
        
        Für FortiGate Modelle basierend auf 64bit oder für FortiGate Modell mit weniger als 1 GB Memory ist es
        dem Kernel möglich auf das Ganze Memory zu zugreifen und es muss daher kein "paging" durchgeführt werden.
        Um dies für ein Modell zu überprüfen kann folgender Befehl abgesetzt werden:
        
        # diagnose hardware sysinfo memory 
        total:    used:    free:  shared: buffers:  cached: shm:
        Mem:  1928380416 502669312 1425711104        0 68321280 176857088 167788544
        Swap:        0        0        0
        MemTotal:      1883184 kB
        MemFree:       1392296 kB
        MemShared:           0 kB
        Buffers:         66720 kB
        Cached:         172712 kB
        SwapCached:          0 kB
        Active:         123776 kB
        Inactive:       115784 kB
        '''HighTotal:           0 kB'''
        '''HighFree:            0 kB'''
        LowTotal:      1883184 kB
        LowFree:       1392296 kB
        SwapTotal:           0 kB
        SwapFree:            0 kB
        
        Für die Positionen "HighTotal" sowie "HighFree" zeigen diese Modell "0 kB". Somit wird für diese Modelle
        der gesamte Memory Bereich als "LowMemory" definiert!

Weitere Befehle stehen zur Verfügung um die Memory Benutzung detailliert aufzulisten. Dazu siehe folgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_die_Memory_Benutzung_eines_FortiGate_Devices_anzeigen_lassen.3F]]

=== Wie kann ich unter FortiOS 5.4 die Memory Benutzung eines FortiGate Devices anzeigen lassen? ===

Wenn die Memory Benutzung eines FortiGate Devices durch nachfolgende Befehle aufgelistet wird müssen diese Werte korrekt intepretiert werden. Nachfolgender Artikel gibt Auskunft wie ein FortiGate Device das Memory benutzt:

        [[FortiGate-5.4:FAQ#Was_ist_betreffend_Memory_im_Zusammenhang_mit_32.2F64bit_auf_einem_FortiGate_Device_unter_FortiOS_5.4_zu_ber.C3.BCcksichtigen.3F]]

Um die "Memory" Benutzung anzeigen zu lassen kann folgender Befehl abgesetzt werden:

        # diagnose hardware sysinfo memory
        total:    used:    free:  shared: buffers:  cached: shm:
        Mem:  464683008 190701568 273981440        0 17981440 89571328 81862656
        Swap:        0        0        0
        MemTotal:       453792 kB
        MemFree:        267560 kB
        MemShared:           0 kB
        Buffers:         17560 kB
        '''Cached:          87472 kB'''
        SwapCached:          0 kB
        '''Active:          39528 kB'''
        '''Inactive:        65624 kB'''
        HighTotal:           0 kB
        HighFree:            0 kB
        LowTotal:       453792 kB
        LowFree:        267560 kB
        SwapTotal:           0 kB
        SwapFree:            0 kB
        
        Die Markierten stellen zeigen den "buffer" sowie "cache" der benötigt wird durch den "I/O Cache". Die gleichen Informationen
        werden mit dem folgenden Befehl angezeigt:
        
        # get hardware memory

Der nachfolgende Befehl zeigt das "shared" Memory:

        # diagnose hardware sysinfo shm
        '''SHM counter:          139'''
        '''SHM allocated:    3317760'''
        '''SHM total:      191135744'''
        conservemode:           0
        shm last entered:     n/a
        system last entered:  n/a
        SHM FS total:   198844416
        SHM FS free:    195190784
        SHM FS avail:   195190784
        SHM FS alloc:     3653632
        
        Das Shared Memory erlaubt Informationen über mehrere Prozesse zu teilen. Auf einer FortiGate laufen verschiedene Prozesse/Deamons. 
        Das FortiOS alloziert seperate Memory Blocks für jeden Prozess. Ein Prozess greift auf diese allozierten seperaten Memory Blocks zu. 
        Der Prozess kann jedoch nicht auf einen anderen seperaten Memory Block zugreifen der für einen anderen Prozess alloziert wurde. Somit 
        kann ein Prozess seine Informationen nicht mit einem anderen Prozess teilen. Für diesen Umstand kann das FortiOS dynamisch "shared" 
        Memory allozieren um den Prozessen den Austausch von Informationen zu ermöglichen. Dieses "shared" Memory kann somit durch mehrer 
        Prozesse geteilt werden und wird über das FortiOS gesteuert.

Der nachfolgende Befehl zeigt die Details des "low" Memory Bereichs:

        # diagnose hardware sysinfo slab
        slabinfo - version: 1.1
        kmem_cache            72    140    112    2    2    1 0
        tcp6_session           0      0    928    0    0    1 0
        ip6_session            0      0    864    0    0    1 0
        sctp_session           0      0    864    0    0    1 0
        tcp_session            7     18    864    1    2    1 1
        ip_session             6     60    800    2    6    1 4
        ip6_mrt_cache          0      0    352    0    0    1 0
        fib6_nodes            15    226     32    1    1    1 0
        ip6_dst_cache         49     70    224    2    2    1 0
        ndisc_cache            3     61    128    1    1    1 0
        ip_mrt_cache           0      0    320    0    0    1 0
        tcp_tw_bucket          0     49    160    0    1    1 1
        tcp_bind_bucket       47    226     32    1    1    1 0
        tcp_open_request       0     61    128    0    1    1 1
        inet_peer_cache        4    120     64    1    1    1 0
        ip_dst_cache          13     41    192    1    1    1 0
        ip_fib_hash           34    226     32    1    1    1 0
        arp_cache              5     61    128    1    1    1 0
        vf                     4      7   2208    1    1    2 0
        vf_entry              21    290     24    1    1    1 0
        if_event_cache         0    120     64    0    1    1 1
        blkdev_requests     2048   3078     96   26   38    1 12
        journal_head           5    156     48    1    1    1 0
        revoke_table           2    509     12    1    1    1 0
        revoke_record          0    226     32    0    1    1 1
        eventpoll pwq        347    406     36    2    2    1 0
        eventpoll epi        341    405     96    5    5    1 0
        dnotify_cache          0      0     20    0    0    1 0
        file_lock_cache        2     88     88    1    1    1 0
        fasync_cache           0      0     16    0    0    1 0
        uid_cache              0      0     32    0    0    1 0
        pkt_buf_head_cache    395    480    480   29   30    1 1
        sock                 402    432    928   51   54    1 3
        sigqueue               0     59    132    0    1    1 1
        kiobuf                 0      0     64    0    0    1 0
        cdev_cache           638    720     64    6    6    1 0
        bdev_cache             3    120     64    1    1    1 0
        mnt_cache             18    120     64    1    1    1 0
        inode_cache         5650   5688    448  315  316    1 1
        dentry_cache        5567   5673    128   92   93    1 1
        filp                3570   3599    128   59   59    1 0
        names_cache            0      4   4096    0    2    1 2
        buffer_head        25224  25272     96  312  312    1 0
        mm_struct             70    122    128    2    2    1 0
        vm_area_struct     12212  13320     64  108  111    1 3
        fs_cache              69    226     32    1    1    1 0
        files_cache           70     95    416    4    5    1 1
        signal_act            78     90   1312   14   15    1 1
        pte-cache           3307   3772   2048  836  943    1 107
        size-131072(DMA)       0      0 131072    0    0   16 0
        size-131072            5      5 131072    5    5   16 0
        size-65536(DMA)        0      0  65536    0    0    8 0
        size-65536             4      6  65536    4    6    8 2
        size-32768(DMA)        0      0  32768    0    0    4 0
        size-32768             2      3  32768    2    3    4 1
        size-16384(DMA)        0      0  16384    0    0    2 0
        size-16384            12     15  16384   12   15    2 3
        size-8192(DMA)         0      0   8192    0    0    1 0
        size-8192              7      8   8192    7    8    1 1
        size-4096(DMA)         0      0   4096    0    0    1 0
        size-4096            378    426   4096  192  213    1 21
        size-2048(DMA)         0      0   2048    0    0    1 0
        size-2048            227    320   2048   57   80    1 23
        size-1024(DMA)         0      0   1024    0    0    1 0
        size-1024            284    304   1024   38   38    1 0
        size-512(DMA)          0      0    512    0    0    1 0
        size-512             304    345    512   22   23    1 1
        size-256(DMA)          0      0    256    0    0    1 0
        size-256              43    186    256    2    6    1 4
        size-128(DMA)          0      0    128    0    0    1 0
        size-128            5071   5124    128   84   84    1 0
        size-64(DMA)           0      0     64    0    0    1 0
        size-64            14835  28200     64  129  235    1 106
        
        Dieser "low" Memory Bereich wird von einem FortiGate Device für verschiedenen Funktionen genützt wie für die allgemeine Aufgaben 
        sowie festen Memory Bereich. Beispiele sind zB:
        
        Slab             Size (Bytes)      Benützt durch
        tcp_session      768               TCP Session
        ip_session       640               None TCP Session
        ip_dst_cache     256               Route cache
        buffer_head      128               Read/write data from disk, flash
        inode_cache      512               Information about files and directories
        dentry_cache     128               Cache for file system directory entries
        apr_cache        128               Cache for ARP

Nachfolgendes Dokument wurde durch Fortinet Released um zu zeigen was/wie Analysiert werden kann betreffend Memory und wie dies zu intepretieren ist speziell wenn die Memory Auslastung hoch ist:

        [[Datei:Memory-Usage-Insights-In-FortiOS-5.pdf]]

=== Was sind die Unterschiede zwischen den verschiedenen "Conserve Mode" unter FortiOS 5.4 und was bedeuten diese? ===

Unter FortiOS 5.4 kann das System in einen sogenannten "Conserve Mode" wechseln. Dies bedeutet: Der "Conserve Mode" sei es der "Regular" und/oder "Kernel" Conserve Mode ist ein Selbstschutz der FortiGate. Ist eine FortiGate kurz vor dem "Conserve Mode" ist diese "short of memory" dh. es steht für die weitere Verarbeitung/Betrieb kein Memory mehr zur Verfügung. Um dies zu verhindern geht der FortiGate Device kurz in den "Conserve Mode" um Memory freizugeben, um weiteren Schaden zu verhindern. Aus diesem Grund ist grundsätzlich der "Conserve Mode" vorübergehender Natur kann jedoch auch permanenter Natur sein, speziell dann wenn ein vorübergehender "Conserve Mode" durch den Administrator unbemerkt bleibt oder ignoriert wird. Ein FortiOS 5.4 kenn folgende "Conserve Mode":

        Regular Conserve Mode
        Kernel Conserve Mode
        Proxy Conserve Mode

Beim "Regular und/oder Kernel" Conserve Mode handelt es sich bei beiden um ein "short of memory" Problem. Der Unterschied liegt darin "wie" diese Situation Zustande kommt dh. welche Limiten überschritten werden:

        '''<big>Regular Conserve Mode</big>'''
        
        Der "Regular" Conserve Mode wird dann ausgelöst wenn zuwenig vom "Gesamten" Memory zur Verfügung steht! Nachfolgende
        Tabelle zeigt auf wann dies der Fall ist:
        
        [[Datei:Fortinet-1080.jpg]]
        
        Die Ursache wieso ein FortiGate Device in den "Regular" Conserve Mode geht kann Prozess abhängig sein dh. ein FortiOS benötigen zuviel
        Prozesse (eher selten) oder hoher Auslastung (shm "shared memory"). Ein "shared memory" - wie der Name selber beschreibt - wird benützt
        für vers. Prozesse (shared). Dieses "shared memory" wird unter "diagnose sys top" nicht aufgelistet da es sich bei den Memory Informationen 
        unter diesem Befehl nicht um das "shared memory" handelt sondern um das Physische Memory. Um die "shared memory" Informationen anzuzeigen
        benutze folgenden Befehl:
        
        # diagnose hardware sysinfo shm
        
        Das "shared memory"  steht vorallem im Zusammenhang mit proxifizierten Prozessen (Antivirus Proxy, SSL Proxy usw.). Dies bedeutet: diese
        proxifizierten Prozesse benötigen "buffer" dh. Platz um Ihre Prozess abzuwickeln und genau diese "buffer" sind im "shared memory"! Diese
        "buffer's" werden auch für andere Prozesse benötigt wie zB "Logging, Quarantine usw". Wenn ein FortiGate Device in den "Regular" Conserve 
        Mode wechselt so erscheint folgender Log Eintrag im "Event" Log: 
        
        conserve=on total=<totalmemMB> free=<freememMB> entermargin=<LF> exitmargin=<HF> msg="The system has entered conserve mode"
        
        Wenn der FortiGate Device wieder aus dem "Regular" Conserve Mode wechselt erscheint folgender Log Eintrag im "Event" Log:
        
        conserve=exit total=<totalmemMB> free=<freememMB> entermargin=<LF> exitmargin=<HF> msg="The system exited conserve mode"

        '''<big>Kernel Conserve Mode</big>'''
        
        Im Gegensatz zum "Regular Conserve" Mode wird der "Kernel Conserve" Mode dann ausgelöst wenn die "LowMemory" Limite des "Regular Conserve" 
        Mode ebenfalls überschritten resp. unterschritten wird (siehe Tabelle oben unter Abschnitt "Regular Conserve" Mode). Die "LowMemory" Limite
        ist das Memory das durch den "Kernel" direkt Adressiert wird. Aus diesem Grund - wenn dieser "LowMemory" Bereich überschritten wird - kann
        der Kernel das Memory das dieser direkt Adressiert nicht mehr addressieren und geht deshalb in den "Kernel Conserve Mode". Die "LowMemory"
        Limite hängt vom spezifischen FortiGate Modell ab. Mit nachfolgenden Befehl kann das "LowMemory" angezeigt werden:
        
        # diagnose hardware sysinfo slab
        
        Die Kernel Data Strukturen auch "kernel buffer" genannt werden für die verschiedensten Aufgaben benötigt dh. 
        
        - Speichern der Firewall Session Elemente 
        - Network Address Translation (NAT) und in dessen Zusammenhang stehende "buffer"
        - Routen sowie dessen Route Cache 
        - Forwarding Database 
        - ARP Cache 
        - usw.
        
        Alles diese wichtigen Funktionen nutzen den "LowMemory" Bereich. Ebenfalls wird dieser Bereich "sehr" intensiv genutzt durch das IPS System,
        Application Control usw. Auch die Auslastung der Firewall mit vielen "sessions" kann ein "Kernel Conserve" Mode auslösen denn zB je mehr 
        "sessions" desto mehr "route cache". Dies gilt auch für die UTM Features dh. je mehr IPS, Application Controll, DLP etc. desto mehr 
        Adressierung im "kernel buffer". Neuere FortiGate Modelle können den gesamten Memory Speicherplatz Adressieren da diese Modelle über 
        eine 64bit Architektur verfügen. Was die Unterschiede betreffend Memory im Zusammenhang mit 32/64bit Architektur sind siehe nachfolgender 
        Artikel:
        
        [[FortiGate-5.4:FAQ#Was_ist_betreffend_Memory_im_Zusammenhang_mit_32.2F64bit_auf_einem_FortiGate_Device_unter_FortiOS_5.4_zu_ber.C3.BCcksichtigen.3F]]
        
        Ein "Kernel Conserve" Mode wird unter folgenden Umständen ausgelöst:
        
        • Der "kernel conserve mode" wird ausgelöst wenn "low memory" (LowFree) unter 20% vom Total des "low memory" (LowTotal) liegt.
        • Der "kernel conserve mode" wird aufgehoben wenn "low memory" (LowFree) über 30% vom Total des "low memory" (LowTotal) liegt.
        
        Sobald der "Kernel Conserve Mode" eintritt und/oder aufgehoben wird so erscheint im Event Log folgendes: 
        
        "The system has entered system conserve mode"
        "The system exited system conserve mode"
        
        In der Kommandozeile kann der "Kernel Conserve" Mode ebenfalls eruiert werden mit folgenden Befehl:
                
        # diagnose hardware sysinfo shm
        SHM counter:          721
        SHM allocated:   17256448
        SHM total:     1489289216
        '''conservemode:           0'''
        shm last entered:     n/a
        system last entered:  n/a
        SHM FS total:  1523073024
        SHM FS free:   1504075776
        SHM FS avail:  1504075776
        SHM FS alloc:    18997248
        
        Die Relevante Position ist "conservemode:" dh. steht diese Positon auf "0" ist der "Kernel Conserve" Mode nicht aktiv. Steht die Position 
        auf "1" ist der "Kernel Conserve" Mode aktiv. Im Mgmt. Web Interface innerhalb des Dashboards und im Widget "Alert Message Console" 
        erscheint eine andere Meldung dh:
        
        "FortiGate has reached system connection limit for x seconds"

        '''<big>Proxy Conserve Mode</big>'''
        
        Zusätzlich zum "Kernel/Regular Conserve" Mode gibt es den "Proxy Conserve" Mode. Wie schon erwähnt wird ein "Kernel Conserve" Mode dann 
        ausgelöst wenn nicht genügen "LowMemory" zur Verfügung steht resp. die Limiten dafür (20%) unterschritten wird. Der "Proxy Conserve" 
        Mode tritt dann ein wenn im Gesamten nicht mehr genügend Memory zur Verfügung steht. Dabei gelten folgenden Limiten:
        
        '''MemTotal'''        '''Enter Proxy Conserve Mode'''        '''Exit Proxy Conserve Mode'''
        <= 128 MB       MemFree <=  5 MB                 MemFree > 10 MB
        <= 256 MB       MemFree <= 10 MB                 MemFree > 20 MB
        <  512 MB       MemFree <= 40 MB                 MemFree > 60 MB
        <=   1 GB       MemFree <= 20%                   MemFree > 30%
        >    1 GB       MemFree <= 12%                   MemFree > 18%
        
        Wenn der "Proxy Conserve" Mode eintritt werden in den verschiedenen Logs folgendes angezeigt:
             
        Event logs:
        conserve=on total=<TotalMemoryMB> free=<FreeMemoryMB> entermargin=<margin> exitmargin<margin> msg="The system has entered conserve mode"
        conserve=exit total=<TotalMemoryMB> free=<FreeMemoryMB> entermargin=<margin> exitmargin<margin> msg="The system exited conserve mode"
             
        Crashlog (Ersichtlich über das Kommando "diagnose debug crashlog read"):
        conserve=entered total=<TotalMemoryMB> free=<FreeMemoryMB> entermargin=<margin> exitmargin<margin>
        conserve=exited total=<TotalMemoryMB> free=<FreeMemoryMB> entermargin=<margin> exitmargin<margin>
        
        Das Verhalten des "Proxy Conserve" Mode kann über folgendes Kommando konfiguriert werden:
        
        # config system global
        # set av-failopen [idledrop | off | one-shot | pass]
        # end
        
        Die einzelnen Optionen für "av-failopen" haben folgende Bedeutung:
        
        idledrop           Verwirft alle "idle" Proxy Sessions
        off                Alle neue Session für die UTM Scanning aktiviert ist werden geblockt
        one-shot           Für alle neuen Sessions wird ein UTM Scanning durchgführt
        pass (default)     Alle neuen Sessions werden erlaubt "ohne" Inspection
        
        Für "av-failopen" ist "pass" der Standard Wert und für die meisten Umgebungen akzeptabel. In einem High Security Umgebung resp. um in 
        allen Fällen zu verhindern das eine Malware etc. den internen Bereich erricht sollte die Option auf "off" gesetzt werden. Desweiteren
        im Zusammenhang mit dem "Proxy Conserve" Mode ist die folgende Optione ebenfalls zu berücksichtigen sofern ein "Explizit Proxy" 
        eingesetzt wird:
        
        # config system global
        # set av-failopen-session [enable | disable]
        # end

Wenn man herausfinden möchte ob ein FortiGate Device kurz vor einem "Conserve Mode" steht, muss das Memory analysiert werden. Durch nachfolgenden Befehl können alle relevanten Daten des Memory's, die für einen "Conserve Mode" heranzuziehen sind wie MemTotal, MemFree, Buffers (slab), LowTotal ,LowFree aufgelistet werden:
        
        # diagnose hardware sysinfo memory 
                total:    used:    free:  shared: buffers:  cached: shm:
        Mem:  1932722176 600489984 1332232192        0 135536640 235864064 151691264
        Swap:        0        0        0
        MemTotal:      1887424 kB
        MemFree:       1301008 kB
        MemShared:           0 kB
        Buffers:        132360 kB
        Cached:         230336 kB
        SwapCached:          0 kB
        Active:         242688 kB
        Inactive:       120144 kB
        HighTotal:           0 kB
        HighFree:            0 kB
        LowTotal:      1887424 kB
        LowFree:       1301008 kB
        SwapTotal:           0 kB
        SwapFree:            0 kB
        
In diesem Beispiel zeigt der Device für "LowFree" 1301008. Dies wierum entspricht 68.93% von "LowTotal" 1887424 (1301008 X 100 : 1887424) und es besteht also keine Gefahr für einen "Kernel Conserve" Mode. Da der Device in diesem Beispiel über 2 GB Memory verfügt (1932722176) und gemäss Tabelle gilt in diesem Fall 160 MB für den "Regular Conserve" Mode. Der Befehl zeigt auch als "MemFree" 1301008 was wiederum 1.3 GB entspricht. Somit keine Gefahr für den Device für einen "Regular Conserve" Mode! Die Frage stellt sich "Was bedeuten die Positionen Cached = Active + Inactive?" Das ist die Information die ein FortiGate Device für seine eigenen Stabilität "cached" (i/o buffering). Der "Inactive" Teil des Memory wird - sofern das System diesen benötigt - wieder freigegeben. Der folgende Befehl zeigt dieses Verhältniss auf sprich die Memory Auslastung ist inkl. "cached". Also ist in dieser Memory Auslastung der "Inactive" Teil ebenfalls enthalten der durch das System - sofern benötigt - freigegeben wird:

        # diagnose system top
        Run Time:  3 days, 20 hours and 34 minutes
        0U, 0S, 100I; 1843T, 1270F, 144KF
                 newcli      247      R       0.5     0.8
                   sshd      245      S       0.3     0.5
              ipsengine       69      S <     0.0     3.5
            proxyworker       56      S       0.0     1.2
                miglogd       42      S       0.0     1.2
                pyfcgid      227      S       0.0     1.2
                pyfcgid      230      S       0.0     1.1
                cmdbsvr       36      S       0.0     1.1
                 httpsd      210      S       0.0     1.0
                 httpsd      115      S       0.0     1.0
                sslvpnd       78      S       0.0     0.9
                 httpsd       44      S       0.0     0.8
                 httpsd      114      S       0.0     0.8
                 newcli      246      S       0.0     0.7
                  fgfmd      102      S       0.0     0.7
                 cw_acd      103      S       0.0     0.7
                    wad       83      S       0.0     0.7
              scanunitd      109      S <     0.0     0.6

Somit wird hier die Memory Auslastung in Prozenten des gesamten Memory aufgelistet inkl. "cached". Der Bereich des "shm" (Shared Memory) wird in dieser Auflistung nicht gezeigt. Im oben gezeigten Beispiel benützt zB die "ipsengine" 3.5% des gesamten Speichers. Eine weitere Möglichkeit für "system top" wäre folgender Befehl:
        
        # diagnose sys top-summary 
        CPU [||||||||||||||                          ]  35.5%
        Mem [|||||||||||                             ]  29.0%   539M/1839M
        Processes: 20 (running=6 sleeping=84)
        
          PID      RSS  ^CPU% MEM%   FDS     TIME+  NAME
        * 28433    18M   35.5  1.0    10  00:04.95  newcli [x2]
          36       20M    0.0  1.1    11  00:47.30  cmdbsvr
                    39       11M    0.0  0.6    87  00:01.33  zebos_launcher [x12]
                    51        9M    0.0  0.5    11  00:32.22  uploadd
                    52       22M    0.0  1.2    57  00:22.81  miglogd
                    53        9M    0.0  0.5     6  00:00.00  kmiglogd
                    54       25M    0.0  1.4    19  03:03.25  httpsd [x4]
                    57       23M    0.0  1.3   814  00:04.45  proxyd [x6]
                    58       10M    0.0  0.6     8  00:00.28  wad_diskd
                    59       12M    0.0  0.7    16  00:01.28  scanunitd [x3]
                    61       57M    0.0  3.1    18  00:08.57  ipsmonitor [x2]
                    9233     14M    0.0  0.8    26  00:00.89  iked
                    65        9M    0.0  0.5     8  00:00.60  merged_daemons
                    66        9M    0.0  0.5     8  00:00.20  fnbamd
                    67        9M    0.0  0.5     9  00:00.12  fclicense
                    71       10M    0.0  0.6    18  00:00.31  forticron
                    72        9M    0.0  0.5    11  00:00.12  forticldd
                    73       11M    0.0  0.6    18  00:00.18  urlfilter
                    74       12M    0.0  0.7    35  00:04.31  authd
                    75       10M    0.0  0.6    14  00:00.47  fcnacd

Zum diesem Befehl stehen einige Optionen zur Verfügung anhand derer die Liste sortiert werden kann:

        # diagnose sys top-summary -h
        Usage: top.py [options]
               
        Options:
             -n LINES, --num=LINES
                                   Number of top processes to show (20 by default)
             -i INTERVAL, --interval=INTERVAL
                                   Update interval, in seconds (1 by default)
             -s SORT, --sort=SORT  Sort mode: [cpu_percent (default)|mem|fds|pid]
             -d, --dump            Dump stats to the files
             -h, --help            show this help message and exit

Nachfolgend ein Beispiel anhand "-s m" um die Prozess nach Memory Benützung zu sortieren sowie alle 60 Sekunden anhand "-i 60" ein Refresh durchzuführen. Die Option "-n 10" Listet die Top 10 Prozesse auf:

         # diagnose sys top-summary '-s mem -i 60 -n 10'

Die Frage: "Was kann ich gegen einen drohenden "Conserve Mode" tun?" ist nicht generell zu beantworten dh. je nach Situation ist ist der Ansatz unterschiedlich. Generell ist der Fokus auf das "Memory" zu legen dh. Konfiguration durchzuführen die "Resourcen" schonender sind um möglichts wenig "Memory Resourcen" zu benützen. Nachfolgend einige Hinweise und Ansätze:
        
         • Reduziere die Anzahl Firewall Sessions (Session Tuning).
         • Reduziere die Grösse der Files betreffend Antivirus Scanning.
         • Deaktiviere alle nicht nötigen Features wie zB Logging, Archiving, DLP, IPS.
         • Entferne das "content summary" (Speziell wenn kein FortiAnalyzer benützt wird).
         • Reduziere das Caching für Explizit Proxy, FortiGuard Antispam sowie Webfiltering.

== Zertifikate ==

=== Was für Standard Zertifikate (Default CA) werden unter FortiOS 5.4 auf einer FortiGate benutzt? ===

Unter FortiOS 5.2 wie auch für FortiOS 5.4 wird ein Device spezifisches Zertifikat benutzt. Dies bedeutet: Sobald unter FortiOS 5.2 sowei 5.4 eine Konfiguration oder Funktion benutzt wird, für die ein Zertifikat Voraussetzung ist, wird dieses im Hintergrund anhand der Serien Nummer des Devices initialisiert. Zu diesen Device spezifischen Zertifikate resp. Standard Zertifikate gehören die Folgenden:

        • Fortinet_CA_SSL
        • Fortinet_SSL
        • PositiveSSL_CA
        • Fortinet_Wifi
        • Fortinet_Factory

Ob es sich bei den Zertifikaten um ein Device spezifisches Zertifikat handelt kann über das Mgmt. Web Interface kontrolliert werden da diese Zertifikate als CN (Common Name) die Serien Nummer des Devices zeigen. Dabei sind folgende Zertifikate relevant:

        • Fortinet_Factory
        • Fortinet_SSL
        • Fortinet_CA_SSL

        System > Certificates

        [[Datei:Fortinet-2038.jpg]]

Die Menüposition "Certificates" ist per Standard nicht aktiviert und muss aktiviert werden damit die Zertifikate eingesehen werden können. Weitere Informationen wie dieses Feature aktiviert wird siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

Unter FortiOS 5.4 wurde das Firmware spezifische Zertifikate "Fortinet_Firmware" das durch alle Fortinet Devices benutzt wurde entfernt und Funktionen die dieses Zertifikat "Fortinet_Firmware" benutzten, benutzen neu das Device spezifische Zertifikat "Fortinet_Factory", welches durch eine Konfiguration resp. Funktion Device spezifisch initiert wird. Das Ablaufdatum des Zertifikates "Fortinet_Factory" wurde erweitert auf das Jahr 2038. Neu benutzt im VDOM Mode jede VDOM Ihre eigenen Zertifikate dh. wird eine neue VDOM hinzugefügt werden oben aufgelistete "default" Zertifikate im Hintergrund automatisch für diese VDOM initiert und in die VDOM CA Liste zur Verfügung gestellt. Für diese VDOM Funktion stehen zwei Optionen für ein Zertifikat zur Verfügung:

        • range [global | vdom]
        • source [factory | user | fortiguard]

Wenn ein Zertifikat definiert wird mit der Option "range" so wird dieses als Global und/oder VDOM definiert basierend darauf ob es in Global und/oder VDOM importiert wurde! Die Option "source" definiert woher das Zertifikat stammt dh. anhand "factory" werden alle "default" Zertifikate eines FortiOS definiert! Wird ein Zertifikat anhand "source" als "user" definiert ist dieses User spezifisch! Zertifikate basierend auf den "Root Certificate Authorities" werden anhand der "source" mit "fortiguard" definiert da diese aus dem Service FortiGuard stammen. Somit kann eine Konfiguration auf der CLI folgendermassen durchgeführt werden:

        # config certificate local
        # config certificate local
        # edit [Name des entsprechenden Zertifikats]
        # set password [Passwort des Zertifikats]
        # set comments [Beschreibung des Zertifikats]
        # set private-key [Private Key des Zertifikats]
        # set certificate [Zertifikat]
        # set csr [Signing Request des Zertifikats]
        # set state [Signing Request State des Zertifikats]
        # set scep-url [URL des SCEP Server des Zertifikats]
        # set range [global | vdom]
        # set source [factory | user | fortiguard | bundle]
        # set auto-regenerate-days [Definition der Anzahl Tage für "auto-regenerate" bevor das Zertifikat abläuft; 0 = disable]
        # set auto-regenerate-days-warning [Definition der Anzahl Tage einer Warnung für "auto-regenerate" bevor das Zertifikat abläuft; 0 = disable]
        # set scep-password [SCEP Server Password für "autoregeneration"]
        # set ca-identifier [CA Identifier für den CA Server für Signing über SCEP]
        # set name-encoding [printable | utf8]
        # set source-ip [IPv4 Source Adresse für SCEP Komunikation]
        # set ike-localid [IKE Local ID
        # set ike-localid-type [asn1dn | fqdn]
        # end

Wenn ein Upgrade durchgführt wird auf FortiOS 5.4 wird somit das "Fortinet_Firmware" Zertifikat komplett entfernt. Zertifikate basierend auf den Standard Zertifikate die jedoch unter 5.0/5.2 benutzt wurde bleiben unverändert. Möchte man diese Standard Zertifikate neu initieren damit diese Device spezifisch initiert werden kann dies über CLI durchgeführt werden. Vor der neu Initierung der Zertifikate müssen jedoch die Abhängigkeiten zu den Funktionen, die auf einem FortiOS zB den Usern zur Verfügung gestellt werden und die daraus resultierenden Folgen, verifziert werden. Danach kann eine Neuinitierung über CLI durchgeführt werden:

        # execute vpn certificate local generate default-ssl-ca 
        # execute vpn certificate local generate default-ssl-ca-untrusted
        # execute vpn certificate local generate default-ssl-serv-key

Nach der Neuinitierung kann über Mgmt. Interface die nachfolgenden entsprechenden Zertifikate gewählt werden und das Datum unter "Valid From" kontroliert werden:

        • Fortinet_Factory
        • Fortinet_SSL
        • Fortinet_CA_SSL

=== Gibt es unter FortiOS 5.4 eine Liste für "Trusted Certificate Authorities" (Vertrauenswürdige Stammzertifizierungsstellen)? ===

Bis anhin dh. unter FortiOS 5.0/5.2 wurde ein Zertifikat in den verschiedenen Konfigurationen wie zB WebFiltering durch "Certificat Inspection" nur anhand folgender Komponenten überprüft:

        • Validity Period (Datum / Gültigkeit)
        • Common Name (CN)

Dies bedeutet: Bis anhin wurde ein Zertifikat durch das FortiOS nicht überprüft ob es von einem "Trusted Certificate Auhtority" stammt da auf einem FortiOS keine solche Liste bestand wie zB unter Windows im Zertifikats Manager (Vertrauenswürdige Stammzertifizierungsstellen). Neu stehen diese "Trusted Certificate Auhtority" unter FortiOS 5.4 zur Verfügung innerhalb des "SSL Inspection" Profiles:

        Security Profiles > SSL Inspection > [Wähle ein entsprechendes SSL Inspection Profile] > Edit > Untrusted SSL Certificates > View Trusted CAs List

        [[Datei:Fortinet-2041.jpg]]

        [[Datei:Fortinet-2042.jpg]]

Diese Liste wird anhand FortiCare Maintenance auf den neusten Stand gehalten. Dies bedeutet: Um die Funktion einwandfrei zu nutzen muss FortiCare lizensiert werden. Ist dies nicht der Fall wird die Liste der "Trusted Certificate Auhtority" nicht auf den neusten Stand gehalten. Wird im Mgmt. Web Interface die Position "Untrusted SSL Certificates" auf "allow/block" gesetzt, wird innerhalb des "SSL Inspection Profile" alle vorhandenen Service auf die jeweilige Action konfiguriert. Ueber CLI steht für diese Action "allow/block" zusätzlich "ignore" zur Verfügung dh. durch "ignore" wird jedes Server Zertifikat als "trusted" angesehen. Dies bedeutet unter CLI folgendes:

        # config firewall ssl-ssh-profile
        # edit [Name des entsprechenden SSL Inspection Profiles]
        # config ssl
        # set inspect-all [disable | certificate-inspection | deep-inspection]
        # set allow-invalid-server-cert [enable | disable]
        # set untrusted-cert [allow | block | ignore]
        # end
        # config https
        # set ports [Konfiguration des TCP Port 1 - 65535; Standard 443]
        # set status [disable | certificate-inspection | deep-inspection]
        # set client-cert-request [bypass | inspect | block]
        # set unsupported-ssl [bypass | block]
        # set allow-invalid-server-cert [enable | disable]
        # set untrusted-cert [allow | block | ignore]
        # end
        # config ftps
        # set ports [Konfiguration des TCP Port 1 - 65535; Standard 990]
        # set status [disable | certificate-inspection | deep-inspection]
        # set client-cert-request [bypass | inspect | block]
        # set unsupported-ssl [bypass | block]
        # set allow-invalid-server-cert [enable | disable]
        # set untrusted-cert [allow | block | ignore]
        # end
        # config imaps
        # set ports [Konfiguration des TCP Port 1 - 65535; Standard 993]
        # set status [disable | certificate-inspection | deep-inspection]
        # set client-cert-request [bypass | inspect | block]
        # set unsupported-ssl [bypass | block]
        # set allow-invalid-server-cert [enable | disable]
        # set untrusted-cert [allow | block | ignore]
        # end
        # config pop3s
        # set ports [Konfiguration des TCP Port 1 - 65535; Standard 995]
        # set status [disable | certificate-inspection | deep-inspection]
        # set client-cert-request [bypass | inspect | block]
        # set unsupported-ssl [bypass | block]
        # set allow-invalid-server-cert [enable | disable]
        # set untrusted-cert [allow | block | ignore]
        # end
        # config smtps
        # set ports [Konfiguration des TCP Port 1 - 65535; Standard 465]
        # set status [disable | certificate-inspection | deep-inspection]
        # set client-cert-request [bypass | inspect | block]
        # set unsupported-ssl [bypass | block]
        # set allow-invalid-server-cert [enable | disable]
        # set untrusted-cert [allow | block | ignore]
        # end
        # set server-cert-mode [re-sign | replace]
        # set caname [Fortinet_CA_SSL | Fortinet_CA_SSLProxy | Fortinet_CA_Untrusted ; Standard Fortinet_CA_SSLProxy]
        # set untrusted-caname [Fortinet_CA_SSL | Fortinet_CA_SSLProxy | Fortinet_CA_Untrusted ; Standard Fortinet_CA_Untrusted]
        # set certname [Fortinet_CA_SSL | Fortinet_CA_SSLProxy | Fortinet_CA_Untrusted | Fortinet_Factory | Fortinet_SSL | Fortinet_SSLProxy | Fortinet_Wifi ; Standard Fortinet_CA_SSLProxy]
        # config ssl-server
        # edit [Gebe einen entsprechenden Integer ein zB "1"]
        # set ip [IPv4 Adresse]
        # set https-client-cert-request [bypass | inspect | block]
        # set smtps-client-cert-request [bypass | inspect | block]
        # set pop3s-client-cert-request [bypass | inspect | block]
        # set imaps-client-cert-request [bypass | inspect | block]
        # set ftps-client-cert-request [bypass | inspect | block]
        # set ssl-other-client-cert-request [bypass | inspect | block]
        # end
        # set ssl-invalid-server-cert-log [disable | enable]
        # set rpc-over-https [enable | disable]
        # end

=== Wie kann ich unter FortiOS 5.4 ein Lokales Zertifikat Exportieren und auf einem anderen FortiGate Device Importieren? ===

Wenn ein Hardware Upgrade für ein FortiGate Device durchgeführt wird dh. zB FG-60D auf FG-100D und ein Restore anhand des Backup Files der FG-60D ist auf der FG-100D aus irgendwelchen Gründen nicht möglich, muss ein entsprechendes Zertifikat das auf der FG-100D eingelesen werden muss zuerst auf der FG-60D exportiert werden. Als Beispiel zeigen die nachfolgenden Schritte den Export des folgenden "RSA Private Key":

        -----BEGIN RSA PRIVATE KEY-----
        Proc-Type: 4,ENCRYPTED
        DEK-Info: DES-EDE3-CBC,21F46CF768868B66
        
        Zw+r9xa1L6r79qbsLnpk7o8Dj99fsdfsdfdYRFvPUhzC0ORelfcPzwrvDoyRQJKJ
        QSfAIQ5lwaWsJoWw9e8O1nl8asdwesu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
        ................................................................
        ................................................................
        ................................................................
        ................................................................
        ................................................................
        bsLnpk7o8Dj99fjsJywFdYRFvPUhzC0ORelfcPzwrvDoyRQJKJfsf9sfsdfsfsfs
        QSfAIQ5lwaWsJoWw9e8O1nl8o+EpYDu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
        -----END RSA PRIVATE KEY-----

Um diesen "RSA Private Key" zu exportieren führe auf der CLI der FG-60D folgendes aus:

        # config vpn certificate local
        # show full

Durch diesen Befehl werden alle Zertifikate aufgelistet. Suche die entsprechende Position für unseren Beispiel "RSA Private Key"! Um den "RSA Private Key" zu sichern muss folgendes in ein Text File (*.txt) gesichert werden:

        -----BEGIN RSA PRIVATE KEY-----
        Proc-Type: 4,ENCRYPTED
        DEK-Info: DES-EDE3-CBC,21F46CF768868B66
        
        Zw+r9xa1L6r79qbsLnpk7o8Dj99fsdfsdfdYRFvPUhzC0ORelfcPzwrvDoyRQJKJ
        QSfAIQ5lwaWsJoWw9e8O1nl8asdwesu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
        ................................................................
        ................................................................
        ................................................................
        ................................................................
        ................................................................
        bsLnpk7o8Dj99fjsJywFdYRFvPUhzC0ORelfcPzwrvDoyRQJKJfsf9sfsdfsfsfs
        QSfAIQ5lwaWsJoWw9e8O1nl8o+EpYDu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
        -----END RSA PRIVATE KEY-----

Setze für das Zertifikat ein Passwort:

        # config vpn certificate local
        # get
        # edit [Name des entsprechenden Zertifikates für "RSA Private Key"]
        # set password [Gebe ein entsprechendes Passwort ein]
        # end

Nun muss das entsprechende Zertifikat über Mgmt. Web Interface runtergeladen werden. Wenn die Position "Certificates" im Mgmt. Web Interface nicht vorhanden ist, wurde das entsprechende Feature nicht auf dem Mgmt. Web Interface aktiviert. Wie dies durchgeführt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

Wähle im Mgmt. Web Interface folgendes:

        System > Certificates

Wähle den entsprechenden Eintrag des Zertifikats und führe einen Rechtsklick aus sowie "Download". Speicher das Zertifikat mit der Endung .cer. Nun kann das entsprechende Zertifikat auf dem neune Device dh. zB FG-100D importiert werden. Dazu wähle im Mgmt. Web Interface folgende Position:

        System > Certificates > Import > Local Certificate

        [[Datei:Fortinet-2039.jpg]]

        [[Datei:Fortinet-2040.jpg]]

        Type                       Certificate
        Certificate file           [*.cer File "RSA Private Key"]
        Key File                   [*.txt File "RSA Private Key"]
        Password                   [Password für "RSA Private Key" konfiguriert anhand "set password"]

Nach einem erfolgreichen Import kontrolliere ob das entsprechende Zertifikat in der Liste erscheint. Der Import Vorgang ist abgeschlossen.
                
 Nach dem Import kontrolliere ob das entsprechende Zertifikat unter der folgenden Position erscheint:
                
                System > Certificates > Local Certificates

== Role ==

=== Was bedeutet unter FortiOS 5.4 die Funktion "Role" innerhalb einer Interface Konfiguration? ===

Wenn man unter FortiOS 5.4 für ein Interface die verschiedenen Konfigurationspositionen näher anschaut, fällt einem die Position "Role" auf:

        [[Datei:Fortinet-2110.jpg]]

Nun stellt sich die Frage um was handelt es sich bei diesem Konfigurationspunkt? Nach Auskunft von Fortinet handelt es sich dabei um ein neues Feature unter FortiOS 5.4 das Fehlkonfigurationen auf früheren FortiOS verhindern soll was wiederum bedeutet: Durch das hinzufügen einer bestimmten "Role" zu einem Interface stehen diesem bestimmte Konfigurationen nicht mehr zur Verfügung. Dadurch wird verhindert das zB auf einem "dmz" Interface ein DHCP Server Konfiguration durchgeführt wird. Dabei ist Wichtig zu wissen welche Konfigurationspunkte durch welche "Role" auf einem Interface entfernt werden. Nachfolgend eine Uebersicht der zur Verfügung stehenden "Role" für ein Interface:

        [[Datei:Fortinet-2111.jpg]]

Wir empfehlen grundsätzlich diese "Role" nicht zu benutzen und für ein Interface die Standard Einstellung "undefined" zu benutzen da dadurch alle Funktionen resp. Konfigurationen für ein Interface zur Verfügung stehen. Nach Auskunft von Fortinet sind diese "Role" im FortiOS nicht konfigurierbar dh. diese sind "hardcoded" implementiert und können nicht verändert werden. Es stehen auf CLI keine Kommando zur Verfügung um diese "Role" zu verändern oder abzufragen um herauszufinden welche Funktionen für eine bestimmte "Role" entfernt wurden oder zur Verfügung stehen. Um die "Role" über CLI für ein Interface zu konfigurieren führe folgendes aus:

        # config system interface
        # edit [Name des entsprechenden Interface zB "internal"]
        # set role [lan | wan | dmz | undefined]
        # end

Weitere Informationen betreffend Interface Konfiguration siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_ein_Interface_Konfigurieren.3F]]

== Interface ==

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device ein Interface Konfigurieren? ===

Wenn ein Interface auf einem FortiGate Device unter FortiOS 5.4 konfiguriert werden soll, kann dies über Mgmt. Web Interface oder CLI durchgeführt werden. Für den "Addressing mode" stehen einem Interface grundsätzlich folgende "mode" zur Verfügung:

        • static
        • dhcp
        • pppoe

Zusätzlich stehen zu diesen "Adressing mode" ebenfalls folgende Funktionen auf einem Interface zur Verfügung:

        • One-Arm-Sniffer
        • Dedicated to Extension Device

Ein "One-Arm-Sniffer" kann dann aktiviert werden, wenn über einen konfigurierten "mirror" Port eines Switches der Traffic dieses Ports dem "One-Arm-Sniffer" Port übermittelt wird und so für den Traffic eine Analyse durchgeführt werden kann. Dabei können zu diesem "One-Arm-Sniffer" Port verschiedene Security Profiles wie Antivirus, Web Filter usw. hinzugefügt werden. Die Funktion "Dedicated to Extension Device" aktiviert auf diesem Interface für die konfigurierte IPv4 Adresse mit Subnet Mask einen DHCP Server und aktiviert zusätzlich "capwap" auf dem Interface. Es fügt ebenfalls das Interface zum "ntp" Server und definiert dieses im DHCP Server als "ntp-service local". Ebenfalls wird im Hintergrund für diesen Device im DHCP Server die VCI Funktion aktiviert für FortiSwitch, FortiExtender sowie FortiAP. Wenn somit FortiAP's betrieben werden, kann diese "Dedicated to Extension Device" Funktion benützt werden. Wir empfehlen diese Funktion nicht für FortiAP's zu benutzen und anstelle dieser Funktion für die FortiAP's eine manuelle Konfiguration des Interfaces sowie DHCP Servers! Wenn ein Interface über Mgmt. Web Interface konfiguriert werden soll kann folgendes durchgeführt werden:  

        Network > Interfaces > [Markiere das entsprechende Interface] > Edit

        [[Datei:Fortinet-1683.jpg]]

        [[Datei:Fortinet-1684.jpg]]

Nachfolgend eine kurze Beschreibung der verschiedenen zur Verfügung stehenden Positionen und deren Bedeutung:

        '''Interface Name'''
        
        Der Interface Name eines FortiOS Devices ist vorgegeben und kann nicht verändert werden. Alle Interfaces auf einem FortiOS
        verfügen über alle Funktionen. Dies bedeutet: Ein "dmz" Interface kann durchaus als "wan" Interface eingesetzt werden. 
        Somit hat der Name eines Interfaces auf einem FortiOS keine Bewandnis mit dessen Funktion. Wenn die MAC Adresse des 
        Interfaces manuell konfiguriert werden soll, kann dies über CLI durchgeführt werden:
        
        # config system interface
        # edit [Name des entsprechenden Interfaces zB "internal"]
        # set macaddr [Konfiguriere eine entsprechende MAC Adresse zB "xx:xx:xx:xx:xx:xx"]
        # end
        
        Wird die ursprüngliche MAC Adresse manuell verändert geht die orginal MAC Adresse nicht verloren, denn durch die manuelle
        Konfiguration wird eine "Current_HWaddr" angelegt und die orginale MAC Adresse bleibt als "Permanent_HWaddr" erhalten.
        Um bei einer Veränderung diese "_HWaddr" aufzulisten führe folgendes auf der CLI aus:

        # get hardware nic dmz | grep HWaddr
        Current_HWaddr   08:5b:0e:47:db:5b
        Permanent_HWaddr 08:5b:0e:47:db:5c
        
        Möchte man zurück zum ursprünglichen Zustand betreffend MAC Adresse des Interfaces, kann folgendes durchgeführt werden:
        
        # config system interface
        # edit [Name des entsprechenden Interfaces zB "internal"]
        # unset macaddr
        # end

        '''Alias'''
        
        Diese Funktion eines "Alias" steht zur Verfügung um einen eigenen Namen für ein Interface zu vergeben da der "Interface
        Name" eines FortiOS nicht verändert werden kann!

        '''Link Status'''
        
        Diese Position zeigt den "Link Status" an dh. ob das Interface aktiv ist!

        '''Type'''
        
        Diese Position indiziert ob es sich um das physisches, vlan oder zB ein WiFi SSID Interface handelt.

        '''Role'''
        
        Ueber diese Position kann jedem Interface eine "Role" (Rolle) vergeben werden. Wird diese Funktion benutzt sind Optionen
        nicht mehr für einige Rollen ersichtlich. Wir empfehlen diese Funktion nicht zu benutzen! Weitere Informationen zu dieser
        Funktion siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Was_bedeutet_unter_FortiOS_5.4_die_Funktion_.22Role.22_f.C3.BCr_eine_Interface_Konfiguration.3F]]

        '''Addressing mode'''
        
        Unter dieser Position können die verschiedenen "Addressing mode" vergeben werden:
        
        • static
        • dhcp
        • pppoe
        • One-Arm-Sniffer
        • Dedicated to Extension Device
        
        Dabei ist für "dhcp" sowie "pppoe" folgendes zu beachten:
        
        Wird die Funktion "Retrieve default gateway from server" aktiviert so wird anhand des zugewiesenen Default Gateway über den
        "dhcp" oder "pppoe" Funktion automatisch ein entsprechender Routing Eintrag durchgeführt. Wird die Funktion "Override internal
        DNS" Server aktiviert werden die von der "dhcp" sowie "pppoe" zugewiesenen DNS Informationen dazu benutzt die System DNS Server
        Informationen zu überschreiben. Die System DNS Server werden über folgende Position Konfiguriert:
        
        Network > Interfaces > DNS > Sepcify
        
        Desweiteren empfehlen wir die "Distance" für "dhcp" sowie für "pppoe" auf "10" zu setzen da die Standard Konfiguration auf einem
        FortiOS für jeden Routing Eintrag "10" beträgt. Dies ist in einer "dual ISP" Konfiguration Rechnung zu tragen! Wenn in den "mode"
        eine IPv4 Adresse definiert wird kann dies in kurz Form oder anhand der regulàren Subnet Mask durchgführt werden dh.:
        
        192.168.1.99/24
        192.168.1.99/255.255.255.0

        '''Administrative Access'''
        
        Diese "Administrative Access" werden benutzt um Zugriff zu erhalten auf den FortiGate Device über das entsprechende Segment. Dies
        bedeutet: Durch die Aktivierung einer Funktion wird im Hintergrund eine automatische "local-in" Policy erstellt, die es ermöglicht
        vom Subnet das auf dem Interface konfiguriert wurde, auf den FortiGate Device zu zugreifen. Wird somit zB "HTTPS" aktiviert so wird
        im Hintergrund automatisch eine "local-in" Policy erstellt die es erlaubt aus dem Subnet das auf dem Interface konfiguriert wurde
        auf das Mgmt. Web Interface des FortiGate Devices zu zugreifen. Diese "local-in" Policy sind über folgende Position ersichtlich:
        
        Policy & Objects > Local In Policy
        
        Steht diese Position über Mgmt. Web Interface nicht zur Verfügung muss dieses Feature aktiviert werden. Weitere Informationen dazu
        siehe nachfolgenden Artikel:
        
        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]] 
        
        Ueber CLI stehen weitere "Administrative Access" Funktionen auf dem Interface zur Verfügung:
        
        # config system interface
        # edit [Name des entsprechenden Interfaces zB "internal"]
        # set allowaccess ?
        ping              PING access.
        https             HTTPS access.
        ssh               SSH access.
        snmp              SNMP access.
        http              HTTP access.
        telnet            TELNET access.
        fgfm              FortiManager access.
        radius-acct       RADIUS accounting access.
        probe-response    Probe access.
        capwap            CAPWAP access.
        # set allowaccess [Konfiguriere die entsprechenden "Administrative Access"]
        # end
        
        Wir empfehlen nur die "Administrative Access" zu aktivieren die benutzt werden!

        '''DHCP'''
        
        Unter dieser Position kann auf dem Interface ein "DHCP" Server aktiviert werden. Weitere Informationen dazu wie dieser DHCP Server zu 
        konfigurieren ist siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_Interface_auf_einer_FortiGate_einen_.22DHCP_Server.22_Konfigurieren.3F]]

        '''Device Detection'''
        
        Wenn diese Funktion aktiviert wird, wird das FortiOS angewiesen jeden Device das dieses Interface benutzt zu identifizieren. Das FortiOS
        identifiziert den Device mit folgenden Informationen:
        
        • MAC Adresse
        • IP  Adresse
        • Operating System
        • Hostname
        • Zeit (Zeit die vergangen ist seit ein Device das letzte Mal erkannt wurde)
        • Interface (über welches Interface diese Erkennung stattgefunden hat)  
        
        Basierend auf diesen Informationen können wiederum zB für Wireless Firewall Policy Rule konfiguriert werden, die zB nur für bestimmte
        Device einen Zugriff erlauben. Wenn diese Funktion aktiviert wird, sind die erkannten Devices über folgende Position ersichtlich:
        
        User & Device > Device List
        
        Um die "Device Detection" in der CLI zu konfigurieren führe folgendes aus:
        
        # config system interface
        # edit [Gebe das entsprechende Interface an zB "dmz"]
        # set device-identification [enable | disable]
        # end

        '''Active Scanning'''
        
        Dieser Konfigurationspunkt steht im Zusammenhang mit "Network Devices" resp. "Device Detection". Wenn "Device Detection" aktiviert
        wird und diese Funktion kann einen entsprechenden Device nicht identifizieren, wird dieser anhand "Active Scanning" Passive gescannt. 
        Dabei wird die gleiche Technik angewandt wie in einem "vulnaribility scan". Diese Funktion wird auf allen Devices die "vulnerability 
        scan" unterstützen per Standard aktiviert. Wir empfehlen zwar "Device Detection" zB im Wireless Bereich zu aktivieren jedoch das 
        "Active Scanning" per Standard zu deaktvieren sowie diese Funktion nur punktuell zu benutzen. Um die Funktion "Active Scanning" zu 
        benutzen muss "Device Detection" zuerst aktiviert werden. Um diese Funktion in der CLI zu aktiviere/deaktivieren führe folgendes
        aus:
        
        # config system interface
        # edit [Gebe das entsprechende Interface an zB "dmz"]
        # set device-identification [enable | disable]
        # set device-identification-active-scan [enable | disable]
        # end

        '''Security Mode'''
        
        Anhand dieser Funktion kann auf dem Interface ein "Captive Portal" aktiviert werden. Dadurch kann ein Zugriff über das Interface nur
        dann erfolgen, wenn eine korrekte Authentifizierung auf dem "Captive Portal" durchgeführt wird! Ein Anwendungsbeispiel wird im folgenden
        Artikel beschrieben:
        
        [[FortiAuthenticator:FAQ#Wie_kann_ich_die_.22Self-Registration.22_Funktion_im_Zusammenhang_mit_einem_.22Interface.22_basierenden_.22Captive_Portal.22_nutzen.3F]]

        '''Scan Outgoing Connections to Botne Sites'''
        
        Diese Funktion steht im Zusammenhang mit der "botnet" Funktion. Wie diese zu konfigurieren ist und was dabei beachtet werden soll, siehe
        nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_Verbindungen_zu_.22botnet.22_Servern_blocken_oder_.C3.BCberwachen.3F]]

        '''Enable Explizit Web Proxy'''
        
        Diese Funktion erlaubt es auf dem entsprechenden Interface einen Explizit Proxy zu aktivieren. Wird diese Funktion aktiviert, kann über
        nachfolgende Position der Explizit Proxy in seiner Grundkonfiguration konfiguriert werden:
        
        Network > Explizit Proxy
        
        Steht diese Menüposition nicht zur Verfügung, wurde das entsprechende Feature für Explizit Proxy nicht aktiviert. Wie diese aktiviert
        werden kann siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

        '''Secondary IP Address'''
        
        Unter dieser Position kann auf dem physischen Interface eine zweite IPv4 Adresse und Subnet konfiguriert werden! Zu dieser zusätzlichen 
        IPv4 Adresse sowie Subnet  können die verschiedenen "Administrative Access" aktiviert werden!

        '''Comments'''
        
        Unter dieser Position kann für das entsprechende Interface ein Kommentar hinterlegt werden!

        '''Interface State'''
        
        Diese Funktion erlaubt es ein Interface in den Status "down" oder "up" zu versetzen dh. wird ein Interface auf "disabled" konfiguriert
        wird es auf "down" gesetzt und ein Link wird nicht etabliert. Wir empfehlen alle nicht benutzten Interfaces auf "disabled" zu setzen.

Möchte man ein Interface mit einer statischen IPv4 Adresse mit Subnet Mask manuell auf der CLI konfigurieren kann dies folgendermassen durchgeführt werden:

        # config system interface
        # edit [Name des entsprechenden Interface zB "internal"]
        # set mode static
        # set ip [IPv4 Adresse mit Subnet Mask zB 192.168.1.99/24]
        # set allowaccess [Konfiguriere den Administrative Access zB "https ping"]
        # end

Für eine manuelle Interface Konfiguration über CLI stehen jedoch per Standard etliche weitere Optionen zur Verfügung. Diese können innerhalb einer Interface Konfiguration auf der CLI aufgelistet werden:

        # config system interface
        # edit [Name des entsprechenden Interface zB "internal"]
        # get
        name                : internal
        vdom                : root 
        cli-conn-status     : 0
        mode                : static 
        dhcp-relay-service  : disable 
        ip                  : 0.0.0.0 0.0.0.0
        allowaccess         : 
        fail-detect         : disable 
        pptp-client         : disable 
        arpforward          : enable 
        broadcast-forward   : disable 
        bfd                 : global 
        l2forward           : disable 
        icmp-redirect       : enable 
        vlanforward         : enable 
        stpforward          : disable 
        ips-sniffer-mode    : disable 
        ident-accept        : disable 
        ipmac               : disable 
        subst               : disable 
        substitute-dst-mac  : 00:00:00:00:00:00
        status              : down 
        netbios-forward     : disable 
        wins-ip             : 0.0.0.0
        type                : physical
        netflow-sampler     : disable 
        sflow-sampler       : disable 
        scan-botnet-connections: disable 
        sample-rate         : 2000
        polling-interval    : 20
        sample-direction    : both 
        explicit-web-proxy  : disable 
        explicit-ftp-proxy  : disable 
        tcp-mss             : 0
        inbandwidth         : 0
        outbandwidth        : 0
        spillover-threshold : 0
        ingress-spillover-threshold: 0
        weight              : 0
        external            : disable 
        devindex            : 10
        description         : 
        alias               : 
        l2tp-client         : disable 
        security-mode       : none 
        device-identification: disable 
        lldp-transmission   : vdom 
        listen-forticlient-connection: disable 
        estimated-upstream-bandwidth: 0
        estimated-downstream-bandwidth: 0
        vrrp-virtual-mac    : disable 
        vrrp:
        role                : undefined 
        snmp-index          : 11
        secondary-IP        : disable 
        auto-auth-extension-device: disable 
        ap-discover         : enable 
        ipv6:
            ip6-mode            : static 
            ip6-allowaccess     : 
            ip6-reachable-time  : 0
            ip6-retrans-time    : 0
            ip6-hop-limit       : 0
            dhcp6-prefix-delegation: disable
        delegated-prefix            : ::/0
        preferred-life-time         : 0
        valid-life-time     : 0
        delegated-DNS1      : ::
        delegated-DNS2      : ::
            ip6-address         : ::/0
            ip6-send-adv        : disable 
            autoconf            : disable 
            dhcp6-relay-service : disable 
        dhcp-relay-ip       : 
        dhcp-relay-type     : regular 
        macaddr             : 08:5b:0e:47:db:5c
        speed               : auto 
        mtu-override        : disable 
        wccp                : disable 
        nst                 : disable 
        drop-overlapped-fragment: disable 
        drop-fragment       : disable 

Je nach Konfiguration stehen weitere Optionen zur Verfügung. Welche Optionen im Gesamten zur Verfügung stehen und was deren Bedeutung ist siehe CLI Refrence:

        [[Datei:Fortigate-CLI-Ref-54.pdf]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device die detaillierten Informationen der Interfaces auflisten? ===

Es gibt unzählige Varianten um die detaillierten Informationen eines Interfaces aufzulisten. Um zB die aktuelle Konfiguration der Interfaces oder eines spezifischen Interfaces aufzulisten, kann folgendes benutzt werden:

        # show system interface internal
        config system interface
            edit "internal"
                set vdom "root"
                set ip 198.18.0.1 255.255.255.0
                set allowaccess ping https ssh fgfm
                set vlanforward enable
                set type physical
                set description "LAN segment local-sg0e0"
                set alias "LAN-INTERNAL"
                set device-identification enable
                        set snmp-index 6
            next
        end

Wenn der Befehl ohne spezifische Angabe eines Interfaces ausgeführt wird, werden sämtliche Interfaces mit dessen Konfiguration aufgelistet:

        # show system interface

Eine andere Variante um die Interfaces mit dessen Details betreffend spezifischen Optionen aufzulisten wäre der folgende Befehl:

        # get system interface
        == [ dmz ]
        name: dmz   mode: static    ip: 198.18.3.1 255.255.255.0   status: up    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ wan1 ]
        name: wan1   mode: static    ip: 193.193.135.66 255.255.255.224   status: up    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: block    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: enable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ wan2 ]
        name: wan2   mode: static    ip: 0.0.0.0 0.0.0.0   status: down    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ modem ]
        name: modem   mode: pppoe    ip: 0.0.0.0 0.0.0.0   netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ ssl.root ]
        name: ssl.root   ip: 0.0.0.0 0.0.0.0   status: up    netbios-forward: disable    type: tunnel   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    wccp: disable    
        == [ internal1 ]
        name: internal1   mode: static    ip: 198.18.0.1 255.255.255.0   status: up    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ internal2 ]
        name: internal2   mode: static    ip: 0.0.0.0 0.0.0.0   status: down    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ internal3 ]
        name: internal3   mode: static    ip: 0.0.0.0 0.0.0.0   status: down    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ internal4 ]
        name: internal4   mode: static    ip: 0.0.0.0 0.0.0.0   status: down    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ internal5 ]
        name: internal5   mode: static    ip: 0.0.0.0 0.0.0.0   status: down    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ internal6 ]
        name: internal6   mode: static    ip: 0.0.0.0 0.0.0.0   status: down    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    
        == [ internal7 ]
        name: internal7   mode: static    ip: 0.0.0.0 0.0.0.0   status: down    netbios-forward: disable    type: physical   netflow-sampler: disable    sflow-sampler: disable    scan-botnet-connections: disable    explicit-web-proxy: disable    explicit-ftp-proxy: disable    mtu-override: disable    wccp: disable    nst: disable    drop-overlapped-fragment: disable    drop-fragment: disable    

Um die Interface "Referenz Device Nummer" (index) aufzulisten kann der Befehl "diagnose netlink interface" benutzt werden. Anhand dieses Befehls lassen sich ebenfalls die Interface "counter" zurücksetzen:

        # diagnose netlink interface [list | clear] [Optional Name des Interfaces]
        
        if=lo family=00 type=772 index=1 mtu=16436 link=0 master=0
        ref=4 state=present fw_flags=0 flags=loopback 
        
        if=dummy0 family=00 type=1 index=2 mtu=1500 link=0 master=0
        ref=1 state=present fw_flags=0 flags=broadcast noarp 
        
        if=eth0 family=00 type=1 index=3 mtu=1500 link=0 master=0
        ref=4 state=start present tx_sched fw_flags=0 flags=up broadcast multicast 
        
        if=dmz family=00 type=1 index=4 mtu=1500 link=0 master=0
        ref=17 state=start present fw_flags=3800 flags=up broadcast run allmulti multicast 
        
        if=wan1 family=00 type=1 index=5 mtu=1492 link=0 master=0
        ref=14 state=start present fw_flags=10 flags=up broadcast run allmulti multicast 
        
        if=wan2 family=00 type=1 index=6 mtu=1500 link=0 master=0
        ref=7 state=present tx_sched fw_flags=0 flags=broadcast allmulti multicast 
        
        if=internal1 family=00 type=1 index=7 mtu=1500 link=0 master=0
        ref=13 state=start present fw_flags=3800 flags=up broadcast run allmulti multicast 
        
        if=internal2 family=00 type=1 index=8 mtu=1500 link=0 master=0
        ref=7 state=present tx_sched fw_flags=0 flags=broadcast allmulti multicast 
        
        if=internal3 family=00 type=1 index=9 mtu=1500 link=0 master=0
        ref=7 state=present tx_sched fw_flags=0 flags=broadcast allmulti multicast 
        
        if=internal4 family=00 type=1 index=10 mtu=1500 link=0 master=0
        ref=7 state=present tx_sched fw_flags=0 flags=broadcast allmulti multicast 
        
        if=internal5 family=00 type=1 index=11 mtu=1500 link=0 master=0
        ref=7 state=present tx_sched fw_flags=0 flags=broadcast allmulti multicast 
        
        if=internal6 family=00 type=1 index=12 mtu=1500 link=0 master=0
        ref=7 state=present tx_sched fw_flags=0 flags=broadcast allmulti multicast 
        
        if=internal7 family=00 type=1 index=13 mtu=1500 link=0 master=0
        ref=7 state=present tx_sched fw_flags=0 flags=broadcast allmulti multicast

Wenn für die/ein Interfaces eventuelle "errors" zB für "duplex mismatch" untersucht werden sollen, kann dies über CLI durchgeführt werden. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_kontrollieren_ob_irgendwelche_.22errors.22_auf_einem_Interface_existieren.3F]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device kontrollieren ob irgendwelche "errors" auf einem Interface existieren? ===

Wenn unter FortiOS 5.4 ein Interface konfiguriert wird, sollte nach einiger Zeit kontrolliert werden ob irgendwelche "errors" auf dem Interface existieren. Viele Probleme im Performance Bereich stammen von "duplex mismatch's" resp. von falsch konfigurierten Interface Einstellungen. Dabei ist folgendes zu berücksichtigen: Ein interface das auf einem FortiOS konfiguriert wird, benutzt per Standard "Auto/Auto". Der nachfolgende Befehl listet alle Interfaces auf mit deren "RX" sowie "TX" sowie mit den "errors":

        # diagnose netlink device list
          Interface|       bytes    packets errs drop fifo other compressed mcast colls
              lo.Rx:                   0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
          dummy0.Rx:                   0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
            eth0.Rx:                   0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
             dmz.Rx:             1156861                 5116                    0                    0                    0                    0                    0                    0   N/A
                .Tx:             2542375                 5776                    0                    0                    0                    0                    0   N/A                    0
            wan1.Rx:             3695930                42208                    0                    0                    0                    0                    0                    0   N/A
                .Tx:             6453468                58966                    0                    0                    0                    0                    0   N/A                    0
            wan2.Rx:                   0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
        internal1.Rx:              44160                  128                    0                    0                    0                    0                    0                    0   N/A
                .Tx:              161160                 2686                    0                    0                    0                    0                    0   N/A                    0
        internal2.Rx:                  0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
        internal3.Rx:                  0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
        internal4.Rx:                  0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
        internal5.Rx:                  0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
        internal6.Rx:                  0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0                    0                    0   N/A                    0
        internal7.Rx:                  0                    0                    0                    0                    0                    0                    0                    0   N/A
                .Tx:                   0                    0                    0                    0                    0 

Wenn "errors" auf einem Interface aufgelistet werden, muss ein event. "duplex mismatch" verifiziert werden. Dabei ist folgendes zu berücksichtigen:

        '''NIC FortiGate auf Auto, Switch auf Auto'''
        
        Resultat: Ausgehend davon das beide Seiten 802.3u Kompatibel sind und beide Seite über höchst Kapazität von 100/full-duplex
                  verfügen, wird auf beiden Seiten 100Mbps full duplex benützt.

        '''NIC FortiGate 100Mbps/full-duplex, Switch auf Auto'''
        
        Resultat: "Duplex mismatch" Keine "auto-negotiation" von dem FortiOS, der Switch bietet die standard Einstellung an 100Mbps/half-duplex.

        '''NIC FortiGate auf Auto, Switch auf 100Mbps/full-duplex'''
        
        Resultat: "Duplex mismatch". Keine "auto-negotiation" Switch, das FortiOS bietet die standard Einstellung an 100Mbps/half-duplex.

        '''NIC FortiGate auf 100Mbps/full-duplex, Switch auf 100Mbps/full-duplex'''
        
        Resultat: Korrekte manuelle Konfiguration.

        '''NIC FortiGate auf 100Mbps/half-duplex, Switch auf Auto'''
        
        Resultat: Keine "auto-negotiation" vom FortiOS, Switch standard Einstellungen 100Mbps/half-duplex. Dies ist eine Ordnungsgemässe 
                  Konfiguration sofern die Standard Duplex Einstellungen des Switches dies dem FortiOS wiedergeben.

        '''NIC FortiGate auf 10Mbps/half-duplex, Switch auf Auto'''
        
        Resultat: Der Switch ist fähig die Einstellungen des FortiOS zu erkennen (NLP) und setzt sich selber ebenfalls auf 10Mbps. Wenn 
                  keine "auto-negotiation" durchgeführt wird auf dem FortiOS (FLP) benützt der Switch "half-duplex". Eine ordnungsgemässe 
                  Konfiguration sofern die standard Einstellungen betreffend Duplex des Switches die des FortiOS entsprechen.

        '''NIC FortiGate auf 10Mbps/half-duplex, Switch auf 100Mbps/half-duplex'''
        
        Resultat: Kein Link! Beide Seiten etablieren keine Link da die "speed" Konfiguration unterschiedlich ist. "auto-negotiation" wurde 
                  auf beiden Seiten deaktiviert.

        '''NIC FortiGate auf Auto, Switch auf 10Mbps/half-duplex'''
        
        Resultat: Link wird etabliert basierend auf einer gültigen Konfiguration. Das FortiOS erkennt die Einstellungen des Switches (NLP) 
                  und setzt sich auf 10Mbps auch ohne "auto-negotiation" des Switches (FLP). Das FortiOS benützt "half-duplex". Der Switch 
                  benützt "half-duplex" nur dann wenn die standard Einstellungen des Switches dem entsprechen.

In der Beschreibung ist von "NLP" und "FLP" die Rede. Diese Abkürzungen haben folgende Bedeutung:

        • NLP    Normal Link Pulse
        • FLP    Fast Link Pulse

Um ein Interface genauer zu untersuchen dh. betreffend "RX" sowie "TX" kann nachfolgender Befehl benutzt werden:

        # diagnose hardware deviceinfo nic [Name des entsprechenden Interfaces zB "internal1"]
        Driver Name     :Fortinet NP4Lite Driver
        Version         :1.0.0
        Admin           :up
        Current_HWaddr   08:5b:0e:47:db:56
        Permanent_HWaddr 08:5b:0e:47:db:56
        Status          :up
        Speed           :100
        Duplex          :Half
        Host Rx Pkts    :146
        Host Rx Bytes   :48326
        Host Tx Pkts    :3085
        Host Tx Bytes   :160450
        Rx Pkts         :146
        Rx Bytes        :50370
        Tx Pkts         :3085
        Tx Bytes        :185100
        rx_buffer_len   :2048
        Hidden          :No
        cmd_in_list     : 0
        promiscuous     : 1
        enabled 802.1x  : 0
        authorized      : 0
        mac bypass      : 0

Bei der Analyse der "TX/RX" Werte ist es Wichtig diese korrekt zu intepretieren dh. nachfolgend eine Liste der Werte die auftreten können und deren Bedeutung:

        Rx_Errors = rx error count              Bad frame was marked as error by PHY.
        
        Rx_CRC_Errors +                         Valid in 10/100M mode.
        RX_Length_Errors -
        Rx_Align_Errors
        
        Rx_Dropped                              Running out of buffer space A newer error is rx_no_buffer_count.
        
        Rx_Missed_Errors                        Equals Rx_FIFO_Errors + CEXTERR (Carrier Extension Error Count). Only valid in 1000M mode,
                                                which is marked by PHY.
        
        Tx_Errors=Tx_Aborted_Errors             ECOL, Excessive Collisions Count. Valid in half-duplex mode.
        
        Tx_Windows_Errors                       LATECOL, Late Collisions Count. Late collisions are collisions that occur after 64-byte time 
                                                into the transmission of data packet while working in 10/100 Mb/s data rate, and 512 byte time 
                                                into the transmission of the packet while working in the 1000 Mb/s data rate. This register 
                                                only increments if transmits are enabled and the device is in half-duplex mode.
        
        Rx_Dropped                              See RX error.
        
        Tx_Dropped                              Not defined.
        
        Collisions                              Total number of collisions experienced by the transmitter. Valid in half-duplex mode.
        
        Rx_Length_Errors                        Transmission length error.
        
        Rx_Over_Errors                          Not defined.
        
        Rx_CRC_Errors                           Frame crc error.
        
        Rx_Frame_Errors                         Same as Rx_Align_Errors. This error is only valid in 10/100M mode.
        
        Rx_FIFO_Errors                          Same as Rx_Missed_errors; missed packet count.
        
        Tx_Aborted_Errors                       ECOL - Excessive Collisions Count. Only valid in half-duplex mode.
        
        Tx_Carrier_Errors                       The PHY should asset the internal carriert sense signal during every transmission Failure to 
                                                do so may indicate that the link has failed, or the PHY has an incorrect link configuration. 
                                                This regiser only increments if tansmits are enabled. This register is not valid in internal 
                                                SerDes1 mode (TBI mode for the 82544GC/E), and is only valid when the Ethernet controller is 
                                                operation at full duplex.
        
        Tx_FIFO_Errors                          Not defined.
        
        Tx_Heartbeat_Errors                     Not defined.
        
        Tx_Window_Errors                        LATECOL - Late Collisions Count.
        
        Tx_Single_Collision_Frames              Counts the number of times that a successfully transfmitted packet encountered a single 
                                                collision. The value only increments if transmits are enabled and the Ethernet controller 
                                                is in half-duplex mode.
        
        Tx_Multiple_Collision_Frames            Multiple Collision Count, counts the number of times that a transmit encountered more than one 
                                                collision but less than 16. The value only increments if transmits are enabled and the Ethernet 
                                                controller is in half-duplex mode.
        
        Tx_Deferred                             Counts defer events. A defer event occurs when the transmitter cannot immediately send a packet 
                                                due to the medium being busy either because another device is transmitting, the IPG timer has 
                                                not expired, half-duplex deferral events, reception of XOFF frames, or the link is not up. This 
                                                register only increments if transmits are enabled. This counter does not increment for sttreaming 
                                                transmits that are deferred due to TX IPG.
        
        Rx_Frame_Too_Longs                      Rx frame over size.
        
        Rx_Frame_Too_Shorts                     Rx frames too short.
        
        Rx_Align_Errors                         This error is only valid in 10/100M mode.
        
        Symbole Error Count                     SYMERRS - Counts the number of symbol errors between reads. The count increases for every bad 
                                                symbol received, whether or not a packet is currently being received and whether or not the link 
                                                is up. This register only increments in internal SerDes mode.

Wenn nach der Analyse der Interfaces für ein Interface manuell der "speed" konfiguriert werden muss, kann dies über CLI durchgeführt werden. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_f.C3.BCr_ein_Interface_den_.22speed.22_Konfigurieren.3F]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device für ein Interface den Traffic/Flow mitverfolgen? ===

Wenn es auf einem FortiOS betreffend dem Traffic auf einem Interface zu Problemen kommt, ist es unabdingbar diesen Traffic zu Analysieren um die nötigen Rückschlüsse zu ziehen. Dabei stehen auf einem FortiOS verschiedenen Varianten auf Layer 2, 3 sowie 4 zur Verfügung. Ueber das Mgmt. Web Interface eines FortiGate Devices stehen dafür die verschiedenen Logs zur Verfügung die über detaillierten Informationen betreffend dem Traffic verfügung. Die Grundvoraussetzung, dass diese Logs die Informationen des Traffic enthalten ist eine korrekte Log Konfiguration. Wie diese durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_sieht_eine_vollst.C3.A4ndige_Log_Konfiguration_f.C3.BCr_FortiOS_5.4_aus_und_wie_wird_diese_durchgef.C3.BChrt.3F]]

Möchte man den Traffic "flow" basierend Analysieren dh. wie das FortiOS einen "flow" abarbeitet, kann dies über CLI anhand des Kommandos "diagnose debug flow" durchgeführt werden. Zu diesem Kommando stehen verschiedene Optionen resp. Filter zur Verfügung um den Traffic für einen Analyse einzuschränken. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate:Diagnose-Command-Guide#debug_flow]]

Um den Traffic auf einem Interface auf Layer 2, 3 (teilweise Layer 4) einzusehen, kann das Sniffer Kommando benützt werden. Dieses basiert auf dem "tcpdump" Kommando das unter Linux benutzt wird. Zu diesem Kommando stehen etliche Varianten zur Verfügung um einen bestimmten Traffic zu Analysieren. Filter können spezifisch für die verschiedenen TCP Headers gesetzt werden. Im Zusammenhang mit Routing Problemen kann eruiert werden über welches Interface das FortiOS einen bestimmten Traffic sendet oder ob eine Fragmentierung durchgeführt wird usw. Weitere Informationen wie dieses Kommando benutzt wird und über welche Optionen es verfügt siehe nachfolgender Artikel:

        [[FortiGate:Diagnose-Sniffer-Guide]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device für ein Interface den "speed" Konfigurieren? ===

Ein Interface unter FortiOS 5.4 für ein FortiGate Device ist per Standard auf "auto" gesetzt. Dies sollte auch so belassen werden. Wenn event. "errors" betreffend zB "duplex mismatchs" verifiziert werden müssen siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_kontrollieren_ob_irgendwelche_.22errors.22_auf_einem_Interface_existieren.3F]]

Wenn nach der Analyse für ein Interface der "speed" manuell konfiguriert werden soll kann dies über die CLI durchgeführt werden:

        # conf system interface
        # edit [Name des entsprechenden Interfaces zB "internal"]
        # set speed ?
        auto        Automatically adjust speed.
        10full      10M full-duplex.
        10half      10M half-duplex.
        100full     100M full-duplex.
        100half     100M half-duplex.
        1000full    1000M full-duplex.
        # set speed [Konfiguriere den zur Verfügung stehenden "speed" für dieses Interface]
        # end

Wie schon erwähnt ist es nicht empfohlen den "speed" auf einem FortiOS manuell zu konfigurieren. Wenn 1000BaseT Gigabit Ethernet Interfaces eingesetzt werden, kann es im Zusammenhang mit "auto" und eingesetzen Switches zu Problemen kommen. Wieso dem so ist, beschreibt der nachfolgnde Knowledge Base Artikel von Fortinet:

        http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=13780

Um den aktuellen "speed" eines Interfaces zu überprüfen kann folgender Befehl benutzt werden:

        # diagnose hardware deviceinfo nic [Name des entsprechenden Interfaces zB "internal1"]
        Driver Name     :Fortinet NP4Lite Driver
        Version         :1.0.0
        Admin           :up
        Current_HWaddr   08:5b:0e:47:db:56
        Permanent_HWaddr 08:5b:0e:47:db:56
        Status          :up
        '''Speed           :100'''
        '''Duplex          :Half'''
        Host Rx Pkts    :146
        Host Rx Bytes   :48326
        Host Tx Pkts    :3085
        Host Tx Bytes   :160450
        Rx Pkts         :146
        Rx Bytes        :50370
        Tx Pkts         :3085
        Tx Bytes        :185100
        rx_buffer_len   :2048
        Hidden          :No
        cmd_in_list     : 0
        promiscuous     : 1
        enabled 802.1x  : 0
        authorized      : 0
        mac bypass      : 0

Um den Interface "speed" auf einem FortiOS mit internen Switch ohne "Hardware Switch Controller" zu Konfigurieren muss folgendes durchgeführt werden:

        # config system global
        # set internal-switch-speed ?
        auto        Automatically adjust speed.
        10full      10M full-duplex.
        10half      10M half-duplex.
        100full     100M full-duplex.
        100half     100M half-duplex.
        1000full    1000M full-duplex.
        # set internal-switch-speed [Konfiguriere den zur Verfügung stehenden "speed" für dieses Interface]
        # end

Um den Interface "speed" auf einem FortiOS mit internen Switch mit "Hardware Switch Controller" zu konfigurieren muss folgendes durchgeführt werden:

        # config system virtual-switch
        # edit [Name des virtual-swtich zB "lan"]
        # config port
        # edit [Name des entsprechenden Ports zB "lan1"]
        # set speed ?
        auto        Automatically adjust speed.
        10full      10M full-duplex.
        10half      10M half-duplex.
        100full     100M full-duplex.
        100half     100M half-duplex.
        1000full    1000M full-duplex.
        # set speed [Konfiguriere den zur Verfügung stehenden "speed" für dieses Interface]
        # end
        # end

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device für ein Interface ein "overlapping" Subnet Konfigurieren? ===

Wenn man für ein Interface eine IPv4 Adresse konfiguriert zB "port1" und dort die IPv4 Adresse "192.168.1.1/24" vergibt und danach versucht eine Secondary Adresse IP und/oder VLAN IP auf "port1" konfigurieren die sich im gleichen Subnet befindet wie die IPv4 Adresse von "port1", so erscheint folgender Fehlermeldung:

        Subnets overlap between 'port1' and the primary IP of 'port1'
        object set operator error, -54 discard the setting
        
        oder
        
        IP address is in same subnet as the others.

Die Fehlermeldung ist klar dh. die IPv4 Adresse die für das Secondary Interface und/oder VLAN Konfiguriert werden möchte, befindet sich im gleichen Subnet wie "port1". Dies wird durch das FortiOS bei jeder Interface Konfigurtion kontrolliert und per Standard verhindert. Dies gilt für jedes Interface Konfiguration auf einem FortiOS mit einer Ausnahme: Wenn ein dezidiertes Mgmt. Interface in einer High Availibility Konfiguration definiert wird, kann für dieses Interface ein "overlapping" Subnet konfiguriert werden. Es gibt jedoch Konstellationen in denen man so eine Konfifguration einer "overlapping" Subnet durchführen muss. Dabei ist jedoch folgendes zu beachten: Durch eine solche Konfiguration kann ein potentieller "loop" verursacht werden der durch das FortiOS nicht mehr verhindert wird, da die Funktion des "overlapping" Subnet deaktiviert wurde. Aus diesem Grund ist so eine Konfiguration nicht zu empfehlen und in den meisten Fällen kann so eine Konfiguration verhindert werden. Wenn dennoch solch eine Konfiguration durchgeführt werde soll, muss das FortiOS angewiesen werden ein "overlapping" Subnet zu akzeptieren. Dies wird erreicht, in dem über die System Settings diese Funktion aktiviert wird. Dies wird über CLI folgendermassen durchgeführt:

        # config system settings
        # set allow-subnet-overlap [enable | disable]
        # end

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device ein VLAN Interface Konfigurieren? ===

Unter FortiOS 5.4 können für alle Devices pro Interfaces 254 VLAN' konfiguriert werden mit folgender Ausnahmen:

        FortiGate 30D series and FortiGate 30E series have a VLAN limit of 20 per interface.

Um ein VLAN auf einem Interface über Mgmt. Web Interface zu konfigurieren muss folgendes durchgeführt werden:

        Network > Interfaces > Create New > Interfaces

        [[Datei:Fortinet-1686.jpg]]

        [[Datei:Fortinet-1687.jpg]]

Was die einzelnen Positionen innerhalb des VLAN Interfaces bedeuten siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_ein_Interface_Konfigurieren.3F]]

Um ein VLAN Interface auf auf CLI zu konfigurieren kann folgendes durchgeführt werden:
        
        # config system interface
        # edit [Name des VLAN zB "vlan-10"]
        new entry added
        # set interface internal
        # set vlanid [Konfiguriere die entsprechende VLAN ID zB "10"]
        # set ip [IPv4 Adresse sowie Subnet Maske für das VLAN zB "10.100.1.10/24"]
        # set vdom root
        # end

Auch für ein VLAN Interface stehen etliche Optionen auf der CLI zur Verfügung. Welche Optionen im Gesamten zur Verfügung stehen sowei welche Bedeutung diese haben siehe CLI Refrence:

        [[Datei:Fortigate-CLI-Ref-54.pdf]]

Wenn ein VLAN konfiguriert wird und es nachträglich zu Problemen kommt kann das "tagging" anhand des Sniffer Kommandos verifziert werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate:Diagnose-Sniffer-Guide#Sniffe_alle_802.1q_Tagging_Packete.3F]]

Weitere Informationen zum Sniffer Kommando findet man auch im nachfolgenden Artikel:

        [[FortiGate:Diagnose-Sniffer-Guide#diagnose_sniffer_packet]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device auf einem Interface die "MTU Size" Konfigurieren? ===

Auf einem FortiOS kann auf sämtlichen Interface die MTU Size konfiguriert werden. Die Standard MTU Size auf einem FortiOS für regulären Interfaces beträgt "1500". Die Konfiguration der MTU Size steht jedoch nur auf CLI zur Verfügung und wird folgendermassen durchgeführt:

        # config system interface
        # edit [Name des entsprechenden Interfaces zB "internal"]
        # set mtu-override enable
        # set mtu [Konfiguriere die MTU Size zB "1500"]
        # next
        # end

Wenn die MTU Size betreffend "Jumbo Frames" konfiguriert wird muss folgendes berücksichtigt werden:

        Jumbo Frames sind Packete die grösser sind als die Standard Maximum Transmission Unit (MTU) von "1500". Uebliche Grössen von Jumbo 
        Frames sind "9000" und "16110" bytes. Jumbo Frames können den Durchsatz massiv erhöhen, in dem ein Jumbo Frame mehr "data" in einem 
        Frame beinhalten ohne den "overhaed" des Headers. Dabei muss darauf geachtet werden, dass alle involvierten Devices wie zB Switch,
        Router etc. diese Jumbo Frames unterstützen. Ist dies nicht der Fall werden die Jumbo Frames von diesen Devices verworfen. Für die
        verschiedenen Treiber sowie für FortiGate Devices grösser als FG-300A werden Jumobo Frames für Fast-Ethernet (100Mbit) und Gigabit
        Ethernet (1000Mbit) Interfaces wie folgt unterstützt:
        
        [[Datei:Fortinet-1089.jpg]]
        
        Um den entsprechenden Treiber für einen Device resp. Interface zu verifizieren benütze folgendes Kommando:
        
        # diagnose hardware deviceinfo nic [Name des entsprechenden Interfaces]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device ein Interface für "PPPoE" Konfigurieren/Troubleshooten? ===

Wenn unter FortiOS 5.4 für einen FortiGate Device ein Interface für "pppoe" konfiguriert werden soll, kann dies über Mgmt. Web Interface durchgeführt werden:

        Network > Interfaces > [Markiere das entsprechende Interface] > Edit > Addressing mode > PPPoE

        [[Datei:Fortinet-1685.jpg]]

Wenn für ein Interface PPPoE konfiguriert wird und im Betrieb die Verbindung verloren geht, verbindet sich das PPPoE Interface neu sobald die PPPoE Verbindung wieder etabliert werden kann. Die zuständingen Optionen die dieses Verhalten steuern sind:

        • Initial Disc Timeout
        • Initial PADT Timeout 

Diese können über Mgmt. web Interface konfiguriert werden. Wenn die Konfiguration über CLI durchgeführt wird, muss folgendes konfiguriert werden:

        # config system interface
        # edit [Name des entsprechenden Interfaces zB "wan1"]
        # set mode pppoe
        # set username [Konfiguriere den entsprechenden Username für PPPoE]
        # set password [Konfiguriere das entsprechende Passwort für PPPoE]
        # set disc-retry-timeout [0 Sekunden Deaktiviert das Feature; Standard 1 Sekunde]  
        # set idle-timeout [0 Sekunden Deaktiviert das Feature; Standard 0 Sekunde]
        # set padt-retry-timeout [0 Sekunden Deaktiviert das Feature; Standard 1 Sekunde] 
        # end
        
Durch "disk-regry-timeout" wird per Standard nach einem Unterbruch nach "1 Sekunde" Versucht eine neue Verbindung zu etablieren. Durch "idle-timout" kann konfiguriert werden ob eine Verbindung beendet werden soll, wenn diese "idle" ist dh. dieses Feature ist im normal Fall durch "0" deaktiviert da eine PPPoE Verbindung permanent aktiv sein soll. Die Option "padt-regry-timout" steuert das PADT dh. dies muss durch den Provider unterstützt werden. Per Standard ist diese Option auf "1" Sekunde gesetzt dh. nach einem Unterbruch wird nach "1" Sekunde ein neuer Versuch unternommen die Verbindung zu etablieren. Wenn es für eine PPPoE Verbindung zu Problemen kommt und ein Troubleshooting durchgeführt werden soll, kann dies anhand "debug" durchgeführt werden. Ein Troubleshooting auf dem Interface direkt ist nicht möglich da PPPoE als Software im Layer 4 läuft. Aus diesem Grund muss ein Troubleshooting auf einem FortiOS anhand des PPPoE Services/Deamon (Layer 4) durchgeführt werden. Dazu verbinde dich anhand SSH oder RS-232 Mgmt. Console auf den FortiGate Device. Ein "debug" kann innerhalb einer Session sehr viele Informationen enthalten. Damit die Informationen für einen spätere Analyse zur Verfügung stehen sollte der "output" des "debug" in ein Log File geschrieben werden. Wenn anhand "putty" eine Verbindung zur FortiGate etabliert wird kann vorgängig so ein Log File über folgende Position innerhalb der "putty" Konfiguration aktiviert/konfiguriert werden:
       
       Category > Session > Logging > All Session output

Danach führe auf der CLI folgendes aus:

        '''Setze den "debug" Filter zurück'''
        
        # diagnose debug reset

        '''Aktiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp enable

        '''Setze einen neuen "debug" Filter für "PPPoE'''
        
        # diagnose debug application pppoed -1

        '''Aktiviere den "debug" Modus'''
        
        # diagnose debug enable

Nun werden die entsprechenden Informationen bei einem Verbindungsversuch des Services/Deamons von "PPPoE" aufgezeichnet. Nachdem das Troubleshooting durchgeführt wurde, sollte der "debug" Filer zurückgesetzt sowie deaktiviert werden:

        '''Deaktiviere den Debug Modus'''
        
        # diagnose debug disable

        '''Deaktiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp disable

        '''Setze den "debug" Filter zurück'''
        
        # diagnose debug reset

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device ein "aggregated" Interface (LACP) Konfigurieren? ===

LACP (RFC 802.3ad) stellt den offiziellen IEEE-Standard für die "Link Aggregation Technik" dar. Link Aggregation bezeichnet die dynamische Bündelung von mehreren physischen Verbindungen zwischen zwei Netzwerk-Komponenten zB von einer FortiGate und Switch zu einer logischen Verbindung. Wenn ein "aggregated" Interface erstellt wird, so wird eine virtuelle MAC Adresse bei einem Standalone FortiGate Device vergeben um die dynamisch gebündelten physischen Interfaces zu representieren. Bei einer FortiGate Device im High Availibility wird wiederum das erste Interface herangezogen um die virtuelle MAC Adresse zu errechnen. Für eine logische Verbindung auf einem FortiGate Device können max. 8 Interfaces gebündelt werden! Fortinet empfiehlt für eine Aggregation entweder 2, 4 oder 8 physische Ports zu benützen. Wenn auf einem FortiOS ein "aggregated" Interface konfiguriert werden möchte, kann dies nur durchgeführt werden, wenn keine Route existiert für das Interface das für eine Aggregation konfiguriert werden möchte. Wenn dies der Fall ist, muss diese Route für das Interface das für eine Aggregation konfiguriert werden möchte temporär gelöscht werden. Desweiteren kann ein "aggregated" Interface nur dann konfiguriert werden, wenn dieses zB in einer Firewall Policy Rule nicht benutzt wird. Auch in diesem Fall müssen die Firewall Policy Rules temporär gelöscht werden. Aus diesem Grund muss vor einer Konfiguration eines "aggregated" Interface folgendes berücksichtigt werden:

        • Interface wird bereits benutzt für eine Aggregation.
        • Interface darf keine IP konfiguriert haben sowie nicht benutzt für PPPoE und/oder DHCP.
        • Interface darf nicht benutzt werden für DHCP Server/Relay.
        • Interface darf keine VLAN's konfiguriert haben.
        • Interface darf nicht benutzt sein in einer Firewall Policy Rule (inkl. Multicast), NAT Konfiguration (VIP), IP Pool.
        • Interface darf nicht benutzt sein als HA Sync (Heartbeat).
        • FortiGate Device unterstützen eine Aggregation ab FG-100D (Ausnahme FG-70D)

Ob ein FortiGate Device "aggregated" Interface unterstützt, kann der Software Matrix entnommen werden dh. Position "Link Aggregation/Redundant Ports for HA":

        [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]

Um ein "aggregated" Interface ueber die CLI zu konfigurieren führe folgendes aus:

        # config system interface
        # edit [Name der Logischen Verbindung zB "aggregated-1"]
        # set vdom root
        # set type aggregate
        # set member [Name der entsprechenden hysischen Interfaces für die Bündelung von mehreren physischen Verbindungen zB "port1 port2"]
        # set lacp-mode active
        # set lacp-ha-slave [disable | enable]
        # set lacp-speed slow
        # set algorithm [L2 | L3 | L4; Standard L4]
        # set ip [IPv4 Adresse der Logischen Verbindung zB "192.168.0.1/24]
        # set min-links [Minimum Anzahl Links die existieren müssen: 1 - 32]
        # set min-links-down administrative
        # set priority-override [enable | disable]
        # set link-up-delay [Gebe die entsprechende Zeit in Millisekunden an; Standard 50]
        # next
        # end

Die Option "algorithm" hat folgende Bedeutung: Diese Option steuert wie "frames" über den Aggregierten Link Distribuiert werden (LAG Group). Dabei muss der entsprechende "algorithm" mit der Switch Konfiguration übereinstimmen. Zur Verfügung stehen folgende "algorithm":

        • L2 — Es wird die Source und Destination MAC Adresse verwendet. Dies bedeutet: Anhand des Hashwerts der MAC Adresse werden 
               gerade Hashwerte über Interface 1 gesendet und ungerade Hashwerte über Interface 2. Dieser "algorithm" sollte dann
               verwendet werden, wenn durch die aggregierten Interfaces ein flaches nicht geroutetes Netzwerk eingebunden wird!
        
        • L3 — Es wird die Source und Destination IPv4 Adresse verwendet. Wenn die IPv4 Adress Informationen nicht zur Verfügung 
               stehen wird L2 "algorithm" benutzt. Dieser "algorithm" sollte dann benutzt werden, wenn durch die aggregierten 
               Interfaces ein geroutetes (kein NAT) Netzwerk eingebunden wird. Dieser "algorithm" sollte unter normalen Umständen 
               benutzt werden!
        
        • L4 — Benützt TCP, UDP oder ESP header Informationen und wird per Standard benutzt. Somit werden die Transportlayer 
               Protokollinformationen für die Verteilung herangezogen. Dieser "algorithm" sollte dann benutzt werden, wenn 
               durch die aggregierten Interfaces einzelne spezifische Services/Server existieren oder angebunden werden!

Wenn auf dem Switch keine "multiple LAG groups" konfiguriert werden können und somit das "primary" und die "subordinate unit" Interface die gleiche MAC Adressse haben, muss "lacp-ha-slave" auf "disable" gesetzt werden da ansonsten ein Failover im HA Verbund "delays" hervorruft und somit die Performance beinträchtigt wird (Session Verlust). Aus diesem Grund ist es empfehlenswert das der Switch der benutzt wird, die Funktion "multiple Link Aggregation (LAG) Groups" unterstützt um dieses Problem zu verhindern! Im Zweifelsfall kann "lacp-ha-slave" auf "disable" gesetzt werden um einen Session Verlust zu verhindern! die Optionen "min-links" sowie "min-links-down" haben folgende Bedeutung: wenn "min-links" überschritten wird, kann anhand "min-links-down" definiert werden wieviele Interfaces als "administrative-down" gesetzt werden um ein "failover" zu erzwingen. Innerhalb der Interface Konfiguration für "aggregated" Interface steht ebenfalls die Optio "link-up-delay" zur Verfügung. Anhand dieser Option soll anhand des "delays" ein "flapping" verhindert werden. Wenn innerhalb einer "aggregated" Konfiguration ein Interface nach dwon-state wieder erreichbar wird, so geschieht dies innerhalb 50 ms. Um ein "flapping" zu verhindern, kann die "link-up-delay" Option dazu benützt werden, die Zeit zu vergrössern bevor ein Interface innerhalb der "aggregated" Konfiguration wieder als Aktiv gekennzeichnet wird. Wenn für die "aggregated" Interfaces eine Redundanz konfiguriert wird, so ist nur ein Port in der Aggregation aktiv dh. der Port der den Traffic abwickelt. Wenn zB. Port 1 aktiv ist und ein "failover" auf Port 2 durchgeführt wird, fragt sich ob ein erneuter "failover" durchgeführt werden soll, wenn Port 1 wiederum aktiv ist/wird. Mit der Option "priority-override" kann dieses Scenarion ob ein erneutes Failover durchgeführt werden soll oder nicht, gesteuert werden. Wenn es zu Problemen kommt in einer Aggregation, kann anhand des folgenden "diagnose" Kommando auf der CLI ein Troubleshooting durchgeführt werden:

        '''Beide Ports in der Aggregation sind up and running''''
        
        • In diesem Beispiel haben die Aggregator ID's dieselben Werte (ID=1). Dies bedeutet beide Ports der Aggregation
          sind up and running!
        
        # diagnose netlink aggregate name [Name des entsprechenden Aggregate Link]
        
        LACP flags: (A|P)(S|F)(A|I)(I|O)(E|D)(E|D)
        (A|P) - LACP mode is Active or Passive
        (S|F) - LACP speed is Slow or Fast
        (A|I) - Aggregatable or Individual
        (I|O) - Port In sync or Out of sync
        (E|D) - Frame collection is Enabled or Disabled
        (E|D) - Frame distribution is Enabled or Disabled
        
        status: up
        distribution algorithm: L4
        LACP mode: active
        LACP speed: slow
        LACP HA: enable
        '''aggregator ID: 1'''
        ports: 2
        actor key: 17
        actor MAC address: 00:09:0f:68:35:94
        partner key: 17
        partner MAC address: 00:09:0f:68:37:d8
         
        slave: port7
        status: up
        link failure count: 3
        permanent MAC addr: 00:09:0f:68:35:94
        actor state: ASAIEE
        partner state: ASAIEE
        '''aggregator ID: 1'''
        
        slave: port8
        status: up
        link failure count: 2
        permanent MAC addr: 00:09:0f:68:35:95
        actor state: ASAIEE
        partner state: ASAIEE
        aggregator ID: 1

        '''Nur ein Port in der Aggregation ist up and running''''
        
        • In diesem Beispiel haben die Aggregator ID's unterschiedliche Werte dh. Port 5 ID=2 und Port 1 ID=1. Dies bedeutet:
          nur der Port 6 ist up and running (ID=1)
        
        # diagnose netlink aggregate [Name des entsprechenden Aggregate Link]
        
        LACP flags: (A|P)(S|F)(A|I)(I|O)(E|D)(E|D)
        (A|P) - LACP mode is Active or Passive
        (S|F) - LACP speed is Slow or Fast
        (A|I) - Aggregatable or Individual
        (I|O) - Port In sync or Out of sync
        (E|D) - Frame collection is Enabled or Disabled
        (E|D) - Frame distribution is Enabled or Disabled
        
        status: up
        distribution algorithm: L3
        LACP mode: active
        LACP speed: slow
        LACP HA: enable
        aggregator ID: 1
        ports: 1
        actor key: 17
        actor MAC address: 00:09:0f:71:1f:22
        partner key: 45
        partner MAC address: 00:0d:66:2f:2b:40
        
        slave: port5
        status: up
        link failure count: 19
        permanent MAC addr: 00:09:0f:71:1f:22
        actor state: ASAIDD < DISABLED
        partner state: ASIODD < OUT OF SYNC / DISABLED
        '''aggregator ID: 2'''
        
        slave: port6
        status: up
        link failure count: 2
        permanent MAC addr: 00:09:0f:71:1f:23
        actor state: ASAIEE
        partner state: ASAIEE
        '''aggregator ID: 1'''

Ebenfalls kann anhand des Sniffer Kommandos der Traffic betreffend eines "aggregated" Interface angezeigt werden:

        # diagnose sniffer packet [Name des entsprechenden Aggregate Link]
        2.546898 aggreg_link -- 802.3ad LACPDU (65535,00-09-0F-68-37-D8,0017,0255,0002) ASAIEE (65535,00-09-0F-68-35-94,0017,0255,0002) ASAIEE 0x0000 0180 c200 0002 0009 0f68 37d9 8809 010 .........h7.....
        Dst Multicast - Src = lowest MAC of all ports in the LAG - Eth frame type

Weitere Informationen wie das Sniffer Kommando anzuwenden ist und welche Optionen zur Verfügung stehen siehe nachfolgender Artikel:

        [[FortiGate:Diagnose-Sniffer-Guide#diagnose_sniffer_packet]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device auf einem Interface "LLDP" Konfigurieren? ===

LLDP (Link Layer Discovery Protocol) ist ein Protokoll das Device Informationen zu anderen Devices weitergiebt. Dieses LLDP kann im Zusammenhang mit der "device-identification" aktiviert werden. Wenn zB ein FortiGate Device verbunden ist mit einem Cisco Switch der LLDP unterstützt, kann dieser Cisco Switch die LLDP Informationen über dieses Interface der FortiGate weitergeben! Die Informationen die über LLDP vom Cisco Switch dem FortiGate Device übermittelt werden umfassen folgende Informationen:

        • Chassis ID
        • Port ID
        • TTL
        • System Name
        • System Description
        • System Capabilities
        • Aggregation
        • Host Name

Damit das Protokoll LLDP benutzt werden kann, muss dieses in den Globalen Optionen aktiviert werden

        # config system global
        # set lldp-transmission [enable | disable]
        # end

Nach der Aktivierung der LLDP Funktion durch "lldp-transmission" steht grundsätzlich LLDP auf allen Interfaces zur Verfügung. Per Standard wird "lldp-transmission" für Interfaces auf "vdom" gesetzt. Durch diese Standard Einstellung wird LLDP auf allen Interfaces genutzt die über eine MAC Adresse verfügen. Um LLDP auf einem Interface im Zusammenhang mit der "device-identification" zu aktivieren führe folgendes aus:

        # config system interface
        # edit [Name des entsprechenden Interface zB "internal"]
        # set device-identification [enable | disable]
        # set lldp-transmission [vdom | enable | disable]
        # end

Nachdem LLDP aktiviert wurde, können die entsprechenden Informationen über das Mgmt. Web Interface unter folgender Position eingesehen werden:

        User & Device > Device List

Auf CLI können die entsprechenden Informationen ebenfalls ausgelesen werden:

        # diagnose user device list
        hosts
          vd root/0  94:65:9c:74:47:c6  gen 2836/18/3  req 20  redir 0
            created 3092757s  seen 1s  fortinet4intern
            ip 198.18.2.2
            type 8 'Windows PC'  src http  c 1  gen 3
            os 'Windows'  version 'NT 10.0 (x64)'  src http  id  1845  c 1
            host 'DESKTOP-HSEH6HM'  src mwbs
          vd root/0  00:16:9d:3a:e7:07  gen 2839/2/8  req 20  redir 0
            created 84513s  seen 17s  internal1
            type 16 'Router/NAT Device'  src cdp  c 1  gen 8
            os 'Cisco CE500 IOS'  version '12.2(25)SEG6'  src cdp  id  45  c 1
            host 'cisco'  src cdp
          vd root/0  00:16:9d:3a:e7:0b  gen 2840/1/9  req 20  redir 0
            created 84514s  seen 17s  dmz
            type 16 'Router/NAT Device'  src cdp  c 1  gen 9
            os 'Cisco CE500 IOS'  version '12.2(25)SEG6'  src cdp  id  45  c 1
            host 'cisco'  src cdp

Zusätzlich stehen für dieses Kommando folgende Optionen zur Verfügung:

        # diagnose user device ?
        list                 List known hosts.
        get                  List a specific host.
        del                  Remove a specific host.
        clear                Clear discovered hosts.
        invalidate           Flag discovered data for revalidation.
        os-summary           Discovered OS summary.
        host-type-summary    Discovered host type summary.
        stats                User device stats.
        filter               Filter for various src-vis diagnostics.

=== Was bedeutet unter FortiOS 5.4 für ein FortiGate Device Interface die Funktion "icmp-redirect" und wie deaktiviere ich diese? ===

Auf einem FortiOS 5.4 ist die Funktion "icmp-redirect" per Standard auf allen Interfaces aktiviert. Die Funktion "icmp-redirect" steuert das Verhalten wie Traffic für Clients/Host im gleichen Subnet verarbeitet werden. Dies bedeutet folgendes:

        Client/Host "A" sendet ein Packet an Client/Host "B" im gleichen Subnet und mit gleichen Routing resp. Default Gateway. Aus diesem
        Grund wird das Packet von Client/Host "A" zum Default Gateway gesendet da Client/Host "A" kein entsprechenden lokalen ARP Eintrag
        (MAC Adresse) von Client/Host "B" verfügt. Der Default Gateway erhält diese Anfrage von Client/Host "A" und da kein ARP Eintrag auf
        dem Default Gateway für Client/Host "B" existiert wird ein ARP Request in das Subnet gesendet (Broadcast "who-has"). Wenn sich der
        Client/Host "B" aktiv im Subnet befindet wird die Anfrage des Default Gateway "who-has" vom Client/Host "B" mit einem "reply" 
        beantwortet. Dieser "reply" beinhaltet die MAC Adresse des Client/Host "B" sowie dessen IPv4 Adresse. Diese Informationen werden
        nun vom Default Gateway zu Client/Host "A" gesendet mit einem "icmp-redirect" was Client/Host "A" anweist nicht den Default Gateway
        zu benutzen um Client/Host "B" zu erreichen sondern da nun der entsprechende ARP Eintrag zur Verfügung steht direkt Verbindung mit
        Client/Host "B" aufzunehmen.

Somit ermöglicht diese Funktion von "icmp-redirect" die Verbindung zwischen zwei Hosts im gleichen Subnet ohne den Traffic über den Default Gateway des Subnets zu senden. Wird "icmp-redirect" aktiviert ermöglicht es auf dem FortiOS eine Verbindung zwischen zwei Clients im gleichen Subnet ohne entsprechende Firewall Policy Rule zu konfigurieren die diesen Traffic erlauben. Somit: Wenn "icmp-redirect" deaktiviert wird, werden Client/Host im gleichen Subnet gezwungen den Traffic ueber den Default Gateway zu senden und auf dem FortiOS müssen entsprechenden Firewall Policy Rules konfiguriert werden, die diesen Traffic erlauben. Um "icmp-redirect" zu konfiguriere muss auf der CLI folgendes durchgeführt werden:

        # config system interface
        # edit [Name des entsprechenden Interfaces zB "internal"]
        # set icmp-redirect [enable | disable]
        # end

=== Was bedeutet unter FortiOS 5.4 für ein FortiGate Device Interface die Funktion "honor-df" und was ist dessen Bedeutung? ===

Wenn ein Device zB ein Router unter FortiOS 5.4 ein "do not fragment bit" sendet, wird dies unter FortiOS 5.4 berücksichtigt. Dies bedeutet: wird die Funktion "honor-df" deaktiviert wird das "do not fragment bit" berücksichtigt. Per Standard ist diese Globale Option aktiviert und kann nur Global und nicht für jedes Interface gesetzt werden. Kommt es zu Fragmentierungs Probleme, können diese mit einer entsprechenden MTU Size verhindert werden. Wie diese MTU Size für ein Interface konfiguriert wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_auf_einem_Interface_die_.22MTU_Size.22_Konfigurieren.3F]]

Um diese Globale Funktion des "do not fragment bit" auf der CLI zu konfigurieren führe folgendes aus

        # config system global
        # set honor-df [enable | disable]
        # end

Per Definition kann der IPv4 Layer keine Angaben darüber machen, ob ein Paket im Verlauf seiner Übertragung fragmentiert wird oder nicht. Die einzige Ausnahme: Der Sender kann das sogenannte "do not fragment bit" setzen, welches alle beteiligten Kommunikationssysteme (Router, Gateways etc.) anweist, keine Fragmentierung vorzunehmen. Für den Fall, dass eine Fragmentierung doch notwendig wäre, wird das Paket verworfen und dem Sender eine ICMP Fehlermeldung vom Typ 3 (destination unreachable) mit Code 4 (fragmentation required but don't fragment bit set) gesendet, welche besagt, dass das Ziel für unfragmentierbare Pakete dieser Größe nicht erreichbar sei. Aus diesem Grund muss mit dieser Funktion vorsichtig umgegangen werden und wird nur in speziellen Situationen benützt resp. aktiviert. 

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device auf einem Interface "Port Security" Konfigurieren? ===

Wenn im Allgemeinen von "Port Security" gesprochen wird, kann dies unterschiedlich intepretiert werden! In den Grundzügen geht es darum eine MAC Adresse auf eine IPv4 Adresse und/oder eine IPv4 Adresse auf eine MAC Adresse zu binden. Diese Konfiguration wird nachträglich dazu genutzt um die Verbindungen auf Layer 2 für diese IPv4 Adressen resp. MAC Adressen zu verhindern. Natürlich kann dies ein FortiOS  auch über den DHCP Server anhand einer "MAC Reservation + Access Control". Ob diese IPv4 auf das Interface zugreifen darf oder über das Interface kann selbstverständlich über Firewall Policy Rule anhand Source und Destination definiert werden. Diese Konfiguration in einer Firewall Policy anhand Source und Destination wird auf Layer 4 anhand des Firewall Deamons duchgeführt (Application Layer). Möchte man jedoch die Security auf Layer 2 durchführen kann "Port Security" genutzt werden dh. der Host/Client wird auf Layer 2 bereits abgelehnt oder zugelassen und somit wird Layer 4 erst später oder überhaupt nicht angewandt. Aus diesem Grund, wenn mit "Port Security" gearbeitet wird im Layer 2, und eine IPv4 auf eine MAC Adresse gebunden wird und/oder eine MAC Adresse auf eine IPv4 Adresse, muss diese Funktion im Layer 4 deaktiviert werden dh. es darf/sollte kein DHCP Sever aktiv sein in diesem Segment da die "MAC Reservation + Access Control" automatisch im Hintergrund zur "ipmacbinding table" hinzugefügt werden und somit eine bestehend Konfiguration überschreiben können. Diese "Port Security" kann auf einem FortiOS nur in der CLI konfiguriert werden und zwar folgendermassen

        '''Eine IPv4 Adresse auf MAC und/oder MAC Adresse auf IPv4 Bindung'''
        
        # config firewall ipmacbinding table
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set ip [Gebe die entsprechende IPv4 Adresse an zB 192.168.1.100]
        # set mac [Gebe die entsprechende MAC Adresse (Für 192.168.1.100) an in HEX dh. 00:00:00:00:00:00] 
        # set name [Konfiguriere "Optional" einen entsprechenden Namen]
        # set status [enable | disable]
        # end

Mit nachfolgenden Kommando können unter "ipmacbinding setting" die Einstellung für "ipmacbinding table" gesetzt werden. Diese Einstellungen gelten für die "impacbinding table" generell und können nicht für deren einzelnen Einträge gesetzt werden: 
        
        # config firewall ipmacbinding setting
        # set bindthroughfw [enable | disable]
        # set bindtofw [enable | disable]
        # set undefinedhost [allow | block]
        # end

Diese Einstellung resp. Optionen haben folgende Bedeutung:

        • bindthroughfw            Enable/disable going through firewall. disable
        • bindtofw                 Enable/disable going to firewall. disable
        • undefinedhost            Allow/block traffic for undefined hosts. block

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device ein Virtual Wire Pair Interface Konfigurieren? ===

Unter FortiOS 5.2 war es möglich für eine Transparent Firewall ein "Port Pair" zu konfigurieren. Neu unter FortiOS 5.4 kann unter einer Transparent Firewall sowie für eine NAT Firewall ein oder mehrere "Virtual Wire Pair" konfiguriert werden. Dies bedeutet: Sei es auf einer Transparent Firewall sowie auf einer NAT Firewall werden 2 Interface's zu einem Pair konfiguriert. Es ist nicht möglich mehr als 2 Ports für einen Virtual Wire Pair zu konfigurieren. Diese Ports sind im Bridge Mode und es können deshalb keine IPv4 Adressen für diese Ports konfiguriert werden. Es können ebenfalls keine VLAN's konfiguriert werden jedoch kann die Funktion für "Wildcard VLAN" aktiviert werden. Bei dieser Virtual Wire Pair Konfiguration ist betreffend Traffic folgendes zu beachten: Alle IPv4 Packete die durch einen Port im Virtual Wire Pair akzeptiert werden, werden über einen zweiten Port im Virtual Wire Pair versendet. IPv4 Packete die auf einem anderen Interfaces auf der Firewall akzeptiert werden, können nicht auf einen Port in der Virtual Wire Pair Konfiguration per Routing versendet werden. Der Traffic zwischen diesen Virtual Wire Pair Ports muss über eine reguläre Firewall Policy Route konfiguriert werden. Diese Konfiguration kann zB benutzt werden um Transparent ein DMZ in ein Segment zu verbinden wobei der Traffic über eine Firewall Policy Rule konfiguriert werden kann. Nachfolgend ein Beispiel für eine NAT Firewall mit einem Virtual Wire Pair Konfiguration die in einer NAT Firewall eine Transparent Firewall anhand Virtual Wire Pair integriert:
           _______________                            ________
          |               |internal2     IPv4 Adresse|        |     
          | FortiGate 60D |------wire-dmz------------| Router |
          |_______________|                          |________|
                       |internal3
                       |
                       |IPv4 Adresse 
                    ___|__________
                   |              |
                   | IPv4 Segment |
                   |______________|

Die Konfiguration eines Virtual Wire Pair kann über Mgmt. Web Interface durchgeführt werden unter folgender Position:

        Network > Interfaces > Wähle unter Create New "Virtual Wire Pair"

Damit die entsprechenden 2 Ports zu einem Virtual Wire Pair hinzugefügt werden können, dürfen für diese Interfaces keine Abhängigkeiten besitzen betreffend einer Konfiguration wie zB für eine DHCP Server usw. Ist dies der Fall müssen diese Abhängigkeiten entfernt werden. Ueber CLI kann die Konfiguration folgendermassen durchgeführt werden:

        # config system virtual-wire-pair
        # edit [Name für Virtual Wire Pair zB "wire-dmz"]
        # set member [Name der entsprechenden Interfaces zB "internal internal3"]
        # set wildcard-vlan [enable | disable]
        # end

Wie schon erwähnt muss eine entsprechende Firewall Policy Rule konfiguriert werden um den entsprechenden Traffic in/out zu erlauben. Diese Firewall Policy Rule wird unter folgender Position konfiguriert:

        Policy & Objects > IP4 Virtual Wire Pair Policy > Create New

        [[Datei:Fortinet-2070.jpg]]

Bei der Konfiguration der Firewall Policy Rule muss auf die "direction" des Traffic geachtet werden unter der Position "Virtual Wire Pair". Dies bedeutet: In diesem Beispiel ist der Traffic von "internal2" nach "internal3" erlaubt jedoch nicht für "internal3" nach "internal2". Somit muss für jede "direction" eine entsprechende Firewall Policy Rule konfiguriert werden! Wenn eine neue Virtual Wire Pair Firewall Policy Rule erstellt wird so ist diese Bestandteil der regulären Firewall Policy Rule unter "IPv4 Policy" und wird am Ende vor der Clean-Up Firewall Policy Rule hinzugefügt. Ersichtlich ist diese jedoch nur unter "IP4 Virtual Wire Pair Policy". Eine Virtual Wire Pair Policy Rule wird somit auf CLI wie eine reguläre Firewall Policy Rule konfiguriert:

        # config firewall policy
        # edit [Gebe einen entsprechende Policy ID an zB "0"]
        # set srcintf [Gebe das entsprechende Source Interface an zB "internal2"]
        # set dstintf [Gebe das entsprechende Destination Interface an zB "internal3"]
        # set srcaddr [Gebe die entsprechende Source Adresse an zB "all"
        # set dstaddr [Gebe die entsprechende Destination Adresse an zB "all"
        # set action [accept | block]
        # set schedule [Gebe einen Schedule an zB "always"]
        # set service [Gebe einen entsprechenden Service an zB "ALL"]
        # set logtraffic [Gebe für Log den Traffic an zB "all"]
        # next
        # end

== Switch Mode ==

=== Was muss ich unter FortiOS 5.4 für ein FortiGate Device betreffend Switch Mode Funktion/Konfiguration beachten? ===

Ein FortiGate Device verfügt mit wenigen Ausnahmen wie zB 500D/1000D über einen Switch Fabric. Dieser Switch Fabric kann auf einem "Hardware Switch Controller" oder "Internal Switch Controller" basieren. Zusätzlich steht jedem FortiGate Device zu den Switch Fabric's anhand eines "Software Switches" eine Software Basierende Lösung zur Verfügung. Dabei ist jedoch zu beachten, dass diese Software Basierende Lösung über den CPU gesteuert wird und somit die Auslastung des CPU Negativ beeinflussen kann. Auf den Einsatz von "Software Switches" sollte aus diesem Grund verzichtet werden. Beim "Hardware Switch Controller" sowie beim "Internal Switch Controller" wird der Traffic Im Gegensatz zum "Software Switch" über den Network Processor (NP) verarbeitet und somit der CPU nicht belastet. Wir unterscheiden somit:

       • Integrated Switch Fabric                  Hardware Switch Controller
       • Internal Switch Fabric / Ethernet Switch  Interner Switch Controller
       • Software Switch                           Software Basierender Switch Controller

Ein FortiGate Device kann somit auch über mehrer Hardware Switch Controller verfügen wie auch Network Prozessoren. Diese könnnen von FortiGate zu FortiGate Device unterschiedlich untereinander verbunden sein! Auskunft welcher FortiGate Device über welchen Controller verfügt sowie wie diese verbunden sind zu anderen Hardware Switch Controller oder zu Network Prozessoren gibt die Hardware Schematic:

        [[Datei:Fortinet-Hardware-Schematics.pptx]]

Ein FortiGate Device ist per Standard im Switch Mode dh. die internen Interfaces zB bei einer FG-60D dh. Internal 1 - 7 Interface sind als Switch Konfiguriert! Möchte man diesen Switch Mode aufbrechen und die einzelnen Interfaces auf dem FortiGate Device zur Verfügung haben, kann dies über Mgmt. Web Interface und CLI durchgeführt werden. Weitere Informationen siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_den_Switch_Mode_aufbrechen_damit_einzelne_Interfaces_zur_Verf.C3.BCgung_stehen.3F]]

Wenn der Switch Mode auf einem FortiGate Device aufgebrochen wurde dh. so das alle Interfaces einzeln zur Verfügung stehen, kann nachträglich wiederum einen Switch Mode für alle oder einzelne Interfaces konfiguriert werden. Dabei gilt als Voraussetzung folgendes: Interfaces die zu einem Switch hinzugefügt werden möchen, dürfen nicht in Benutzung sein dh. zB in Gebrauch für eine Firewall Policy Rule oder zB DHCP Server Konfiguration usw. Dies kann über die entsprechende Referenz (Ref.) eines Interfaces über Mgmt. Web Interface kontrolliert werden. Diese zusätzliche Spalte kann für die Interfaces eingeblendet werden:

        Network > Interfaces > [Rechte Maustaste auf der Spalte] > [Wähle "Ref." sowie "Apply]

        [[Datei:Fortinet-2077.jpg]]

        [[Datei:Fortinet-2078.jpg]]

Ist ein Interface das zu einem Switch hinzugefügt werden möchte in Gebrauch, müssen die Abhängigkeiten des Interfaces aufgelöst werden um nachträglich zu ermöglichen dieses Interface zu einem Switch hinzuzufügen. Um ein Switch über Mgmt. Web Interface zu konfigurieren wähle folgendes:

        Network > Interfaces > Create New > Interfaces

        [[Datei:Fortinet-2079.jpg]]

Danach kann über die Position "Type" der entsprechende Switch dh. zB "Hardware Switch" gewählt werden und über die Position "Physical Interface Members" die entsprechenden Interfaces:

        [[Datei:Fortinet-2080.jpg]]

Ueber CLI wird die Konfiguration folgendermassen durchgeführt:

        '''Hardware Switch'''
        
        # config system virtual-switch
        # edit [name des Virtual Switch zB "virt-sw-0"]
        # set physical-switch [Name des Virtual Switch zB "sw0]
        # set span [enable | disable]
        # set span-dest-port [Definiere den Destination Spanning Port]
        # set span-source-port [Definiere den Source Spanning Port]
        # set span-direction [rx | tx | both]
        # config port
        # edit [Füge ein entsprechendes Interface hinzu zB "internal4"]
        # set speed [auto | 10full | 10half | 100full | 100half | 1000full]
        # set status [up | down]
        # set alias [Optional Vergebe einen entsprechenden Alias für das Interface]
        # end
        # edit [Füge ein entsprechendes Interface hinzu zB "internal5"]
        # set speed [auto | 10full | 10half | 100full | 100half | 1000full]
        # set status [up | down]
        # set alias [Optional Vergebe einen entsprechenden Alias für das Interface]
        # end
        # end

        '''Software Switch'''
        
        # config system switch-interface
        # edit [name des Software Switches zB "soft-sw-0"]
        # set member [Gebe die entsprechenden Interfaces an zB "internal1 internal2"]
        # set vdom [Name der entsprechenden VDOM zB "root"]
        # set span [enable | disable]
        # set span-dest-port [Definiere den Destination Spanning Port]
        # set span-source-port [Definiere den Source Spanning Port]
        # set span-direction [rx | tx | both]
        # set type switch
        # end

Danach können die konfigurierten Switches anhand des vergebenen Interface Namens über Mgmt. Web Interface sowie in der CLI konfiguriert werden! Weitere Informationen zu der Interface Konfiguration siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_ein_Interface_Konfigurieren.3F]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device den Switch Mode aufbrechen damit einzelne Interfaces zur Verfügung stehen? ===

Der nachfolgende Artikel erklärt, dass ein FortiOS resp. ein FortiGate Device über verschiedenen Hardware Komponenten verfügt der den Switch Mode steuert:

        [[FortiGate-5.4:FAQ#Was_muss_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_betreffend_Switch_Mode_Funktion.2FKonfiguration_beachten.3F]]

Somit stellt sich die Frage wie sich die Vorgehensweise darstellt um einen Switch Mode aufzubrechen dh. damit alle Interfaces auf einem FortiGate Device einzeln zur Verfügung stehen! Dabei spielt die Abhängikeit einzelner Konfigurationen auf diesem Switch Mode eine entscheidende Rolle. Dies bedeutet: Ist der Switch Mode in Benützung dh. durch eine Konfiguration wie zB einem DHCP Server, kann der Switch Mode nicht aufgelöst werden um den Interface Mode zu aktivieren. Dieses Konfigurations Referenz (Ref.) kann auf dem Switch Mode oder Interfaces eingesehen werden indem man in der Interface Uebersicht die Spalte "Ref." einblendet:

        Network > Interfaces > [Rechte Maustaste auf der Spalte] > [Wähle "Ref." sowie "Apply]

        [[Datei:Fortinet-2077.jpg]]

Somit müssen diese Abhängigkeiten im ersten Schritt aufgelöst werden um den Switch Mode aufzubrechen resp. um in den Interface Mode zu gelangen. Geht man von einer "factoryreset" Konfiguration aus, existiert auf jedem FortiOS resp. FortiGate Device auf dem Switch Mode folgende Standard Konfiguration:

        • Standard Firewall Policy Rule die es erlaubt aus dem "internal/lan" Segment (Switch Mode) über das "wan" Interface auf das Internet zu zugreifen!
        • DHCP Server Konfiguration auf dem "internal/lan" Segment (Switch Mode)!

Um diese zwei Konfigurationen zu löschen gehen über CLI folgendermassen vor:

        # config firewall Policy
        # get
        == [ 1 ]
        policyid: 1
        # del 1
        # end

Bei dieser "policyid: 1" handelt es sich um die Standard Firewall Policy Konfiguration im "factoryreset"  wie vorhergehend beschrieben. Ist der FortiGate Device nicht mehr in der "factoryreset" Konfiguration muss durch nachfolgenden Befehl die entsprechenden Firewall Policy Rules im ersten Schritt verifiziert werden damit diese im zweiten Schritt gelöscht werden können:

        # show firewall policy

Das gleiche gilt für den DHCP Server dh.:

        # config system dhcp server
        # get 
        == [ 1 ]
        id: 1
        # del 1
        # end

Bei dieser "id: 1" handelt es sich wiederum um den Standard DHCP Server Konfiguration im "factoryreset" wie vorhergehend beschrieben. Ist der FortiGate Device nicht mehr in der "factoryreset" Konfiguration muss durch den nachfolgenden Befehl der zu löschende DHCP Server im ersten Schritt verifiziert werden um diesen im zweiten Schritt zu löschen:

        # show system dhcp server

In diesem Sinne müssen alle Abhängigkeiten auf einem FortiGate Device im Switch Mode im ersten Schritt aufgelöst werden um nachträglich die Konfiguration für den Interface Mode durchzuführen. Das Aufbrechen des Switch Mode resp. die Interface Mode Konfiguration ist Abhängig von dem Switch Controller der eingesetzt wird auf einem FortiGate Device. Nachfolgende Konfiguration kann in jedem Fall durchgeführt werden und führt zur Aufbrechung der Interfaces resp. zum Interface Mode:

        # config system global
        # get | grep internal-switch-mode
        set internal-switch-mode switch
        # set internal-switch-mode interface
        # end
        changing switch mode will reboot the system!
        Do you want to continue? (y/n)'''y'''

Bei diesem Vorgang wird die gesamte Konfiguration auf dem Switch Mode entfernt dh. inkl. der IPv4 Adress Konfiguration. Wenn der "internal-switch-mode" bereits als "interface" konfiguriert ist und es existiert ein "Switch Mode" handelt es sich um einen FortiGate Device mit einem "Hardware Switch Controller". In diesem Fall muss folgende Konfiguration durchgeführt werden um den Switch Mode aufzubrechen dh. in einzelne Interfaces. Dazu muss der "virtual-switch" gelöscht werden der die einzelnen Interfaces zum "Hardware Switch Controller" bindet:

       # config system virtual-switch
       # get
       == [ lan ]
       name: lan    
       # del lan
       # end

Auch bei dieser Konfiguration dh. beim löschen des "virtual-switch" wird die gesamte Konfiguration des "virtual-switch" entfernt inkl. der IPv4 Adress Konfiguration. Bei dieser Konfiguration wird kein Neustart des Devices durchgeführt. Es wird jedoch empfohlen diesen kurz durchzuführen:

        # execute restart

Wie schon erwähnt, wird die gesamte Konfiguration inkl. IPv4 Adress Konfiguration auf dem Switch Mode gelöscht. Somit verfügen die aufgebrochenenen einzelnen Interface über keine Konfiguration mehr. Soll nachträglich über CLI eine Konfiguration durchgeführt werden siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_ein_Interface_Konfigurieren.3F]]

=== Welche Konfigurations Möglichkeiten stehen unter FortiOS 5.4 für einen FortiGate Device im Switch Mode zur Verfügung? ===

Was ein Switch Mode ist oder wie ein Switch Mode unter FortiOS 5.4 konfiguriert wird kann im nachfolgenden Artikel nachgelesen werden:

        [[FortiGate-5.4:FAQ#Was_muss_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_betreffend_Switch_Mode_Funktion.2FKonfiguration_beachten.3F]]

Wenn ein Switch Mode konfiguriert wurde stehen innerhalb dieser Konfiguration verschiedenen Optionen zur Verfügung um den Switch zu konfigurieren dh. zB für Duplex, Mirror Port usw. Diese Konfiguration wird unter CLI durchgeführt:

        '''Interface Speed Konfiguration'''
        
        Verfügt ein FortiGate Device über einen "Internal Switch Fabric / Ethernet Switch" muss die Interface Speed Konfiguration
        Global durchgeführt werden. Diese Konfiguration gilt ebenfalls für den "Software Switch":
        
        # config system global
        # set internal-switch-speed [1000full | 100full | 100half | 10full | 10half | auto]
        # end
        
        Verfügt ein FortiGate Device über einen "Integrated Switch Fabric" muss die Interface Speed Konfiguration innerhalb des
        Virtual Switch durchgeführt werden:
        
        # config system virtual-switch
        # edit [name des Virtual Switch zB "virt-sw-0"]
        # set physical-switch [Name des Virtual Switch zB "sw0]
        # config port
        # edit [Editiere oder füge ein entsprechendes Interface hinzu zB "internal4"]
        # set speed [auto | 10full | 10half | 100full | 100half | 1000full]
        # set status [up | down]
        # set alias [Optional Vergebe einen entsprechenden Alias für das Interface]
        # next
        # end
        # end

        '''Interface Mirror Port Konfiguration'''
        
        Verfügt ein FortiGate Device über einen "Integrated Switch Fabric" muss eine Mirror Port Konfiguration innerhalb des
        Virtual Switch durchgeführt werden:
        
        # config system virtual-switch
        # edit [name des Virtual Switch zB "virt-sw-0"]
        # set physical-switch [Name des Virtual Switch zB "sw0]
        # set span [enable | disable]
        # set span-dest-port [Definiere den Destination Spanning Port]
        # set span-source-port [Definiere den Source Spanning Port]
        # set span-direction [rx | tx | both]
        # end
        
        Soll die Mirror Port Konfiguration innerhalb eines Software Switches" durchgeführt werden so muss folgendes über CLI durchgeführt
        werden:
        
        # config system switch-interface
        # edit [name des Software Switches zB "soft-sw-0"]
        # set span [enable | disable]
        # set span-dest-port [Definiere den Destination Spanning Port]
        # set span-source-port [Definiere den Source Spanning Port]
        # set span-direction [rx | tx | both]
        # end

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device im Switch Mode "STP" (Spanning Tree Protocoll) Konfigurieren? ===

Das Spanning Tree Protocol (STP) ist ein vitaler Teil von Switch-Infrastrukturen. Siehe auch nachfolgender Link:

        http://de.wikipedia.org/wiki/Spanning_Tree_Protocol

Netzwerke können mit einer Vielzahl von Switches als Verbindungs-/Koppelungselement aufgebaut werden. Allerdings muss die LAN-Technologie sicherstellen, dass zwischen zwei Rechnern jeweils nur ein Datenpfad existiert um Pakete eindeutig weiterleiten zu können. Die Vermeidung von Effekten wie Broadcast-Storms wird nur erreicht, wenn ein Algorithmus existiert der die Schleifenfreiheit der Topologie sicherstellt. Dies bedeutet folgendes: ein Switch wird in einen Zustand versetzt in dem er keine Pakete weiterleitet um einen Loop zu verhindern und somit verhindert der Spanning-Tree Algorithmus dafür das es keine unerwünscht kreisenden Pakete gibt (Loop). Er identifiziert Mehrfachwege, indem er Topologien mit redundanten Wegen durch eine logische Blockierung bestimmter Pfade in eine Baumtopologie überführt, die keine Schleifen besitzen. Die inaktiven Switches werden in einen Standby-Modus geschaltet. Bei Ausfall der primären Verbindung können diese sofort aktiviert werden und erzeugen auf diese Weise ein hohes Maß an Fehlertoleranz. STP wird auf einer FortiGate nur auf einem internen Switch untersützt. ab FortiOS 5.0 untersützen ein FortiOS "RSTP" (Rapid Spanning Tree 802.1D). Dies wird erreicht anhand einer einzelnen Instanz (instance 0) für MSTP (Multiple Spanning Tree Protocol 802.1Q). MSTP ist rückwärts Kompatible zu RSTP und STP. Wenn für einen internen Switch auf einer FortiGate STP aktiviert werden soll kann dies über eine globale Konfiguration durchgeführt werden. Dies wird folgendermassen durchgeführt:

       # config system stp
       # set switch-priority [Setze die Switch Priorität 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440; Standard 32768]
       # set hello-time [Definition in Sekunden 1-10; Standard 2]
       # set forward-delay [Definition in Sekunden 4-30; Standard 15]
       # set max-age [Definition für "age" 6-40; Standard 20]
       # set max-hops [Definition Maximale Hops 1-40; Standard 20]
       # end

Wie schon erwähnt gilt diese Konfiguration nur für den Switch Mode auf einer FortiGate. Wenn auf einem einzelnen Interface auf der FortiGate um Loops zu verhindern STP Informationen erlaubt werden sollen kann dies mit folgender Option aktiviert werden:

       # config system interface
       # edit [Name des Interface zB "internal1"]
       # set stpforward [enable | disable]
       # end

Wenn für einen Switch Mode auf der FortiGate anhand "system stp" STP konfiguriert wurde und nachträglich die STP Informationen überprüft werden möchten, kann dies mit nachfolgenden Befehl durchgeführt werden:

        # diagnose sys stp status
        
        STP Status Information        
        
          Switch Priority            32768
          Switch MAC Address         00090f4be8fe
          Root Priority              32768
          Root MAC Address           00090f4be8fe
          Root Pathcost              0
          This bridge IS the root
        
          Regional Root Priority     32768
          Regional Root MAC Address  00090f4be8fe
          Regional Root Path Cost    0
          Remaining Hops             20
          This bridge IS the regional root
        
          Port        Speed   Cost       Priority   Role         State       Edge
          __________  ______  _________  _________  ___________  __________  ____
          internal1   10M     2000000    0          DISABLED     DISCARDING  YES
          internal2   10M     2000000    0          DISABLED     DISCARDING  YES
          internal3   10M     2000000    0          DISABLED     DISCARDING  YES
          internal4   10M     2000000    0          DISABLED     DISCARDING  YES
          internal5   10M     2000000    0          DISABLED     DISCARDING  YES

== Sniffer Mode / CTAP ==

=== Wie kann ich unter FortiOS 5.4 für einen Fortigate Device einen Sniffer Port konfigurieren? ===

Unter FortiOS ist es möglich eine FortiGate Interface so zu konfigurieren, dass dieses FortiGate Interface als "sniffer" Port agiert. Dies bedeutet: Auf einem Switch wird eine sogenannter "mirror" Port (oder auch "span" Port) konfiguriert. Der Switch spiegelt (mirror) somit jedes Packet das er erhält auf diesen "mirror" Port. Somit bekommt dieser "mirror" Port auf dem Switch jeden Traffic mit, der über den Switch verarbeitet wird. Wird nun ein FortiGate Interface im "sniffer" Mode an diesen "mirror" Port angeschlossen, erhält die FortiGate somit smätlichen Traffic des "mirror" Port und kann diesen vearbeiten. Dabei ist es möglich einzelne UTM Faetures, Firewall Policy usw. zu aktivieren/konfigurieren und den Traffic so zu verarbeiten als ob der FortiGate Device zwischen dem Traffic agieren würde. Dies bedeutet: Dabei wird der Traffic nicht effektiv geblockt da es sich nur um Traffic handelt der über den "mirror" Port weitergeleitet wird und somit kann die FortiGate über diesen "sniffer" Port nicht reguläre in den Traffic eingereifen. Somit stellt dieser "sniffer" Modus eine ideale Möglichkeit dar den Traffic einer Umgebung zu analysieren und daraus entsprechende Auswertungen und Konfigurationen zu ermitteln. Für die Auswertung resp. Analyse ist es empfohlen einen FortiAnalyzer einzusetzen. Für einen solche "sniffer" Mode Konfiguration muss speziell wenn die UTM Features benutzt werden möchten der FortiGate Device registriert sein sowie der FortiGate Device muss über die entsprechenden UTM Featueres zB UTM-Bundle verfügen. Damit die Registration sowie UTM Features aktiviert werden können muss auf der FortiGate Device über den Mgmt. Port das Internet erreichbar sein. Ebenso benötigt der FortiGate Device über den Mgmt. Port DNS Zugriff. Ausgehend von der Factory Default Zustand eines FortiGate Devices kann folgendes konfiguriert werden:

        '''Konfiguration Mgmt. Interface Port'''
        
        # config system interface
        # edit [Name des Interfaces zB "port1"]
        # set vdom "root"
        # set alias [Setze einen gewünschten Alias für das Mgmt. Interface zB "Management"]
        # set ip [IPv4 Adresse des Mgmt. Interfaces zB "198.18.0.2/24"]
        # set allowaccess https ssh ping]
        # end 

        '''Konfiguration DHCP Server für Mgmt. Interface Port'''
        
        # config system dhcp server
        # edit[Wähle einen entsprechenden Integer zB "1"]
        # set default-gateway [IPv4 Adresse für den Default Gateway zB "198.18.0.2"]
        # set dns-service default
        # set interface [Name des Interfaces für den DHCP Server zB "portl"
        # config ip-range
        # edit [Wähle einen entsprechenden Integer zB "1"]
        # set end-ip [Start IPv4 Adresse für DHCP Server zB "198.18.0.254"]
        # set start-ip [End IPv4 Adresse für DHCP Server zB "198.18.0.129"]
        # next
        # end
        # set [Netmaks für DHCP Server zB "netmask 255.255.255.0"]
        # next
        # end

        '''Konfiguration Default Gateway für Mgmt. Interface Port'''
        
        # config router static
        # edit [Wähle einen entsprechenden Integer zB "1"]
        # set gateway [IPv4 Adresse des Gateway für Mgmt. Interface zB "198.18.0.1"]
        # set device [Name des Mgmt. Interface Port zB "port1"]
        # end

        '''Konfiguration des NTP Servers sowie TimeZone'''
        
        # config system global
        # set timezone 26
        # end
        
        # config system ntp
        # set ntpsync enable
        # set type custom
        # set syncinterval 60
        # set server-mode disable
        # config ntpserver
        # edit [Wähle einen entsprechenden Integer zB "1"]
        # set server [Wähle einen entsprechenden NTP Server zB "ch.pool.ntp.org"]
        # set ntpv3 disable
        # next
        # end
        # end

        '''Konfiguration des System DNS Server'''
        
        # config system dns 
        # set primary [IPv4 Adresse des Primary DNS Server]
        # set secondary [IPv4 Adresse des Secondary DNS Server]
        # end

        '''Konfiguration des FortiGuard Ports'''
        
        # config system fortiguard
        # set port 8888
        # end

        '''Konfiguration des Interface für den "sniffer" Mode'''
        
        # config system interface
        # edit [Name des entsprechenden Interfaces zB "wan1"]
        # set vdom "root"
        # set allowaccess ping
        # set ips-sniffer-mode enable
        # set type physical
        # set alias [Setze einen gewünschten Alias für das Mgmt. Interface zB "Sensor"]
        # end

        '''Konfiguration der "sniffer" Policy'''
        
        # config firewall sniffer
        # edit [Wähle einen entsprechenden Integer zB "1"]
        # set ipv6 enable
        # set non-ip enable
        # set interface "wan1"
        # set logtraffic all
        # next
        # end

        '''Konfiguration FortiAnalyzer Logging'''
        
        # config log fortianalyzer setting
        # set status enable
        # set server [IPv4 Adresse des FortiAnalyzers]
        # set upload-option realtime
        # set reliable enable
        # end
        
        # config log fortianalyzer filter
        # set severity information
        # set fortward-traffic enable
        # set local-traffic enable
        # set multicast-traffic enable
        # set sniffer-traffic enable
        # set anomaly enable
        # set voip enable
        # set dlp-archive enable
        # unset filter
        # set filter-type include
        # end

Möchte man UTM Features benützen dh. anhand konfigurierter UTM-Profiles können diese nachträglich innerhalb der "sniffer" Policy eingebunden resp. aktiviert werden. Verbinde nun zB in unseren Beiespiel den "wan1" Port des FortiGate Devices mit dem konfigurierten "mirror" Port auf dem Switch. Verbinde das Mgmt. Interface in unserem Beispiel "port1" mit dem internen Netz und verbinde dich auf das Mgmt. Web Interface. Wie schon erwähnt muss das Mgmt. Interface über den Default Gateway über Internet Zugriff verfügen. Dabei muss folgender Traffic erlaubt werden sei es extern und/oder intern damit alle Services inkl. UTM-Features für den "sniffer" Mode einwandfrei funktionieren: 

        • DNS (UDP 53)
        • NTP (UDP/TCP 123)
        • FortiGuard (TCP 8888)
        • FortiAnalyzer RSH (UDP/TCP 514)
        • ICMP

Danach kann auf der FortiGate folgendes durchgeführt werden:

        '''Verifiziere den Default Gateway'''
        
        # get router info routing-table all
        Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
        O - OSPF, IA - OSPF inter area
        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
        E1 - OSPF external type 1, E2 - OSPF external type 2
        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
        * - candidate default
        S* 0.0.0.0/0 [10/0] via 198.18.0.1, portl
        C 198.18.0.0/24 is directly connected, portl

        '''Verifiziere die System DNS Server'''
        
        # exec ping www.fortinet.com

        '''Verifiziere die System Zeit/Datum'''
        
        # execute time

        '''Führe ein Update durch für UTM-Features/FortiGuard'''
        
        # execute update-now

Nun muss als letzter Schritt der FortiGate Device auf dem FortiAnalyzer eingebunden werden. Dies bedeutet: Ein entsprechende Anfrage wurde durch die Konfiguration "config log fortianalyzer" bereits zum FortiAnalyzer gesendet. Im Device Manager des FortiAnalyzer kann dementsprechend der FortiGate Device Bestätigt und eingebunden werden! Nach der Einbindung des FortiGate Devices im FortiAnalyzer verifiziere ob die Logs unter dem FortiAnalyzer für den FortiGate Device ersichtlich sind. Dieser Konfigurationsvorgang ist ebenfalls im nachfolgenden Dokument nochmals beschrieben:

        [[Datei:POC_Sniffer_Mode_v2.1.pdf]]

=== Wie kann ich für einen Fortigate Device das CTAP Portal nutzen und um was handelt es sich dabei? ===

CTAP steht für "Cyber Threat Assessment Portal" und ist ein Gratis Service von Fortinet für Fortinet Partner. Dies bedeutet: Anhand eines FortiGate Devices im "sniffer" Mode oder "transparent" Mode kann auf dem FortiGate Device der FortiAnalyzer der CTAP Funktion eingebunden werden. Somit werden alle Logs/Informationen zu diesem Service übermittelt und anhand eines Reports ausgewertet. Dabei ist folgendes zur berücksichtigen:

        '''Minimum FortiGuard Requirements FortiGate Device'''
        
        Der FortiGate Devices muss über ein Full FortiGuard verfügen! Der Grund ist der Folgende:
        In der "sniffer" Policy sind die verschiedenen UTM Features wie IPS, Application Control,
        AV sowie WebFilter aktiviert. Um eine umfängliche Auswertung zu erhalten, sind diese UTM
        Features die nur im Zusammenhang mit FortiGuard genutzt werden können unumgänglich.

        '''Unterstützte FortiGate Devices'''
        
        CTAP unterstützt die folgenden FortiGate Devices:
        
        • FG-100D
        • FG-300D
        • FG-1500D
        
        Dazu siehe auch: [https://ctap.fortinet.com/app/faq|"What FortiGate Models Are Supported?"]

        '''Unterstützung FortiOS für die unterstützten FortiGate Devices'''
        
        CTAP unterstützt die folgenden FortiOS Versionen:
        
        • FortiOS 5.4.0
        • FortiOS 5.2.5/5.2.6
        
        Dazu siehe auch: [https://ctap.fortinet.com/app/doc|"FortiGate Configuration Files"]

Wenn CTAP benützt werden möchte kann folgendes durchgeführt werden:

        • Downloade für den entsprechenden FortiGate Device das entsprechende Konfigurationsfile:
          
          [https://ctap.fortinet.com/app/doc|"FortiGate Configuration Files"]

        • Downloade für den entsprechenden FortiGate Device das entsprechende FortiOS für das Konfigurationsfile:
          
          https://support.fortinet.com/Download/FirmwareImages.aspx (Support Account Login)

        • Führe von Grundauf für den entsprechenden FortiGate Device mit dem entsprechenden FortiOS eine Firmware Wiederherstellung durch:
          
          [[FortiGate-5.4:FAQ#Wie_kann_ich_ein_FortiGate_Device_von_Grundauf_mit_einem_entsprechenden_FortiOS_installieren_.28staging.29.3F]]

        • Führe für den entsprechenden FortiGate Device anhand des entsprecheden Konfigurationsfile ein Restore durch:
          
          [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einem_FortiGate_Device_ein_Backup.2FRestore_durchf.C3.BChren.3F]]

        • Anhand des nachfolgenden Links führe einen Check durch für den entsprechenden FortiGate Device:
          
          [https://ctap.fortinet.com/app/doc/CTAP-Checklist.pdf|"CTAP FortiGate Configuration Checklist"]
          
          Für weitere Konfigurationen siehe auch nachfolgender Artikel:
          
          [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_Fortigate_Device_einen_Sniffer_Port_konfigurieren.3F]]

        • Ueberprüfe ob das benützte Mgmt. Interface über Internet Access verfügt für folgende Ports:
          
          DNS/FortiGuard (UDP 53) 
          NTP (TCP/UDP 123)
          FortiGuard (HTTPS 443)
          FortiAnalyzer RSH (TCP/UDP 514 / 96.45.37.72)

        • Führe ein Login durch auf dem CTAP Portal anhand der Support Account Zugangs Informationen und Registriere den entsprechenden 
          FortiGate Device mit dessen Serien Nummer für den CTAP Service:
          
          https://ctap.fortinet.com/
          
          In der Registrierung muss ein entsprechendes Datum für "Logging start date" sowie "Logging end date" definiert werden. Ein Report
          wird nach "Logging end date" nach 48 Stunden bereitgestellt. Die empfohlene Zeitdauert ist 3 - 7 Tage für "Logging start/end date".

Danach kann der FortiGate Device in der entpsrechenden Umgebung in Betrieb genommen werden. Weitere Informationen findet man nach einem erfolgreichen Login ebenfalls unter folgenden Link:

        FAQ        https://ctap.fortinet.com/app/faq
        Download   https://ctap.fortinet.com/app/doc

== Switch Controller ==

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device die Switch Controller Funktion aktivieren und wie benutze ich diese? ===

Eine FortiGate Device kann über einen Hardware Switch Controller verfügen. Diese FortiGate Devices verfügen ebenfalls über einen Switch Controller. Um was es sich bei einem Hardware Switch Controller handelt und welche FortiGate Device über einen solchen Hardware Switch Controller verfügen siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Was_muss_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_betreffend_Switch_Mode_Funktion.2FKonfiguration_beachten.3F]]

Das nachfolgende Fortinet Dokument gibt Auskunft welche Voraussetzungen betreffend FortiOS im Zusammenhang mit den FortiGate Devices gelten, damit diese über den Switch Controller FortiSwitches verwalten können:

        [[Datei:FortiGate_Managed_FortiSwitch_Matrix.pdf]]

Der Switch Controller auf einem FortiGate Device ist per Standard deaktiviert. Dieser wird benutzt um FortiSwitches zu verwalten dh. diese über den FortiGate Switch Controller einzubinden und in allen belangen über diesen zu konfigurieren. Um den Switch Controller zu aktivieren muss über CLI folgendes durchgeführt werden:

        # config system global
        # set switch-controller [enable | disable]
        # set switch-controller-port [Port für den Switch Controller;  Standard 6246]
        # end

Wenn die Option "switch-controller" aktiviert wurde, steht innerhalb des Mgmt. Web Interfaces der FortiGate der Switch Controller über folgende Menüposition zur Verfügung:

        WiFi & Switch Controller

        [[Datei:Fortinet-2081.jpg]]

Wie ein FortiSwitch auf den FortiGate Switch Controller eingebunden und konfiguriert wird siehe nachfolgendes Fortinet Dokument:

        [[Datei:Fortigate-Managing-Switch-54.pdf]]

== Administrator ==

=== Wie kann ich unter FortiOS 5.4 für den Administrator "admin" das Passwort zurücksetzen wenn dieses nicht mehr bekannt ist? ===

Um ein Passwort des standard Administrators "admin" neu zu setzen, wenn dieses nicht mehr bekannt ist gelten folgende Voraussetzungen:

        • Serien Nummer des Devices muss bekannt sein (Rückseite des Gerätes) zB FGT60D4613015338
        • Der FortiGate Device muss neu gestartet werden (power off/on)
        • Der Zugriff für den Vorgang muss über Console erfolgen (RS-232)

Um das Passwort zurück zu setzen für den standard Administrator "admin" erstelle einen Serielle Console (RS-232) Zugriff:
           
        8 bits 
        no parity 
        1 stop bit 
        9600 baud (the FortiGate-300 uses 115,000 baud) 
        Flow Control = None 

Da der Zugriff nicht mehr gewährleistet ist über den standard Administrator "admin" und da der FortiGate Device neu gestartet werden muss, kann nur anhand power off/on ein Neustart des FortiGate Devices erzwungen werden. Führe diesen Neustart anhand power off/on aus! Sobald das Login erscheint, führe ein Login durch anhand des Users "maintainer" und als Passwort benutze "bcpb[Serien Nummer des FortiGate Devices]:

        User     = 	maintainer
        Password = 	bcpbFGT60D4613015338
        Welcome!

Nun kann das Passwort des standard Administrators "admin" neu konfiguriert werden:

        # config system admin
        # edit admin
        # set password [Neues Passwort]
        # end

Dieser Vorgang wird nach 2 Minuten deaktiviert dh. Nach einem power on muss innerhalb 2 Minuten eingeloggt werden da das Login anhand des Users "maintainer" nach 2 Minuten deaktiviert wird. Dieser Vorgang wird auf jedem Fortinet Device benutzt um das Passwort des standard Administrators "admin" wiederherzustellen. Es gibt keine andere Möglichkeit, dieses Passwort über Remote Zugriff zB SSH wiederherzustellen! Dies Funktion für den User "maintainer" resp. das Login kann unter der globalen Konfiguration im FortiOS deaktiviert werden. Wird dies durchgeführt gibt es keine Möglichkeit mehr das Passwort des standard Administrators zurück zu setzen:
        
        # config system global
        # set admin-maintainer [enable | disable]
        # end

=== Wie kann ich unter FortiOS 5.4 für einen Administrator den Management Zugriff aktiviere und was muss ich berücksichtigen? ===

Der User "admin" der per Standard auf einem FortiOS existiert, ist eine Administrator der über ein Profile "super_admin" verfügt. Das Profile "super_admin" verfügt über sämtliche zur Verfügung stehenden Rechte. Sofern gewünscht, kann dieser User "admin" auch gelöscht werden und mit einem neuen Administrator ersetzt werden basierend auf dem Profile "super_admin". Dies wird jedoch nicht empfohlen. In einem Profile können für die verschiedene Funktionen "Read Only, Read-Write sowie None" konfiguriert werden und somit eingeschränkt werden. Weitere Einschränkungen in den einzelnen Funktionen, die in einem Profile zur Verfügung stehen, sind nicht möglich und stehen auch nicht auf Kommandozeile zur Verfügung. Somit ist ein FortiGate Device über deren CLI und/oder Mgmt. Web Interface nicht "Mandanten" fähig. Wenn eine "Mandanten" Fähigkeit eine Anforderung darstellt muss, kann dies nur durch den Einstatz eines FortiManagers gewährleistet werden. Um für einen entsprechenden Administrator den Zugriff auf das FortiOS resp. den FortiGate Device zu ermöglichen, muss ein entsprechender Mgmt. Access über ein Interface aktiviert resp. konfiguriert werden. Für diesen Management Zugriff stehen folgende Möglichkeiten zur Verfügung:

        • ping              PING access.
        • https             HTTPS access.
        • ssh               SSH access.
        • snmp              SNMP access.
        • http              HTTP access.
        • telnet            TELNET access.
        • fgfm              FortiManager access.
        • radius-acct       RADIUS accounting access.
        • probe-response    Probe access.
        • capwap            CAPWAP access.

Diese verschiedenen Management Access Funktionen können teilweiese über Mgmt. Web Access sowie vollumfänglich über CLI konfiguriert werden:

        [[Datei:Fortinet-2005.jpg]]

        # config system interface
        # edit [Name des Interfaces]
        # set allowaccess [ping | https | ssh | snmp | http | telnet | fgfm | radius-acct | probe-response | capwap]
        # end

Wenn ein Management Access aktiviert wird so wird im Hintergrund eine "local-in" Firewall Policy erstellt, die den Zugriff aus dem IPv4 Subnet/Segment, das durch die IPv4 Adress Konfiguration des Interfaces definiert wird, zulässt. Sofern das Feature aktiviert wurde, können diese "local-in" Firewall Policies über das Mgmt. Web Interface eingesehen werden. Weitere Informationen wie verschiedenen Features aktiviert/deaktiviert werden siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

Wenn das Feature "Local In Policy" zur Verfügung steht sind die einzelnen "local-in" Policies unter folgender Position ersichtlich:

        Policy & Objects > Local In Policy > Administrative Access

=== Wie kann ich unter FortiOS 5.4 für einen Administrator den Management Zugriff anhand einer IPv4 Adresse/Subnet einschränken? ===

Wenn einem Administrator ein Management Access konfiguriert wird zB für HTTPS so kann dieser Management Zugriff anhand eines "Trusted Host" eingeschränkt werden. Durch diese Konfiguration wird die "local-in" Policy Rule erweitert, damit der Zugriff nur von diesem "Trusted Host" erlaubt wird. Dabei ist jedoch zu berücksichtigen, dass dieser "Trusted Host" Konfiguration nicht für ein bestimmtes Interface durchgeführt werden kann sondern nur für den Administrator. Somit wird der Zugriff auf allen Interfaces für die ein Management Access Konfiguriert wurde eingeschränkt. Eine "Trusted Host" Konfiguration kann über Mgmt. Web Interface und/oder über CLI durchgeführt werden:

        System > Administrators > [Markiere den entsprechenden Administrator] > Edit

        [[Datei:Fortinet-2002.jpg]]

        [[Datei:Fortinet-2006.jpg]]

        # config system admin
        # edit [Name des entsprechenden Administrators zB "admin"]
        # set trusthost1 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost2 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost3 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost4 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost5 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost6 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost7 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost8 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost9 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # set trusthost10 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
        # end

=== Wie kann ich unter FortiOS 5.4 für einen Administrator das Passwort neu setzen? ===

Wenn ein Administrator dh. der User "admin" das erste Mal über Mgmt. Web Interface, SSH, Telnet oder Console ein Login durchgeführt ist als standard Passwort kein Passwort gesetzt. Wenn dieses Passwort nach dem erstmaligen Login konfiguriert werden möchte, kann dies über Mgmt. Web Interface durchgeführt werden oder über CLI. Die maximale Länge eines Passwort eines Administrators ist seit FortiOS 5.0 128 Zeichen lang und gilt ab FortiOS 5.2 auf für reguläre User:

        '''Mgmt. Web Interface'''
        
        Dashbaord > System Information > Current Administrator > Change Password
        
        [[Datei:Fortinet-2000.jpg]]
        
        [[Datei:Fortinet-2001.jpg]]
        
        oder
        
        System > Administrators > [Markiere einen entsprechenden Administrator] > Edit
        
        [[Datei:Fortinet-2002.jpg]]
        
        [[Datei:Fortinet-2003.jpg]]
        
        [[Datei:Fortinet-2001.jpg]]

        '''CLI'''
        
        # config system admin
        # edit admin
        # set password [Setze ein neues Passwort]
        # end

Ist das Passwort des Administrators "admin" nicht mehr bekannt kann dieses anhand des Users "maintainer" neu konfiguriert werden. Dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_den_Administrator_.22admin.22_das_Passwort_zur.C3.BCcksetzen_wenn_dieses_nicht_mehr_bekannt_ist.3F]]

=== Wie kann ich unter FortiOS 5.4 für einen Administrator das Timeout Konfigurieren? ===

Als Timeout gilt per Standard für jeden Administrator 5 Minuten. Diese Konfiguration kann über Mgmt. Web Interface sowie in der CLI verändert werden:

        System > Settings

        [[Datei:Fortinet-2004.jpg]]

        # config system global
        # set admintimeout [1 - 480 Minuten; Standard 5 Minuten]
        # end

Desweiteren ist zu berücksichtigen, dass dieses Timout nicht für SSH gilt. Das Timeout für SSH wird über folgendes Kommando über CLI gesetzt:

       # config system global
       # set admin-ssh-grace-time [0 - 3600 Sekunden; Standard 120 Sekunden]
       # end

=== Wie kann ich unter FortiOS 5.4 für einen Administrator den Lockout Schwellwert und Zeit Konfigurieren? ===

Wenn ein regulärer Administrator oder jemand der sich anhand eines Administrator Names versucht einloggen wird automatisch mit einem "Lockout" versehen dh. er wird ausgesperrt für eine bestimmte Zeit. Die Anzhal möglicher Anmeldungen für ein "Lockout" sowie die Zeitspanne für das "Lockout" kann über CLI konfiguriert werden

        # config system global
        # set admin-lockout-threshold [Anzahl Möglichkeiten; Standard Wert ist 3]
        # set admin-lockout-duration [Zeitspanne in Sekunden; Stanard Wert ist 60]
        # end

=== Wie können unter FortiOS 5.4 mehrere Administratore zur gleichen Zeit ein Login durchführen? ===

Dies wird per Standard ermöglicht dh. es können mehrere Personen anhand des standard Administrators "admin" zur gleichen Zeit ein Login durchführen wie auch zusätzlich definierte Administratoring. Die zuständige Konfiguration dies zu ermöglichen resp. dies zu verhindern ist eine globale Konfiguration:

        # config system global
        # set admin-concurrent [enable | disable]
        # end

=== Wie kann ich unter FortiOS 5.4 für einen Administrator eine Public Key Authentication Konfigurieren? ===

Wenn man unter FortiOS 5.4 für einen Administrator eine Public Key Authentication konfigurieren möchte so kann dies über die entsprechende CLI Kommandos durchgeführt werden. Nachfolgendes Beispiel zeigt, wie ein Public Key Authentication über ein CentOS anhand des OpenSSH Clients konfiguriert wird. Ausgangslage eine Public Key Authentication ist ein entsprechenden "privat/public" Key. Dieser ermöglicht einem Administrator auf einem FortiOS ohne Passwort anhand des OpenSSH Clients auf dem FortiOS einzuloggen. Um ein "privat/public" Key auf einem CentOS zu erstellen, führe folgendes als User "root" durch:

        # cd /root
        # pwd
        /root

Die Informationenen einer Public Key Authentication dh. für den "privat/public" Key werden im Homeverzeichnis des User "root" im Verzeichnis .ssh gespeichert. Erstelle dieses Verzeichnis und vergebe die entsprechenden Rechte:

        # mkdir /root/.ssh
        # chmod 700 /root/.ssh
        # chown root:root /root/.ssh

Nun werden für die Public Key Authentication ein "privat" sowie einen "public" Key erstellt. Diese sind voneinander abhängig dh. der "public" Key basiert auf dem "privat" Key und somit ermöglicht der "public" Key eine Public Key Authentication anhand des "privat" Key:

        # which ssh-keygen
        /usr/bin/ssh-keygen
        
        # ssh-keygen -t rsa -f /root/.ssh/id_rsa 
        Generating public/private rsa key pair.
        Enter passphrase (empty for no passphrase): 
        Enter same passphrase again: 
        Your identification has been saved in /root/.ssh/id_rsa.
        Your public key has been saved in /root/.ssh/id_rsa.pub.
        The key fingerprint is:
        2b:cf:8d:7f:51:cb:5b:d4:77:13:d4:79:93:ab:da:63 root@mydomain.local.intra

Gebe keine "passphrase" ein sondern einfach "Enter"! Nach der erfolgreichen Generierung haben wir folgende Keys:

        # ls -la /root/.ssh/*
        -rw------- 1 root root 1675 Dec  9 13:07 /root/.ssh/id_rsa
        -rw-r--r-- 1 root root  408 Dec  9 13:07 /root/.ssh/id_rsa.pub

Das File "id_rsa" stellt den "privat" Key dar und "id_rsa.pub" stellt den "public" Key dar. Der "privat" Key muss mit den entsprechenden Rechten geschützt werden:

        # chmod 600 /root/.ssh/id_rsa

Der "public" Key muss nun auf dem FortiOS dem entsprechenden Administrator für die Public Key Authentication hinzugefügt werden. Dies wird folgendermassen durchgeführt:

        # more /root/.ssh/id_rsa.pub
        ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsum+V+qTCDNAfjGCtgn/X771NZHveHJgHAfoi6JXjVpZ7Ojd7wQ/30jM7Ma8kwecbAdGV/MStq/lX2Z09qZ/Wkq3V0k+XctrNBOc5fR26vsMwZk5GeJuYLmhXD+agTNNDf1VfRhOKj7UcLoV45kKYBZwzkOFt1E0dODFcdOY+12LwVgAHGd5cPSR3tRXY07HEEnlob0fOSb6XuKZmpgBWhEfNbGBH2gI+bEJC9E9ZoqWYGF3Vi5RgvoeW8l9zSYwtj+zwG9VG0MN9SKJR6gAhqpSvSLsZEUkbNJ9zHocxMsIw4qZ+ATU9+QYhECJTfZmWWCuC1amyV+e1KljpiH9aQ== root@mydomain.local.intra

Durch den Befehl "more" wird der Inhalt des Files "id_rsa_pub" resp. des "public" Key ausgelesen. Dabei ist zu beachten, dass es sich um eine Zeile handelt. Dies bedeutet: In einem späteren Zeitpunkt muss diese Zeile dem entsprechenden Administrator als Public Key Authentcation Information hinzugefügt werden. Dabei gilt Grundlegend folgendes in der CLI zur Definition der Public Key Authentication:

        # config system admin
        # edit admin
        # set ssh-public-key1 "[key-type] [key-value]"
        # end

Somit muss für unser Beispiel der [key-type] dh. heisst "ssh-rsa" definiert werden mit dem entsprechenden [key-value]:

        # config system admin
        # edit admin
        # set ssh-public-key1 "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsum+V+qTCDNAfjGCtgn/X771NZHveHJgHAfoi6JXjVpZ7Ojd7wQ/30jM7Ma8kwecbAdGV/MStq/lX2Z09qZ/Wkq3V0k+XctrNBOc5fR26vsMwZk5GeJuYLmhXD+agTNNDf1VfRhOKj7UcLoV45kKYBZwzkOFt1E0dODFcdOY+12LwVgAHGd5cPSR3tRXY07HEEnlob0fOSb6XuKZmpgBWhEfNbGBH2gI+bEJC9E9ZoqWYGF3Vi5RgvoeW8l9zSYwtj+zwG9VG0MN9SKJR6gAhqpSvSLsZEUkbNJ9zHocxMsIw4qZ+ATU9+QYhECJTfZmWWCuC1amyV+e1KljpiH9aQ== root@mydomain.local.intra"
        # end

Die Konfiguration ist abgeschlossen. Nun kann dieses auf dem CentOS System getestet werden anhan des nachfolgenden OpenSSH Client Kommandos:

        # ssh admin@mydomain.local.intra
        The authenticity of host 'mydomian.local.intra (mydomain.local.intra)' can't be established.
        RSA key fingerprint is 71:cb:81:d8:2d:e0:09:82:0a:c1:e9:28:10:05:ad:35.
        Are you sure you want to continue connecting (yes/no)? '''yes'''
        Warning: Permanently added 'mydomain.local.intra' (RSA) to the list of known hosts.
        #

Bei der ersten Verbindung muss der Host verifiziert werden anhand des "fingerprint" für den Host. Wird zB die Hardware des Hosts "mydomain.local.intra" ausgetauscht muss der entsprechenden Key auf dem CentOS System im Verzeichnis "/root/.ssh/known_hosts" gelöscht werden. Aus diesem Grund da der "fingerprint" auf dem Hostnamen basiert, kann nicht mit der IPv4 Adresse verbunden werden anstelle des Hostnames da der "fingerprint" für die IPv4 Adresse sich vom Host "fingerprint" unterscheidet: 

        # cat /root/.ssh/known_hosts
        mydomain.local.intra ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDrSes+GhiRczY3D/X+AzEHp8X+esH017S4VeqFs4yaGh8rbyUb/iGIoeixqJkB3B1YxLlQ7jc5kgHXspoDl5XN2uoUjd65mBpXZ61/cezNZR+YFmCKCsozHsNjO+LZsvfgXmW03tdX6lL53MzGZdYrW7AOzI2SOJXE7kDANMh5xQ==

Nachdem der "fingerprint" abgespeichert wurde kann aus dem CentOS ausgeloggt werden und abermals eingeloggt werden. Die Frage zum "fingerprint" für den Hostnamen erscheint nun nicht mehr sondern direkt der Prompt des FortiOS resp. FortiGate Devices. Als Erweiterung kann zusätzlich zur Public Key Authentiation, die es ermöglicht über ein CentOS CLI Kommandos auf der FortiOS abzusetzen und Informationen des FortiOS zum CentOS zu transferieren, SCP (Secure Copy) aktiviert werden um das Kopieren von Informationen vom FortiOS zum CentOS zu ermöglichen:

        # config system global 
        # set admin-scp [enable | disable]
        # end

Anhand der "SCP" Funktion und "sysconfig" kann nun ein automatisiertes Backup des FortGate Devices durchgeführt werden. Manuell kann dies folgendermassen auf dem CentOS getestet werden:

        # scp admin@mydomain.local.intra:sys_config /root/
        sys_config                                                                   100%  104KB  20.7KB/s   00:05    
        # ls -la /root/sys_config
        -rw-------  1 root root 106032 Dec  9 13:31 sys_config

Um eine Automation auf dem CentOS zu konfigurieren dh. ein automatisiertes Backup kann ein "crontab" so konfiguriert werden, dass das entsprechenden File mit Datum versehen wird und in ein entsprechednes Verzeichnis gespeichert wird:

        # crontab -e
        
        -------------- crontab -------------- 
        
        30 3 * * 0 scp admin@firewall.local.ch:sys_config /root/$(date +%Y%m%d-%H:%M:%S)_sys_config.conf
        
        -------------- crontab --------------
        
Der Cron Eintrag für "crontab" betreffend Ausführung hat folgende Bedeutung und Aufbau:
        
        * * * * * [Path to script or command]
        
        *                Minuten (0-59)
          *              Stunden (0-23)
            *            TagDesMonats (1-31)
              *          Monat des Jahres (1-12)
                *        TagDerWoche (0-6 with 0=Sunday)

== Policy Rule ==

=== Gibt es für eine Firewall Policy Rule für FortiOS 5.4 betreffend benutzen Objekten eine Limite (Policy is too big for system)? ===

Ja diese Limite existiert und zwar bei allen FortiOS Versionen. Dies bedeutet: wenn eine Firewall Policy Rule erstellt wird und in dieser Firewall Policy Rule wird zB eine Gruppe benutzt für Objekte und in dieser Gruppe exisiteren eine Vielzahl von Objekten kann es zu Fehlermeldungen kommen wie zB:

        "Policy is too big for system"

Dieser Umstand tritt auf wenn zB ein Upgrade durchgeführt wird und nachträglich eine neue Firewall Policy Rule erstellt werden möchte. Die Limite für eine Firewall Policy Rule betreffend enthaltenen Objekte ist die Folgende:

        Für FortiOS 5.4.0 oder höher 9000+ Objekte

Der Grund für diese Limite ist realtiv einfach. Eine Firewall Policy Rule wird in den Kernel eines FortiOS geschrieben. In diesem Kernel existieren "memory limits" und diese verhindern das mehr Memory alloziert wird als gesetzt. Wenn dieser Umstand eintritt dh. zB für die Limite von 8000 Objekten (FortiOS 5.2.4 und tiefer) muss die Firewall Policy aufgeteilt werden in zwei Firewall Policy Rules.

=== Unter FortiOS 5.4 für eine "Firewall Policy Rule" existiert die Position "Name" um was handelt es sich dabei? ===

Wenn man unter FortiOS 5.4 eine neue Firewall Policy Rule" erstellt so fällt einem auf das im oberen Bereich eine Position existiert "Name". Wenn man für die zu erstellende "Firewall Policy Rule" per Standard keinen "Name" vergiebt so kann die "Firewall Policy Rule" nicht nicht entsprechend abgespeichert werden da per Standard die Vergabe des "Name" erzwungen wird. Diese Position indiziert einen "PCI Compliance" und wird für "Audits" benützt:

        [[Datei:Fortinet-1615.jpg]]

Die Bezeichnung des "Name" kann nicht benützt werden um die Logs auf der FortiGate zu Filtern da keine entsprechende Position zur Verfügung steht um dies auszuführen. Ebenso ist diese Position in den "Log Refrence" nicht enthalten. Somit steht diese Position rein im Zusammenhang mit der "PCI Compliance" resp. "Audits". Dies wird dann ersichtlich wenn ein "PCI Compliance" Report ausgeführt wird:

        [[Datei:Fortinet-1617.jpg]]
        
        '''NOTE''' Weitere Informationen dazu wie ein "PCI Compliance" Report ausgeführt wird und um was es sich dabei
             handelt siehe nachfolgenden Artikel:
             
             [[FortiGate-5.4:FAQ#Was_ist_.22PCI_Compliance.22_und_wie_kann_ich_unter_FortiOS_5.4_einen_.22PCI_Compliance.22_Report_ausf.C3.BChren.3F]]

Bei einem Upgrade auf FortiOS 5.4 werden zwar die bestehenden "Firewall Policy Rules" übernommen dh. ohne "Name" und auch wenn bestehende "Firewall Policy Rules" modifiziert werden wird die Position "Name" nicht erzwungen, jedoch bei jeder neu erstellten "Firewall Policy Rule" wird "Name" erzwungen. Möchte man diese Funktion deaktiveren dh. damit die Vergabe von "Name" nicht mehr erzwungen wird so kann dieses Feature über folgende Position aktiviert werden:

        System > Feature Select > Allow unnamed Policies

Ebenso kann über CLI dies konfiguriert werden:

        # config system settings
        # set gui-allow-unnamed-policy [enable | disable]  
        # end

=== Unter FortiOS 5.4 für eine "Firewall Policy Rule" existiert die Position "Central-NAT" nicht mehr was ist zu beachten? ===

Unter FortiOS 5.0 sowie 5.2 konnte ein Source NAT anhand der folgenden Konfiguration in einer Firewall Policy Rule durchgeführt werden:

        • Use Outgoing Interface Address
        • Use Dynamic IP Pool
        • Use Central NAT Table

Die "Central NAT Table" Funktion stand unter FortiOS 5.0 sowie 5.2 in einer Firewall Policy Rule nur dann zur Verfügung, wenn dieses Feature aktiviert wurde. Unter FortiOS 5.4 steht nun nur noch folgende Positionen zur Verfügung:

        • Use Outgoing Interface Address
        • Use Dynamic IP Pool

Das Feature/Funktion für "Central NAT Table" kann unter FortiOS 5.4 nicht aktiviert werden resp. existiert nicht mehr. Bei einem Upgrade von FortiOS 5.2 auf 5.4 kommt es auf der Mgmt. Console (RS-232) deshalb zu folgenden "rror" Meldungen:

        >>>  "set" "central-nat" "enable" @ root.firewall.policy.10:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.16:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.18:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.20:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.21:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.22:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.23:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.30:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.24:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.25:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.26:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.27:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.28:command parse error (error -61)
        >>>  "set" "central-nat" "enable" @ root.firewall.policy.29:command parse error (error -61)

Diese "error" Meldungen können nachträglich auf dem FortiOS ebenfalls über die CLI ausgelesen werden anhand des folgenden Kommandos:

        # diagnose debug config-error-log read

Somit gilt folgendes für ein Upgrade von FortiOS 5.2 auf 5.4:

        • Für jede Firewall Policy Rule die "Central NAT Table" benutzt, wird  "Use Outgoing Interface Address" konfiguriert!

Wenn ein FortiOS als IPv4 Adresse auf zB dem "wan1" 1 public IPv4 Adresse benutzt, wird durch "Use Outgoing Interface Address" keine Aenderung durchgeführt. Sind auf dem "wan1" Interface mehrer Public IPv4 Adressen konfiguriert sei es anhand einer Subnet Mask, Secondary Interface oder ARP Eintrag und diese zusätzlichen IPv4 Adressen wurden im Source NAT anhand der Central NAT Table benutzt müssen die entsprechenden Firewall Policy Rules manuell überprüft und konfiguriert werden anhand der Funktion "Use Dynamic IP Pool". Das gleiche gilt für Source NAT Konfigurationen anhand der Central NAT Table im Bereich von privaten IPv4 Adressen im Zusammenhang zB eines IPSec site2site VPN's usw. Das IP Pool Objekt das in der Central NAT Table Funktion benutzt wurde, bleibt bei einem Upgrade unverändert bestehen und kann weiterhin für die "Dynamic IP Pool" Konfiguration benützt werden. Somit ersetzt die Funktion "Dynamic IP Pool" die Central NAT Table Konfiguration. Da die "Dynamic IP Pool" Funktion bereits auf FortiOS 5.0 sowie 5.2 existiert kann vor einem Upgrade oder nach einem Upgrade eine allfällige Modifikation durchgeführt werden. Wie ein Source NAT anhand der "Dynamic IP Pool" Konfiguration durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.4_f.C3.BCr_eine_.22Firewall_Policy_Rule.22_ein_Source_NAT_anhand_.22Dynamic_IP_Pool.22_oder_.22Outgoing_Interface_Address.22.3F]]

=== Wie konfiguriere ich unter FortiOS 5.4 für eine "Firewall Policy Rule" ein Source NAT anhand "Dynamic IP Pool" oder "Outgoing Interface Address"? ===

Wenn auf einem FortiOS 5.4 ein Source NAT konfiguriert werden soll kann dies anhand zweier Funktionen durchgeführt werden:

        • Use Outgoing Interface Address
        • Use Dynamic IP Pool

Wenn "Use Outgoing Interface Address" benutzt wird so wird das Source NAT anhand der IPv4 Adresse durchgeführt, die auf dem Interface der FortiGate konfiguriert wurde. Dies bedeutet folgendes:

        '''Beispiel: Use Outgoing Interface Address'''
        
        • In diesem Beispiel wird eine Anfrage durchgeführt eines Hosts/Client im LAN mit IPv4 Adresse zB 192.168.1.100 auf www.google.com.
          Auf dem FortiGate Device ist ein "wan1" konfiguriert mit der IPv4 Adresse von 212.59.153.66/29. Das Routing für www.google.com ist
          auf "wan1" konfiguriert anhand des Default Gateways!    
          
          __________________________________________________________________
         |            '''Original'''            ||            '''Translate'''           |
         |________________________________||________________________________|
         |      Source   |  Destination   ||      Source   |  Destination   |
         |_______________|________________||_______________|________________|
         |     LAN IP    | www.google.com ||      wan1 IP  | www.google.com |
         |_______________|________________||_______________|________________| 
         | 192.168.1.100 | www.google.com || 212.59.153.66 | www.google.com |
         |_______________|________________||_______________|________________|  
         
         Somit wird durch die Funktion "Use Outgoing Interface Address" ein Source NAT durchgeführt anhand der IPv4 Adresse 212.59.153.66.

Wenn dies unter Mgmt. Web Interface für die entsprechende Firewall Policy konfiguriert werden möchte, muss innerhalb der Firewall Policy Rule die Position "NAT" aktiviert werden um ein Source NAT zu konfiguieren. Dies bedeutet: Die Position "NAT" innerhalb einer Firewall Policy Rule steht nur im Zusammenhang mit einem Source NAT und darf für "Destination NAT (VIP Objekt)" nicht aktiviert werden. Um eine Firewall Policy Rule anhand "Use Outgoing Inerface Address" zu konfigurieren führe folgendes durch:

        Policy & Objects > IPv4 Policy > Create New
        
        [[Datei:Fortinet-1688.jpg]]

Diese Konfiguration ist relativ statisch denn diese unterstützt nur die konfigurierte IPv4 Adresse des Interfaces! Wenn jedoch mehrer IPv4 Adressen auf dem Interface konfiguriert sind oder ein Source NAT durchgeführt werden möchte anhand einer IPv4 Adresse die nicht auf einem Interface konfiguriert ist/wurde kann dies über die Funktion "Use Dynamic IP Pool" durchgeführt werden. Folgendes Beispiel:

        '''Beispiel: Use Dynamic IP Pool'''
        
        • In diesem Beispiel wird eine Anfrage durchgeführt eines Hosts/Client im LAN mit IPv4 Adresse zB 192.168.1.100 auf www.google.com.
          Auf dem FortiGate Device ist ein "wan1" konfiguriert mit der IPv4 Adresse von 212.59.153.66/29. Für das Source NAT soll jedoch nicht
          212.59.153.66 benutzt werden sondern 212.59.153.67.e Das Routing für www.google.com ist auf "wan1" konfiguriert anhand des Default
          Gateways!    
          
          ___________________________________________________________________
         |            '''Original'''            ||            '''Translate'''            |
         |________________________________||_________________________________|
         |      Source   |  Destination   ||      Source    |  Destination   |
         |_______________|________________||________________|________________|
         |     LAN IP    | www.google.com || IP Pool Objekt | www.google.com |
         |_______________|________________||________________|________________| 
         | 192.168.1.100 | www.google.com || 212.59.153.67  | www.google.com |
         |_______________|________________||________________|________________|  
         
         Somit wird durch die Funktion "Use Dynamic IP Pool" ein Source NAT durchgeführt anhand der IPv4 Adresse 212.59.153.67.

Wenn dies unter Mgmt. Web Interface für die entsprechende Firewall Policy konfiguriert werden möchte, ist die Ausgangslage ein entsprechendes "IP Pool" Objekt. Um dieses zu erstellen führe folgendes durch:

        Policy & Objects > IP Pools > Create New

        [[Datei:Fortinet-1689.jpg]]

Unter CLI wird ein "IP Pool" Objekt folgendermassen konfiguriert:

        # config firewall ippool
        # edit [Name des entsprechenden IP Pool Objekts]
        # set comment [Gebe einen entsprechenden Kommentar ein]
        # set type [overload | one-to-one | fix-port-range | port-block-allocation]
        # set startip [IPv4 Adresse]
        # set endip [IPv4 Adresse]
        # set arp-reply [enable | disable]
        # set arp-intf [Gebe das entsprechende Interface an für ARP; keine Definition = Any]
        # end

Danach erstelle eine neue Firewall Policy Rule in dem das "IP Pool" Object eingebunden wird:

        Policy & Objects > IPv4 Policy > Create New
        
        [[Datei:Fortinet-1690.jpg]]

        [[Datei:Fortinet-1691.jpg]]

Möchte man anhand der Funktion "Dynamic IP Pool" für ein ganzes Subnet NAT durchführen zB für ein IPSec site2site VPN kann das innerhalb des "IP Pool" Objekts anhand der Option "Fixed Port Range" konfiguriert werden. Dies bedeutet: Wenn zB im LAN die IPv4 Adresse mit Subnet Mask 192.168.1.0/24 existiert, diese jedoch anhand eines Source NAT "translated" werden soll anhand IPv4 Adresse und Subnet Mask 10.10.10.0/24 kann folgendes "IP Pool" Objekt anhand "Fixed Port Range" erstellt werden:

        Policy & Objects > IP Pools > Create New

        [[Datei:Fortinet-1692.jpg]]

Wird dieses "IP Pool" Object für eine "outgoing" Firewall Policy Rule eingebunden und somit ein Source NAT konfiguriert wird folgedes durchgeführt:

        • In diesem Beispiel wird als IPSec Destination 172.16.0.1 benutzt was wiederum die Encryption Domain darstellt!
          ___________________________________________________________________
         |            '''Original'''            ||            '''Translate'''            |
         |________________________________||_________________________________|
         |      Source   |  Destination   ||      Source    |  Destination   |
         |_______________|________________||________________|________________|
         |     LAN IP    |  IPsec IP dst  || IP Pool Objekt |  IPsec IP dst  |
         |_______________|________________||________________|________________| 
         | 192.168.1.1   |   172.16.0.1   ||    10.10.10.1  |   172.16.0.1   |
         |_______________|________________||________________|________________|  
         | 192.168.1.2   |   172.16.0.1   ||    10.10.10.2  |   172.16.0.1   |
         |_______________|________________||________________|________________|  
         | 192.168.1.3   |   172.16.0.1   ||    10.10.10.3  |   172.16.0.1   |
         |_______________|________________||________________|________________|  
         | 192.168.1.4   |   172.16.0.1   ||    10.10.10.4  |   172.16.0.1   |
         |_______________|________________||________________|________________|  
         | 192.168.1.5   |   172.16.0.1   ||    10.10.10.5  |   172.16.0.1   |
         |_______________|________________||________________|________________|  
         | 192.168.1.6   |   172.16.0.1   ||    10.10.10.6  |   172.16.0.1   |
         |_______________|________________||________________|________________|  

Wie in diesem Beispiel gezeigt wird .1 it .1 aus dem Source NAT IPv4 Adresse und Subnet Mask übersetzt und .2 mit .2 usw. Wenn in den verschiedenen Konfigurationen für die zur Verfügung stehenden "IP Pool" Konfiguration dh. "overload", "one-to-one" sowie "Fixed Port Range" unterschiedliche IPv4 Adress Subnet Mask's benutzen gilt folgendes:

        • Wenn die Anzahl der Source Adressen gleich ist wie die definierte IP Pool Adressen wird eine 1:1 Uebersetzung ausgeführt für die
          die definierten IPv4 Subnet Masks. Wenn in dieser Konstellation "Fixed Port Range" benutzt wird bleibt der Source Port des Hosts/
          Client unverändert. Wenn in mehreren Firewall Policy Rules in dieser Konstellation das gleiche "IP Pool" Objekt benutzt wird oder
          das gleiche IPv4 Subnet wird in mehreren "IP Pool" Objekt benutzt kann es zu Konflikten kommen!

        • Wenn die Anzahl der Source Adressen grösser ist als die definierten IP Pool Adressen wird ein sogenannter "wrap-around" Mechanismus
          verwendet. Dies bedeutet: Es wird zufüllig eine IP aus dem definiert IP Pool Adress Subnet verwendet. Wird in dieser Konstellation
          "Fixed Port Range" benutzt, bleibt der Source Port des Hosts/Client unverändert. Es können in dieser Konstellation Konflikte entstehen
          da durch User verschiedenen Sessions geöffnet werden mit den gleichen Source IPv4 Adressen/Port, Destination IPv4 Adressen/Port sowie
          das Protokoll (TCP 5 tuples).

        • Wenn die Anzahl der Source Adressen kleiner ist als die definierten IP Pool Adressen, werden einige IP Pool Adressen benützt und die
          restlichen nicht.

Somit wenn ein 1:1 Uebersetzung konfiguriert werden soll, sollte nicht "one-to-one" benutzt werden da diese Funktion den Source Port des Hosts/Client verändert. Soll der Source Port nicht verändert werden und eine 1:1 Uebersetzung durchgeführt werden muss "Fixed Port Range" benutzt werden!

=== Wenn ich für eine "Firewall Policy Rule" unter FortiOS 5.4 verschiedenen "Inspection Mode" benütze (flow/proxy) was gilt? ===

Neu unter FortiOS 5.4 wird der "Inspection Mode" Global konfiguriert dh. weitere Informationen siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Was_hat_sich_unter_FortiOS_5.4_betreffend_.22Security_Profiles.22_und_.22Inspection_Mode.22_grunds.C3.A4tzlich_ge.C3.A4ndert.3F]]

Wie dieser Artikel aufzeigt ist es jedoch möglich für "Security Profiles" individuelle Konfigurationen für den "Inspection Mode" durchzuführen dh. "proxy mode" und/oder "flow mode". Wenn dies geschieht kann der Traffic jedoch nicht individuell nach Konfiguration im "proxy mode" und/oder "flow mode" abgearbeitet werden dh. es gilt dann:

        Wenn in einer Firwall Policy Rule "proxy mode" sowie "flow mode" Security Profiles gemischt werden, wird für alle UTM
        Funktionen die beides anbieten dh. "proxy mode" und/oder "flow mode" automatisch "proxy mode" benutzt obwohl ein 
        Security Profile "flow mode" konfiguriert wurde!

=== Wieso kann ich für eine "Firewall Policy Rule" unter FortiOS 5.4 nicht verschiedenen "Interfaces" für eine Source/Destination definieren? ===

Per Standard ist es möglich seit FortiOS 5.0 für eine Source und/oder Destination in einer Firewall Policy Rule mehrere Interfaces über Web Mgmt. Interface zu definieren. Ab FortiOS 5.4.1 gibt es jedoch eine Option die das verhindern kann:

        # config system settings
        # set gui-multiple-interface-policy [enable | disable]
        # end

Ist diese Option Deaktiviert und es wird versucht ein Interface für Source und/oder Destination hinzu zufügen, wird das bestehende definierte Interface gelöscht und mit dem neu definierten überschrieben. Die Option "gui-multiple-interface-policy" hat keinen Einfluss wenn ein zusätzliches Interface für eine Source und/oder Destination über CLI hinzugefügt wird. Weitere Informationen betreffend Aktivierung/Deaktivierung von verschiedenen Gui Funktionen siehe auch nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

=== Wie Blocke ich für eine "Firewall Policy Rule" unter FortiOS 5.4 Source Traffic für ein VIP Objekt? ===

Wenn man ein Destination NAT dh. anhand eines VIP Objekts konfiguriert und die Source zB für "wan1" auf "all" gesetzt wird, stellt sich die Frage wie kann ich eine Firewall Policy Rule konfigurieren um bestimmte Source IPv4 Adressen zu Blocken. Ausgangslage für dieses Beispiel wäre folgende Firewall Policy Rule in der ein Destination NAT (VIP Objekt) konfiguriert ist für SMTP Service:

        [[Datei:Fortinet-2071.jpg]]

Würde man vor dieser Firewall Policy Rule eine Firewall Policy Rule konfigurieren die den Traffic von einer bestimmten Source auf das internal LAN Interface Blockt, würde diese Firewall Policy Rule nicht für VIP Objekte angewendet werden da die Virtuellen IP Objekte im Hintergrund in der Virtuellen Policy anderst verarbeitet werden und somit VIP Objekte durch diese Firewall Policy Rule nicht berücksichtigt werden:

        [[Datei:Fortinet-2072.jpg]]

Um dieser Firewall Policy Rule zu ermöglichen das VIP Objekte berücksichtigt werden, kann über CLI für die Firewall Policy Rule (Policy ID) durch Aktivierung der folgende Option dies ermöglicht werden:

        # config firewall policy
        # edit [Gebe die entsprechende Policy ID an zB "9"]
        # set match-vip [enable | disable]
        # end

Durch das Aktivieren der Option "match-vip" kann somit die Policy ID 9 den Traffic für VIP Objekte blockieren obwohl das VIP Objekt nicht explizit in der Firewall Policy Rule konfiguriert wurde da durch "match-vip" die entsprechende Firewall Policy angewiesen wird die Virtuellen Policy zu berücksichtigen. Wir empfehlen jedoch eine Firewall Policy Rule so zu konfigurieren in der das VIP Objekt explizit konfiguriert wird und somit explizit für eine bestimmte Source geblockt wird. Dadurch muss auf CLI die Option "match-vip" nicht explizit aktiviert werden:

        [[Datei:Fortinet-2073.jpg]]

        [[Datei:Fortinet-2074.jpg]]

Wenn eine bestimmte Source generell ausgeschlossen werden soll für eine Destination oder im Gesamten zB über GeoIP empfehlen wir eine manuelle "Local-In Firewall Policy Rule". Diese kann nur über CLI konfiguriert werde und wird vor der regularen Firewall Policy und vor der Virtuellen Policy verarbeitet:

        # config firewall local-in-policy
        # edit [Gebe eine entsprechende Policy ID an zB "1"]
        # set ha-mgmt-intf-only disable
        # set intf "wan1"
        # set srcaddr "net-local-geo-ip-russia"
        # set dstaddr "all"
        # set action deny
        # set service "ALL"
        # set schedule "always"
        # set auto-asic-offload enable
        # set status enable
        # end

Durch diese "Local-In Firewall Policy Rule" wird somit sämtliche Traffic auf "wan1" mit der Source "net-local-geo-ip-russia" geblockt. Bei einer differenzierter Konfiguration von verschiedenen Services muss jedoch folgendes berücksichtigt werden: Für die "Local-In Firewall Policy" existiert keine "Clean-Up" Firewall Policy Rule dh. sämtlicher Traffic der nicht geblockt wird erreicht die reguläre Firewall Policies die über das Mgmt. Web Gui ersichtlich sind!

=== Unter FortiOS 5.4 für eine "Firewall Policy Rule" existiert die Funktion "Policy Learning Mode" um was handelt es sich dabei? ===

Ab FortiOS 5.4.2 gibt es die Möglichkeit für eine Firewall Policy Rule die Funktion "Policy Learning Mode" zu aktivieren. Diese Funktion ist per Standard deaktiviert und muss über die CLI aktiviert werden sowie steht diese Funktion nur dann zur Verfügung, wenn der FortiGate Device über Reporting Funktionen verfügt. Dies ist zB bei kleineren Geräten nur für die FG-51E sowie FG-80D der Fall. Weitere Auskunft welche Geräte über die Reporting Funktion verfügen siehe nachfolgendes Dokument das Auskunft gibt welche Funktion bei welchem FortiGate Device zur Verfügung steht:

        [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]

Um die Funktion "Policy Learning Mode" ueber CLI zu aktiviere führe folgendes aus:

        # config system settings
        # set gui-policy-learning [enable | disable]
        # end

Wird diese Gui Option aktiviert, steht über Mgmt. Web Interface innerhalb einer Firewall Policy Rule neu der Learning Mode unter "Action" zur Verfügung:

        [[Datei:Fortinet-2138.jpg]]

Wenn der "Policy Learning Mode" für eine Firewall Policy Rule aktiviert wird so gilt folgendes:

        Es werden im Flow Mode im Hintergrund folgende UTM Features resp. Profiles der Firewall Policy Rule hinzugefügt:
        
        • av-profile
        • webfilter-profile
        • spamfilter-profile
        • dlp-sensor
        • ips-sensor
        • application-list
        • profile-protocol-options
        
        Diese UTM Profiles sind statischer Natur und können nicht editiert werden. Die Funktion "SSL inspection" (deep
        inspection) wird für diese Firewall Policy Rule für die der "Policy Learning Mode" aktiviert ist deaktiviert!
        Nachfolgende Funktionen/Profiles werden nicht zur dieser Firewall Policy Rule im "Policy Learning Mode" hinzugefügt:


        • DNS Filter (Kein Flow Mode vorhanden)
        • Web Application Firewall (Kein Flow Mode vorhanden)
        • CASI(Benötigt für die Grundfunktionen Hauptsächlich "SSL inspection")

Diese Funktion kann Hauptsächlich benutzt werden für Analysezweck dh. Wenn Firewall Policy Rules die implementiert werden sollen umbekannt sind, kann über diese Funktion anhand eines Reportings eruiert werden welche Firewall Policy Rules implementiert werden müssen. Dazu muss ein einwandfreies Logging auf dem FortiGate Device konfiguriert sowie zur Verfügung stehen (Disk Logging). Wie eine einwandfreie Log Konfiguratin für einen FortiGate Device durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_sieht_eine_vollst.C3.A4ndige_Log_Konfiguration_f.C3.BCr_FortiOS_5.4_aus_und_wie_wird_diese_durchgef.C3.BChrt.3F]]

Wenn die Funktion "Policy Learning Mode" für eine Firewall Policy Rule aktiviert wurde und Logging einwandfrei zur Verfügung steht, kann nach einiger Zeit ein Report über folgende Menüposition erstellt werden:

        Log & Report > Learning Report

Unter dieser Position stehen zwei Reports zur Verfügung:

        • Full Report
        • Report Summary

Diese Reports können über eine "schedule" automatisiert werden für "5 Minuten, 1 Stunde oder 24 Stunden.

== Session ==

=== Wie kann ich unter FortiOS 5.4 die aktiven "Sessions" auf meinem System anzeigen/auflisten lassen? ===

Wenn auf einem FortiOS alle aktiven "Sessions" die existieren in der Anzahl aufgelistet werden sollen kann nachfolgender Befehl benutzt werden:

        # get system session status
        The total number of sessions for the current VDOM: 14

Möchte man nun die einzelnen "Sessions" auflisten ohne deren Details kann nachfolgender Befehl benutzt werden:

        # get system session list
        PROTO   EXPIRE SOURCE                  SOURCE-NAT       DESTINATION            DESTINATION-NAT 
        udp     63     192.168.5.2:56751       -                192.168.1.1:53         -               
        udp     179    193.193.135.66:26730    -                193.193.135.65:53      -               
        udp     73     193.193.135.66:26967    -                193.193.135.65:53      -               
        tcp     5      192.168.1.1:3418        -                192.168.1.10:514       -               
        udp     175    193.193.135.70:5246     -                193.193.135.66:5246    -               
        udp     179    193.193.135.66:1024     -                193.193.135.65:514     -               
        udp     175    193.193.135.70:39322    -                193.193.135.66:5247    -               
        udp     179    0.0.0.0:68              -                255.255.255.255:67     -               
        udp     160    192.168.3.3:46417       -                192.168.3.1:5247       -               
        tcp     3599   192.168.5.2:49170       -                192.168.2.1:22         -               
        udp     175    192.168.3.3:5246        -                192.168.3.1:5246       -   

        '''NOTE''' Nachfolgend die Beschreibung der einzelnen Spalten:
               
             PROTO               Transportprotokoll der Session (ISO-Model Schicht 4)
             EXPIRE              Zeit bevor die Session terminiert wird
             SOURCE              Source IP Adresse und Source Portnummer
             SOURCE-NAT          Source NAT IP Adresse ein '-' steht für kein NAT.
             DESTINATION         Destination IP Adresse und Destinations Portnummer
             DESTINATION-NAT     Destination NAT IP Adresse ein '-' steht für kein NAT

Wenn auf einem "produktiven System alle aktiven "Sessions" aufgelistet werden kann diese Liste enorm lang sein. Um die Liste der "Sessions" zu filtern kann "grep" benutzt werden. Nachfolgend ein Beispiel

        # get system session list | grep [Such Pattern zB 192.168.3.1]
        udp     160    192.168.3.3:46417       -                192.168.3.1:5247       -               
        udp     175    192.168.3.3:5246        -                192.168.3.1:5246       -

        '''NOTE''' Wie der filter "grep" benutzt wird und welche Optionen dieser Befehl beinhaltet zeigt nachfolgender Artikel:
             
             [[FortiGate-5.4:FAQ#Kann_ich_unter_FortiOS_5.4_Linux.2FUnix_basierenden_Befehl_.22grep.22_auf_der_Kommandozeile_ben.C3.BCtzen.3F]]

Zu den aufgelisteten "Sessions" sowie zur "Session Table" können detailliert Informationen angezeigt und aufgelistet werden. Nachfolgend eine Uebersicht über die zur Verfügung stehenden Kommandos sowie deren Anwendung:

        # get system session-info expectation
        # get system session-info full-stat
        # get system session-info list
        # get system session-info statistics
        # get system session-info ttl
        
        Diese Kommandos zeigen folgende Informationen:
        
        '''NOTE''' Das Ausführen dieser Befehle kann auf der Console unmengenen von Daten auslösen. Speziell für Devices mit
             hoher Auslastung ist dies zu berücksichtigen.
        
             '''expectation'''         Listet/zeigt die zu erwartenden Sessions auf!
        
             '''full-stat'''           Listet detaillierte Informationen auf betreffend der Session Table sowie deren zu erwartenden Session, Errors, Statistic usw.
        
             '''statistics'''          Listet die gleichen Informationen auf wie "full-stat" jedoch ohne "session table" sowie "expected session"
        
             '''list'''                Listet detaillierte Informationen über jede Session auf wie Protokoll Nummer, Shaping Informationen, Policy usw.
        
             '''ttl'''                 Listet die Informationen auf betreffend der momentanen Konfiguration betreffend "config system session-ttl" sowie die globalen
                                 Einstellungen sowie die spezifizierten Protokoll Konfigurationen sofern diese existieren.

=== Welche Informationen werden für eine einzelne Session unter FortiOS 5.4 in der "Session" Liste aufgeführt und was bedeuten diese? ===

Wenn der nachfolgender Befehl auf einer FortiGate ausgeführt wird, werden sämtliche "Sessions" mit deren detaillierten Informationen aufgelistet:

        # diagnose sys session list

Im "output" ist jede einzelne aktive "Session" mit deren Details aufgeführt. Als Beispiel nachfolgender Output einer Session:

        session info: proto=6 proto_state=02 duration=11 expire=21 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
        origin-shaper=
        reply-shaper=
        per_ip_shaper=
        ha_id=0 policy_dir=0 tunnel=/
        state=local nds 
        statistic(bytes/packets/allow_err): org=120/2/0 reply=176/2/1 tuples=2
        orgin->sink: org out->post, reply pre->in dev=0->7/7->0 gwy=0.0.0.0/0.0.0.0
        hook=out dir=org act=noop 198.18.0.1:21164->198.18.0.90:514(0.0.0.0:0)
        hook=in dir=reply act=noop 198.18.0.90:514->198.18.0.1:21164(0.0.0.0:0)
        pos/(before,after) 0/(0,0), 0/(0,0)
        misc=0 policy_id=0 auth_info=0 chk_client_info=0 vd=0
        serial=002606e7 tos=ff/ff ips_view=0 app_list=0 app=0
        dd_type=0 dd_mode=0
        npu_state=00000000

Dabei werden unzählig Positionen mit deren detaillierten Informationen aufgeführt. Diese haben folgende Bedeutung:

        proto=6                         Gibt an um welches Protokoll es sich handelt zB 6 = TCP. Weitere Informationen zu den Protokoll Nummern siehe auch nachfolgender Artikel:
                                        
                                        [[Allgemein:Assigned-Internet-Protocol-Numbers-RFC]]

        proto_state=02                  Die erste Stelle des "proto_state" gibt an ob diese Session Client Seiting eine "proxy_based" Inspection ist dh. wenn es sich um keine "proxy_based" 
                                        Inspection handelt wird eine "0" gesetzt. Die zweite Stelle dh. in unserem Beispiel "2" gibt Server Seitig den "state" an. Die gülten "states" sind:
                                        
                                        [[Datei:Fortinet-1418.jpg]]
                                        
                                        Wenn der "proto_state" als "00" ausgegeben wird so handelt es sich um UDP. Dies bedeutet: Obwohl UDP "stateless" ist wird durch die FortiGate zwei
                                        Sessions benutzt dh. "00" one-way und "01" both-ways!
                                        
                                        [[Datei:Fortinet-1419.jpg]]

        expire=21                       Diese Positione gib an wie lange die Session noch gültig ist bis diese gelöscht wird resp. abgelaufen ist (TTL = time to live).

        origin-shaper=                  Gibt an ob ein Traffic Shaper benutzt wird. Wenn ein Traffic Shaper benutzt wird werden Informationen ausgegeben betreffend Priorität und Bandbreite.
        reply-shaper=                   Nachfolgend ein Beispiel:
        per_ip_shaper=                  
                                        origin-shaper=OutShapper prio=2 guarantee 12800Bps max 128000Bps traffic 92Bps
                                        reply-shaper=InShaper prio=4 guarantee 2560Bps max 25600Bps traffic 125Bps
                                        per_ip_shaper=PerIPShaper

        state=may dirty none app ntf    Der "state" indiziert die "session flags". Dazu nachfolgende Liste der meistgebrauchten "session flags":
                                        
                                        log        Session is being logged
                                        local      Session is to/from local stack (orgin or terminated from FortiGate)
                                        ndr        Session will be checked by IPS signature
                                        nds        Session will be checked by IPS anomaly
                                        br         Session is being bridged (TP mode)
                                        npu        Session can be offloaded to NPU
                                        wccp       Session is handled by WCCP
                                        npd        Session cannot be offloaded to NPU
                                        redir      Session is being processed by an application layer proxy
                                        authed     Session was successfully authenticated
                                        auth       Session required (or required) authentication
                                        
                                        Grundsätzlich wird jedes "erste" Packet über die Firewall Policy kontrolliert. Wenn dieses Packet erlaubt wird über die Firewall Policy wird eine "session"
                                        erstellt und bezeichnet (flag) als "may_dirty". Wenn eine Aenderung in der Firewall Policy durchgeführt wird so werden "alle" existierenden "sessions" von
                                        "may_dirty" auf "diry" gesetzt. Dadurch werden sämtliche Packet ab diesem Zeitpunkt nicht mehr über den NPU gesendet sondern zum CPU. Der CPU kontrolliert
                                        abermals das Packet in der Firewall Policy und wenn dieses erlaubt wird, werden diese "sessions" auf "may_dirty" gesetzt. Wenn dieses Packet in der Firewall
                                        Policy nicht erlaubt wird werden diese Packet verworfen und mit einem "flag" "block" versehen. Danach verbleibt die "session" im Memory bis diese den TTL
                                        resp. "expire" erreicht. So kann die FortiGate über die "flags" "dirty"und/oder "may_dirty" erkenne/evaluieren nach einer Modifikation der Firewall Policy 
                                        ob diese weiterhin erlaubt werden (may_dirty) resp. die entsprechende "session" geblockt werden (block).

        policy_id=0                     Gibt an welche Firewall Policy-ID benutzt wurde. Die Firewall Policy-ID 0 indiziert eine "Local-In Policy".

        statistic                       Steht für den Packet Counter der auch über die Firewall Policy der FortiGate ersichtlich ist

        hook=out dir=org                Gibt an wie die Packete für "out" und "in" verarbeiet werden dh. wenn NAT (Network Address Translation) benutzt wird so werden die Positionen "act=snat" 
        hook=in dir=reply               sowie "act=dnat" aufgeführt. Aus den nachfolgenden Informationen kann eruiert werden wie NAT durchgeführt wurde. Nachfolgend ein Beispiel mit NAT:
                                        
                                        hook=post dir=org act=snat 100.1.10:50194 -> 216.58.216.110:80(10.200.1.1:50194)
                                        hook=pre dir=reply act=dnat 216.58.216.110:80 -> 10.200.1.1:50194(10.0.1.10:50194)

        npu_state=00000000              Zeigt ob eine Session über "hardware acceleration" beschleunigt wurde. Wenn dies der Fall ist resp. möglich wäre wird "npu info:" aufgeführt mit den 
                                        entsprechenden "counters" für die "hardware acceleration" aus denen man entnehmen kann ob die Session über die Hardware Beschleunigung abgearbeitet wurde.
                                        Nachfolgend ein Beispiel:
                                        
                                        npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0/0

        no_ofld_reason                  Zeigt den Grund wieso eine Session nicht über "hardware acceleration" beschleunigt wird! Nachfolgend ein Beispiel:
                                        
                                        no_ofld_reason: redir-to-av redir-to-ips non-npu-intf

        user=                           Wenn eine Session erstellt wird für eine Verbindung im Zusammenhang mit Authentifizierung wird der "user=" sowie die Gruppenzugehörigkeit "group=" sowie
        group=                          das "authed" Flag gesetzt.
        authed

=== Wie kann ich unter FortiOS 5.4 herausfinden ob eine Session über den NP Prozessor beschleunigt wird (Offloading)? ===

Um für die einzelnen "Sessions" herauszufinden ob eine "Session" über den NP Prozessor beschleunigt wird, kann dies im Mgmt. Web Interface aktiviert werden. Dazu muss folgendes gewählt werden:

        FortiView > All Sessions > [Rechtsklick auf eine Spalte zB "Source"] > [Wähle im "Dropdownmenu" FortiASIC] > [Bestätige mit "Apply"]

        [[Datei:Fortinet-1634.jpg]]
         
Um auf der CLI die detaillierten Informationen einer einzelnen "Sessions" aufzulisten sowie mit deren Informationen herauszufinden ob "Sessions" beschleunigt werden benutze folgender Befehl:

        # diagnose sys session list

Unter FortiOS 5.4 wird für eine "Session" wenn diese nicht beschleunigt wird neu der Grund innerhalb "no_ofld" aufgelistet dh. in der "Session" erscheint folgendes:

        no_ofld_reason: redir-to-av redir-to-ips non-npu-intf
        no_ofld_reason: local.
        
        '''NOTE''' Die Information zB "redir-to-av" indiziert unter "no_ofld_reason" das die Beschleunigung nicht durchgeführt werden konnte
             da für den Traffic ein "redirect" (redir-*) durchgeführt wurde. Für dieses Beispiel zur "Antivirus Engine"!

Ebenfalls indiziert die nachfolgende Position keine Beschleunigung und deckt sich mit "no_ofld":

        npu_state=00000000

Wenn eine Session Accelerated wird oder die Möglichkeit dazu besteht wird folgendes ausgegeben:

        npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0/0

Was die einzelnen Positionen in einer Session idizieren resp. bedeuten kann im folgenden Artikel nachgelesen werden:

        [[FortiGate-5.4:FAQ#Welche_Informationen_werden_f.C3.BCr_eine_einzelne_Session_unter_FortiOS_5.4_in_der_.22Session.22_Liste_aufgef.C3.BChrt_und_was_bedeuten_diese.3F]]

Wenn man jedoch auf einem Device arbeitet mit vielen "Sessions" sollte anhand eines gesetzten Filters für "Sessions" gearbeitet werden dh. zB alle "Sessions" für eine bestimmte Policy-ID, Source-IP usw. Dazu kann die Filter Funktion benutzt werden. Die zur Verfügung stehenden Filter sind:

        # diagnose sys session filter
        vd             Index of virtual domain. -1 matches all.
        sintf          Source interface.
        dintf          Destination interface.
        src            Source IP address.
        nsrc           NAT'd source ip address
        dst            Destination IP address.
        proto          Protocol number.
        sport          Source port.
        nport          NAT'd source port
        dport          Destination port.
        policy         Policy ID.
        expire         expire
        duration       duration
        proto-state    Protocol state.
        clear          Clear session filter.
        negate         Inverse filter.

Zum Beispiel um einen bestimmten Port oder eine Destination Adresse zu Filtern  müssen folgende Befehle verwendet werden:

        # diagnose sys session filter dport [Port]
        # diagnose sys session filter dst [Destination IPv4 Adresse]

Den Filter kann mit folgendem Befehl überprüft werden:

        # diagnose sys session filter
        session filter:
                vd: any
                proto: any
                proto-state: any
                source ip: any
                NAT'd source ip: any
                dest ip: '''[Destination IPv4 Adresse]'''
                source port: any
                NAT'd source port: any
                dest port: '''[Port]'''
                policy id: any
                expire: any
                duration: any

Der Filter ist jetzt gesetzt kann nun benutzt werden, um die betreffende "Session/s" aufzulisten:

        # diagnose sys session list

Den "Session" Filter kann mit folgendem Befehl gelöscht oder zurückgesetzt werden:

        # diagnose sys session filter clear
        
        '''NOTE''' Wird dieser Befehl "ohne" Filter ausgeführt so werden sämtliche Sessions gelöscht. Aus diesem Grund ist dieser Befehl
             mit Vorsicht auszuführen! Dies bedeutet ebenfalls: Wenn bestimmte "sessions" gelöscht werden sollen müssen diese 
             vorgängig mit einem entsprechenden Filter gesetzt werden. Dieser Filter kann nachträglich mit "diagnose sys session 
             filter" kontrolliert werden! Wenn nachträglich "diagnose sys session clear" ausgeführt wird, werden sämgliche "sessions" 
             gemäss dem gesetzten Filter für "diagnose sys session filter" gelöscht! 

Danach kann wiederum kontrolliert werden ob dies durchgeführt wurde:

        # diagnose sys session filter

Zusätzlich wenn der FortiGate Device über einen NP6 Prozessor verfügt über CLI überprüft werden welche Sessions dem NP6 Prozessor übergeben werden. Um die ID des NP6 zu verifizieren kann auf CLI unter FortiOS 5.4 folgendes benutzt werden:

        # get hardware npu np6 [dce | ipsec-stats | port-list | session-stats | sse-stats]

Die verschiedenen Optionen haben folgende Bedeutung:

        dce NP6        - non-zero subengine drop counters.
        ipsec-stats    - NP6 IPsec offloading statistics.
        port-list      - NP6 port list.
        session-stats  - NP6 session offloading statistics counters.
        sse-stats      - show hardware session statistics counters

Danach kann anhand der ID des NP6 eine entsprechende Abfrage durchgeführt werden zB:

        # diagnose npu np6 sse-stats [ID des NP6 zB "0"]
        Counters        SSE0            SSE1            Total
        --------------- --------------- --------------- ---------------
        active          35189           34937           '''70126'''
        insert-total    134611036       134624481       269235517
        insert-success  134611036       134624481       269235517
        delete-total    134575847       134589544       269165391
        delete-success  134575847       134589544       269165391
        purge-total     0               0               0
        purge-success   0               0               0
        search-total    3799074893      3871207649      3375315246
        search-hit      3580496168      3652493853      2938022725
        --------------- --------------- --------------- ---------------
        pht-size        8421376         8421376
        oft-size        8355840         8355840
        oftfree         8355763         8355758
        PBA             3001

        # diagnose npu np6 sse-stats [ID des NP6 zB "1"]
        Counters        SSE0            SSE1            Total
        --------------- --------------- --------------- ---------------
        active          37977           37861           '''75838'''
        insert-total    134842807       134847764       269690571
        insert-success  134842807       134847764       269690571
        delete-total    134804830       134809903       269614733
        delete-success  134804830       134809903       269614733
        purge-total     0               0               0
        purge-success   0               0               0
        search-total    3890365012      4023832938      3619230654
        search-hit      3670809994      3804413458      3180256156
        --------------- --------------- --------------- ---------------
        pht-size        8421376         8421376
        oft-size        8355840         8355840
        oftfree         8355749         8355755
        PBA             2983

Der "output" zeigt die Anzahl der "half" Sessions für einen definierten NP6. Eine typische Sessions basiert auf zwei "half" Sessions dh. "ingress" und "egress". Das hier gezeigte Beispiel zeigt 70126 "half" Sessions auf "NP6_0" sowie 75838 "half" Session auf "NP6_1"! Unter FortiOS 5.4 ist es möglich für eine Firewall Policy Rule ein "accounting" zu aktiveren resp. zu deaktivieren. Per Standard ist das "accounting" aktiviert (enable-by-log) sofern das "logging" für die entsprechende Firewall Policy Rule aktiviert wurde:

        # config system np6
        # edit np6_0
        # set per-session-accounting [disable | all-enable | enable-by-log]
        # end

Wenn das "logging" auf einer Firewall Policy Rule keinen Einfluss haben soll auf die "accounting" Funktion kann die Option "all-enable" gesetzt werden!

=== Was bedeutet "Offloading" Sessions" unter FortiOS 5.4 und wie funktioniert die Funktion "Offloading"? ===

FortiGate’s und auch andere Hersteller Typen benutzen für die Acceleration ein "offloading". Offloading bedeutet: Wenn ein neues Paket/Session gesendet wird so wird dieses als "diry" gekennzeichnet und somit über den CPU abgearbeitet. Wenn weitere Pakete folgen dh. mit gleicher Source, Destination usw. wird dies durch das "offloading" erkannt und das Paket/Session wird als "may dirty" gekennzeichnet. Dadurch wird für diese Pakete/Sessions ein "offloading" durchgeführt dh. es wird nicht mehr über den CPU abgearbeitet sondern durch das "offloading" (NP). Wenn sich an der Firewall Policy oder an der Konfiguration etwas ändert wird daS Paket abermals als "dirty" gekennzeichnet und somit wird eine Verarbeitung über CPU erzwungen (kein offloading) usw. Nachfolgende Grafik visualisiert diesen Paket Flow dirty / may dirty):

        [[Datei:Fortinet-1633.jpg]]

Der zuständige ASIC-Prozessor für dieses „Offloading“ ist der NP Prozessor zB. bei der FG-60D/90D ist ein "NP4Lite" Prozessor im Einsatz. Weitere Informationen darüber welcher Device über welchen Prozessor, Memory sowie NP verfügt siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wo_finde_ich_eine_Uebersicht_welcher_FortiGate_Device_zB_.C3.BCber_wieviel_.22Memory.22_verf.C3.BCgt.2C_ein_.22SOC.22_und.2Foder_.22NP.22_verbaut_ist.3F]]

Ein "offloading" auf einer FortiGate muss nicht aktiviert werden sondern ist in jeder Firewall Policy Rule per Standard aktiviert durch folgende Konfiguration:

        # config firewall policy
        # edit [Policy ID Nummer]
        # set auto-asic-offload [enable / disable]
        # end
        
        '''NOTE''' Es muss berücksichtig werden, dass bei einem Troubleshooting nicht mehr alle Pakete/Sessions in einem 
             "Paket Sniffer" (diagnose sniffer Paket) angezeigt werden. Der Grund ist der folgende: Solange die
             Paket als "dirty" gekennzeichnet" werden werden diese über den CPU abgearbeitet und sind im "kernel"
             über den "Paket Sniffer" ersichtlich. Werden die Paket als "may dirty" gekennzeichnet dh. es wird ein
             "offloading" durchgeführt werden die Paket direkt zum NP gesendet dh. nicht mehr über den Kernel und
             somit sind die Paket für den "Paket Sniffer" nicht mehr ersichtlich.

Ebenso ist betreffend UTM Features folgendes zu berücksichtigen: Wenn für eine Firewall Policy Rule ein Security Profile konfiguriert wird dh. zB. "Antivirus" so wird kein "offloading" mehr durchgeführt, da das Paket/Session durch den "CP" (Content Prozessor) abgearbeitet werden muss und somit kann das Paket nicht den direkten Weg über den "NP" Prozessor wählen. Somit anstelle die Option "auto-asic-offload" für eine Firewall Policy Rule zu deaktiveren um "offload" zu deaktivieren, kann das gleiche erreicht werden in dem vorübergehend für die entsprechende Firewall Policy ein Security Profile aktiviert wird. Somit muss festgestellt werden: Ist für eine Firewall Policy Rule ein UTM Features aktiviert wird kein "offloading" mehr durchgeführt!

=== Wie beeinflusst unter FortiOS 5.4 die Option "check-protocol-header" eine Session sowie das "Offloading"? ===

Unter "system global" existiert eine Option "check-protocol-header". Diese Option ist zuständig wie die "protocol headers" innerhalb des "TCP Headers" untersucht werden. Die Option kann folgendermassen gesetzt werden:

        # config system global
        # set check-protocol-header [loose | strict]
        # end
        
Die zwei zur Verfügung stehenden Optionen haben folgende Bedeutung:

        • loose — Das FortiOS untersucht im "basic" Verfahren die "protocol headers" in dem das FortiOS überprüft ob der 
                  "TCP Header" Teil einer Session ist. Ebenso umfasst die "basic" Ueberprüfung die Länge des Layer 4 "TCP 
                  Headers", des "IP Headers", die "IP Version", die "IP Checksu"m sowie ob die "IP Optionen" korrekt 
                  gesetzt sind.

        • strict — Das FortiOS führt sämtliche "basic" Verfahren durch plus ob die ESP Packete über die korrekte Sequenz 
                   Nummer verfügen sowie SPI und Datalänge.

Per Standard ist die Option auf "loose" gesetzt und und somit beeinflusst "loose" das "Offloading" nicht. Wird die Option auf "strict" gesetzt wird das "Offloading" resp. die "Beschleunigung" (Acceleration) komplett deaktiviert da die zusätzlichen ESP Packete sowie SPI und Datenlänge untersucht werden. Wenn die Option "strict" gesetzt wird erscheint aus diesem Grund ein entsprechender Hinweis.

        # config system global
        # set check-protocol-header strict
        # end
        Warning: This setting may break compatibility with some vendors and applications, cause loss of existing
        sessions,reduce overall system performance, drop ESP traffic from VPN tunnels terminated at this unit,
        and disable all hardware acceleration!
        Do you want to continue? (y/n)

Somit sollte "strict" nur dann benutzt werden wenn die zusätzlichen Verfahren wie ESP Sequenz Nummer, SPI und Datenlänge aus Security technigschen Gründen verifiziert werden müssen.

== Inspection Mode ==

=== Was hat sich unter FortiOS 5.4 betreffend "Security Profiles" und "Inspection Mode" grundsätzlich geändert? ===

Für FortiOS 5.2 und tiefer wurde der "Inspection Mode" dh. "proxy mode" und/oder "flow mode" über die "Security Profiles" gesteuert. Dies bedeutet: Es gab keine "Globale" Einstellung um den Mode eben "proxy" und/oder "flow" Mode zu bestimmen. Dies ist nun möglich dh. der "Inspecton Mode" kann nun "Global" konfiguriert werden und gilt als Konfiguration für sätmliche bestehenden und neu erstellten "Security Profiles". Die Konfiguration wird unter Mgmt. Web Interface über folgender Position konfiguriert:

        [[Datei:Fortinet-1620.jpg]]

        [[Datei:Fortinet-1621.jpg]]

Wie man sieht wird bei dieser Konfiguration ein Hinweis eingeblendet dh. "Warning" um darauf hinzuweisen, dass dieser Wechsel des "Inpsection Mode" zur Folge hat, dass entsprechende "Security Profiles" umgeschrieben werden. Dieser Hinweis dh. die "Warning" wird nur über Mgmt. Web Interface angzeigt dh. wird die Konfiguration mit nachfolgenden Kommando über CLI durchgeführt, wird kein entsprechender Hinweis gezeigt:

        # config system settings
        # set inspection-mode [proxy | flow]
        # end

Somit steht neu der "Inspection Mode" für jede VDOM im "vdom" Mode individuell zur Verfügung und kann seperat konfiguriert werden da die Option unter "config system settings" verfügbar ist dh. keine "Globale" Konfiguration sondern für jede VDOM konfigurierbar:

        # config vdom
        # edit [VDOM Name zB "root"]
        # config system settings
        # set inspection-mode [proxy | flow]
        # end

Wenn der "Inspection Mode" geändert wird dh. von "proxy mode" auf "flow mode" oder umgekehrt so führt das FortiOS 5.4 im Hintergrund folgende Modifikationen automatisch durch:

        -> Für jedes "Antivirus" Profile wird das Kommando "set inspection-mode [proxy | flow]" durchgeführt.
           
        -> Für jedes "WebFilter" Profile wird das Kommando "set inspection-mode [proxy | flow]" durchgeführt.
                     
        -> Wenn Global unter "config system settings" von "proxy mode" auf "flow mode" umkonfiguriert wird so 
           wird für jede "Firewall Policy Rule" für die ein "Security Profile" im "proxy mode" existiert dieses
           entfernt! 
           
           '''NOTE''' Wenn die "proxy mode" Security Profiles in den Firewall Policy Rules entfernt werden wie beschrieben so ist diese
                Konfiguration nicht mehr Rückgängig zu machen dh. es ist umbedingt empfohlen vorgängig ein Backup der Konfiguration
                durchzuführen. Ebenso empfiehlt es sich über Mgmt. Console den folgenden "debug" für die CLI zu aktivieren um so zu 
                sehen was genau bei der Aenderung durchgeführt wird:
                
                # diagnose debug cli -1 

Desweiteren ist ebenfalls zu berücksichtigen "was" mit den Security Profiles "Antivirus" sowie "WebFilter" durchgeführt wird, wenn der "Inspection Mode" geändert wird. Nachfolgende Tabelle zeigt au welche Unterschiede in den verschiedenen "Inspection Mode" für "Antivirus" sowie "WebFilter" Security Profiles existieren:

        [[Datei:Fortinet-1622.jpg]]

        [[Datei:Fortinet-1623.jpg]]
        [[Datei:Fortinet-1624.jpg]]

Nichts desto trotz und obwohl die Konfiguration unter "config system settings" konfiguriert wird, steht in den "Security Profiles" die "proxy mode" und "flow mode" unterstützten die Option per Standard bei Folgenden "Security Profiles" zur Verfügung um individuell eine Konfiguration durchzuführen:

        # config [webfilter | antivirus] profile
        # edit [Name des Profiles]
        # set inspection-mode [proxy | flow]
        # end

Somit fragt man sich, ob diese "Security Profiles" dh. "WebFilter" und/oder "Antivirus" die einzigen die individuell konfiguriert werden können da andere "Security Profiles" ebenfalls im "proxy mode" und/oder "flow mode" unterstüzen. Nachfolgende Tabelle zeigt auf welche "Security Profiles" welchen "Inspection Mode" unterstützen:

        [[Datei:Fortinet-1625.jpg]]

Somit kann auch ein "DLP" sowie ein "Spamfilter" auf "flow mode" konfiguriert werden jedoch sind diese per Standard im "proxy mode" und werden bei Aenderung des "Globalen" Mode unter "config system settings" nicht in "flow mode" unkonvertiert und verbleiben somit im "proxy mode":

        # config dlp sensor
        # edit [Name des Profiles]
        # set flow-based [enable | disable]
        # end

        # config spamfilter profile
        # edit [Name des Profiles]
        # set flow-based [enable | disable]
        # end

Wenn der "Inspection Mode" für verschiedenen "Security Profiles" individuell konfiguriert wird ist zu berücksichtigen, was durchgeführt wird in einer "Firewall Policy Rule" wenn beide "Inspection Mode" benützt werden dh. "proxy mode" und/oder "flow mode". Weitere Informationen dazu siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wenn_ich_f.C3.BCr_eine_.22Firewall_Policy_Rule.22_unter_FortiOS_5.4_verschiedenen_.22Inspection_Mode.22_ben.C3.BCtze_.28flow.2Fproxy.29_was_gilt.3F]]

=== Wird unter FortiOS 5.4 betreffend "deep-inspection" für Transparent/Explizit Proxy die TLS 1.2 Verschlüsselung unterstützt? ===

TLS 1.2 wird grundsätzlich im Zusammenhang mit "deep-inspection" für Explizit/Transparent Proxy auf einer FortiGate ab FortiOS 5.2.1 unterstützt! Für SSL Offloading und andere Proxy Features wird jedoch TLS 1.2 nicht unterstützt. Ab FortiOS 5.4 wird TLS 1.2 in folgenden Funktionen unterstützt:

        • Transparent proxy-based SSL deep-inspection
        • Explicit-proxy-based SSL deep-inspection
        • SSL offload (LoadBalancer VIP)
        • Wan Opt SSL tunnels
        • SIP over SSL/TLS

== Radius ==

=== Wie konfiguriere ich auf einer FortiGate unter FortiOS 5.4 eine "Radius" Authentifizierung? ===

Eine Radius Authentifizierung kann in verschiedenen Services für eine Authentifizierung genützt werden. Dabei kann ein lokaler User als Radius Authentifizierung konfiguriert werden oder eine Gruppe. Ausgangslage für die Authentifizierung ist die Konfiguration der Radius Anbindung. Diese kann über CLI oder über Mgmt. Web Interface durchgeführt werden:

        User & Device > RADIUS Servers > Create New

        [[Datei:Fortinet-2031.jpg]]

Wenn man die Radius Server Konfiguration über CLI durchführen möchte so kann folgendes konfiguriert werden:

        # config user radius
        # edit [Name des Radius Servers]
        # set server [IPv4 Adresse des Radius Servers]
        # set secret [Shared Secret des Radius Servers]
        # set secondary-server [IPv4 Adresse des Secondary Radius Servers]
        # set secondary-secret [Shared Secret des Secondary Radius Servers]
        # set tertiary-server [IPv4 Adresse des Tertiary Radius Servers]
        # set tertiary-secret [Shared Secret des Tertiary Radius Servers]
        # set timout [Definition des Timouts für den Radius Server 0 - 300 Sekunden; Standard 5]
        # set all-usergroup [disable | enable]
        # set use-management-vdom [enable | disable}
        # set nas-ip [IPv4 Adress der NAS IP oder Station ID; Standard 0.0.0.0]
        # set acct-interim-interval [Accounting Interval 600 - 86400 Sekunden; Standard 0]
        # set radius-coa [disable | enable]
        # set radius-port [Radius Port; Standard 0]
        # set h3c-compatibility [disable | enable]
        # set auth-type [auto | ms_chap_v2 | ms_chap | chap | pap]
        # set source-ip [Source IPv4 Adresse der Radius Anfrage]
        # set username-case-sensitive [disable | enable]
        # set password-renewal [disable | enable]
        # config accounting-server
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set status [disable | enable]
        # set server [IPv4 Adresse für den Accounting Server]
        # set secret [Shared Secret des Accounting Servers]
        # set port [Accounting Port]
        # set source-ip [Source IPv4 Adresse der Accounting Anfrage]
        # end
        # end

Der Standard Port für alle Radius Server wird unter "system global" konfiguriert und ist per Standard auf 1812 konfiguriert, kann jedoch für jeden einzelnen Radius Server konfiguriert werden anhand "radius-port"! Wenn mehrere Radius Server dh. zB secondary-server definiert werden so werden diese nur benutzt wenn der primary nicht erreichbar ist. Wenn der Radius Server korrekt konfiguriert wurde können lokale User basierend auf Radius oder ein lokale Gruppe basierend auf Radius konfiguriert werden, die in den verschiedenen Services für eine Authentifizierung benutzt werden können:

        User & Device > User Definition > Create New

        [[Datei:Fortinet-2032.jpg]]

        [[Datei:Fortinet-2033.jpg]]

        [[Datei:Fortinet-2034.jpg]]

Die Definition einer Email Adresse sowie Two-Factor Authentication ist Optional. Dieser lokal erfasste User kann nun zu einer lokalen Gruppen hinzugefügt werden sowie der lokale User und/oder Gruope zu den verschiedenen Service für eine Authentifizierung genutzt werden. Eine Gruppe basierend auf Radius Authentifizierung kann folgendermassen konfiguriert werden:

        User & Device > User Groups > Create New

        [[Datei:Fortinet-2035.jpg]]

        [[Datei:Fortinet-2036.jpg]]

Diese lokale Gruppe kann nun in den verchiedenen Services für eine Authentifizierung genutzt werden. Wenn in einer lokalen Gruppe ein Radius Server hinzugefügt wird, dürfen in dieser Gruppe keine lokalen User hinzugefügt werden für die eine Radius Server Konfiguration durchgeführt wurde.

=== Wie kann ich auf einer FortiGate unter FortiOS 5.4 für eine "Radius" Konfiguration ein Troubleshooting durchführen? ===

Wenn man eine Radius Server Anbindung unter FortiOS 5.4 konfiguriert so wird auf der FortiGate ein Radius Server Anbindung konfiguriert mit der IPv4 Adresse oder FQDN des Radius Servers. Die Authentifizierung der Radius Server Anbindung auf der FortiGate zum Radius Server wird über ein definiertes "Preshared Key" konfiguriert. Ebenso muss der FortiGate Device anhand dess IPv4 Adresse oder FQDN Name der IPv4 Adresse der FortiGate auf dem Radius Server als "Radius Client" konfiguriert werden. Anhand dieser Konfiguration sowie des "Preshared Key" wird der Traffic über TCP 1812 (New Radius) sowie das Accounting TCP 1813 verschlüsselt und Authorisiert. Um die Komunikation zwischen dem Radius Client und Radius Server zu überprüfen stehen verschiedenen Kommandos zur Verfügung. Um die Radius Anbindung auf dem FortiGate Device über CLI anhand eines Users zu testen kann folgendes ausgeführt werden:

        # diagnose test authserver radius [Server Name] [Schema] [Gebe einen entsprechenden User an] [Gebe das Passwort an des gewählten Users]

ls "Schema" kann folgendes definiert werden:

        chap, pap, mschap, mschap2

Wird kein spezifisches "Schema" definiert benutzt das "diagnose test" Kommando "auto". Um den Traffic über TCP Port 1812 anhand des Sniffers aufzuzeichnen kann folgendes Kommando benutzt werden:

        # diagnose sniffer packet [Name des Interfaces zB "internal"] 'port 1812' 3

Muss der Radius Port von New Radius 1812 auf Old Radius 1645 konfiguriert werden, kann dies Global für alle definierten Radius Server unter "system global" durchgeführt werden oder in der Radius Server Konfiguration selber:

        # config system global
        # set radius-port [Definiere den entsprechenden TCP Port; Standard 1812]
        # end

        # config user radius
        # edit [Name des Radius Servers]
        # set radius-port [Radius Port; Standard 0]
        # end

Der Traffic der Radius Anbindung kann ebenfalls über Debug aufgezeichnet und Analysiert werden. Dabei ist zu berücksichtigen, dass es zwei unterschiedliche Deamons/Service zur Verfügung stehen im Zusammenhang mit Debug:

        • authd (Deamon für alle lokalen sowie remote Authentifizierungen inkl. FSSO)
        • fnbamd (Fortigate non-blocking auth deamon)

Bei diesem Debug Vorgang wird relativ viel "output" erzeugt in einer Session. Deshalb ist es wichtig den "output" über eine SSH Verbindung durchzuführen sowie den "output" in ein Log File zu schreiben, damit dieser "output" später für eine Analyse zur Verfügung steht. Für ein "debug" führe folgendes auf der CLI aus: 

        1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
        2. Erstelle eine Consolen Verbindung zur FortiGate per SSH
        3. Führe ein Login durch und gebe folgendes ein:

        '''Setze alle Debug Filter zurück'''
        
        # diagnose debug reset

        '''Setze einen Debug Filter für "fnbamd" und/oder "authd"'''
        
        # diagnose debug application fnbamd –1
        # diagnose debug application authd –1

        '''Aktiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp enable

        '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug enable 

In diesem Beispiel werden beide Filter dh. für "fnbamd" sowie "authd" aktiviert. Für eine detailliert Analyse kann es empfehlenswert sein nur die einzelnen Filter zu setzen. Nach der Konfiguration des Filter sowie Aktivierung des Debug kann eine entsprechende Abfrage resp. Authentifizierung basierend auf Radius durchgeführt werden und der "output" gemäss gesetzten Filter "fnbamd" und/oder "authd" wird erstellt. Nach erfolgten "debug" sollte die "debug" Funktion deaktiviert und der gesetzte Filter zurück gesetzt werden:

        '''Deaktiviere die Debug Funktion'''
        
        # diagnose debug disable

        '''Dektiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp disable

        '''Setze den Debug Filter zurück'''
        
        # diagnose debug reset

== Active Directory / LDAP ==

=== Wie konfiguriere ich auf einer FortiGate unter FortiOS 5.4 ein "Active Directory/LDAP" Authentifizierung? ===

Wenn unter FortiOS 5.4 ein "ActiveDirectory" konfiguriert werden möchte, kann dies über das Mgmt. Web Interface durchgeführt werden oder CLI. Wenn zB ein LDAP wie "OpenLDAP" konfiguriert werden muss, kann dies zwar über Mgmt. Web Interface durchgeführt werden, jedoch ist dabei zu berücksichtigen, dass unter CLI die entsprechenden Optionen wie zB "group-member-check" sowie "member-attr" korrekt für den "OpenLDAP" gesetzt werden müssen. Um ein Windows basierendes "ActiveDirectory" über Web Mgmt. Interface zu konfigurieren gehe folgendermassen vor:

        User & Device > LDAP Servers > Create New

        [[Datei:Fortinet-1671.jpg]]

        [[Datei:Fortinet-1672.jpg]]

Nachfolgend für die einzelnen Positionen eine Beschreibung was zu konfigurieren ist:

        '''Name:'''
        
        Für diese Position muss ein Name für den entsprechenden LDAP Server vergeben werden. Dieser Name steht nicht im Zusammenhang
        mit dem LDAP Server und kann frei gewählt werden. Wir empfehlen hier den Host Namen des LDAP Servers zu konfiguriren!

        '''Server IP/Name:'''
        
        Unter dieser Position muss entweder die IPv4 Adresse oder der FQDN des LDAP Servers konfiguriert werden. Wenn der FQDN Name
        des LDAP Servers konfiguriert wird, muss dem FortiOS ermöglicht werden über die konfigurierten "System DNS Server" diesen FQDN
        Name des LDAP Servers aufzulösen. Um keine Abhängigkeiten zu einem DNS Server zu schaffen empfehlen wir die IPv4 Adresse des 
        LDAP Servers zu konfigurieren! Wenn dennoch ein FQDN des LDAP Servers konfiguriert wird kann die DNS Auflösung über CLI auf
        dem FortiOS kurz getestet werden:
        
        # execute ping [IPv4 Adresse des LDAP Servers]
        
        Desweiteren stehen auf CLI weitere "Server IP/Name" für Secondary und Tertiary Server Konfiguration zur Verfügung. Werden diese
        konfiguriert werden diese Fallback Server nur dann genutzt, wenn der Primary LDAP Server nicht zur Verfügung steht resp. der
        Secondary Server:
        
        # config user ldap
        # edit [Name des LDAP Servers]
        # set server [IPv4 Adresse des LDAP Servers]
        # set secondary-server [Secondary IPv4 Adresse des LDAP Servers]
        # set tertiary-server [Tertiary IPv4 Adresse des LDAP Servers]
        # end

        '''Server Port:'''
        
        Per Standard ist für diese Position der Standard Port eines LDAP Servers konfiguriert dh. Port "389". Durch diesen per Standard
        gesetzten Port wird die Komunikation zwischen dem FortiOS und dem LdAP Servers unverschlüsselt durchgeführt. Möchte man für eine
        sichere Komunikation eine Verschlüsselung konfgurieren, muss die Position "Secure Connection" aktiviert werden. Wird diese Position
        aktiviert, so kann für die Verschlüsselung zwischen "LDAPS" und "STARTTLS" gewählt werden. Der LDAP Port wird bei einer "Secure
        Connection" per Standard auf "636" gesetzt. Bei beiden verschlüsselungs Varianten muss ein entsprechendes Zertifikat definiert
        werden dh. das entsprechende Zertifikat basierend auf dem Active Directory/LDAP muss auf dem FortiOS eingespielt werden und nach 
        dem Import auf dem FortiOS unter "Certificate" ausgewählt werden! Per Standard wird unter einem Active Directory/LDAP Konfiguration
        "LDAPS" benutzt.

        '''Common Name Identifiert:'''
        
        Unter dieser Position wird definiert wie der User im Active Directory/LDAP gesucht wird. Per Standard wird für diese Position als
        Common Name Identifier "cn" gesetzt kann jedoch für ein Active Directory/LDAP ebenfalls auf "sAMAccountName" gesetzt werden. Dabei
        ist folgendes zu beachten:
        
        • cn                = Anhand "cn" wird das Active Directory/LDAP mit dem "vollständigen Namen" des Users im Active Directory/LDAP
                              gesucht. Dies bedeutet: Der User muss als Login Usernamen den "Vollständigen Namen" benutzen anstelle des 
                              Active Directory/LDAP Usernamens sprich "sAMAccountName"!
        
        • sAMAccountName    = Anhand des "sAMAccountName" wird das Active Directory/LDAP anhand des Usersname der im Active Directory/LdAP
                              für den User definiert wurde durchsucht, anstelle des "vollständigen Namens" wie unter "cn" beschrieben!

        '''Distinguished Name:'''
        
        Der "Distinguished Name" eines Active Directory/LDAP Servers definiert die "domainComponent" eine Organization. Dies bedeutet: 
        Dieser  Name identifiziert das Objekt innerhalb der Hierarchie des Verzeichnisses, und zwar von der untersten Ebene (dem Objekt 
        selbst) durch alle Container hindurch bis zum Ursprung des Verzeichnisses, was bei Active Directory/LDAP die Domäne ist. Und 
        genau dies Active Directory Domaine muss hier definiert werden. Ausgehend davon, dass ein entsprechender Name sowie IPv4 oder 
        FQDN Name für das Active Directory/LDAP vergeben wurde, kann anhand "Fetch DN" der "Distinguished Name" vom Active Directory/LDAP 
        abgefragt werden sofern ein "Simple" und/oder "Anonymous" Bind Type zum Active Directory/LDAP erlaubt wird. Ist als "Bind Type" 
        Regular gesetzt muss ein für die "Regular" Bind Type Verbindung ein entsprechender Administrator mit dessen Passwort definiert 
        werden. Was dabei zu berücksichtigen ist siehe nachfolgend der Abschnitt "Bind Type". Ein "Distinguised Name" sieht per Standard 
        für ein Active Directory/LDAP folgendermassen aus:
        
        dc=mydomain,dc=ch
        
        Besitzt ein Active Directory/LDAP mehrer Organisationen dh. "Organization unit" (ou) und der "Distinguished Name" soll für eine bestimmte
        Organisation konfiguriert werden sieht ein "Distinguised Name" folgendermassen aus:
        
        ou=Oranization,dc=mydomain,dc=ch

        '''Bind Type:'''
        
        Unter der Position "Bind Type" wird definiert wie die Verbindung zum Active Directory/LDAP Server durchgeführt werden soll. Bei 
        "Simple" und "Anonymous" muss kein "User DN" mit einem entsprechenden "Password" definiert werden. Unter "Regular" muss dieser 
        "User DN" sowie dessen "Password" definiert werden. Wir empfehlen per Standard "Regular" zu benutzen und "Simple" sowie "Anonymous" 
        Bind auf dem Active Directory nicht zu erlauben. Damit ein "Regular" Bind Type durchgeführt werden kann, benötigt man einen Active 
        Directory/LDAP Administrator "User DN" mit dessen "Password". Dieser Administrator resp. "User DN" sollte im Active Directory/LDAP 
        über volle Rechte für "read-only" verfügen. Es sollte sich dabei nicht um den Standard "Administrator" des Active Directory/LDAP 
        handeln sondern explizit für diese Anbdindung konfiguriert werden. Wenn nach der Konfiguration des Administrators auf dem Active 
        Directory/LDAP der "User DN" verifiziert werden muss, kann auf dem Active Directory/LDAP in einer DOS Box folgendes durchgeführt 
        werden, um den "User DN" zu verifizieren. Dabei muss berücksichtigt werden, dass die DOS Box die auf dem Active Directory/LDAP 
        anhand "cmd" geöffnet wird, als "Administrator" geöffnet wird ansonsten können nachfolgende Kommandos nicht durchgeführt werden 
        und es kommt zu Fehlermeldungen:
        
        Um "Regular Bind" zu konfiguriren sind 3 Grundsätzliche Informationen unerlässlich:
        
        • Administrator Username und dessen Passwort
        
        • User DN  (User DN des Administrators)
        • Bind DN  (Distiguished Name des Administrators)
        
        '''User DN'''
        
        > dsquery user -name [Name des Adminstrators]
        cn=Adminstrator,cn=users,dc=mydomain,dc=ch
        
        '''Bind DN'''
        
        > dsquery user -samid Administrator
        cn=Adminstrator,cn=users,dc=mydomain,dc=ch
        
        Somit muss als "User DN" für Bind Type "Regular" folgendes konfiguriert werden:
        
        cn=Adminstrator,cn=users,dc=mydomain,dc=ch

Nach Abschluss der Konfiguration sollte diese anhand des "Test" Button getestet werden. Dies bedeutet: Wird dies durchgeführt und die Konfiguration wurde korrekt durchgeführt, öffnet sich ein zusätzliches Fenster in dem das Active Directory/LDAP ersichtlich ist und der "tree" des Active Directory/LDAP abgebildet wird sowie ermöglicht wird in der Active Directory/LDAP Hirarchie zu "browsen"! Um eine entsprechende Konfiguration auf CLI durchzuführen kann folgendes durchgeführt werden:

        # config user ldap
        # edit [Name des LDAP Servers]
        # set server [IPv4 Adresse des LDAP Servers]
        # set secondary-server [Secondary IPv4 Adresse des LDAP Servers]
        # set tertiary-server [Tertiary IPv4 Adresse des LDAP Servers]
        # set source-ip [Source IPv4 Adresse für die LDAP Anfrage]
        # set cnid [Definiere den Common Name dh zB "sAMAccountName" oder "cn"; Standard "cn"]
        # set dn [Definiere den Distinguished Name zB "dc=mydomain,dc=ch"] 
        # set type [simple | anonymous | regular]
        # set username [Definiere den "User DN" für Administrator wenn "Regular" benutzt wird]
        # set password [Definiere das Passwort für "User DN" des Administrators]
        # set group-member-check [user-attr | group-object]
        # set group-object-filter [Definiere den Group Object Filer sofern "group-object" benutzt wird]
        # set secure [disable | starttls | ldaps]
        # set ca-cert [Definiere das entsprechende Zertifikat sofern "secure" aktiviert wird]
        # set port [Definiere den LDAP Server Port; Standard 389 oder 636]
        # set password-expiry-warning [enable | disable ; Passwort Expiry Warnings]
        # set password-renewal [enable | disable ; Passwort Expiry Renewal]
        # set member-attr [Definiere das Member Attribute "groupMembership", "memberOf"; Standard "memberOf"]
        # set search-type [Definiere den Search Type; Standard "nested"]
        # end

Wird für den LDAP Server die "password-expiry-warning" sowie "password-renewal" Optionen aktiviert, muss darauf geachtet werden das "Regular" benutzt wird sowie der defnierte "User DN" für den Administrator mit dessen Passwort über "read-write" Rechte im Active Directory/LDAP verfügen. Der Grund ist der Folgende: wenn die Option "password-renewal" aktiviert ist so muss ein Schreibprozess durch die LDAP Anbindung auf dem FortiOS durch den definierten "User DN" in das ActiveDirecory erfolgen! Ohne "read-write" Rechte des Administrators resp. des definierte "User DN" der die Anbindung zum ActiveDirectory ermöglicht, kann dieser Schreibprozess nicht erfolgen. Im Grundsatz wird dies nicht empfohlen! Wenn diese Funktion des "password-renewal" genutzt wird, muss zwingend eine Verschlüsselung konfiguriert werden sowie der Bind Type "Regular" dh. die Active Directory/LDAP Server Anbindung muss über Port 636 sowie anhand "starttls" oder "ldaps" und dem entsprechenden Zertifikat erfolgen. Wie schon erwähnt kann die Konfiguration nach Abschluss einer Active Directory/LDAP Konfiguration über das Mgmt. Web Interface über den "Test" Button getestet werden. Ebenfalls empfehlen wir die Anbindung anhand eines regulären Active Directory/LDAP Users zu testen. Dies kann auf der CLI mit folgenden Befehl durchgeführt werden:

        # diagnose test authserver ldap [IPv4 Adresse oder FQDN Name des Active Directory/LDAP Server] [Username] [Passwort]
        authenticate '[Username]' against 'WindowsLDAP' succeeded!

Dieser Test testet einen definierten User mit dessen Passwort für die erfolgte Active Directory/LDAP Server Konfiguration. Dies bedeutet: Dieser Test zeigt ob der User mit dem entsprechenden Usernamen und Passwort im Active Directory/LDAP existiert. Dieser Test berücksichtigt unter normalen Umständen jedoch keine Group Membership usw. sondern zeigt nur ob der Username im Active Directory/LDAP existiert und überprüft dessen Passwort. Ist dieser Test erfolgreich, ist die Active Directory/LDAP Anbindung generell korrekt konfiguriert. Möchte man ein tieferes Troubleshooting durchführen für eine Active Directory/LDAP Anbindung kann dies anhand "debug" durchgeführt werden. Weitere Informationen dazu siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_auf_einer_FortiGate_unter_FortiOS_5.4_f.C3.BCr_eine_.22Active_Directory.2FLDAP.22_Konfiguration_ein_Troubleshooting_durchf.C3.BChren.3F]]

=== Wie konfiguriere ich auf einer FortiGate unter FortiOS 5.4 ein "User/Gruppe" für Active Directory/LDAP Authentifizierung? ===

Ausgehend davon, dass ein Active Direcotry/LDAP Konfiguration korrekt durchgeführt wurde können User und/oder Gruppen für die verschiedenen Funktionen wie zB SSL-VPN für eine Active Directory/LDAP Authentifizierung konfiguriert werden. Wie ein Active Directory/LDAP Konfiguration durchgeführt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22Active_Directory.2FLDAP.22_Authentifizierung.3F]]

Wenn eine einfach Authentifizierung (Username und Passwort) für einen User konfiguriert werden soll, kann dies anhand des Mgmt. Web Interfaces durchgeführt werden. Dazu wähle folgendes:

        User & Device > User Definition > Create New

        [[Datei:Fortinet-1673.jpg]]

        [[Datei:Fortinet-1674.jpg]]

        [[Datei:Fortinet-1675.jpg]]

Danach kann anhand des "LDAP Tree" der gewünschte User gesucht und hinzugefügt werden. Der User kann nachträglich zu einer "Gruppe" hinzugefügt werden, jedoch darf in dieser Gruppe unter "Remote groups" der "Active Directory/LDAP" Server nicht hinzugefügt werden. Dies bedeutet: Wenn die User auf dem FortiOS einzeln als "lokale" User über den Active Directory/LDAP Server hinzugefügt werden, dürfen diese nicht Mitglied sein von einer lokalen "Gruppe" in dem der Active Directory/LDAP Server unter "Remote Server" hinzugefügt wurde! Wird keine zweifach Authentifizierung durchgeführt dh. die User sollen anhand Username und Passwort eine Authentifizierung durchführen  und es sollen keine "lokalen" User auf dem FortiOS erfasst werden, kann eine Active Directory/LDAP Konfiguration anhand eine "lokalen" Gruppe durchgführt werden. Dazu wird eine "lokale" Gruppe erfasst und unter "Remote groups" der konfigurierte Active Directory/LDA" Server hinzugefügt. In diesem Schritt kann unter "Regular" Bind Type entweder "with group search" oder "without group search" gewählt werden:

        User & Device > User Groups > Create New

        [[Datei:Fortinet-1679.jpg]]

        [[Datei:Fortinet-1680.jpg]]

Wird der Active Directory/LDAP Server unter "Remote Serve" ausgewählt und sofort bestätigt dh. keine Gruppe hinzugefügt wir ein "Any" konfiguriert:

        [[Datei:Fortinet-1681.jpg]]

Diese Konfiguration "Any" bedeutet "without group search" was wiederum folgendes bedeutet: Es wird im Active Directory/LDAP der ganze "tree" durchsucht nach dem entsprechenden User und nicht nach einer spezifischen Gruppe. Soll ein "group search" konfiguriert werden so kann innerhalb des "Remote Server" Konfiguration unter "Groups" eine oder mehrer Gruppen hinzugefügt werden die berücksichtigt werden sollen. Somit wird nur diese entsprechenden Gruppen im Active Directory/LDAP herangezogen für eine Authentifizierung. Die entsprechenden User müssen für die Authentifizierung diesen Active Directory/LDAP Gruppen hinzugefügt werden: 

        [[Datei:Fortinet-1682.jpg]]

Wenn für ein User eine zweichfach Authentifizierung konfiguriert werden muss zB für FortiToken, SMS oder Email Authentifzierung muss der User auf dem FortiOS als "lokaler" User aus dem Active Directory/LDAP Server hinzugefügt werden. Auch in diesem Fall gilt: Wenn die User auf dem FortiOS einzeln als "lokale" User für eine zweifach Authentifizierung über den Active Directory/LDAP Server hinzugefügt werden, dürfen diese nicht Mitglied sein von einer lokalen "Gruppe" in dem der Active Directory/LDAP Server unter "Remote Server" hinzugefügt wurde! Die zweifach Authentifizierung kann innerhalb des hinzugefügten Active Directory/LDAP Users für FortiToken, SMS sowie EMail konfiguriert werden. Die Voraussetzung für eine zweifach Authentifizierung basierend für SMS oder Email sind entweder ein "SMS Custom" oder ein "Email Service". Dabei ist zu berücksichtigen, dass ein SMS Versandt nur möglich ist über einen "Email to SMS" Provider und nicht über HTTP/S "get" und/oder "post". Ein "SMS Custom" kann unter CLI folgendermassen konfiguriert werden:

        '''SMS Custom'''
        
        # config system sms-server
        # edit [Name des SMS Service]
        # set mail-server [FQDN des SMS Mail Server]
        # next
        # end

Ein Email Server wird über CLI folgendermassen konfiguriert:

        '''Email Service'''
        
        # config system email-server
        # set reply-to [Absender Email Adresse]
        # set server [FQDN SMTP Server]
        # set port [Gebe einen entsprechenden Port an zB "25"]
        # set source-ip [Optional gebe eine Source IPv4 Adresse an für den Absender der SMTP Nachricht]
        # set source-ip6 [Optional gebe eine Source IPv6 Adresse an für den Absender der SMTP Nachricht]
        # set authentication [enable | disable]
        # set username [Username für die Authentifizierung]
        # set password [Passwort für die Authentifizierung]
        # set validate-server [enable| disable]
        # set security [none | smtps | starttls]
        # end

Weitere Inforamtionen zum Email Service siehe auch nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]

Somit sind die Voraussetzungen für einen SMS Service, Email Service oder auch FortiToken gegeben kann der "lokale" User für zweifach Authentifizierung konfiguriert werden. Die Aktivierung eines spezifischen zweifach Authentifizierungs Service zB SMS und Email muss über CLI für den User aktiviert werden:

        '''Zweifach Authentifizierung basierend auf SMS Custom'''
        
        # config user local
        # edit [Name des lokeln User aus Active Directory/LDAP]
        # set type ldap
        # set two-factor sms
        # set sms-server custom
        # set sms-custom-server [Name des SMS Service der konfiguriert wurde unter "system sms-server"]
        # set sms-phone [Defniere die Mobile Nummer des Active Directory/LDAP Users zB "0041798556715"]
        # set ldap-server [Name des konfigurierten Active Directory/LDAP Server]
        # end

        '''Zweifach Authentifizierung basierend auf Email Service'''
        
        # config user local
        # edit [Name des lokeln User aus Active Directory/LDAP]
        # set type ldap
        # set two-factor email
        # set email-to [Email Adresse des Active Directory/LDAP Users zB "andrea.soliva@also.com"]
        # set ldap-server [Name des konfigurierten Active Directory/LDAP Server]
        # end

Nach der Konfiguration auf der CLI sieht der entsprechende Active Directory/LDAP User über Mgmt. Web Interface folgendermassen aus:

        '''Zweifach Authentifizierung basierend auf SMS Custom'''
        
        [[Datei:Fortinet-1676.jpg]]

        '''Zweifach Authentifizierung basierend auf Email Service'''
        
        [[Datei:Fortinet-1677.jpg]]

Wird die zweifach Authentifizierung anhand FortiTokens durchgeführt, und ausgehend davon das die entsprechenden FortiToken auf dem FortiOS korrekt registriert wurden, muss folgendes durchgeführt werden:

        '''Zweifach Authentifizierung basierend auf FortiToken'''
        
        # config user local
        # edit [Name des lokeln User aus Active Directory/LDAP]
        # set type ldap
        # set two-factor fortitoken
        # set fortitoken [Serial Nummer des entsprechenden FortiToken zB "FTKMOBXXXXXXXXX"]
        # set sms-server [fortiguard | custom]
        # set sms-custom-server [Name des SMS Service der konfiguriert wurde unter "system sms-server"]
        # set sms-phone [Defniere die Mobile Nummer des Active Directory/LDAP Users zB "0041798556715"]
        # set ldap-server [Name des konfigurierten Active Directory/LDAP Server]
        # end
        
        [[Datei:Fortinet-1678.jpg]]

In diesem Beispiel wurden nicht der physische FortiToken benützt sondern ein FortiTokenMobile dh. anhand einer "App" existiert der FortiToken Software basierend auf einem Mobile Device. In so einem Fall, muss der Activation Code über "SMS" oder "Email" für die Aktivierung des FortiTokenMobile dem entsprechenden Mobile Device (Mobile Nummer) für den User aus dem Active Directory/LDAP zugesendet werden. Bei einem physischen FortiToken fällt dieser Schritt zur Aktivierung des FortiToken weg.

=== Wie kann ich auf einer FortiGate unter FortiOS 5.4 für eine "Active Directory/LDAP" Konfiguration ein Troubleshooting durchführen? ===

Wenn es für eine "Active Directory/LDAP" Konfiguration zu Problemen kommt, kann ein "debug" durchgeführt werden. Dieser "debug" wird anhand des "Fortigate non-blocking auth deamon" durchgeführt und wird auch als Service "fnbamd" bezeichnet. Dabei wird relativ viel "output" erzeugt in einer Session. Deshalb ist es wichtig den "output" in ein Log File zu schreiben, damit dieser "output" später für eine Analyse zur Verfügung steht. Für ein "debug" führe folgendes auf der CLI aus:

        1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
        2. Erstelle eine Consolen Verbindung zur FortiGate per SSH
        3. Führe ein Login durch und gebe folgendes ein:

        '''Setze alle Debug Filter zurück'''
        
        # diagnose debug reset

        '''Setze einen Debug Filter für "fnbamd"'''
        
        # diagnose debug application fnbamd –1

        '''Aktiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp enable

        '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug enable 

Danach kann eine entsprechende Abfrage resp. Authentifizierung basierend auf Active Directory/LDAP durchgeführt werden und der "output" gemäss gesetzten Filter "fnbamd" wird erstellt. Nach erfolgten "debug" sollte die "debug" Funktion deaktiviert und der gesetzte Filter zurück gesetzt werden:

        '''Deaktiviere die Debug Funktion'''
        
        # diagnose debug disable

        '''Dektiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp disable

        '''Setze den Debug Filter zurück'''
        
        # diagnose debug reset

Eine weitere Möglichkeit Authentifizierungsprobleme für Active Directory/LDAP zu untersuchen ist das Sniffer Kommando. Dabei werden innerhalb des Sniffer "output" Frames in "HEX" ausgegeben die nachträglich intepretiert werden könnnen. Nachfolgend eine Liste der verschiedenen Meldungen:

        0x525 - user not found
        0x52e - invalid credentials
        0x530 - not permitted to logon at this time
        0x531 - not permitted to logon from this workstation
        0x532 - password expired
        0x533 - account disabled
        0x701 - account expired
        0x773 - user must reset password
        0x775 - account locked out

        # diagnose sniffer packet any "port 389" 3

Der Filter für das Sniffer Kommando sollte so gut wie möglich eingeschränkt werden dh. Kombinationen wie zB die IPv4 Adresse des Clients bei dem Authentifizierungs Probleme auftreten können anhand eines Filters weiter einzuschränkt werden wie zB:

        # diagnose sniffer packet any "port 389 and host 192.168.1.1" 3

Für weitere Informationen betreffend Sniffer Kommando siehe auch nachfolgender Artikel:

        [[FortiGate:Diagnose-Sniffer-Guide#diagnose_sniffer_packet]]

== SSL-VPN ==

=== Was ist unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode betreffend Port Konfiguration zu berücksichtigen? ===

Wenn ein SSL-VPN Portal sei es im Port/Tunnel Mode konfiguriert wird so stellt sich die Frage, welchen Port soll benützt werden für die SSL-VPN Funktion. Per Standard benutzt eine FortiOS Konfiguration den TCP Port 10443 da der TCP Port 443 bereits für den Administrativen Access benutzt wird. Somit sollte der Administrative Access Port verschoben werden auf zB TCP Port 8443. Dies kann über Mgmt. Web Inerface und/oder CLI durchgeführt werden:

        System > Settings > Administration Settings

        [[Datei:Fortinet-2020.jpg]]

        # config system global
        # set admin-sport [Konfigurierte den entsprechenden TCP Port für HTTPS zB "8443"]
        # end

Sobald die Konfiguration durchgeführt wurde, kann der TCP Port für die SSL-VPN Funktion neu gesetzt werden:

        VPN > SSL-VPN Settings > Listen Port

        [[Datei:Fortinet-2021.jpg]]

        # config vpn ssl settings
        # set port [Konfigurierte den entsprechenden TCP Port für SSL-VPN zB "443"]
        # end

Desweiteren ist es unter FortiOS 5.4 neu möglich einen Redirect für HTTP (TCP 80) auf HTTPS (SSL-VPN TCP Port) zu aktivieren wobei per Standard diese Funktion nicht aktiviert ist:

        # config vpn ssl settings
        # set https-redirect [enable | disable]
        # end

Der TCP Port 443 für SSL-VPN kann jedoch nur dann definiert werden, wenn dieser Port für die Public IPv4 Adresse des entsprechenden Interfaces zB "wan1" nicht bereits in Gebrauch ist wie zB für ActiveSync VIP Adresse (Destination NAT)! Wenn dennoch der SSL-VPN TCP Port 443 benutzt werden soll auf dem "wan1" Interface obwohl dieser TCP Port 443 bereits in Gebrauch ist für zB ActiveSync gilt folgende Voraussetzung dies dennoch zu ermöglichen resp. zu Konfigurieren:

       • Eine Public IPv4 Adresse auf dem "wan1" Interface als Main IPv4 Adresse des Interface!
       • Zweite Public IPv4 Adresse als Secondary IPv4 Adresse auf dem "wan1" Interface!

Auch wenn auf dem zB "wan1" Interface eine zweite Public IPv Adresse als Secondary IPv4 Adresse konfiguriert wird, ändert sich die Situation nicht, denn der Administrative Access und die SSL-VPN Access stellen zwei System Services dar die sich innerhalb dieser System Services nicht einen und denselben TCP Port teilen können! Also muss konsequent für jeden System Service ein anderer Port vergeben werden zB für Adminstrative Access HTTPS 443 und für SSL-VPN HTTPS 10443. Um dem User dennoch auf dem "wan1" Interface zu ermöglichen den TCP Port 443 zu nutzen obwohl dieser bereits in Gebrauch ist, kann ein Workaround konfiguriert werden. Ausgangslage für diesen Workaround ist ein eigens dafür erstelltes Loopback Interface das anhand einer frei definierten IPv4 Adresse Konfiguriert wird. Diese IPv4 Adresse für dieses Loopback Interface darf nicht in einem Netzwerk Segment benutzt werden! Danach wird ein entsprechendes VIP Objekt das auf einem Loopback Interface konfiguriert wird sowie anhand der Secondary IPv4 Adresse auf dem "wan1" Interface der TCP Port 443 konfiguriert und über ein Port Forwarding anhand TCP Port 10443 der Zugriff auf die SSL-VPN Funktion ermöglicht. Somit wird logisch gesehen folgendes konfiguriert:

        wan1 Main IPv4 Adresse       = TCP Port 443 --> '''Administrative Access TCP Port 443'''
        wan1 Secondary IPv4 Adresse  = TCP Port 443 --> VIP Objekt Secondary Public IPv4 Adresse TCP Port 443 --> Loopback Interface TCP Port Forwarding 10443 --> '''SSL-VPN Listen Port 10443'''

Nachfolgendes Dokument von Fortinet erklärt diese Konfiguration Schritt für Schritt:

        [[Datei:Using-Port-443-for-MGMT-Access-and-SSL-VPN.pdf]]

=== Was ist unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode betreffend Protokoll Konfiguration zu berücksichtigen? ===

Wenn ein SSL Port/Tunnel Mode konfiguriert wurde unter FortiOS 5.0/5.2 so wurde bis anhin für das Protokoll TCP benutzt! Dies bedeutet: es wurde eine enkapsulierte TCP Verbindung in einer TCP Verbindung benutzt was wiederum bedeutet: Informationen die durch den SSL Port/Tunnel Mode gesendet werden, sind enkapsuliert in einer HTTPS Verbindung die auf TCP basiert. Dies kann betreffend Timeouts usw. Problematisch sein und ist auch Performance technisch gesehen nicht Optimal. Wieso dem so ist zeigt nachfolgender Link auf:

        http://sites.inka.de/bigred/devel/tcp-tcp.html 

Neu unter FortiOS 5.4 wird per Standard UDP benutzt dh. eine DTLS (Datagram Transport Layer Security) Verbindung basierend auf UDP wobei die gleiche Security benutzt wird wie für SSL (TLS). Weitere Informationen betreffend DTLS siehe nachfolgender Link:

        https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security

Diese UDP basierende DTLS Verbindung können die Performance dramatisch erhöhen da die verschiedenen Problematiken betreffend enkapsulierter TCP Verbindung über eine TCP Verbindung (HTTPS) nicht auftreten. Die Funktion DTLS zu aktivieren oder weiterhin TCP zu benutzen kann über folgende Konfiguration konfiguriert werden wobei zu berücksichtigen ist, dass DTLS per Standard aktiviert ist:

       # config vpn ssl settings
       # set dtls-tunnel [enable | disable]
       # end

=== Wie kann ich unter FortiOS 5.4 ein SSL-VPN für Portal/Tunnel Mode auf einer FortiGate konfigurieren? ===

Wenn auf auf einem FortiGate Device ein SSL-VPN konfiguriert werden soll, muss unterschieden werden zwischen Portal und/oder Tunnel Mode. Beide Modi sind Unabhängig dh. es braucht keine Portal Mode um den Tunnel Mode zu betreiben und/oder Tunnel Mode um den Portal Mode zu betreiben. Beim Portal Mode handelt es sich um die Browser basierende Variante dh. über den Browser wird auf einem Portal das auf dem FortiGate Device zur Verfügung gestellt wird eingeloggt und anhand der zur Verfügung stehenden Connection Tools oder Bookmarks zB RDP, Port Forwarder, HTTP, HTTPS usw. auf eine interne Resource zugegriffen. Beim Tunnel Mode muss unter FortiOS 5.4 die FortiClient Software auf dem Host/Client für den SSL-VPN Zugriff installiert werden. Anhand dieser Host/Client FortiClient Software wird ein SSL basierender Tunnel zum FortiGate Device aufgebaut und der Zugriff erfolgt über diesen Tunnel. Auf jedem FortiGate Device kann ein SSL-VPN für Portal und/oder Tunnel Mode konfiguriert werden. Dabei ist die Anzahl der Portal limitiert. Auskunft über die Limitierungen im SSL-VPN Bereich gibt das "max_value" Dokument für FortiOS 5.4. Weitere Informationen siehe nachfolgender Link:

        [http://help.fortinet.com/fgt/54/max-values/5-4-0/max-values.html Datei:Fortigate-Max-Values-54.pdf] (FortiOS 5.4 Max Values / Online Version http://help.fortinet.com/fgt/54/max-values/5-4-0/max-values.html)

Wenn dennoch versucht wird mehr Portale in deren Anzahl als durch "max_value" definiert ist zu konfigurieren, kommt es zu einer Fehlermeldung:

        # config vpn ssl web portal
        # edit [Name des entsprechenden SSL-VPN Portals]        
        Too many entries in all tables of .vpn.ssl.web.portal in vdom root: 1 / vdom-max = 3

In einigen Konfigurationsschritten werden Features angewandt die aktiviert werden müssen wie zB "Realm". Wie diese Features im Mgmt. Web Interface eines FortiGate Devices aktiviert werden siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

Damit ein SSL-VPN Konfiguration durchgeführt werden kann benötigt man folgende Objekte:

        • SSL-VPN IPv4 Pool Objekt
        • LAN IPv4 Objekt
        • User/Gruppe Objekt
        • SSL-VPN Portal Profiles

In unserem Beispiel gehen wir von folgender Situation aus:

                          ____________                  _________________________
        193.193.135.66/29|            | 198.18.0.1     |                         |        Office IPv4 Pool 198.18.1.0/25
        ----- WAN 1 -----|  Fortigate |------ LAN -----| LAN Env. 198.18.0.0/24  |
                         |____________|                |_________________________|        

Erstelle das SSL-VPN IP Pool Objekt das für folgende Funktion benutzt wird: Wird eine erfolgreiche Authentifizierung durchgeführt sei es für Portal und/oder Tunnel Mode,  wird dem User eine IPv4 Adresse zugewiesen aus diesem IPv4 Pool Objekt resp. Subnet. Diese IPv4 Adresse benutzt ein User in einer aktiven Verbindung als dessen Source IPv4 Adresse:

        Policy & Objects > Addresses > Create New > net-local-ip-pool-ssl-vpn-198.18.1.0-25

        [[Datei:Fortinet-2007.jpg]]

Erstelle das LAN IPv4 Objekt das für folgende Konfiguration benutzt wird: Für die Konfiguration muss das LAN IPv4 Subnet definiert werden um zwei Konfigurationen innerhalb des SSL-VPN durchzuführen. Einerseits wird das durch das LAN IPv4 Objekt die zu erreichende Destination resp. Ziel Adressen definiert und auf der anderen Seite dadurch ein Splitt Tunneling ermöglicht:

        Policy & Objects > Addresses > Create New > net-local-lan-198.18.0.0-24

        [[Datei:Fortinet-2008.jpg]]

Erstelle eine Gruppe für den Tunnel Mode sowie für Portal Mode:

        User & Device > User Groups > Create New > gr-ssl-fc-tunnel-vpn-local-intra

        [[Datei:Fortinet-2009.jpg]]

        User & Device > User Groups > Create New > gr-ssl-fc-portal-vpn-local-intra

        [[Datei:Fortinet-2010.jpg]]

Erstelle zwei User "local-0.intra" sowie "local-1.intra" und füge "local-0.intra" zur Gruppe "gr-ssl-fc-tunnel-vpn-local-intra" sowie "local-1.intra" zur Gruppe "gr-ssl-fc-web-vpn-local-intra" hinzu:

        User & Device > User Definition > Create New > Local User > User Name: local-0.intra

        [[Datei:Fortinet-2011.jpg]]

        User & Device > User Definition > Create New > Local User > User Name: local-1.intra

        [[Datei:Fortinet-2012.jpg]]

Im nächsten Schritt werden die SSL-VPN Portal Profiles erstellt. Diese definieren welche Modi zur Verfügung stehen. In einem späteren konfigurations Schritt werden die entsprechenden SSL-VPN Gruppen zu diesen SSL-VPN Portal Profiles gemappt. In unserem Beispiel existieren zwei Gruppen dh. "gr-ssl-fc-tunnel-vpn-local-intra" sowie "gr-ssl-fc-portal-vpn-local-intra". Somit erstellen wir ein SSL-VPN Portal Profile für den Tunnel Mode sowie ein SSL-VPN Portal Profile für den Portal Mode. Zusätzlich wird ein "default" SSL-VPN Portal Profile erstellt, dass für alle User gilt die nicht Mitglied beider Gruppen sind. In diesem SSL-VPN Portal Profile werden keine Funktionen zur Verfügung gestellt und gilt somit als "default" SSL-VPN Portal Profile:

        VPN > SSL-VPN Portals > Create New > local-fc-portal-access.intra

        [[Datei:Fortinet-2013.jpg]]

Unter "Predefined Bookmarks" können entsprechende Bookmarks für die User vorbereitet werden wie zB für RDP. Wird die Position "User Bookmarks" aktiviert so ist es den Usern für dieses SSL-VPN Portal Profile erlaubt eigenen Bookmarks zu erstellen! Desweiteren ist für die Konfiguration unter FortiOS 5.4 zu berücksichtigen, dass die RDP Native Funktion entfernt wurde und mit RDP HMTL5 ersetzt worden ist. Ebenso wurde im SSL-VPN Portal Profile für den Web Mode das "Tunnel Mode Widget" entfernt und steht somit aus Sicherheitsgründen nicht mehr zur Verfügung!

        VPN > SSL-VPN Portals > Create New > local-fc-tunnel-access.intra

        [[Datei:Fortinet-2014.jpg]]

Das "default" SSL-VPN Portal Profile ist ein Profile das durch alle User genutzt wird die nicht Mitglied einer definierten Gruppe im Mapping ist. Dies bedeutet: Aus Sicherheitsgründen wird aus diesem Grund ein "default" SSL-VPN Portal Profile erstellt, dass über keine entsprechenden Funktion verfügt. Ein SSL-VPN Portal Profile kann nur dann erstellt werden wenn mindestens ein Mode aktiviert ist dh. für das "default" Portal Profile aktivieren wir den Web Mode jedoch aktivieren keine entsprechenden Funktionen:

        VPN > SSL-VPN Portals > Create New > local-fc-default-access.intra

        [[Datei:Fortinet-2015.jpg]]

In den nächsten konfigurations Schritten wird unter der Menü Position "SSL-VPN Settings" ein Mapping Konfiguriert für die entsprechende Gruppen und SSL-VPN Portal Profiles. In diesem Mapping ist es zusätzlich möglich anhand eines "Realms" dieses Mapping zu differenzieren dh. zwischen Gruppen und SSL-VPN Portal Profiles nochmals zu differenzieren. Dieser Konfigurationsschritt ist Optional und wird nicht für jede Konfiguration benötigt. In unserem Beispiel erstellen wir einen "Realm" den wir zur Gruppe "gr-ssl-fc-portal-vpn-local-intra" sowie SSL-VPN Portal "local-fc-portal-access.intra" Mappen. Das Mapping erfolgt mit einem Realm "portal" dh. um das SSL-VPN Portal Profile "local-fc-portal-access.intra" für die Gruppe "gr-ssl-fc-portal-vpn-local-intra" aufzurufen, müssen die User den entsprechenden Realm "portal" eingeben ansonsten ist das SSL-VPN Portal nicht zugänglich und der User kann sich nicht anmelden dh.:

        https://[FQDN Public IPv4 Adresse des "wan1" Interfaces]/portal

        VPN > SSL-VPN Realms > Create New > portal

        [[Datei:Fortinet-2016.jpg]]

Nun kann die SSL-VPN Konfiguration anhand der "SSL-VPN Settings" abgeschlossen werden. Dabei ist folgendes zu beachten: Unter "Authentication/Portal Mapping" wird wie schon erwähnt eine entsprechenden Gruppe anhand eines Realms zu einem SSL-VPN Portal Profile gemappt. In dieser Konfiguration dieses Mapping gilt wie für eine Firewall Policy Rule Definition "top down first match wins". Als sogenannte "clean-up" Rule muss ein entsprechendes SSL-VPN Portal Profile definiert werden das für alle anderen User resp. Gruppen gilt. Für diese Position wird unser "default" SSL-VPN Portal Profile definiert in dem zwar Web Mode aktiviert ist jedoch ohne jegliche Funktionen:

        VPN > SSL-VPN Settings

        [[Datei:Fortinet-2017.jpg]]

Die Konfiguration des SSL-VPN Funktion sei es für Portal/Tunnel Mode ist grundsätzlich abgeschlossen. Damit die Funktion vervollständig wird hinsichtlich Routing und Firewall Policy Rule, muss auf der einen Seite der IPv4 IP Pool Adressen auf das "ssl.root" Interface geroutet werden sowie eine entsprechende Firewall Police Rule konfiguriert werden, die den Traffic des Users auf die entsprechenden Resourcen im LAN erlaubt:

        Network > Static Routes > Create New

        [[Datei:Fortinet-2018.jpg]]

Dieser statische Route Eintrag muss nur dann erstellt werden, wenn für "vpn ssl settings" die Option "auto-tunnel-static-route" deaktiviert ist. Ist diese Option aktiviert so wird auf Layer 4 für den Service SSL-VPN ein Routing Eintrag erstellt. Dieser Eintrag da dieser im Layer 4 erstellt wird ist nicht über Layer 3 ersichtlich dh. in der Routing Table. Der entsprechende Routing Eintrag unter Layer 4 wird nur dann erstellt wenn ein User erfolgreich einer Verbindung etabliert hat!

        Policy & Objects > IPv4 Policy > Create New

        [[Datei:Fortinet-2019.jpg]]

Die Konfiguration ist abgeschlossen und kann getestet werden! Für den SSL-VPN Portal Mode muss nun die folgende URL benützt werden:

        https://[FQDN Public IPv4 Adresse des "wan1" Interfaces]/portal

Für den SSL-VPN Tunnel Mode muss die entsprechende Software auf dem Client/Host installiert werden. Wir empfehlen den FortiClient im "VPN-Only" Mode. Das entsprechende Software Packet wird über diese MediaWiki Seite zur Verfügung gestellt und über folgenden Link runtergeladen werden:

        [[FortiGate:KonfigExample#Typische_KMU_Konfiguration]]

Bei der Auswahl des FortiClient ist folgendes zu beachten: FortiOS 5.4 sei es für SSL-VPN und/oder IPSec unterstützt kein FortiClient in der Version 5.0 dh. es muss der FortiClient 5.4 installiert werden oder FortiClient ab 5.2.5. Bei der Installation des FortiClient ist darauf zu achten dieser anhand administrations Rechten installiert wird. Wenn dies durchgeführt wird, kann über das FortiClient Menü eine entsprechende SSL-VPN Verbindung konfiguriert werden. Wenn eine Verbindung zur IPv4 Public Adresse oder FQDN des FortiGate Devices erstellt wird, sollte nach einer erfolgreichen Authentifizierung durch den User die Routing Einträge auf dem Client/Host kontrolliert werden. Dies bedeutet: Durch die Definition des Split Tunneling im SSL-VPN Portal Tunnel Profile "local-fc-tunnel-access.intra" wird anhand des definiert internen LAN IPv4 Subnet Adresse nach der  erfolgreichen Authentifizierung durch den SSL-VPN Tunnel zum Client/Host ein entsprechender Routing Eintrag gesendet und lokal auf dem Client/Host erstellt. Dieser Routing Eintrag ist verantwortlich, dass ausschlieschlich nur der definierte IPv4 Subnet Adressen des internen LAN Segment durch den SSL-VPN Tunnel gesendet werden. Destinationen die nicht dieser Definition entsprechen dh. des internen IPv4 LAN Segments, werden über den definiert Default Gateway des Client/Host gesendet (Split Tunneling). Dieser Umstand sollte Rechnung getragen werden und beim Testen des Tunnel Modes kontrolliert werden. Die gesamte hier gezeigte Konfiguration kann ebenfalls über CLI durchgeführt werden. Nachfolgend werden die entsprechenden Kommandos gezeigt die für diese Konfiguration ausgeführt werden müssen. Dabei ist folgendes zu berücksichtigen: Die hier gezeigten Befehle zeigen nur die auszuführenden Kommandos dh. die Kommandos die nicht von der standard Konfiguration eines FortiOS abweichen werden hier nicht gezeigt:

        # config firewall address
        # edit "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
        # set comment "SSL-VPN IP Pool local-sg0e0"
        # set subnet 198.18.1.0 255.255.255.128
        # next
        # end

        # config firewall address
        # edit "net-local-lan-198.18.0.0-24"
        # set comment "Net lan local-sg0e0"
        # set subnet 198.18.0.0 255.255.255.0
        # next
        # end

        # config user local
        # edit "local-0.intra"
        # set type password
        # set passwd "[Password]"
        # next
        # end

        # config user local
        # edit "local-1.intra"
        # set type password
        # set passwd "[Password]"
        # next
        # end

        # config user group
        # edit "gr-ssl-fc-tunnel-vpn-local.intra"
        # set group-type firewall
        # set member "local-0.intra"
        # next
        # end

        # config user group
        # edit "gr-ssl-fc-portal-vpn-local.intra"
        # set group-type firewall
        # set member "local-1.intra"
        # next
        # end

        # config vpn ssl web portal
        # edit "local-fc-portal-access.intra"
        # set web-mode enable
        # set limit-user-logins enable
        # config bookmark-group
        # edit "gui-bookmarks"
        # config bookmarks
        # edit "RDP"
        # set apptype rdp
        # set server-layout de-de-qwertz
        # set description "HTML5 RDP Connection"
        # set host "198.18.0.94"
        # set port 3389
        # next
        # end
        # set heading "Welcome to local.ch"
        # set custom-lang "en"
        # next 
        # end

        # config vpn ssl web portal
        # edit "local-fc-tunnel-acces.intra"
        # set tunnel-mode enable
        # set limit-user-logins enable
        # set keep-alive enable
        # set save-password enable
        # set ip-pools "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
        # set split-tunneling-routing-address "net-local-lan-198.18.0.0-24"
        # set dns-server1 198.18.0.91
        # next
        # end

        # config vpn ssl web portal
        # edit "local-fc-default-access.intra"
        # set web-mode enable
        # set user-bookmark disable
        # config bookmark-group
        # edit "gui-bookmarks"
        # next
        # end
        # set display-connection-tools disable
        # set display-history disable
        # set display-status disable
        # set heading "SSL-VPN Portal - dummy"
        # next
        # end

        # config vpn ssl web realm
        # edit "portal"
        # set max-concurrent-user 100
        # set login-page "<!DOCTYPE html>
        <nowiki><html lang=\"en\" class=\"main-app\">
          <head>
            <meta charset=\"UTF-8\">
            <meta http-equiv=\"X-UA-Compatible\" content=\"IE=8; IE=EDGE\">
            <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">
            <link href=\"/css/main-blue.css\" rel=\"stylesheet\" type=\"text/css\">
            <title>
              Please Login
            </title>
          </head>
          <body>
            <div class=\"view-container\">
              <form class=\"prompt\" action=\"%%SSL_ACT%%\" method=\"%%SSL_METHOD%%\" name=\"f\" autocomplete=\"off\">
                <div class=\"content with-header\">
                  <div class=\"header\">
                    <div>
                      WARNING!
                      <br>
                      <br>
                      You must have prior authorization to login to this system. All connections are logged and monitored. By login to this system you fully consent to all monitoring. Unauthorized login or use will be prosecuted to the full extent of the law. You have been warned!
                    </div>
                  </div>
                  <div class=\"sub-content\">
                    <div class=\"wide-inputs\">
                      %%SSL_LOGIN%%
                    </div>
                    <div class=\"button-actions wide\">
                      <button class=\"primary\" type=\"button\" name=\"login_button\" id=\"login_button\" onClick=\"try_login()\">
                        Login
                      </button>
                    </div>
                  </div>
                </div>
              </form>
            </div>
          </body>
          %%SSL_HIDDEN%%
        </html>
        "</nowiki>
        # next 
        # end

        # config vpn ssl settings
        # set servercert "Fortinet_Factory"
        # set idle-timeout 1800
        # set tunnel-ip-pools "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
        # set dns-suffix "local.intra"
        # set dns-server1 198.18.0.91
        # set port 443
        # set auto-tunnel-static-route disable
        # set source-interface "wan1"
        # set source-address "all"
        # set source-address6 "all"
        # set default-portal "local-fc-default-access.intra"
        # config authentication-rule
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set source-interface "wan1"
        # set source-address "all"
        # set groups "gr-ssl-fc-tunnel-vpn-local.intra"
        # set portal "local-fc-tunnel-acces.intra"
        # set auth local
        # next
        # edit [Gebe einen entsprechenden Integer an zB "2"]
        # set source-interface "wan1"
        # set source-address "all"
        # set groups "gr-ssl-fc-portal-vpn-local.intra"
        # set portal "local-fc-portal-access.intra"
        # set realm "portal"
        # set auth local
        # next
        # end
        # end

        # config router static
        # edit [Gebe einen entsprechenden Integer ein zB "2"]
        # set dst 198.18.1.0 255.255.255.128
        # set device "ssl.root"
        # set comment "SSL VPN IPool local-sg0e0"
        # end

        # config firewall policy
        # edit [Gebe einen entsprechende Policy ID ein zB "2"]
        # set srcintf "ssl.root"
        # set dstintf "internal1"
        # set srcaddr "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
        # set dstaddr "net-local-lan-198.18.0.0-24"
        # set action accept
        # set schedule "always"
        # set service "ALL"
        # set logtraffic all
        # set groups "gr-ssl-fc-tunnel-vpn-local.intra" "gr-ssl-fc-portal-vpn-local.intra"
        # set comments "Allow Incoming SSL VPN Tunnel Connection local-sg0e0"
        # next
        # end

=== Welche Software kann ich unter FortiOS 5.4 für SSL-VPN im Portal/Tunnel für verschiedene Devices einsetzen? ===

Ausgehend davon das ein SSL-VPN im Portal/Tunnel Mode auf einer FortiGate unter FortiOS 5.4 korrekt konfiguriert wurde, kann für verschiedene Devices wie zB Windows, MacOSx, IOS oder Android Software von Fortinet eingesetzt werden. Wie ein SSL-VPN im Portal/Tunnel Mode auf einem FortiGate Device konfiguriert wird unter FortiOS 5.4 siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

Grundsätzlich stellt Fortinet für den SSL-VPN Tunnel Mode den FortiClient Endpoint Security zur Verfügung. Dabei ist zu beachten, dass der FortiClient Endpoint Security im VPN-Only Mode benutzt wird. Dies bedeutet: Diese Art des FortiClient Endpoint Security beinhaltet nur SSL-VPN sowie die Möglichkeit für IPSec VPN und beinhaltet keine UTM Features. Ueber folgenden Link können diese FortiClient's Endpoint Security im VPN-Only Mode runtergeladen werden:

        [[FortiGate:KonfigExample#Typische_KMU_Konfiguration]]

Basierend auf FortiOS 5.4 und FortiClient VPN-Only Mode oder FortiClient Tunnel Mode gilt folgendes:

        • Für Microsoft Windows 7/8/10 FortiClient Endpoint Security ab Version 5.2.5 oder ab Version 5.4
        • Für Microsoft Windows 10 App Desktop/Phone FortiClient (Windows App) ab Version 1.0.0
        • Für Apple MacOSx 10.8/9/10/11 FortiClient Endpoint Security ab Version 5.2.5 oder ab Version 5.4
        • Für Apple iOS ab Version 9.0.0 FortiClient iOS ab Version 5.4.0.121
        • Für Android ab Version 4.1 Jelly Bean, 4.4.3 KitKat, 5.0.1 Lollipop FortiClient VPN Android 5.2.6

Nachfolgend die einzelnen Release Notes der erwähnten Versionen:

        [[Datei:forticlient-5.2.5-windows-release-notes.pdf]]
        [[Datei:forticlient-5.4.0-windows-release-notes.pdf]]
        [[Datei:forticlient-v1.0.0-windows-app-user-guide.pdf]]
        [[Datei:forticlient-5.2.5-os-x-release-notes.pdf]]
        [[Datei:forticlient-5.4.0-mac-os-x-release-notes.pdf]]
        [[Datei:forticlient-v5.4-ios-user-guide.pdf]]
        [[Datei:forticlient-5.2.6-vpn-android-release-notes.pdf]]

Basierend auf FortiOS 5.4 SSL-VPN Portal Mode dh. eingesetzte Betriebssysteme sowie Browser gilt folgendes:

        • Microsoft Windows 7 SP1 (32-bit/64-bit) Microsoft Internet Explorer version 11
        • Mozilla Firefox version 42
        • Microsoft Windows 8/8.1 (32-bit/64-bit) Microsoft Internet Explorer version 11
        • Mozilla Firefox 42
        • Mac OS 10.9 Safari 7
        • Linux CentOS version 6.5 Mozilla Firefox 42

Desweiteren ist zu berücksichtigen, dass die Release Notes zu konsultieren sind betreffend SSL-VPN Tunnel Mode und den spezifischen Funktionen wie zB Split Tunneling, DNS Sufix usw.

=== Wie kann ich unter FortiOS 5.4 ein SSL-VPN für Portal/Tunnel Mode konfigurieren anhand einer 2ten Public IPv4 Adresse? ===

Wenn man ein SSL-VPN für Portal/Tunnel Mode konfiguriert so wird unter normalen Umständen die Main IPv4 Adresse benutzt die auf dem zB "wan1" Interface konfiguriert wurde. Dazu siehe auch nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

Im vorhergehenden Artikel wird beschrieben wie ein SSL-VPN für Portal/Tunnel Mode anhand der Main IPv4 Adresse auf dem zB "wan1" Interface konfiguriert wird. Dieser Artikel basiert auf folgendem Beispiel und benutzt somit als SSL-VPN Interface "wan1" und somit die IPv4 Adresse 193.193.135.66:
                           ____________                  _________________________
         193.193.135.66/29|            | 198.18.0.1     |                         |        Office IPv4 Pool 198.18.1.0/25
         ----- WAN 1 -----|  Fortigate |------ LAN -----| LAN Env. 198.18.0.0/24  |
                          |____________|                |_________________________|  

Nun möchte man jedoch die IPv4 Adresse 193.193.135.67 benutzen für das SSL-VPN Portal und nicht 193.193.135.66, stellt sich die Frage wie das zu bewerkstelligen ist? Ein Ansatz wäre ein Secondary Interface unter "wan1" zu konfigurieren anhand der IPv4 Adrese 193.193.135.67/32. Dies wird jedoch verhindert durch die CLI Option "allow-subnet-overlap disable". Diese Option verhindert, dass auf einem existierenden Interface ein Overlapping Subnet konfiguriert wird. Weitere Informationen zu "allow-subnet-overlap" siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_f.C3.BCr_ein_Interface_ein_.22overlapping.22_Subnet_Konfigurieren.3F]]

Wenn diese Option "allow-subnet-overlap" aktiviert wird, kann auf dem "wan1" Interface anhand einer Secondary Interface IPv4 Adresse 193.193.135.67/32 konfiguriert werden und als SSL-VPN Portal/Tunnel Adresse unter VPN SSL Settings das "wan1" Interface. Dadurch kann zwar 193.193.135.67 benutzt werden für den SSL-VPN Portal/Tunnel Zugriff, jedoch wird dadurch nicht verhindert das 193.193.135.66 ebenfalls zur Verfügung steht für einen SSL-VPN Portal/Tunnel Mode Zugriff. Abhilfe würde eine Manuelle "Local-In Policy" Rule schaffen, die den Zugriff auf diese Adresse 193.193.135.66 und dem SSL-VPN Portal/Tunnel Mode verhindert. Diese Konfiguration einer Manuellen "Local-In Policy" Rule muss jedoch in der CLI durchgeführt werden anhand folgender Befehle:

       # config firewall local-in-policy
       # edit [Gebe eine entsprechende Policy ID an zB "1"]
       # set ha-mgmt-intf-only disable
       # set intf "wan1"
       # set srcaddr "all"
       # set dstaddr [Gebe das entsprechende Objekt an für die IPv4 Adresse zB "pub-ip-193.193.135.66-32"
       # set action deny
       # set service [Gebe das entsprechende Objekt an für den SSL-VPN Port zB "https"]
       # set schedule "always"
       # set auto-asic-offload enable
       # set status enable
       # end

Die Konfiguration anhand "allow-subnet-overlap enable" sollte jedoch verhindert werden, da durch diese Konfiguration resp. durch eine Fehlkonfiguration auf dem FortiOS ein potentieller "loop" verursacht werden kann und dieser durch das FortiOS nicht mehr verhindert wird! Eine weitere Lösung wäre die Konfiguration anhand eines VIP Objektes (Destination NAT) durchzuführen und unter VPN-SSL Settings ein spezifisches Interface zu konfigurieren das den Zugriff auf zB "wan1" nicht mehr ermöglich für den SSL-VPN Portal/Tunnel Mode. Dies kann anhand eines Loopback Interfaces konfiguriert werden. Dies bedeutet: Es wird ein spezifisches Loopback Interface konfiguriert anhand einer IPv4 Adresse die auf dem FortiOS resp. im Netzwerksegment nicht benützt wird. In unserem Beispiel benützen wir die IPv4 Adresse 198.18.100.1/32. Dabei sollte beachtet werden, dass ein Loopback Interface nicht anhand der Standard Loopback Interface Adressen konfiguiert wird dh. 127.0.x.x da diese IPv4 Adressen für verschiedenen Service unter FortiOS bereits benutzt werden. Um ein Loopback Interface zu konfigurieren führe folgendes durch:

        Network > Interfaces > Create New > Interfaces

        [[Datei:Fortinet-2112.jpg]]

        [[Datei:Fortinet-2113.jpg]]

Als nächsten Schritt konfigurieren wir ein VIP Objekt (Destination NAT) anhand der Public IPv4 Adresse die für den Zugriff des SSL-VPN Portal/Tunnel Mode benützt werden soll und auf die Loopback Interface IPv4 Adresse Uebersetzt wird:

        Policy & Objects > Virtual IPs > Create New > Virtual IP

        [[Datei:Fortinet-2114.jpg]]

Anhand dieses VIP Objekts und durch die Konfiguration 193.193.135.67 und "wan1" wird auf diesem Interface anhand der MAC Adresse des "wan1" im Hintergrund ein ARP Eintrag auf Layer 4 für 193.193.135.67 auf "wan1" erstellt! Nun muss für das SSL-VPN Portal/Tunnel Mode unter den SSL-VPN Settings das Loopback Interface definiert werden damit ausschliesslich dieses für SSL-VPN Tunnel/Portal Mode zur Verfügung steht und somit "wan1" für diesen Service ausgeschlossen wird:

        VPN > SSL-VPN Settings > Listen on Interface(s)

        [[Datei:Fortinet-2115.jpg]]

Nun wird anhand einer regulären Firewall Policy Rule der SSL-VPN Zugriff konfiguriert dh. damit dieser über die entsprechende IPv4 193.193.135.67 zur Verfügung gestellt wird:

        Policy & Objects > IPv4 Policy

        [[Datei:Fortinet-2116.jpg]]

Das definierte Interface für "Outgoing Interface" definiert unser zuvor konfiguriertes Loopback Interface. Wenn ein User nun https://193.193.135.67 zB für den Portal Mode im Browser aufruft, gibt diese IP auf dem "wan1" Interface antwort da auf diesem Interface für die IPv4 Adresse 193.193.135.67 ein ARP Eintrag im Layer 4 existiert. Da ein VIP Objekt (Destination NAT) für diese IPv4 Adresse existiert und Uebersetzt wird auf das Looback Interface sowie dieses wiederum unter SSL-VPN Settings definiert wurde als Interface, erscheint der SSL-VPN Portal/Tunnel Mode. Somit wird zwar durch diese Firewall Policy Rule der SSL-VPN Service zur Verfügung gestellt, jedoch eine Authentifizierung oder Zugriff auf interne Resource ist nicht möglich da keine entsprechende Firewall Policy Rule existiert. Damit eine Authentifizierung durchgführt werden kann sowie interne Resourcen aufgerufen werden können, muss für den SSL-VPN Service dh. "ssl.root" eine zusätzliche Firewall Policy Rule konfiguriert werden:

        Policy & Objects > IPv4 Policy

        [[Datei:Fortinet-2117.jpg]]

Als letzter Schritt muss, sofern die "realm" Funktion benutzt wird, die Interfaces für diese "realms" kontrolliert werde um diese ebenfalls auf das Loopback Interface "nic-ssl-vpn" zu konfigurieren dh. die muss über CLI durchgeführt werden:

        # config vpn ssl settings
        # get | grep source-interface
        source-interface     : "nic-ssl-vpn"
        # config authentication-rule
        # edit [Gebe einen entsprechenden Integer an für den "realm" Eintrag zB "1"]
        # set source-interface nic-ssl-vpn
        # end
        # end

Um ein Troubleshooting durchzuführen für diese Konfiguration sollte in erster Linie überprüft werden ob die entsprechende IPv4 Adresse resp. der entsprechende SSL-VPN Port erreichbar ist (SYN/ACK):

        # diagnose sniffer packet any "port [Gebe den entsprechenden Port an zB 443" 4

Wenn dies zB nicht der Fall ist sollte überprüft werden ob das VIP Objekt angesprochen wird und ob der SSL-VPN Port der unter SSL-VPN Settings konfiguriert wurde antwort gibt. Dies kann anhand folgenden Befehls durchgeführt werden:

        # diagnose debug disable
        # diagnose debug reset
        # diagnose debug flow trace stop
        # diagnose debug flow filter clear
        # diagnose debug flow filter port [Gebe den entsprechenden Port an zB "443"]
        # diagnose debug flow filter daddr [Gebe die entsprechende Public IPv4 Adresse an zB "193.193.135.71"]
        # diagnose debug flow show console enable
        # diagnose debug flow show function-name enable
        # diagnose debug flow trace start 10
        # diagnose debug enable
        # diagnose debug flow trace start

Nun kann die Konfiguration getestet werden. Weitere Informationen betreffend der SSL-VPN Portal/Tunnel Mode Konfiguration siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

=== Wie kann ich unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode eine Two-Factor Authentifizierung konfigurieren? ===

Ausgangslage für eine Two-Factor Authentifizierung ist ein einwandfreie Konfiguration eines SSL-VPN Portal/Tunnel Mode. Wie diese durchzuführen ist siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

Diese Konfiguration kann danach erweitert werden mit einer Two-Factor Authentifizierung basierend auf:

        • Local User FortiGate Two-Factor Authentication FortiToken oder FortiToken Mobile
        • Local User FortiGate Two-Factor Authentication ODA basierend auf Email oder SMS Provider
        • Local User FortiGate Two-Factor Authentication LDAP/Radius basierend auf SMS oder FortiToken/FortiToken Mobile

Wichtig bei einer Two-Factor Authentication auf einer FortiGate ist der folgende Umstand:

        • Für eine Two-Factor Authentication muss der User Lokal auf der FortiGate erfasst werden!

Dies bedeutet: Auch wenn eine Two-Factor Authentication über LDAP oder Radius durchgeführt wird muss ein lokaler User auf der FortiGate konfiguriert werden. Eine Konfiguration in dem innerhalb einer Gruppe der Remote Authentication Server hinzugefügt wird zB Radius und der User lokal nicht auf der FortiGate existiert, ist nicht möglich! Deshalb gilt: Für jede Two-Factor Authentication muss der User auf einer FortiGate Lokal erfasst werden. Wenn eine Two-Factor Authentication konfiguriert werden soll anhand eines FortiToken, FortiToken Mobile oder ODA muss folgendermassen vorgeganen werden:

        '''ODA Two-Factor Authentication basierend über Email oder SMS'''
        
        Für eine ODA Two-Factor Authentication basierend auf Email muss der entsprechende Email Service als Voraussetzung konfiguriert
        werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]
        
        Für eine ODA Two-Factor Authentication basierend auf SMS muss der entsprechende SMS Service/Provider als Voraussetzung konfiguriert 
        werden. Dabei ist folgendes zu berücksichtigen: Ein Versandt der SMS für Two-Factor Authentication ist nur über den Email Service 
        möglich dh. deshalb gilt für den SMS Versand ebenfalls als Voraussetzung ein konfigurierter Email Service! Ein Versand der SMS über 
        HTTP/S get und post ist direkt über eine FortiGate nicht möglich. Wie ein SMS Service/Provider auf einer FortiGate konfiguriert wird 
        siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einer_FortiGate_einen_SMS_Service.2FProvider_konfigurieren.3F]]
        
        Wenn diese Voraussetzungen dh. konfigurierter Email Service sowie SMS Service/Provider bestehen kann ein lokaler User für Two-Factor
        Authentication konfiguriert werden. Für diese Konfiguration muss die CLI benutzt werden da die Two-Factor Funktion für SMS/Email nur 
        über CLI konfiguriert werden kann:
        
        # config user local
        # edit [Name des User zB "local-3.intra"]
        # set type password
        # set two-factor '''sms'''
        # set sms-server custom
        # set sms-custom-server [Name des SMS Service/Provider zB "swisscom"]
        # set sms-phone [Mobile Nummer des User zB "41798456615"]
        # set password [Passwort des Users]
        # end
        
        # config user local
        # edit [Name des User zB "local-4.intra"]
        # set type password
        # set two-factor '''email'''
        # set email-to [Email Adresse des Users zB "local-4@local.intra"]
        # set password [Passwort des Users]
        # end
        
        Die über CLI erfassten User sind nachträglich über Mgmt. Web Interface wie üblich ersichtlich:
        
        [[Datei:Fortinet-2025.jpg]]
        
        [[Datei:Fortinet-2026.jpg]]
        
        Nach Abschluss der Konfiguration können die entsprechenden User zu einer lokalen Gruppe hinzugefügt werden, die benutzt wird in
        der SSL-VPN Portal/Tunnel Mode Konfiguration für die Authentifizierung! Damit die Two-Factor Authentifizierung für SSL-VPN sei
        es im Portal/Tunnel Mode durchgeführt werden kann, muss diese Two-Factor Authentifizierung für die SSL-VPN Funktion aktiviert
        werden. Dies kann über CLI konfiguriert werden:
        
        # config vpn ssl settings
        # set force-two-factor-auth [enable | disable]
        # end

        '''FortiToken/FortiToken Mobile Two-Factor Authentication'''
        
        Wenn eine Two-Factor Authentication über FortiToken sowie FortiToken Mobile konfiguriert werden soll muss als Voraussetzung der 
        FortiToken oder FortiToken Mobile in aller erster Linie korrekt registriert werden. Weitere Informationen dazu siehe nachfolgenden
        Artikel:
        
        [[FortiToken:FAQ]]
        
        Wenn der FortiToken oder FortiToken Mobile korrekt registriert wurde kann der entsprechende FortiToken einem User zugewiesen werden.
        Um einen FortiToken Mobile einem User hinzuzufügen muss entweder ein Mobile Nummer und/oder eine Email Adresse definiert werden um
        den entsprechenden Aktivierungs-Code dem User zu übermitteln. Aus diesem Grund gilt als Voraussetzung um diese zu ermöglichen die 
        Konfiguration eines SMS Service/Provider oder ein Email Service. Weitere Informationen dazu siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einer_FortiGate_einen_SMS_Service.2FProvider_konfigurieren.3F]]
        
        Die Konfiguration eines lokalen User über CLi muss folgendermassen durchgeführt werden:
        
        # config user local
        # edit [Name des User zB "local-5.intra"]
        # set type password
        # set two-factor '''fortitoken'''
        # set fortitoken [Gebe den entsprechende FortiToken oder FortiToken Mobile an]
        # set email-to [Email Adresse des Users zB "local-5@local.intra"]
        # set sms-server custom
        # set sms-custom-server [Name des SMS Service/Provider zB "swisscom"]
        # set sms-phone [Mobile Nummer des User zB "41798456615"]
        # set password [Passwort des Users]
        # end
        
        Die Konfiguration über Mgmt. Web Interface wird folgendermassen durchgeführt:
        
        User & Device > User Definition > Create New > User Type > Local User
        
        [[Datei:Fortinet-2027.jpg]]
        
        [[Datei:Fortinet-2028.jpg]]
        
        [[Datei:Fortinet-2029.jpg]]
        
        [[Datei:Fortinet-2030.jpg]]
        
        Nach Abschluss der Konfiguration können die entsprechenden User zu einer lokalen Gruppe hinzugefügt werden, die benutzt wird in
        der SSL-VPN Portal/Tunnel Mode Konfiguration für die Authentifizierung! Damit die Two-Factor Authentifizierung für SSL-VPN sei
        es im Portal/Tunnel Mode durchgeführt werden kann, muss diese Two-Factor Authentifizierung für die SSL-VPN Funktion aktiviert
        werden. Dies kann über CLI konfiguriert werden:
        
        # config vpn ssl settings
        # set force-two-factor-auth [enable | disable]
        # end

        '''LDAP oder Radius Two-Factor Authentication basierend auf FortiToken, FortiToken Mobile, ODA basierend auf SMS Service oder Email Service'''
        
        Für eine Two-Factor Authentifizierung basierend auf Radius oder LDAP Server muss ein entsprechender LDAP oder Radius Server 
        konfiguriert werden. Der Radius oder LDAP Server darf in einer Gruppe nicht als Remote Server konfiguriert werden sondern 
        der lokale User muss als LDAP oder Radius User konfiguriert werden. Ausgangslage ist somit die Konfiguration eines LDAP 
        oder Radius Servers. Weitere Informationen wie ein LDAP oder Radius Server Einbindung konfiguriert wird siehe nachfolgender 
        Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22Active_Directory.2FLDAP.22_Authentifizierung.3F]]
        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_eine_.22Radius.22_Authentifizierung.3F]]
        
        Wenn die Konfiguration des LDAP oder Radius Servers durchgeführt wurde, kann ein lokaler User für Two-Factor Authentication 
        konfiguriert werden sei es für FortiToken, FortiToken Mobile oder ODA basierend auf SMS Service oder Email Service. Dabei ist 
        die gleiche Konfiguration durchzuführen wie vorhergehend für diese Two-Factor Authentication erklärt. Der lokale User wird 
        anstelle von "password" auf die entsprechende Authentication gesetzt dh.:
        
        # config user local
        # edit [Name des User zB "local-5.intra"]
        # set type [ldap | radius]
        # end
        
        Ein lokal zu konfigurierder LDAP User kann anhand des User Wizards direkt aus dem LDAP Verzeichnis gezogen werden sofern die 
        LDAP Konfiguration korrekt durchgeführt wurde. Nach Abschluss der Konfiguration können die entsprechenden User zu einer lokalen 
        Gruppe hinzugefügt werden, die benutzt wird in der SSL-VPN Portal/Tunnel Mode Konfiguration für die Authentifizierung! Dabei darf 
        in dieser Gruppe kein Remote Groupt resp. LDAP Server oder Radius Server hinzugefügt werden. Damit die Two-Factor Authentifizierung 
        für SSL-VPN sei es im Portal/Tunnel Mode durchgeführt werden kann, muss diese Two-Factor Authentifizierung für die SSL-VPN Funktion 
        aktiviert werden. Dies kann über CLI konfiguriert werden:
        
        # config vpn ssl settings
        # set force-two-factor-auth [enable | disable]
        # end

Um einen Debug durchzuführen für SSL-VPN im Zusammenhang mit einer Two-Factor Authentication kann folgendes durchgeführt werden:

        1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
        2. Erstelle eine SSH Verbindung zur FortiGate.
        3. Führe ein Login durch und gebe folgendes ein:
           
           '''Setze alle Debug Filter zurück'''
           
           # diagnose debug reset

           '''Aktiviere für den debug "output" den "timestamp"'''
           
           # diagnose debug console timestamp enable

           '''Setze die verschiedenen Debug Filter für Two-Factor Authentication'''
           
           # diagnose debub application fnbamd -1
           # diagnose debub application authd -1
           # diagnose debub application sslvpn -1

           '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
           
           # diagnose debug enable 

Nach erfolgreichen Debug deaktiviere diesen wiederum und lösche die Filter:

           '''Dektiviere den Debug Modus mit dem gesetzen Debug Filter'''
           
           # diagnose debug disable 

           '''Setze alle Debug Filter zurück'''
           
           # diagnose debug reset

=== Wie kann ich unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode eine Active Directory/LDAP Authentifizierung konfigurieren? ===

Ausgangslage für eine Active Directory/LDAP Authentifizierung ist ein einwandfreie Konfiguration eines SSL-VPN Portal/Tunnel Mode. Wie diese durchzuführen ist siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

In der hier gezeigten Konfiguration eines SSL-VPN Portal/Tunnel Mode werden lokale User konfiguriert und diesen lokalen Gruppen hinzugefügt. Für eine Active Directory/LDAP Authentifizierung können zwar die User lokal konfiguriert werden dh. aus dem Active Directory/LDAP Verzeichnis gewählt werden und einer lokalen Gruppe hinzugefügt werden jedoch ist dies mit einigem Aufwand verbunden. Sofern keine Two-Factor Authentifizierung durchgeführt wird, kann der entsprechenden Active Directory/LDAP Server innerhalb der entsprechenden Gruppe unter "Remote Groups" direkt definiert werden. Dabei ist es möglich "Any" (Regular/Simple bind without search)zu konfigurieren oder eine entsprechende Gruppe oder Gruppen (Regular/Simple bind with search). Wie ein Active Directory/LDAP Server konfiguriert wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22Active_Directory.2FLDAP.22_Authentifizierung.3F]]

Wie in einer lokalen Gruppe ein Active Directory/LDAP Server hinzugefügt und konfiguriert wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22User.2FGruppe.22_f.C3.BCr_Active_Directory.2FLDAP_Authentifizierung.3F]]

Wenn dem User ermöglicht werden soll ein Passwort Renewal durchzuführen muss ein "Regular Bind" konfiguriert werden sowie der Administrator für "Regular Bind" muss über "read-write" Rechte im Active Directory/LDAP Verzeichnis verfügen. Wenn diese Voraussetzung gegeben ist, kann die entsprechende Funktion innerhalb des Active Directory/LDAP Server Konfiguration aktiviert werden:

        # config user ldap
        # edit [Name des entsprechendne LDAP Servers]
        # set password-expiry-warning [enable | disable]
        # set password-renewal [enable | disable]
        # end

=== Wie kann ich unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode ein Host Check konfigurieren? ===

Mit einem SSL-VPN Portal/Tunnel Mode ist es möglich einen sogenannten Host Check auszuführen dh. wenn der User zB über den Browser die SSL-VPN Seite für das Portal öffnet, wird im Hintergrund ein sogenannter Host Check ausgeführt. Dieser Host Check überprüft im Hintergrund anhand der Client/Host Software ob ein bestimmter "Registry Eintrag" existiert. Ist dieser Host Check erfolgreich wird die entsprechende Login Seite des SSL-VPN Portal geöffnet. Dieser Host Check kann ebenfalls im gleicher Art und Weise für den Tunnel Mode benützt werden dh. Versucht sich ein User über SSL-VPN Tunnel Mode einzloggen, wird das Einloggen nur dann erlaubt wenn der Host Check erfolgreich ist. Dies erlaubt zB ob ein Zugriff über einen bestimmten Device resp. Client/Host erlaubt ist oder nicht. Ein Anwendungsbeispiel wäre zB der Zugriff über einen Device resp. Client/Host im Internet Café soll verhindert werden und der Zugriff über einen Device wie ein Geschäfts Client/Host soll erlaubt werden. Damit dieser Host Check resp. anhand "Registry Check" im SSL-VPN Portal/Tunnel Mode angewendet werden kann, muss die SSL-VPN Client/Host Software dh. FortiClient auf dem Client/Host installiert werden. Ist dies nicht der Fall wird der Zugriff verhindert. Der Grund ist der Folgende: Um den Host Check durchzuführen anhand eines "Registry Eintrages" anzuwenden muss anhand einer lokalen Software dh. FortiClient dies überprüft werden. Da die FortiClient Software als Administrator installiert werden muss, sind die Voraussetzungen gegeben um den entsprechenden Host Check auszuführen resp. den Zugriff auf den Registry Eintrag zu ermöglichen! Ausgehend davon, dass ein SSL-VPN Portal/Tunnel Mode korrekt konfiguriert und getestet wurde kann diese Konfiguration für einen Host Check erweitert werden. Wie eine SSL-VPN Portal/Tunnel Mode Konfiguration durchgeführt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

Erstelle einen entsprechenden Host Check resp. Registry Eintrag verweis auf der CLI anhand folgender Befehle:

        # config vpn ssl web host-check-software
        # edit [Vergebe einen Namen für den Host Check]
        # config check-item-list
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set target [Gebe den entsprechenden Registry Key an zB "HKLM\\SOFTWARE\\Something\\Example"]
        # set type registry
        # next
        # end
        # next
        # end

Binde den Host Check in das entsprechende SSL-VPN Portal/Tunnel Mode Profile:

        # config vpn ssl web portal
        # edit [Name des entsprechenden Portal/Tunnel Mode]
        # set host-check custom
        # set host-check-policy [Name des Host Check Eintrage für "host-check-software"]
        # next
        # end

Die Konfiguration ist abgeschlossen und kann getestet werden. Wenn ein Client/Host versucht im entsprechenden SSL-VPN Portal/Tunnel Mode für das ein Host Check konfiguriert wurde zu zugreifen und der entsprechende Registry Eintrag des Host Check existiert nicht oder der Client/Host verfügt nicht über die Client/Host Software dh. FortiClient wird folgendes angezeigt:

        '''SSL-VPN Tunnel Mode Host Check nicht erfolgreich!'''
        
        [[Datei:Fortinet-1371.jpg]]

        '''SSL-VPN Portal Mode Host Check nicht erfolgreich!'''
        
        [[Datei:Fortinet-1372.jpg]]

        '''Keine Client/Host Software dh. FortiClient vorhanden!'''
        
        If you see the yellow warning bar that the hostcheck ActiveX control is not installed or need permission to run, please click on it 
        to install or run it. Alternatively, if you do not want to install or run the ActiveX control, the host checking function can be 
        performed by a Java applet.

=== Wie kann ich unter FortiOS 5.4 für ein SSL-VPN Portal Mode ein Custome Language File konfigurieren? ===

Auf einem FortiOS werden grundsätzlich keine anderen Sprachen im Mgmt. Web Interface ermöglicht ausser:

        [English | French | Spanish | Portuguese | Japanese | Tradional Chinese | Simplified Chinese | Korean]

Diese Konfiguration der Sprachen setzt die entsprechende Sprache auf dem Mgmt. Web Interface sowie die Replacement Messages dh. ebenso das SSL-VPN Portal. Die entsprechende Sprache kann über folgende Position konfiguriert werden:

        System > Settings > Language > [English | French | Spanish | Portuguese | Japanese | Tradional Chinese | Simplified Chinese | Korean]

Ab FortiOS 5.2 ist es zusätzlich möglich für ein SSL-VPN Portal ein Custome Language File selber zu erstellen. Dafür muss die entsprechende Funktion resp. Feature über CLI aktiviert werden: 

        # config system global
        # set gui-custom-language [enable | disable]
        # end

Wird dieses Feature aktiviert so steht eine neue Menüposotion zur Verfügung:

        System > Custome Languages

        [[Datei:Fortinet-2022.jpg]]

Unter der Position "View/Download Sample Language Template" kann ein Beispiel eines Custome Language File runtergeladen werden. Dieses kann als Vorlage dienen um ein entsprechendes Sprachefile für ein SSL-VPN Portal zu erstellen. Nachfolgend ein Beispiel dieses "Sample Language Template":
        
        [[Datei:sample-language-template-54.txt]]

Nachdem das entsprechende Sprachefile erstellt wurde, kann dieses über die "Custome Language" Menüposition wieder hochgeladen werden. Vergebe dazu einen Namen sowie eine Beschreibung:

        [[Datei:Fortinet-2023.jpg]]

Nachträglich kann das entsprechende Sprachfile in einem SSL-VPN Portal Profile definiert werden:

        VPN > SSL VPN Portals > [Wähle das entsprechende SSL-VPN Portal Profile] > Language

        [[Datei:Fortinet-2024.jpg]]

Das Sprachefile kann ebenfalls benutzt werden für "SSL VPN Personal Bookmarks" Funktion. Das entsprechende Sprachefile für diese Funktion "SSL VPN Personal Bookmarks" kann nur über CLI konfiguriert werden:
   
       # config vpn ssl web user-bookmark
       # edit [Wähle einen entsprechenden Namen für die Bookmarks]
       # set custom-lang  [Wähle das entsprechende Sprachfile]
       # end
       # end

Die Funktion "SSL VPN Personal Bookmarks" steht nicht per Standard über das Mgmt. Web Interface einer FortiGate zur Verfügung. Wie dieses Feature aktiviert wird siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

=== Wie kann ich unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode ein Windows OS Check konfigurieren? ===

Mit einem SSL-VPN Portal/Tunnel Mode ist es möglich einen sogenannten Windows OS Check auszuführen dh. wenn der User zB über den Browser die SSL-VPN Seite für das Portal öffnet, wird im Hintergrund ein sogenannter Windows OS Check ausgeführt. Dieser Windows OS Check überprüft im Hintergrund anhand der Client/Host Software ob ein bestimmtes OS installiert ist und über einen bestimmten Patch Level verfügt. Beim Patch Level wird konfiguriert über welchen Patch Level er im Minimum verfügt! Ist dieser Windows OS Check erfolgreich wird die entsprechende Login Seite des SSL-VPN Portal geöffnet. Dieser Windows OS Check kann ebenfalls im gleicher Art und Weise für den Tunnel Mode benützt werden dh. Versucht sich ein User über SSL-VPN Tunnel Mode einzloggen, wird das Einloggen nur dann erlaubt wenn der Windows OS Check erfolgreich ist. Dies erlaubt zB ob ein Zugriff über einen bestimmten Device resp. Client/Host der über einen bestimmten Patch Level verfügt erlaubt ist oder nicht. Damit dieser Windows OS Check im SSL-VPN Portal/Tunnel Mode angewendet werden kann, muss die SSL-VPN Client/Host Software dh. FortiClient auf dem Client/Host installiert werden. Ist dies nicht der Fall wird der Zugriff verhindert. Der Grund ist der Folgende: Um den Windows OS Check durchzuführen mit dem entsprechenden Patch Level, muss anhand einer lokalen Software dh. FortiClient dies überprüft werden. Da die FortiClient Software als Administrator installiert werden muss, sind die Voraussetzungen gegeben um den entsprechenden Windows OS Check mit entsprechenden Patch Level auszuführen! Ausgehend davon, dass ein SSL-VPN Portal/Tunnel Mode korrekt konfiguriert und getestet wurde kann diese Konfiguration für einen Windows OS Check erweitert werden. Wie eine SSL-VPN Portal/Tunnel Mode Konfiguration durchgeführt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]

Die Funktion des Windows OS Check muss im entsprechenden SSL-VPN Portal/Tunnel Mode Profile direkt konfiguriert werden:

        # config vpn ssl web portal
        # edit [Name des entsprechenden Portals im Web Mode/Tunnel Mode]
        # set os-check [enable | disable]
        # config os-check-list [windows-7 | windows-8 | windows-8.1 | windows-2000 | windows-vista | windows-xp]
        # set action [check-up-to-date | deny | allow]
        # set latest-patch-level [1 - 255]
        # set tolerance 1
        # end
        # end

Wird die "action" auf "allow" gesetzt muss kein entsprechender Patch Level definiert werden da nur kontrolliert wird ob der Client/Host über das definierte "OS" verfügt. Möchte man einen minimum Patch Level konfigurieren, muss die Option "check-up-to-date" gesetzt werden! Wird "check-up-to-date" gesetzt, wird mit dem entsprechenden "latest-patch-level" der minimum Patch Level definiert. Somit steht die Definition "tolerance" im direkten Zusammenhang mit "latest-patch-level". Dies bedeutet: die "tolerance" definiert -1 für die Definition "latest-patch-level". Die Option kann differnziert angewendet werden dh. möchte man zB "windows-7" im "latest-patch-level" mit einer  "tolerance 1" erlauben jedoch "windows-xp" nicht, würde man folgendes konfigurieren:
             
        # config vpn ssl web portal
        # edit [Name des entsprechenden Portals im Web Mode/Tunnel Mode]
        # set os-check enable
        # config os-check-list windows-7
        # set action check-up-to-date
        # set latest-patch-level 2
        # set tolerance 1
        # end
        # config os-check-list windows-xp
        # set action deny
        # end
        # end

=== Wie kann ich unter FortiOS 5.4 für SSL-VPN Funktion für den SSL-VPN Deamon/Service einen Restart ausführen? ===

Die normale Vorgehensweise auf einem FortiOS einen Deamon/Service neu zu starten ist über das Kommando "diagnose test application". Jedoch steht für die SSL-VPN Funktion kein entsprechender Befehl zur Verfügung. Eine nicht offizielle Variante ist den SSL-VPN Deamon/Service über dessen PID (Process ID) und anhand des "kill" Befehls neu zu starten. Damit dies durchgeführt werden kann, muss zuerst die PID (Prozess ID) eruiert werden:

        # diagnose sys top 5 20

In der Liste die ausgegeben wird, werden alle Deamons/Service aufgelistet mit deren PID. Dabei ist unter normalen Umständen der Deamon/Service für SSL-VPN auch enthalten mit dem Namen "sslvpnd". Die zweite Spalte der List gibt die PID an. Folgendes Beispiel:

        sslvpnd       76      S      0.0    1.2

Eine andere Variante die Prozess ID (PID) zu eruieren ist über den folgenden Befehl:

        # fnsysctl ls -l /var/run/

Auch hier wird eine Liste ausgegeben mit allen Deamon/Services die auf dem System existieren. Im Gegesatz zu "diagnose sys top" werden jedoch Files aufgelistet der Deamon/Services und in diesen Files sind die jeweiligen PID der Deamon/Services enthalten. Unser Deamon/Service File hat den Namen:

        sslvpnd.pid

Um nun das entsprechende File des Deamon/Service auszulesen um die PID zu erhalten führe folgendes aus:

        # fnsysctl more /var/run/sslvpnd.pid
        76

Nun kann der SSL-VPN Deamon/Service neu gestartet werden anhand des "kill" Befehls sowie dem entsprechenden "kill level":

        # diagnose sys kill [Kill Level/Sequenz 1 - 32 wobei 11 den Prozess Stoppt und neu Startet] [PID des Prozesses zB. "76"]

Um einen erfolgreichen Neustart des Deamons/Service zu bestätigen kann wiederum die PID eruiert werden und diese trägt bei einem Neustart nun eine neue PID Nummer:

        # fnsysctl more /var/run/sslvpnd.pid
        7101

=== Gibt es unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode die Möglichkeit dem Deamon/Service mehr Resourcen zu zuweisen? ===

Wenn ein SSL-VPN Portal/Tunnel Mode auf einer FortiGate als Deamon/Service (sslvpnd) den Usern zur Verfügung gestellt wird, kann diessem Deamon/Service mehr Resourcen zugewiesen werden. Dies ist jedoch nur möglich auf grösseren FortiGate Devices resp. FortiGate Devices die über mehrer CPU's verfügen. Mehr Resourcen werden zur Verfügung gestellt, in dem die "worker" Anzahl erhöht wird dh. damit stehen mehr "worker" innerhalb des Deamons/Services für SSL-VPN zur Verfügung. Dies benötigt jedoch im Hintergrund ebenfalls mehr CPU Resourcen sowie Memory. Die "worker" Anzahl kann nicht nur erhöht werden sondern auch limitiert. Die dazu zur Verfügung stehenden Kommandos sind die Folgenden:

        # config system global
        # set ssl-worker-count [Anzahl "worker" Anzahl 0 - 4294967295; Standard 0]
        # set sslvpn-max-workercount [Maximum Anzahl "worker" Prozesse für SSL-VPN; Standard 39]

In diesem Zusammenhang stehen ebenfalls folgende zwei Optionen zur Verfügung, die für die Beschleuningung im SSL-VPN zuständig sind dh. durch die Aktivierung der zwei folgenden Optionen wird eine Hardware Beschleunigung über den Content Prozessor durchgeführt für "kpx" sowie "cipher". Dies bedeutet: Ueber den Content Prozessor wird die Verschlüsselung/Entschlüsselung des SSL-VPN Traffics durchgeführt:

        # config system global
        # sslvpn-kxp-hardwareacceleration [enable | disable]
        # sslvpn-cipherhardware-acceleration [enable | disable]
        # end

=== Gibt es unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode eine Statistik betreffend Resourcen? ===

Eine SSL-VPN Portal/Tunnel Statistik betreffend Resourcen kann über CLI anhand folgenden Befehls aufgelistet werden:

        # diagnose vpn ssl statistics 
        SSLVPN statistics (root):
        ------------------
        Memory unit:               1
        System total memory:       1928445952
        System free memory:        1473814528
        SSLVPN memory margin:      314572800
        SSLVPN state:              normal
        
        Max number of users:       0
        Max number of tunnels:     0
        Max number of connections: 0
        
        Current number of users:       0
        Current number of tunnels:     0
        Current number of connections: 0

Bei dieser Statistik ist folgendes zu berücksichtigen: Wenn der "SSLVPN state" von "normal" auf "busy" wechselt, geht/befindet sich der SSL-VPN Deamon/Service im Conserve Mode. Oft ist der "busy" Status zurückzuführen auf zuwenig Memory resp. Resourcen. Wenn der SSL-VPN Deamon im Conserve Mode ist, heisst dies nicht das sich die FortiGate im Conserve Mode befindet! Die Ursache wieso der SSL-VPN Deamon/Service sich im Conserve Mode befindet sollte untersucht werden da dies geschieht um nicht die ganze FortiGate zu beeinträchtigen. Somit ist der Conserve Mode des SSL-VPN Deamons nicht gleich Conserve Mode des FortiOS!

=== Wie kann ich auf einer Windows Workstation einen FortiSSLVPNclient Stoppen sowie Starten? ===

Bei einem FortiSSLVPNclient handelt es sich um den SSL only Software Client für ein SSL-VPN Verbindung für Tunnel Mode. Diese Client Software darf nicht verwechselt werden mit der FortiClient Endpoint Security Software dh. die SSL only Funktion ist zwar im FortiClient Endpoint Security VPN-only Mode enthalten, jedoch sind die beiden Software Package grundsätzlich verschieden. Wir empfehlen Grundsätzlich die FortiClient Endpoint Security Software im VPN-only Mode einzusetzen da dieses Package über IPSec Mode und/oder SSL-VPN Mode verfügt. Diese Packages für den FortiClient Endpoint Security VPN-only Mode werden über folgenden Link zur Verfügung gestellt:

        [[FortiGate:KonfigExample#Typische_KMU_Konfiguration]]

Beachte dabei folgendes: FortiClient Entpoint Security in der Version 5.0 kann nicht unter FortiOS 5.4 eingesetzt werden. Somit muss unter FortiOS 5.4 der FortiClient Endpoint Security in der Version 5.4 oder ab 5.2.5 eingesetzt werden. Wenn dennoch der FortiSSLVPNclient eingesetzt wird und dieser gestoppt und/oder neu gestartet werden soll, kann dies auf einer Windows Workstation in einer DoS Box durchgeführt werden:

        > FortiSSLVPNclient.exe [connect | disconnect]

Für "FortiSSLVPNclient.exe" stehen zusätzliche folgende Optionen zur Verfügung:

        [[Datei:Fortinet-1596.jpg]]

Wurde der FortiClient Endpoint Security VPN-only Mode installiert und man möchte verhindert das dieser automatisch startet siehe nachfolgenden Artikel:
             
        [[FortiClient:FAQ#Wie_kann_ich_verhindern_das_der_FortiClient_Endpoint_Security_auf_einer_Workstation_einen_automatischen_Start_ausf.C3.BChrt.3F]]

== IPSec / VPN ==

=== Wird unter FortiOS 5.4 für ein IPSec VPN auf einem FortiGate Device ein "Offloading" durchgeführt? ===

Unter FortiOS 5.4 wird automatisch ein "Offloading" für IPSec VPN durchgeführt. Dabei ist zu beachten: Ein "Offloading" wird für "Diffie-Hellman Key" Austausch sowie für den "ESP Traffic" durchgeführt. Neu kann dieses "Offloading" im IPSec VPN Bereich auch deaktiviert werden:

        # config system global
        # set ipsec-asic-offload [enable | disable]
        # end

Per Standard ist das "Offloading" aktiviert. Unter gewissen Umständen zB wenn ein "debug" durchgeführt wird ist es ratsam dieses "Offloading" vorübergehend zu daektivieren. Wenn ein IPSec VPN durch eine FortiGate konfiguriert wird dh. wenn dieses nicht terminiert wird auf der FortiGate dh. kein "unencrypt" durchgeführt wird, und sofern der FortiGate Device über einen NP6 Prozessor verfügt, wird ein "Offloading" für diesen Traffic des IPSec VPN's über den NP6 Prozessor durchgeführt.

=== Was sind die Unterschiede/Grundlagen eines IPSec Site2Site VPN Tunnels im "Main Mode" und "Aggressive Mode"? ===

Wenn ein IPSec Site2Site VPN Tunnel sei es im "Main Mode" oder "Aggressive Mode" konfiguriert und später anhand eines Troubleshooting untersucht werden muessen, ist es Wichtig zu wissen wie ein IPSec Site2Site VPN Tunnel funktioniert in der Phase-1/2 um festzustellen in welchem Schritt der Aufbaus ein IPSec Site2Site VPN fehlschlägt. Bei der Wahl des Modes ist dabei folgendes festzuhalten: Eine Site2Site VPN Konfiguration sollte sofern möglich im "Main Mode" konfiguriert werden. Nur in Ausnahmefällen dh. zB für Fremdhersteller sollte der "Aggressive Mode" gewählt werden dh. wenn diese ein "Aggressive Mode" voraussetzen! Im Grundsatz für ein "Main Mode" oder "Aggressive Mode" wird ein Site2Site VPN Tunnel in 4 Schritten aufgebaut:

        Schritt 1: Ein Site2Site IPSec Tunnel wird dann aufgebaut, wenn lokaler Traffic initiert wird um eine Destination der Remote Seite zu erreichen!
                   Dadurch wird ein IPSec Site2Site VPN Tunnel aufgebaut um den Traffic durch den IPSec Site2Site VPN Tunnel (encrypted und encapsulated)
                   zur Remote Seite senden zu können!
        
        Schritt 2: In der Phase-1 wird eine einzelne IKE SA ausgetauscht. Dies stellt die "Security Association" dar!
        
        Schritt 3: In der Phase-2 werden zwei IKE SA ausgetauscht dh. der "Security Association" und zwar für jede Richtung des Traffics dh. in/out!
        
        Schritt 4: Traffic wird über den etablierten IPSec Tunnel gesendet (in/out)!

Diese 4 Schritte stellen eine Grobübersicht dar des Aufbaus eines Site2Site VPN Tunnels. Somit ist in einem Troubleshooting Wichtig zu wissen, welcher Schritt konnte nicht durchgeführt werden um den Site2Site VPN Tunnel zu etablieren damit das Problem eingegrenzt werden kann! Dies bedeutet als Beispiel: Ist Phase-1 abgeschlossen ist das "Pre-Shared-Secret" nicht das Problem, denn dieser  Schritt wurde bereits abgeschlossen. Zusätzlich zu diesen 4 Schritten ist es Wichtig zu wissen wie ein "Main Mode" oder "Aggressive Mode" funktioniert dh. welche detail Schritte werden für diese 2 Modi durchgeführt und wo liegen die Unterschiede! Nachfolgend werden diese zwei Mode mit den detail Schritten beschrieben:

        '''Main Mode Komunikation'''
        
        • Für die Etablierung des "Main Mode" werden 6 Packete für die Komunikation benutzt:
        
        [[Datei:Fortinet-1422.jpg]]
        
        Packet 1: Ein lokaler Client (Initiator) initiert Traffic für die Remote Seite der den IPSec Site2Site VPN Tunnel
                  und somit eine oder mehrere Sicherheitsrichtlinien benützt.
        Packet 2: Der Responder selektiert seine Sicherheitsrichtlinien die er benützen will und antwortet.
        Packet 3: Der Client der den Traffic initiert hat sendet seinen Key.
        Packet 4: Der Responder antwortet ebenfalls mit seinem Key.
        Packet 5: Der Client sendet Final seine Peer ID und den hash payload.
        Packet 6: Der Responder antwortet ebenfalls mit der Peer ID und dem hash payload.
        
        Im Gegensatz zum "Aggressive Mode" sendet der Initiator im "Main Mode" seine Peer-ID nicht zu Beginn. Somit kann die FortiGate die IPSec
        VPN Verbindung nicht mit dieser Information identifizieren. Als Identifikation wird die Source IPv4 Adresse benutzt! die Peer-ID wird im
        "Main Mode" zu einem späteren Zeitpunkt übermittelt und kann somit nicht verwendet werden für die Identifizierung der Verbindung. Aus 
        diesem Grund wird der "Main Mode" Hauptsächlich im Site2Site IPSec VPN Verfahren benutzt und um die einzelnen Client2Site IPSec VPN (Dial-Up)
        eindeutig anhand der "Local-ID" zu Identifizieren der "Aggressive Mode" da die "Local-ID" zur Identifizierung der IPSec VPN Verbindung in
        der Phase-1 übermittelt wird.

        '''Aggressive Mode Komunikation'''
        
        • Für die Etablierung des "Aggressive Mode" werden 3 Packete für die Komunikation benutzt:
        
        [[Datei:Fortinet-1423.jpg]]
        
        Packet 1: Ein lokaler Client (Initiator) initiert Traffic für die Remote Seite der den IPSec Site2Site VPN Tunnel
                  und somit eine oder mehrere Sicherheitsrichtlinien benützt. Die Key-ID sowie Peer ID (Local-ID) werden in 
                  diesem Schritt zur Remote Seite gesendet.
        Packet 2: Der Responder antwortet mit den gleichen Informtionen plus sendet dieser seinen "hash".
        Packet 3: Der Initiator sendet dem Responder den "hash payload".
        
        Die "Peer-ID" zur Identifizierung der IPSec VPN Verbindung wird in der Phase-1 im "Aggressive Mode" als "Local-ID" konfiguriert und 
        übermittelt. Im "Main Mode" wird die Source IPv4 Adresse benutzt um die IPSec Verbindung zu identifizieren, denn die "Local-ID" 
        (Peer-ID) wird im "Main Mode" zu einem späteren Zeitpunkt übermittelt. Somit kann diese "Local-ID" im "Aggressive Mode" benutzt 
        werden um verschiedenen gleichzeitige IPSec VPN Phase-1 Verbindungen zu unterscheiden! Aus diesem Grund wird der "Aggressive Mode" 
        Hauptsächlich benutzt für Client2Site IPSec VPN (Dial-Up) um die einzelnen verschiedenen existierenden Phase-1 für die verschiedenen
        Devices anhand der "Local-ID" in der Phase-1 zu identifizieren.

Desweiteren ist zu berücksichtigen, wenn auf einem FortiOS mehrere Phase-1 Konfigurationen existieren diese nach folgenden Kriterien selektiert werden:

        • Für alle eingehenden IPSec VPN Verbindungen selektiert das FortiOS die IPSec VPN Verbindung in "Alphabetischer Reihenfolge"
          nach folgenden Kriterien:
          
          1. Local Gateway
          2. Mode (Main Mode oder Aggressive Mode)
          3. Peer ID (Local ID) sofern Aggressive Mode
          4. Authentication Methode (Pre-Shared Key or PKI)
          5. Zertifikats Informationen sofern PKI

Ein Site2Site IPSec VPN wird durch die Lokale IPv4 Adresse definiert sowie der Remote Gateway IPv4 Adresse und im "Main Mode" stellt dies keine Probleme dar. Existieren jedoch mehrere Phase-1 für Client2Site VPN (Dial-UP) sollte für die Identifizierung der "Aggressive Mode" benützt werden denn durch die konfigurierte "Local-ID" (Peer-ID) in der Phase-1 sowie auf der Client Seite kann die IPSec Client2Site VPN Verbindung eindeutig identifiziert werden. Dabei ist auch zu berücksichtigen, das der "Pre-Shared-Key" kein selektierungs Kriterium für eine IPSec VPN Verbindung ist.

=== Wie kann ich unter FortiOS 5.4 für eine IPSec VPN Verbindung ein Troubleshooting (Debug) durchführen? ===

Wenn eine IPSec VPN Verbindung sei es für Client2Site und/oder Site2Site in der Phase-1 und/oder Phase-2 ein Troubleshooting durchgeführt werden soll, kann dies anhand des Debug Kommandos durchgeführt werden. Dabei ist folgendes zu berücksichtigen: Dieses Troubleshooting anhand des Debug Kommandos zeigt nur den Traffic resp. die Etablierung der Phase-1 und/oder Phase-2. Der Traffic eines Hosts/Clients als Initiator und/oder Responders wird nicht aufgezeigt. Das Debug Kommando für die Phase-1 und 2 basiert auf folgenden Befehl:

        # diagnose application ike [Debug Level]

Im Grundsatz kann der tiefste Debug Level benützt werden um alle Nachrichten im Debug auszugeben dh. "-1". Es stehen jedoch verschiedenen dezidierte Debug Level zu Verfügung um nur spezifische Informationen der Phase-1 und 2 im Debug auszugeben. Es sind dies die folgenden Debug Level:

        -1 Alle Debug Informationen werden ausgegeben
         1 Nur die Wichtigsten Error Meldungen werden angezeigt
         2 Zeige nur Konfigurations Aenderungen
         4 Zeige nur Verbindungsversuche
         8 Zeige nur Phase-1 sowie Phase-2 Komunikations Meldungen
        16 Zeige nur NAT-T Meldungen (Nat-Traversal)
        32 Zeige nur DPD Meldungen an
        64 Zeige nur Encryption/Decryption Key's an
        128 Zeige nur den Encryption Traffic payload 

Speziell wenn mehrere IPSec VPN Verbindungen auf einem FortiOS konfiguriert wurden, ist es wichtig einen Filter zu konfigurieren/anzuwenden um zB nur den Output einer spezifische IPSec Verbindung anzeigen zu lassen. Dazu steht folgender Befehl zur Verfügung:

        # diagnose vpn ike log-filter ?
        
        list         Display the current filter.
        clear        Erase the current filter.
        name         Phase1 name to filter by.
        src-addr4    IPv4 source address range to filter by.
        dst-addr4    IPv4 destination address range to filter by.
        src-addr6    IPv6 source address range to filter by.
        dst-addr6    IPv6 destination address range to filter by.
        src-port     Source port range to filter by.
        dst-port     Destination port range to filter by.
        vd           Index of virtual domain. -1 matches all.
        interface    Interface that IKE connection is negotiated over.
        negate       Negate the specified filter parameter.

Somit kann anhand dieses Befehls zB die Phase-1 anhand des "name" ein Filter gesetzt werden:

        # diagnose vpn ike log-filter name [Name der Phase-1]

Danach kann nachträglich nach Konfiguration des Filters dieser mit folgendem Befehl kontrolliert werden:

        # diagnose vpn ike log-filter list
        vd: any
        name: [Name der Phase-1]
        interface: any
        IPv4 source: any
        IPv4 dest: any
        IPv6 source: any
        IPv6 dest: any
        source port: any
        dest port: any

Der Filter kann modifziert und nach Gebrauch mit folgenden Befehl gelöscht werden:

        # diagnose vpn ike log-filter clear

Zusätzlich um sich über ein IPSec VPN Tunnel den Ueberblick zu verschaffen, steht folgendes Kommando zur Verfügung das jedoch nur Informationen ausgiebt, wenn ein IPSec VPN Tunnel etabliert resp. aktiv ist:

        # get vpn ipsec tunnel [details | name | summary]
        
        details     List all IPSec tunnels in details.
        name        List IPSec tunnel by name.
        summary     List all IPSec tunnels in summary.

        # get vpn ipsec stats [crypto | tunnel]
        
        crypto      IPSec crypto statistic
        tunnel      IPSec tunnel statistic

Die Grundlagen resp. Informationen und Möglichkeiten für ein Troubleshooting sind nun bekannt und somit kann ein Debug anhand dieser Informationen ausgeführt werden. Dabei ist folgendes zu berücksichtigen: Ein Debug kann sehr viele Informationen enthalten und sollte deshalb nicht über eine RS-232 Mgmt. Console des FortiGate Devices ausgeführt werden (Buffer Limitierung). Ebenso ist es zu empfehlen die Debug Informationen in ein Log File zu schreiben, damit die Informationen für eine Analyse später zur Verfügung stehen. Ein Debug für IPSec VPN Phase-1 und/oder Phase-2 sollte somit folgendermassen durchgeführt werden:

        '''Verbinde dich anhand SSH zum FortiGate Device'''
        
        Wenn anhand "putty" eine SSH Verbindung zu einem FortiGate Device etabliert wird, kann vorgängig ein Log 
        File über folgende Position innerhalb der "putty" Konfiguration aktiviert/konfiguriert werden:
        
        Category > Session > Logging > All Session output

        '''Setze den "debug" Filter zurück'''
        
        # diagnose debug reset

        '''Aktiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp enable

        '''Aktiviere für "application ike" einen entsprechenden Filter'''
        
        # diagnose vpn ike log-filter [Setze eine entsprechende Filter zB "name [Name Phase-1]"]

        '''Kontrolliere für "application ike" den gesetzen Filter'''
        
        # diagnose vpn ike log-filter list

        '''Aktiviere den entsprechenden Debug Level für "ike"'''
        
        # diagnose debug application ike [Aktiviere den entsprechenden "ike" Debug Level zB "-1"]

        '''Aktiviere den Debug Modus'''
        
        # diagnose debug enable

Damit nun ein entsprechender Debug Output generiert wird, muss Traffic eines CLients/Hosts für die Remote Seite initiert werden damit Phase-1 und Phase-2 etabliert werden. Dies kann zB anhand eines "icmp" Traffic vom Initiator zur Remote Seite erreicht werden wobei darauf zu achten ist, dass der entsprechende Traffic durch eine Firewall Policy Rule erlaubt ist! Nun wird ein entsprechender Output der Phase-1 und 2 durch diesen Traffic aufgezeichnet. Nachfolgendes Dokument von Fortinet zeigt anhand eines Beispiel für eine Site2Site IPSec VPN Verbindung zweier FortiGate Devices auf welche Fehler resp. Fehlermeldungen entstehen können und was deren Bedeutung ist:

        [[Datei:Fortigate-IPSEC-Debugging.pdf]]

Um den Debug Mode zu beenden kann nachfolgender Befehl in die SSH Console kopiert werden gefolgt von [ENTER]. Dieser Befehl deaktiviert den laufenden Debug Mode:

        '''Deaktiviere die Debug Funktion'''
        
        # diagnose debug disable

Nachdem der Output erfolgreich erzeugt wurde resp. das Troubleshooting beendet wurde und nicht mehr benötigt wird, sollten alle Filter und Debug Level zurückgesetzt werden:

        '''Dektiviere für den debug "output" den "timestamp"'''
        
        # diagnose debug console timestamp disable

        '''Setze den "ike log-filter" Filter zurück'''
       
        # diagnose vpn ike log-filter clear

        '''Setze alle Debug Filter zurück'''
       
        # diagnose debug reset

Wenn ein IPSec Site2Site VPN in der Phase-1 und 2 erfolgreich etabliert wurde, jedoch kein Traffic durch den VPN Tunnel gesendet werden kann, so muss ein tiefergreifendes Troubleshooting durchgeführt werden. Das nachfolgendes Textfile zeigt wie so ein Troubleshooting durchgeführt wird um die entsprechenden Debug Informationen zu erhalten und diese nachträglich anhand eines Tickets im Support Level P3 Fortinet zu übermitteln:

        [[Datei:FGT-Site2Site-Full-Debug-VPN-Up.txt]]

=== Wie kann ich unter FortiOS 5.4 eine Konfigurierte IPSec VPN Verbindung von Grundauf neu Starten/Initieren? ===

Wenn eine IPSec VPN Verbindung speziell für Site2Site VPN Konfiguriert wurde und nachträglich an dieser Konfiguration Aenderungen durchführt werden wie zB Encryption, Routing usw. Ist es wichtig, dass dieses Site2Site VPN auf beiden Seiten neu gestartet wird resp. Routing Informationen auf den neusten Stand gebracht werden sowie die Konfigurationsänderungen. Dabei steht unter FortiOS 5.4 auf dem Mgmt. Web Interface die Möglichkeit zur Verfügung über die folgende Position ein IPSec mit "up/down" neu zu starten:

        Monitor > IPsec Monitor [Markiere einen entsprechenden VPN Tunnel] > [Rechte Maustaste wähle "up/down"]

Um Routing Informationen auf einem FortiGate Device vollumfänglich neu zu initieren führe folgenden Befehl auf der CLI aus:

        # execute router restart

Diese Möglichkeit über Mgmt. Web Interface anhand "up/down" eine IPSec VPN Verbindung neu zu starten stellt zwar eine Möglichkeit dar, jedoch wird dadurch der entsprechenden IPSec VPN Tunnel nicht von Grundauf neu etabliert! Dies bedeutet: Die "Security Association" der Phase-1 wird dadurch nicht gelöscht und neu initiert. Diese Möglichkeit über Mgmt. Web Interface entspricht den folgenden Kommandos in der CLI die ausschliesslich im Zusammenhang stehen mit der Phase-2 und somit bestätigen das die Phase-1 resp. die "Security Association" nicht beeinflusst wird:

        # diagnose vpn tunnel down [Name Phase-2]
        # diagnose vpn tunnel up [Name Phase-2]

Um die Phase-2 zu beinflussen dh. zB ein "reset" durchzuführen stehen für das Kommando "diagnose vpn tunnel" weitere Optionen zur Verfügung:

        # diagnose vpn tunnel ?
        down         Shut down tunnel
        up           Activate tunnel
        list         List all tunnel
        dialup-list  Lit dialup tunnel
        reset        Flush tunnel SAs and reset NT-T and DPD configuration
        flush        Flush tunnel SAs
        delinbsa     Remove tunnel sa
        deloutbsa    Remove tunnel sa
        dumpsa       Dump all sa
        Stat         Tunnel statistic info

Wenn ein Neustart der Phase-2 nicht den gewünschten Erfolg bringt, wird oft als letzte Alternative ein Neustart des FortiGate Devices durchgeführt, was natürlich den gewünschten Erfol bringt jedoch nicht in jeder Situation möglich ist resp. sinnvoll ist da ein Unterbruch durch den Neustart des FortiGate Devices verursacht wird! Somit sollen IPSec VPN Verbindung auf einem FortiGate Device von Grundauf neu gestartet werden, kann damit die Informationen und Konfigurationsaenderungen in der Phase-1 komplett erneuert werden folgender Befehl ausgeführt werden:

       # diagnose debug reset
       # diagnose debug application ike 2 
       # diagnose debug enable 
       # diagnose vpn ike restart 

Das Komando "application ike 2" wird durchgeführt um die Konfigurtionsaenderungen anzuzeigen und mit "diagnose debug enable" zu kontrollieren ob die Phase-1 sowie 2 korrekt etabliert wurden! Dabei ist jedoch zu berücksichtigen, dass durch "diagnose vpn ike restart" alle IPSec VPN Verbindungen auf einem FortiOS neu gestartet werden und somit für alle Konfigurierten IPSec VPN Verbindungen ein Unterbruch stattfindet. Soll nur eine bestimmte IPSec VPN Verbindung neu gestartet werden, kann folgender Befehl benutzt werden:

       # diagnose debug reset
       # diagnose debug application ike 2 
       # diagnose debug enable 
       # diagnose vpn ike gateway flush [name Phase 1]

== IPSec / L2TP ==

=== Wie wird unter FortiOS 5.4 für einen FortiGate Device eine IPSec VPN basierend auf L2TP konfiguriert? ===

Unter FortiOS 5.4 kann neu eine IPSec VPN basierende L2TP Verbindung für Windows auf Interface Based VPN konfiguriert werden. Unter FortiOS 5.2 sind IPSec VPN Verbindungen basierend auf L2TP nur als Policy Based VPN konfigurierbar. Der Vorteil einer Policy Based IPSec VPN Verbindung basierend auf L2TP, ist das verschiedenen Devices diese benutzen können dh. IOS Devices, Android usw. Damit ein Policy Based VPN konfigiert werden kann muss im Mgmt. Web Interface die Funktion für Software Based VPN's in der CLI aktiviert werden. Dazu muss folgendes ausgeführt werden:

        # config system settings
        # set gui-policy-based-ipsec [enable | disable]
        # end

In den nachfolgenden Schritten wird erklärt wie ein Interface Based VPN für IPSec VPN L2TP sowie ein Policy Based VPN für IPSec VPN L2TP konfiguriert wird. Die einfachste Art und Weise ist dies über CLI zu konfigurieren. Führe folgendes aus:

        '''IPSec VPN L2TP Phase-1 und Phase-2 Interface Based'''
        
        # config vpn ipsec phase1-interface
        # edit [Name der Phase-1 zB "hard-l2tp"]
        # set comments "Interface Based IPSec Phase1 L2TP"
        # set type dynamic 
        # set interface [Name des Interfaces für die Verbindung zB "wan1"]
        # set ip-version 4 
        # set ike-version 1 
        # set local-gw 0.0.0.0
        # set keylife 86400
        # set authmethod psk 
        # set mode main 
        # set peertype any 
        # set mode-cfg disable 
        # set proposal aes256-md5 3des-sha1 aes192-sha1 
        # set add-route enable 
        # set exchange-interface-ip disable 
        # set localid [Name der Local-ID zB "hard-l2tp"]
        # set localid-type auto 
        # set negotiate-timeout 30
        # set fragmentation enable 
        # set dpd on-demand 
        # set forticlient-enforcement disable 
        # set npu-offload enable 
        # set dhgrp 2 
        # set suite-b disable 
        # set wizard-type custom 
        # set xauthtype disable 
        # set idle-timeout disable 
        # set ha-sync-esp-seqno enable 
        # set auto-discovery-sender disable 
        # set auto-discovery-receiver disable 
        # set auto-discovery-forwarder disable 
        # set nattraversal enable 
        # set default-gw 0.0.0.0
        # set default-gw-priority 0
        # set psksecret [Vergebe ein Pre-Shared Secrete]
        # set keepalive 10
        # set distance 15
        # set priority 0
        # set dpd-retrycount 3
        # set dpd-retryinterval 20
        # end
        
        # config vpn ipsec phase2-interface
        # edit [Name der Phase-2 zB "hard-l2tp"]
        # set comments "Interface Based IPSec Phase2 L2TP"
        # set phase1name [Name der Phase1 zB "hard-l2tp"]
        # set proposal aes256-md5 3des-sha1 aes192-sha1 
        # set pfs disable 
        # set replay enable 
        # set keepalive disable 
        # set add-route phase1 
        # set auto-discovery-sender phase1 
        # set auto-discovery-forwarder phase1 
        # set keylife-type seconds 
        # set encapsulation transport-mode 
        # set l2tp enable 
        # set protocol 0
        # set src-port 0
        # set dst-port 0
        # set dhcp-ipsec disable 
        # set keylifeseconds 3600
        # end

        '''IPSec VPN L2TP Phase-1 und Phase-2 Policy Based'''
        
        # config vpn ipsec phase1
        # edit [Name der Phase-1 zB "soft-l2tp"]
        # set comments "Policy Based IPSec Phase1 L2TP"
        # set type dynamic 
        # set interface [Name des Interfaces für die Verbindung zB "wan1"]
        # set ike-version 1 
        # set local-gw 0.0.0.0
        # set keylife 28800
        # set authmethod psk 
        # set mode main 
        # set peertype any 
        # set mode-cfg disable 
        # set proposal aes256-md5 3des-sha1 aes128-sha1 aes192-sha1 
        # set add-route disable 
        # set exchange-interface-ip disable 
        # set localid [Name der Local-ID zB "soft-l2tp"] 
        # set localid-type auto 
        # set negotiate-timeout 30
        # set fragmentation enable 
        # set dpd on-idle 
        # set forticlient-enforcement disable 
        # set npu-offload enable 
        # set dhgrp 1 2 5 
        # set suite-b disable 
        # set wizard-type custom 
        # set xauthtype disable 
        # set idle-timeout disable 
        # set ha-sync-esp-seqno enable 
        # set nattraversal enable 
        # set psksecret [Vergebe ein Pre-Shared Secrete]
        # set keepalive 10
        # set distance 1
        # set priority 0
        # set dpd-retrycount 3
        # set dpd-retryinterval 5
        # end
        
        # config vpn ipsec phase2
        # edit [Name der Phase-2 zB "soft-l2tp"]
        # set comments "Policy Based IPSec Phase1 L2TP"
        # set phase1name [Name der Phase1 zB "soft-l2tp"]
        # set use-natip enable 
        # set proposal aes256-md5 3des-sha1 aes128-sha1 aes192-sha1 
        # set pfs disable 
        # set replay enable 
        # set keepalive enable 
        # set add-route disable 
        # set keylife-type both 
        # set encapsulation transport-mode 
        # set l2tp enable 
        # set protocol 0
        # set src-port 0
        # set dst-port 0
        # set dhcp-ipsec disable 
        # set keylifeseconds 3600
        # set keylifekbs 250000        
        # end

Die Phase-1 und 2 wurden konfiguriert. Fuer die Authentifizierung der User muss nun eine Gruppe konfiguriert werden die zur L2TP Funktion hinzugefügt wird. In dieser Konfiguration muss ebenfalls ein IP-Pool definiert werden dh. dieser IP-Pool stellt ein IPv4 Subnet dar aus diesem dem User nach erfolgreicher Authentifizierung eine IPv4 Adresse auf dem Host/Workstation zugewiesen wird. Konfiguriere ein IP-Pool Objekt sowie eine entsprechende Gruppe für die Authentifizierung und füge diese Informationen der L2TP Funktion hinzu:

        '''Konfiguriere ein IP-Pool Objekt'''
        
        # config firewall address
        # edit "net-ip-pool-ipsec-l2tp-vpn-198.18.4.128-25"
        # set comment "IPSec L2TP VPN IP-Pool"
        # set subnet 198.18.4.128 255.255.255.128
        # next
        # end

        '''Konfiguriere ein LAN Objekt'''
        
        # config firewall address
        # edit "net-local-lan-198.18.0.0-24"
        # set comment "Net LAN local"
        # set subnet 198.18.0.0 255.255.255.0
        # next
        # end

        '''Konfiguriere ein User Objekt'''
        
        # config user local
        # edit "local-0.intra"
        # set type password
        # set passwd "[Password]"
        # next
        # end

        '''Konfiguriere ein Gruppen Objekt'''
        
        # config user group
        # edit "gr-ipsec-l2tp-vpn"
        # set group-type firewall
        # set member "local-0.intra"
        # next
        # end

Nun kann diese Information der L2TP Funktion hinzugefügt werden:

        # config vpn l2tp
        # set eip [IPv4 Start IP des Ranges für IP Pool zB "198.18.4.129"]
        # set sip [IPv4 End IP des Ranges für IP Pool zB "198.18.04.254"]
        # set status enable
        # set usrgrp [Name der entsprechenden User Gruppe für L2TP zB "gr-ipsec-l2tp-vpn"]
        # end

Nun können die entsprechenden Firewall Policy Rules erstellt werden. Dabei ist zu folgendes zu beachten: Die Firewall Policy Rules sei es für Policy Based VPN und/oder Interface Based VPN bestehen aus 2 Firewall Policy Rules. Die erste Firewall Policy Rule definiert den Zugriff auf die L2TP Funktion sowie auf das WAN Interface für die Authentifizierung und die zweite Firewall Policy Rule erlaubt den Zugriff in das interne LAN Segment. Für die Definition der Firewall Policy Rule Authentication Rule benötigt man den Service L2TP (TCP/UDP Port 1701). Dieser wird folgendermassen konfiguriert:

        Policy & Objects > Services > Create New

        [[Datei:Fortinet-2103.jpg]]

Konfiguriere nun die Firewall Policy Rules für IPSec VPN L2TP Interface Based und/oder Policy Based:

        Policy & Objects > IPv4 Policy

        '''IPSec VPN L2TP Interface Based'''
        
        [[Datei:Fortinet-2100.jpg]]
        
        [[Datei:Fortinet-2101.jpg]]

        '''IPSec VPN L2TP Policy Based'''
        
        [[Datei:Fortinet-2102.jpg]]
        
        [[Datei:Fortinet-2101.jpg]]

Die Konfiguration ist abgeschlossen und ein entsprechender Host/Workstation kann basierend auf IPSec VPN L2TP für einen Test konfiguriert werden. Wie ein Windows 10 Host/Workstation basierend auf IPSec VPN L2TP konfiguriert wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_wird_unter_Windows_10_f.C3.BCr_ein_FortiOS_5.4_eine_IPSec_VPN_basierend_Verbindung_auf_L2TP_konfiguriert.3F]]

=== Wie wird unter Windows 10 für ein FortiOS 5.4 eine IPSec VPN basierend Verbindung auf L2TP konfiguriert? ===

Der nachfolgende Artikel erklärt wie unter FortiOS 5.4 eine IPSec VPN L2TP Verbindung auf einem FortiGate Device konfiguriert wird:

        [[FortiGate-5.4:FAQ#Wie_wird_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_eine_IPSec_VPN_basierend_auf_L2TP_konfiguriert.3F]]

Wenn auf einem Host/Workstation basierend auf Windows 10 eine solche IPsec VPN L2TP Verbindung zu einem FortiGate Device sei es Interface Based und/oder Policy Based konfiguriert werden solll muss folgendes durchgeführt werden:

        Start > Einstellungen > Netzwerk und Internet > VPN > VPN-Verbindung hinzufügen

        [[Datei:Fortinet-2104.jpg]]

Diese Informationen können nachträglich jederzeit geändert werden:

        [[Datei:Fortinet-2105.jpg]]

Nun kann bereits ein erster Verbindungstest durchgeführt werden! Obwohl man davon ausgeht, dass über "Erweiterte Optionen" die L2TP Verbindung in den Details konfiguriert werden kann ist dies nicht möglich. Wenn eine L2TP Verbindung konfiguriert wird so wird im Hintergrund unter den Netzwerk Adaptern ein Hybrid Adapter (WAN Miniport) erstellt der die neu konfigurierte L2TP Verbindung darstellt. Um die L2TP Verbindung in deren Details zu konfigurieren muss dies über diesen Netzwerk Adapter über dessen Eigenschaften durchgeführt werden:

        Start > Windows Durchsuchen "ncpa.cpl" > Enter

Wähle nun den "soft-hard-l2tp" WAN Miniport (L2TP) Adapter und führen eine Rechten Mausklick aus sowie wähle Eigenschaften:

        [[Datei:Fortinet-2106.jpg]]

        [[Datei:Fortinet-2107.jpg]]

        [[Datei:Fortinet-2108.jpg]]

        [[Datei:Fortinet-2109.jpg]]

Wenn die Position unter den "Erweiterten TCP/IP Einstellung" betreffend "Standardgateway für das Remotenetzwerk verwenden" aktiviert ist so wird ein "Splitt Tunneling" durchgeführt!

=== Wie kann ich unter FortiOS 5.4 für eine IPSec VPN basierend auf L2TP Konfiguration ein Debug ausführen? ===

Wenn man eine IPSec VPN Verbindung basierend auf L2TP konfiguriert und es später bei der Verbindung zu Problemen kommt kann mit nachfolgenden Befehl für diese Verbindung ein Debug ausgeführt werden. Da in diesem Output einige Informationen ausgegeben wird, sollte eine SSH Verbindung für den Debug erstellt werden sowie die Informationen des Outputs in ein Log File geschrieben werden zur späteren Analyse:

        1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
        2. Erstelle eine Consolen Verbindung zur FortiGate (RS232 basierend resp. Seriell)
        3. Führe ein Login durch und gebe folgendes ein:
          
           '''Setze alle Debug Filter zurück'''
           
           # diagnose debug reset

           '''Aktiviere den L2TP Debug Filter'''
           
           # diagnose debug application l2tp -1

           '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
          
           # diagnose debug enable 

Nun kann eine Verbindung erstellt werden:

        create_new_tunnel()-100: Allocated new Tunnel id=1, total count = 1 
        handle_control_packet()-549: 
        check_control_hdr()-173: check_control_hdr: control, peer_call_id = 0, Ns = 0, Nr = 0
        check_control_hdr()-185: Updated control rec seqno. Value is now 1
        __avp_protocol_version()-233: peer is using version 8, revision 128.
        __avp_framing_caps()-248: supported peer framing:  
        __avp_bearer_caps()-264: supported peer bearers:
        __avp_firmware_rev()-279: peer's firmware version 2048
        _avp_hostname()-295: Peer's hostname is 'DESKTOP-HSEH6HM'
        __avp_vendor()-310: peer's vendor 'Microsoft'
        __avp_assigned_tunnel()-339: peer's tunnel 1
        avp_receive_window_size()-359: peer's RWS 8.
        run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (1).  Tunnel is 1, call is 0.
        run_ctrl_state_machine()-97: ** run_ctrl_state_machine - SCCRQ **
        run_ctrl_state_machine()-108: Rule 193.193.135.65 to 193.193.135.65avp_put_hostname()-84: Sent the host name = 193.1 
        run_ctrl_state_machine()-166: Sending SCCRP
        schedule_event()-94: 
        schedule_event()-100: Message due 11066, now = 10966
        handle_control_packet()-549: 
        check_control_hdr()-173: check_control_hdr: control, peer_call_id = 0, Ns = 1, Nr = 1
        check_control_hdr()-185: Updated control rec seqno. Value is now 2
        run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (3).  Tunnel is 1, call is 0.
        run_ctrl_state_machine()-175: ** run_ctrl_state_machine - SCCCN **
        L2TPD 97: 180:Connection established to 193.193.135.65, 1701.  Local: 1, Remote: 1.
        start_hello_timer()-59: L2TP: starting Hello timer for tunnel 1, next in 60 seconds.
        schedule_event()-94: 
        schedule_event()-100: Message due 16967, now = 10967
        handle_network_packet()-271: Sending a ZLB to acknowledge last message
        send_zlb()-73: ** send_zlb **
        handle_control_packet()-549: 
        check_control_hdr()-173: check_control_hdr: control, peer_call_id = 0, Ns = 2, Nr = 1
        check_control_hdr()-185: Updated control rec seqno. Value is now 3
        __avp_assigned_call()-392: Parsed new call id of 1
        __avp_call_serno()-418: serial number is 0
        __avp_bearer_type()-445: peer's bears anamylog
        avp_handler()-723: AVP 1 was ignored 
        run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (10).  Tunnel is 1, call is 1.
        run_ctrl_state_machine()-225: ** run_ctrl_state_machine - ICRQ **
        run_ctrl_state_machine()-235: New call was created for tunnel 1, call id = 1
        run_ctrl_state_machine()-290: This call is the master_call, its peer_call_id = 2 
        run_ctrl_state_machine()-298: run_ctrl_state_machine: sending ICRP
        schedule_event()-94: 
        schedule_event()-100: Message due 11067, now = 10967
        handle_control_packet()-549: 
        check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 3, Nr = 2
        check_control_hdr()-185: Updated control rec seqno. Value is now 4
        __avp_tx_speed()-495: TX is 100000000
        __avp_frame_type()-474: peer's framing sync
        avp_handler()-723: AVP 29 was ignored 
        run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (12).  Tunnel is 1, call is 1.
        run_ctrl_state_machine()-307: ** run_ctrl_state_machine - ICCN **
        start_pppd()-180: Starting pppd
        L2TPD 29: 181:Starting call (launching pppd, opening GRE)
        run_ctrl_state_machine()-327: Call established with 193.193.135.65, Local: 2, Remote: 1, Serial: 0
        handle_network_packet()-271: Sending a ZLB to acknowledge last message
        send_zlb()-73: ** send_zlb **
        L2TPD 25: 454:Client 193.193.135.65 control connection started (id 1), assigned ip 198.18.4.130
        start_pppd()-466: /bin/pppd start_pppd()-466: 0 start_pppd()-466: l2tp start_pppd()-466: hard-l2tp start_pppd()-466: nodetach start_pppd()-466: 198.18.4.129:198.18.4.130 start_pppd()-466: +pap start_pppd()-466: +chap start_pppd()-466: peer-remote start_pppd()-466: 193.193.135.65 start_pppd()-466: lcp-echo-interval start_pppd()-466: 5 start_pppd()-466: lcp-echo-failure start_pppd()-466: 3 start_pppd()-466: dns-addr start_pppd()-466: 193.193.135.65 start_pppd()-468: 
        monitor_ctrl_pkt_xmit()-94: 
        monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.
        monitor_ctrl_pkt_xmit()-94: 
        monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.

Dazwischen sieht man immer wieder sogenannte Keepalive Nachrichten:

        send_hello()-33: L2TP: send Hello for tunnel 1 
        schedule_event()-94: 
        schedule_event()-100: Message due 35604, now = 35504
        start_hello_timer()-59: L2TP: starting Hello timer for tunnel 1, next in 60 seconds.
        schedule_event()-94: 
        schedule_event()-100: Message due 41504, now = 35504
        handle_control_packet()-549: 
        handle_control_packet()-578: L2TP received control ZLB.
        monitor_ctrl_pkt_xmit()-94: 
        monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.

Wenn eine L2TP Verbindung beendet wird so wird folgendes ausgegeben:

        handle_control_packet()-549: 
        check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 4, Nr = 6
        check_control_hdr()-185: Updated control rec seqno. Value is now 5
        __avp_assigned_call()-381: close call id 1
        run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (14).  Tunnel is 1, call is 1.
        run_ctrl_state_machine()-332: ** run_ctrl_state_machine - CDN **
        run_ctrl_state_machine()-373: Connection closed to 193.193.135.65, serial 0 ()
        handle_network_packet()-271: Sending a ZLB to acknowledge last message
        send_zlb()-73: ** send_zlb **
        l2tp_handle_calls()-309: closing The master call
        close_call()-409: ** close_call **
        close_call()-424: Closing call 2
        free_call()-227: ** free_call **
        l2tp_vdbind_msg_handler()-86: del_vdbind message:vd=root 0 devindex=77 ppp1
        handle_control_packet()-549: 
        check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 5, Nr = 6
        check_control_hdr()-185: Updated control rec seqno. Value is now 6
        __avp_assigned_tunnel()-339: peer's tunnel 1
        avp_result_code()-581: peer closing for reason 6, error = 0 ()
        run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (4).  Tunnel is 1, call is 1.
        run_ctrl_state_machine()-187: ** run_ctrl_state_machine - StopCCN **
        run_ctrl_state_machine()-218: Connection closed to 193.193.135.65, port 1701 (), Local: 1, Remote: 1
        handle_network_packet()-271: Sending a ZLB to acknowledge last message
        send_zlb()-73: ** send_zlb **
        send_to_tunnel()-708: send packet to tunnel (id=1) failed (No such device)l2tp_handle_calls()-296: closing down tunnel 1
        close_tunnel()-445: ** close_tunnel **
        close_tunnel()-458: Closing and destroying tunnel 1
        L2TPD 26: 460:Client 193.193.135.65 control connection (id 1) finished
        close_calls_for_tunnel()-109: 
        free_call()-227: ** free_call **
        free_tunnel()-126: Done close_calls_for_tunnel 
        l2tp_vdbind_msg_handler()-86: del_vdbind message:vd=root 0 devindex=76 hard-l2tp_0

Nach einem Debug sollte dieser wieder deaktiviert werden:

        '''Deaktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug disable 

Da eine L2TP Verbindung auf IPSec IKE 500 basiert kann diese Verbindung ebenfalls im IKE Debug Mode überprüft werden:

        '''Setze alle Debug Filter zurück'''
       
        # diagnose debug reset

        '''Aktiviere den IKE Debug Filter'''
        
        # diagnose debug application ike -1

        '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug enable

Nun kann eine L2TP Verbindung erstellt werden:

        ike shrank heap by 131072 bytes
        ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
        ike 0: IKEv1 exchange=Identity Protection id=aa4d18c090210beb/0000000000000000 len=408
        ike 0: in         AA4D18C090210BEB00000000000000000110020000000000000001980D0000D40000000100000001000000C801010005030000280101000080010007800E0100800200028004001480030001800B0001000C000400007080030000280201000080010007800E0080800200028004001380030001800B0001000C000400007080030000280301000080010007800E0100800200028004000E80030001800B0001000C000400007080030000240401000080010005800200028004000E80030001800B0001000C000400007080000000240501000080010005800200028004000280030001800B0001000C0004000070800D00001801528BBBC00696121849AB9A1C5B2A51000000010D0000181E2B516905991C7D7C96FCBFB587E461000000090D0000144A131C81070358455C5728F20E95452F0D00001490CB80913EBB696E086381B5EC427B1F0D0000144048B7D56EBCE88525E7DE7F00D6C2D30D000014FB1DE3CDF341B7EA16B7E5BE0855F1200D00001426244D38EDDB61B3172A36E3D0CFB81900000014E3A5966A76379FE707228231E5CE8652
        ike 0:aa4d18c090210beb/0000000000000000:1: responder: main mode get 1st message...
        ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (20): 01528BBBC00696121849AB9A1C5B2A5100000001
        ike 0:aa4d18c090210beb/0000000000000000:1: VID MS NT5 ISAKMPOAKLEY 1E2B516905991C7D7C96FCBFB587E46100000009
        ike 0:aa4d18c090210beb/0000000000000000:1: VID RFC 3947 4A131C81070358455C5728F20E95452F
        ike 0:aa4d18c090210beb/0000000000000000:1: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F
        ike 0:aa4d18c090210beb/0000000000000000:1: VID FRAGMENTATION 4048B7D56EBCE88525E7DE7F00D6C2D3
        ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (16): FB1DE3CDF341B7EA16B7E5BE0855F120
        ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (16): 26244D38EDDB61B3172A36E3D0CFB819
        ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (16): E3A5966A76379FE707228231E5CE8652
        ike 0: cache rebuild start
        ike 0:hard-l2tp: cached as dynamic
        ike 0:ipsec-cisco: cached as dynamic
        ike 0:ipsec-fc: cached as dynamic
        ike 0:ipsec-ios: cached as dynamic
        ike 0:soft-l2tp: cached as dynamic
        ike 0: cache rebuild done
        ike 0:aa4d18c090210beb/0000000000000000:1: negotiation result
        ike 0:aa4d18c090210beb/0000000000000000:1: proposal id = 1:
        ike 0:aa4d18c090210beb/0000000000000000:1:   protocol id = ISAKMP:
        ike 0:aa4d18c090210beb/0000000000000000:1:      trans_id = KEY_IKE.
        ike 0:aa4d18c090210beb/0000000000000000:1:      encapsulation = IKE/none
        ike 0:aa4d18c090210beb/0000000000000000:1:         type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.
        ike 0:aa4d18c090210beb/0000000000000000:1:         type=OAKLEY_HASH_ALG, val=SHA.
        ike 0:aa4d18c090210beb/0000000000000000:1:         type=AUTH_METHOD, val=PRESHARED_KEY.
        ike 0:aa4d18c090210beb/0000000000000000:1:         type=OAKLEY_GROUP, val=MODP1024.
        ike 0:aa4d18c090210beb/0000000000000000:1: ISAKMP SA lifetime=86400
        ike 0:aa4d18c090210beb/0000000000000000:1: SA proposal chosen, matched gateway hard-l2tp
        ike 0:hard-l2tp: created connection: 0x282d5d8 5 193.193.135.66->193.193.135.65:500.
        ike 0:hard-l2tp:1: selected NAT-T version: RFC 3947
        ike 0:hard-l2tp:1: cookie aa4d18c090210beb/aa460884c9a5fe4a
        ike 0:hard-l2tp:1: out         AA4D18C090210BEBAA460884C9A5FE4A0110020000000000000000BC0D00003800000001000000010000002C01010001000000240501000080010005800200028004000280030001800B0001000C0004000070800D0000144A131C81070358455C5728F20E95452F0D000014AFCAD71368A1F1C96B8696FC775701000D0000148299031757A36082C6A621DE000503F30D0000144048B7D56EBCE88525E7DE7F00D6C2D3000000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000
        ike 0:hard-l2tp:1: sent IKE msg (ident_r1send): 193.193.135.66:500->193.193.135.65:500, len=188, id=aa4d18c090210beb/aa460884c9a5fe4a
        ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
        ike 0: IKEv1 exchange=Identity Protection id=aa4d18c090210beb/aa460884c9a5fe4a len=260
        ike 0: in         AA4D18C090210BEBAA460884C9A5FE4A0410020000000000000001040A000084D99329CD327B8970838CA205A0D5307B49B5A0C18A7F3F8C71394C32BB4492D791D618C1485CE08FF5B40B95C9F8DADE7E9144546DC28EDBADBEE66718F9FA1F7C3AAB8B77E070F1A69F625C0EC2BC3A41CA3BB187623E698577D59BEC1444DEB2652BF8F4F34C0D2BA0ECB40E0E8CFB946CDB83FA67F48C7C18D53269EF714140000344876B5805539226D8FB6263DFC82CFC1141327CCC4FC24DC4DF2A5854856BFF6DD8FE365166AE4959FFFE5E36ED1A97414000018C3CB105F2081C65ABC507A6360B420BD6C63A504000000186E3667290C70AF03888129732489F98C2F2008F1
        ike 0:hard-l2tp:1: responder:main mode get 2nd message...
        ike 0:hard-l2tp:1: NAT not detected 
        ike 0:hard-l2tp:1: out         AA4D18C090210BEBAA460884C9A5FE4A0410020000000000000000E40A0000841F28ABB22B649D97C001F6E6612A4F6F188F62B588094828060FECB6BA59E4FAD2F5A9BC6C9FA77801B35ECD8EB56DF560F3F0BAE9399D274AA0CB525299B012E89F553F46C810DE2FDD3A404F562A59A8E7C3B6713D2908B97C2504B3DD273D2D3D896E6315BC2E7D626E9B8086277F1E512729C800D5A802A51A39A79A16A01400001432115D76A5E09AE02500AC02F8C49809140000186E3667290C70AF03888129732489F98C2F2008F100000018C3CB105F2081C65ABC507A6360B420BD6C63A504
        ike 0:hard-l2tp:1: sent IKE msg (ident_r2send): 193.193.135.66:500->193.193.135.65:500, len=228, id=aa4d18c090210beb/aa460884c9a5fe4a
        ike 0:hard-l2tp:1: ISAKMP SA aa4d18c090210beb/aa460884c9a5fe4a key 24:EF2D0070A61A6C8EB939A82DCE075EB1C9A070E8829BA92B
        ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
        ike 0: IKEv1 exchange=Identity Protection id=aa4d18c090210beb/aa460884c9a5fe4a len=68
        ike 0: in AA4D18C090210BEBAA460884C9A5FE4A0510020100000000000000440065EB6A84C809391146CD1777FE42557EFDF98F26BA183E2AB1BE971A452F6B60D81286CABBDB9D
        ike 0:hard-l2tp:1: responder: main mode get 3rd message...
        ike 0:hard-l2tp:1: dec AA4D18C090210BEBAA460884C9A5FE4A0510020100000000000000440800000C01000000C1C187410000001819096E5122DC4ABADA92067C7F4DC42A2F1CC50100000000
        ike 0:hard-l2tp:1: peer identifier IPV4_ADDR 193.193.135.65
        ike 0:hard-l2tp:1: PSK authentication succeeded
        ike 0:hard-l2tp:1: authentication OK
        ike 0:hard-l2tp:1: enc AA4D18C090210BEBAA460884C9A5FE4A0510020100000000000000450800001102000000686172642D6C3274700000001886098E8AED21AF61BAB552DBB9569262FD04D41A
        ike 0:hard-l2tp:1: out AA4D18C090210BEBAA460884C9A5FE4A05100201000000000000004CEF653FA7AE0CB6D675FE349D124EFA7E37373798AF9C9A18E48754FAA77BB95D4771603A1BAA34CF2140219EB4DA8D95
        ike 0:hard-l2tp:1: sent IKE msg (ident_r3send): 193.193.135.66:500->193.193.135.65:500, len=76, id=aa4d18c090210beb/aa460884c9a5fe4a
        ike 0:hard-l2tp: adding new dynamic tunnel for 193.193.135.65:500
        ike 0:hard-l2tp_0: added new dynamic tunnel for 193.193.135.65:500
        ike 0:hard-l2tp_0:1: established IKE SA aa4d18c090210beb/aa460884c9a5fe4a
        ike 0:hard-l2tp_0: DPD disabled, not negotiated
        ike 0:hard-l2tp_0:1: no pending Quick-Mode negotiations
        ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
        ike 0: IKEv1 exchange=Quick id=aa4d18c090210beb/aa460884c9a5fe4a:00000001 len=468
        ike 0: in         AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000001D432F0F9FCBD2C46118A392716D67F4C136C97AC63BCC60BBE53F566DBD3B7D5B68C1FB3108F5577D7830F30904245D2BCA5F670FFCC961CF0B6C3DEFBE5365AA7BA96C7353BCCA7A0E3C9DC2459C416EF5607CBF56C547F229F4DFF1866042D7B693635F6109417312373D569E974567485C281FFCACE6895DF2422C645EF70AA03309958AA0C587B8AF18AD11D6393E6D1584122964EE63B3459F2D42F2714459C116744DFC2804F56398BBA315963709D79C84AA30841C9DDAD5930ACBF2EB96DC0E0FE621DFD7D4902921C403DC1880CEB89801D55A0F4E062F2D80CEE16761A7DAD6939F98D76F9880BC75BEBF4BA298D876330CDAFFC84CADD184E5B53CD26AC3520BD6C021EA8F9152CE7B83DF3D974CB212E8EE66FFEA7213715C51A41F527BCA12094958DF3CA8A0D2EEBD5F1CFBAD68F778EE90D2618726224B4AF6F86770FAEBCDA09545CF60F67BFCF8F6D8618107ECD32A4254E14C40CB08A943B9DBED98432C400C589B918EC535099E19AED2AA3F9807FBC6AC12C8C998049AC7E6E9C99A002B75B23AEA4E53AA483DF6C5B5131305BEBF895A3D88E3AB7EF49C92B2F8255570314F4BA6E3EC7D9CB3D8AB0225DB20427D4
        ike 0:hard-l2tp_0:1:1: responder received first quick-mode message
        ike 0:hard-l2tp_0:1: dec         AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000001D401000018A0A03E654E031396EADA663B7EDD0C07050619C60A00014C000000010000000102000038010304018E16AE560000002C010C0000800400028006010080050002800100010002000400000E1080010002000200040003D09002000038020304018E16AE560000002C010C0000800400028006008080050002800100010002000400000E1080010002000200040003D09002000034030304018E16AE5600000028010300008004000280050002800100010002000400000E1080010002000200040003D09002000034040304018E16AE5600000028010200008004000280050002800100010002000400000E1080010002000200040003D09002000034050304018E16AE5600000028010B00008004000280050002800100010002000400000E1080010002000200040003D09000000034060204018E16AE5600000028010300008004000280050002800100010002000400000E1080010002000200040003D09005000034840342D236C88544D55B7B99D07D9E34612A31304D65B32E1D6015A37DBDCA32C2C6730E89B702175EFF83F3F7937E650500000C011106A5C1C187410000000C011106A5C1C187420000000000000000
        ike 0:hard-l2tp_0:1:1: peer proposal is: peer:17:193.193.135.65-193.193.135.65:1701, me:17:193.193.135.66-193.193.135.66:1701
        ike 0:hard-l2tp_0:1:hard-l2tp:1: trying
        ike 0:hard-l2tp_0:1:1: transport mode, override with 17:193.193.135.66-193.193.135.66:1701 -> 17:193.193.135.65-193.193.135.65:0
        ike 0:hard-l2tp_0:1:hard-l2tp:1: matched phase2
        ike 0:hard-l2tp_0:1:hard-l2tp:1: dynamic client
        ike 0:hard-l2tp_0:1:hard-l2tp:1: my proposal:
        ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 1:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:   protocol id = IPSEC_ESP:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      trans_id = ESP_AES_CBC (key_len = 256)
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      encapsulation = ENCAPSULATION_MODE_TRANSPORT
        ike 0:hard-l2tp_0:1:hard-l2tp:1:         type = AUTH_ALG, val=MD5
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      trans_id = ESP_3DES
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      encapsulation = ENCAPSULATION_MODE_TRANSPORT
        ike 0:hard-l2tp_0:1:hard-l2tp:1:         type = AUTH_ALG, val=SHA1
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      trans_id = ESP_AES_CBC (key_len = 192)
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      encapsulation = ENCAPSULATION_MODE_TRANSPORT
        ike 0:hard-l2tp_0:1:hard-l2tp:1:         type = AUTH_ALG, val=SHA1
        ike 0:hard-l2tp_0:1:hard-l2tp:1: incoming proposal:
        ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 1:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:   protocol id = IPSEC_ESP:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      trans_id = ESP_AES_CBC (key_len = 256)
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      encapsulation = ENCAPSULATION_MODE_TRANSPORT
        ike 0:hard-l2tp_0:1:hard-l2tp:1:         type = AUTH_ALG, val=SHA1
        ike 0:hard-l2tp_0:1:hard-l2tp:1: incoming proposal:
        ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 2:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:   protocol id = IPSEC_ESP:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      trans_id = ESP_AES_CBC (key_len = 128)
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      encapsulation = ENCAPSULATION_MODE_TRANSPORT
        ike 0:hard-l2tp_0:1:hard-l2tp:1:         type = AUTH_ALG, val=SHA1
        ike 0:hard-l2tp_0:1:hard-l2tp:1: incoming proposal:
        ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 3:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:   protocol id = IPSEC_ESP:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      trans_id = ESP_3DES
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      encapsulation = ENCAPSULATION_MODE_TRANSPORT
        ike 0:hard-l2tp_0:1:hard-l2tp:1:         type = AUTH_ALG, val=SHA1
        ike 0:hard-l2tp_0:1:hard-l2tp:1: negotiation result
        ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 3:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:   protocol id = IPSEC_ESP:
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      trans_id = ESP_3DES
        ike 0:hard-l2tp_0:1:hard-l2tp:1:      encapsulation = ENCAPSULATION_MODE_TRANSPORT
        ike 0:hard-l2tp_0:1:hard-l2tp:1:         type = AUTH_ALG, val=SHA1
        ike 0:hard-l2tp_0:1:hard-l2tp:1: using transport mode.
        ike 0:hard-l2tp_0:1:hard-l2tp:1: replay protection enabled
        ike 0:hard-l2tp_0:1:hard-l2tp:1: SA life soft seconds=3586.
        ike 0:hard-l2tp_0:1:hard-l2tp:1: SA life hard seconds=3600.
        ike 0:hard-l2tp_0:1:hard-l2tp:1: IPsec SA selectors #src=1 #dst=1
        ike 0:hard-l2tp_0:1:hard-l2tp:1: src 0 7 17:193.193.135.66-193.193.135.66:1701
        ike 0:hard-l2tp_0:1:hard-l2tp:1: dst 0 7 17:193.193.135.65-193.193.135.65:0
        ike 0:hard-l2tp_0:1:hard-l2tp:1: add dynamic IPsec SA selectors
        ike 0:hard-l2tp_0:1: add route 193.193.135.65/255.255.255.255 oif hard-l2tp_0(78) metric 15 priority 0
        ike 0:hard-l2tp_0:1:hard-l2tp:1: tunnel 1 of VDOM limit 0/0
        ike 0:hard-l2tp_0:1:hard-l2tp:1: add IPsec SA: SPIs=050b610b/8e16ae56
        ike 0:hard-l2tp_0:1:hard-l2tp:1: IPsec SA dec spi 050b610b key 24:CECD897C1D6CEA9445C7CB218B1F308591B79CF14AFF8ED9 auth 20:F799C64C21DF1F50B9EA765625FE356DEFF8B2AF
        ike 0:hard-l2tp_0:1:hard-l2tp:1: IPsec SA enc spi 8e16ae56 key 24:F810F84E22FDFB2C0FD865039F21B338D7A040DAF26A4010 auth 20:E6690E6A422F4F252232280A0352CCD5D9613595
        ike 0:hard-l2tp_0:1:hard-l2tp:1: transport mode encapsulation is enabled
        ike 0:hard-l2tp_0:1:hard-l2tp:1: added IPsec SA: SPIs=050b610b/8e16ae56
        ike 0:hard-l2tp_0:1:hard-l2tp:1: sending SNMP tunnel UP trap
        ike 0:hard-l2tp_0:1: enc         AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000000A0010000186F56BECBF32164E50F7E3C99A1BFA94AB531936F0A00004000000001000000010000003403030401050B610B00000028010300008004000280050002800100010002000400000E1080010002000200040003D09005000014BBE04D5BEEE0A28771BFF7A8646EF79C0500000C011106A5C1C187410000000C011106A5C1C18742
        ike 0:hard-l2tp_0:1: out         AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000000A436DA1BBE5DCD1822EFFBA4C5CBD4002E4EBA549B603DDBD4FEDEA1AB0E4DD12093BE8EC9C3A00687353EAADF5ACF357FEBD217403E01FB93EC91A931DF78905791473F33B11AE78C5A34ABEA4AEE22CC3E9BBA7502964D009611B721896DAC8E90E9343B93E419CE5D65DCDFB430BA72E5BA65E74BD6B5752E1D3AB4EFA835CA1EFE8F581712192D
        ike 0:hard-l2tp_0:1: sent IKE msg (quick_r1send): 193.193.135.66:500->193.193.135.65:500, len=164, id=aa4d18c090210beb/aa460884c9a5fe4a:00000001
        ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
        ike 0: IKEv1 exchange=Quick id=aa4d18c090210beb/aa460884c9a5fe4a:00000001 len=60
        ike 0: in AA4D18C090210BEBAA460884C9A5FE4A08102001000000010000003CF7762C20EDCE39718739F6CA9090C9541F4B52C64B0C5F8AFD6F259E3958B849
        ike 0:hard-l2tp_0:1: dec AA4D18C090210BEBAA460884C9A5FE4A08102001000000010000003C0000001814ABFDB8D0724DADF789C2FE776B54C96CA5AF200000000000000000
        ike 0:hard-l2tp_0:hard-l2tp:1: send SA_DONE SPI 0x8e16ae56
        ike 0:hard-l2tp: IP 198.18.4.129 added
        ike 0:hard-l2tp: IP 198.18.4.129 removed
        ike 0:hard-l2tp: IP 198.18.4.129 added
        ike shrank heap by 122880 bytes

Wenn eine Verbindung beendet wird so wird folgendes ausgegeben:

        ike 0:hard-l2tp: IP 198.18.4.129 removed
        ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
        ike 0: IKEv1 exchange=Informational id=aa4d18c090210beb/aa460884c9a5fe4a:1cf649be len=76
        ike 0: in AA4D18C090210BEBAA460884C9A5FE4A081005011CF649BE0000004CD31698F8D44776ACCE84EAD31BFCB734D1C2B1AFE9D363C2957B6B9E23CC83BA9F3952F01FCD9723A29DEAEFE52FF559
        ike 0:hard-l2tp_0:1: dec AA4D18C090210BEBAA460884C9A5FE4A081005011CF649BE0000004C0C000018BAA486A10C0011F351DC7B67F6962DD85BD6E2840000001000000001030400018E16AE560000000000000000
        ike 0:hard-l2tp_0:1: recv IPsec SA delete, spi count 1
        ike 0:hard-l2tp_0: deleting IPsec SA with SPI 8e16ae56
        ike 0:hard-l2tp_0:hard-l2tp: deleted IPsec SA with SPI 8e16ae56, SA count: 0
        ike 0:hard-l2tp_0: sending SNMP tunnel DOWN trap for hard-l2tp
        ike 0:hard-l2tp_0:1: del route 193.193.135.65/255.255.255.255 oif hard-l2tp_0(78) metric 15 priority 0
        ike 0:hard-l2tp_0:hard-l2tp: delete
        ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
        ike 0: IKEv1 exchange=Informational id=aa4d18c090210beb/aa460884c9a5fe4a:d067794b len=84
        ike 0: in AA4D18C090210BEBAA460884C9A5FE4A08100501D067794B00000054D4E69E9BAA9C908F4F57CD39D1124581CC953A68AECACF09047E627775B79959051814136840D0CEE26E25790FD32F61CE8ACAABD2625ECA
        ike 0:hard-l2tp_0:1: dec         AA4D18C090210BEBAA460884C9A5FE4A08100501D067794B000000540C000018101526418B5431D9C02B4DF551019E33EBA220200000001C0000000101100001AA4D18C090210BEBAA460884C9A5FE4A00000000
        ike 0:hard-l2tp_0:1: recv ISAKMP SA delete aa4d18c090210beb/aa460884c9a5fe4a
        ike 0:hard-l2tp_0: deleting
        ike 0:hard-l2tp_0: flushing 
        ike 0:hard-l2tp_0: sending SNMP tunnel DOWN trap
        ike 0:hard-l2tp_0: flushed 
        ike 0:hard-l2tp_0: delete dynamic
        ike 0:hard-l2tp_0: deleted

Nach erfolgreichen Debug Mode sollte dieser wieder deaktiviert sowie zurück gesetzt werden:

        '''Deaktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug disable 

        '''Setze alle Debug Filter zurück'''
        
        # diagnose debug reset

== DDoS ==

=== Wie kann ich unter FortiOS 5.4 eine DDos Policy Konfigurieren und was muss ich berücksichtigen? ===

Neu steht unter FortiOS 5.4 die Konfiguration der DDos Policy auch für kleinere Devices wieder im Mgmt. Web Interface zur Verfügung. Dabei stellt die DDoS Policy neu unter FortiOS 5.4 ein klassische Policy dar in der "top down first match wins" gilt. Die entsprechende Menüposition befindet sich unter:

        Policy & Objects > IPv4 Policy

Ist diese Menüposition nicht vorhanden muss dieses Feature aktiviert werden. Wie dies durchgeführt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

Für eine DDoS Policy Konfiguration muss in erster Linie folgendes berücksichtigt werden: Eine DDoS Policy auf einem FortiOS wird nicht innerhalb der Stateful Inspection Firewall Policy abgearbeitet sondern diese wird vor der Stateful Inspection Firewall Policy abgearbeitet! Dies bedeutet wiederum: Möchte man einen Host im internen Bereich vor einer DDos Attake schützen und dieser Host wurde in der Stateful Inspection Firewall Policy anhand eines VIP Objekts für Destination NAT konfiguriert, muss in der DDos Policy die externe Public IPv4 Adresse des Host benutzt werden und nicht die interne IPv4 Adresse des Hosts da die DDos Policy vor der Stateful Inspection Firewal Policy abgearbeitet wird! Somit kann anhand einer explizit konfigurierten DDoS Policy ein spezifischer Service wie zB SMTP anhand "tcp_src_session" und/oder "tcp_dst_session" geschützt werden. Dies bedeutet: Wenn ein SMTP MX Server auf dem TCP Port 25 geschützt werden soll um zu verhindern das durch ein SMTP Denial of Service Attacke versucht wird von einer bestimmten Source eine Vielzahl von SMTP Verbindung aufzubauen, können diese SMTP Verbindungen anhand "tcp_src_session" für den SMTP Server limitiert werden und somit eine Denial of Service Attacke für den SMTP Service verhindert werden. Dabei spielt der definierte "threshold" eine wichtige Rolle denn durch diese Definition wird die maximal Anzahl möglicher Verbindungen definiert. Für einige Anomalien gilt eine spezifische Zeit dh. wenn innerhalb dieser Zeit der "thresold" überschritten wird so wird die definierte Aktion ausgeführt. In den verschiedenen Anomalien gilt deshalb betreffend "thresold" folgende Definition: 

        • Flooding Anomaly           Wenn die Anzahl der Session für eine einzelne Destination innerhalb einer Sekunden den "threshold" 
                                     erreicht, wird für die Destination ein "Flooding Anomaly" ausgelöst!        
        
        • Scan Anomaly               Wenn die Anzahl der Sessions von einer einzelnen Source innerhalb einer Sekunden den "threshold" 
                                     erreicht, wird für die Source eine "Scan Anomaly" ausgelöst!
        
        • Source Session Limit       Wenn die Anzahl gleichzeitiger Session von einer einzelnen Source den "thresold" erreicht, ist die
                                     Limite für diese einzelne Source erreicht und es wird eine "Source Session Limit Anomaly" ausgelöst!
        
        • Destination Session Limit  Wenn die Anzahl gleichzeitiger Session für eine einzelne Destination den "thresold" erreicht, ist
                                     die Limite für diese einzelne Destination ereicht und es wird eine "Destination Limit Anomaly" 
                                     ausgelöst!  

Nachfolgendes Beispiel zeigt wie eine DDoS Policy konfiguriert wird anhand "tcp_src_session" und einem "thresold 100" sowie dem Service TCP Port 25. Dieses Beispiel limitiert somit eine Source IPv4 Adresse die für eine Verbindung auf den SMTP MX Server benutzt wird auf 100 maximale Verbindungen. Werden diese maximalen Verbindungen durch eine Source IPv4 Adresse überschritten (thresold), wird die Source IPv4 Adresse zB für eine bestimmte Zeit geblockt resp. in "quarantine" gesetzt:

        # config firewall DoS-policy
        # edit [Vergebe eine entsprechende Policy ID zB "1"]
        # set interface [Definiere ein entsprechendes Interface zB "wan1"]
        # set srcaddr "all"
        # set dstaddr [Name des Adress Objekts für den SMTP Server zB "host-local-198.18.0.92-32"]
        # set service [Name des Service Objekts für den SMTP Service zB "SMTP"] 
        # config anomaly
        # edit [Name der Anomaly zB für Source IPv4 Adressen "tcp_src_session"]
        # set status enable
        # set log enable
        # set action block
        # set quarantine attacker
        # set quarantine-expiry [Definition der Zeitdauer für Quarantine des Attackers; 0-365d für Tage; 0-24h für Stunden; 0-1440m für Minuten; Minimum 0d0h1m]
        # set quarantine-log enable
        # set threshold [Definiere Maximal Anzahl Möglicher Verbindungen für Source IPv4 Adresse 0-2147483647; Beispiel 100]
        # end
        # end

Diese Konfiguration kann zwar über Mgmt. Web Interface durchgeführt werden jedoch ist die "quarantine" Konfiguration nur über CLI verfügbar:

        Policy & Objects > IPv4 Policy > Create New

        [[Datei:Fortinet-2055.jpg]]

Wir empfehlen Grundsätzlich nach den spezifischen DDoS Policy Rules eine generelle DDoS Policy Rule zu implementieren um einen generellen grundsätzlichen Schutz zu bieten. Diese kann über CLI wie folgt konfiguriert werden:

        # config firewall DoS-policy
        # edit [Vergebe eine entsprechende Policy ID zB "1"]
        # set interface [Definiere ein entsprechendes Interface zB "wan1"]
        # set srcaddr "all"
        # set service "ALL"
        # config anomaly
        # edit "tcp_syn_flood"
        # set status enable
        # set log enable
        # set action block
        # set threshold 2000
        # next
        # edit "tcp_port_scan"
        # set status enable
        # set threshold 1000
        # next
        # edit "tcp_src_session"
        # set status enable
        # set threshold 5000
        # next
        # edit "tcp_dst_session"
        # set status enable
        # set threshold 5000
        # next
        # edit "udp_flood"
        # set status enable
        # set log enable
        # set action block
        # set threshold 2000
        # next
        # edit "udp_scan"
        # set status enable
        # set threshold 2000
        # next
        # edit "udp_src_session"
        # set status enable
        # set threshold 5000
        # next
        # edit "udp_dst_session"
        # set status enable
        # set threshold 5000
        # next
        # edit "icmp_flood"
        # set status enable
        # set log enable
        # set action block
        # set threshold 250
        # next
        # edit "icmp_sweep"
        # set status enable
        # set threshold 100
        # next
        # edit "icmp_src_session"
        # set status enable
        # set threshold 300
        # next
        # edit "icmp_dst_session"
        # set status enable
        # set threshold 1000
        # next
        # edit "ip_src_session"
        # set threshold 5000
        # next
        # edit "ip_dst_session"
        # set threshold 5000
        # next
        # edit "sctp_flood"
        # set threshold 2000
        # next
        # edit "sctp_scan"
        # set threshold 1000
        # next
        # edit "sctp_src_session"
        # set threshold 5000
        # next
        # edit "sctp_dst_session"
        # set threshold 5000
        # next
        # end
        # next
        # end

Möchte man diese DDoS Policy über Mgmt. Web Interface konfigurieren muss folgendes konfiguriert werden:

        Policy & Objects > IPv4 Policy > Create New

        [[Datei:Fortinet-2056.jpg]]

Diese DDoS Policy die einen generellen Schutz bietet jedoch nicht Service spezifisch ist kann auf kleineren FortiGate Devices ohne Probleme angewendet werden! Wie schon erwähnt gilt unter FortiOS 5.4 für die DDoS Policy "top down first match wins". Aus diesem Grund muss auf die Rheienfolge der DDoS Policy Rules geachtet werden dh. in unserem Beispiel ist die spezifischen DDoS Policy Rules an erster Stelle und die generelle DDoS Policy am Ende. Muss die Reihenfolge verändert werden kann anhand eines Drag & Drop in der Spalte Seq# über Mgmt. Web Interface die durchgeführt werden. Dies wird folgendermassen durchgeführt:

        # config firewall DoS-policy
        # get
        == [ 1 ]
        policyid: 1
        == [ 2 ]
        policyid: 2
        
        # move [Gebe die entsprechende Policy ID an] [after | before] [Gebe die entsprechende Policy ID an]

Für unsere Beispiel ergiebt sich folgende Konfiguration betreffend der Reihenfolge:

        [[Datei:Fortinet-2057.jpg]]

=== Wie finde ich unter FortiOS 5.4 für eine DDos Policy heraus welche Werte ich in einer Anomaly benutzen soll? ===

Wenn eine DDoS Policy konfguriert wird im generellen dh. nicht für einen spezifischen Service können die Standard "threshold" verwendet werden sofern keine speziellen Bedürfnisse resp. Topology existiert. Wie diese generelle DDoS Policy zu konfigurieren ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_eine_DDos_Policy_Konfigurieren_und_was_muss_ich_ber.C3.BCcksichtigen.3F]]

Wenn jedoch spezielle Bedürfnisse existieren (Topology) und/oder für spezielle Services die geschützt werden sollen keine Anhaltspunkte existieren fragt sich wie ein "threshold" zu ermittelnt ist. Im obigen Link wird anhand eines SMTP MX Servers gezeigt wie der SMTP Service anhand "tcp_src_session" für maximale Verbindungen einer Source geschützt werden kann! Will man nun den "threshold" ermitteln kann die gleiche Konfiguration durchgeführt werden jedoch wir die "action" auf Pass gesetzt und das Log aktiviert. So kann nach einiger Zeit über die Logs eine Auswertung vollzogen werden um den maximalen "threshold" zu ermitteln. Für das Beispiel des SMTP MX Servers im vorhergehenden Link würde das folgende Konfiguration bedeuten:

       # config firewall DoS-policy
       # edit [Vergebe eine entsprechende Policy ID zB "1"]
       # set interface [Definiere ein entsprechendes Interface zB "wan1"]
       # set srcaddr "all"
       # set dstaddr [Name des Adress Objekts für den SMTP Server zB "host-local-198.18.0.92-32"]
       # set service [Name des Service Objekts für den SMTP Service zB "SMTP"] 
       # config anomaly
       # edit [Name der Anomaly zB für Source IPv4 Adressen "tcp_src_session"]
       # set status enable
       # set log enable
       # set action '''pass'''
       # set quarantine '''none'''
       # set threshold [Definiere Maximal Anzahl Möglicher Verbindungen für Source IPv4 Adresse 0-2147483647; Beispiel 100]
       # end
       # end

Dabei spielt der definiert "threshold" insofern nur eine Nebenrolle da die "action" auf "pass" gesetzt wurde dennoch sollte ein entsprechender "thresold" gesetzt werden. Wenn ein "threshold" erreicht wird so wird ein entsprechender Log Eintrag erstellt im "Anomaly" Log. Dieses findet man unter folgender Position:

        Log & Report > Anomaly

        [[Datei:Fortinet-2058.jpg]]

Im diesem Beispiel wurde der "threshold" für "tcp_syn_flood" überschritten! Anhand dieser Informationen kann der "threshold" ermittelt werden! Betreffend Logs ist jedoch folgendes zur Berücksichtigen: Wenn zB eine "flood" Attacke durchgeführt wird so wird nicht für alle Verbindungen ein Log Eintrag erstellt da dieses Vorgehen Memory und/oder CPU des FortiGate Devices beeinträchtigen würde. Stattdessen werden die Logs periodisch korreliert resp. Zusammengezogen (1 Log Eintrag für jeden Incident über 50). Dies bedeutet wiederum: Es wird für alle Verbindungen betreffend einer IPv4 Adresse periodisch (ca. 1 Minute) 1 Log Eintrag erstellt. Diese Funktion wird in den Logs anhand "count" indiziert. Zusätzlich steht über CLI anhand "diagnose" weitere Befehle zur Verfügung. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_DDos_Policy_weitere_Informationen_auflisten_f.C3.BCr_einen_Analyse.3F]]

=== Wie kann ich unter FortiOS 5.4 für eine DDos Policy weitere Informationen auflisten für einen Analyse? ===

Unter CLI steht für eine DDoS Policy folgendes Kommando zur Verfügung:

        # diagnose ips anomaly [clear | config | filter | list | status]

Die verschiedenen Optionen für "ips anomaly" haben folgende Bedeutung:

        • clear            Löscht die anomaly meters
        • config           Listet die DOS-sensoren auf
        • filter           Listet den "anomaly" Filter auf
        • list             Listet die "anomaly" meters auf
        • status           Listet den "anomaly" status auf

Somit kann zB mit folgenden Befehl die konfigurierten DDoS Policies aufgelistet werden die Konfiguriert wurden:

        # diagnose ips anomaly config
        DoS sensors in kernel vd 0:
        DoS id 2 proxy 0
          0 tcp_syn_flood status 0 log 0 nac 0 action 0 threshold 2000
          1 tcp_port_scan status 0 log 0 nac 0 action 0 threshold 1000
          2 tcp_src_session status 1 log 1 nac 1 action 7 threshold 100
          3 tcp_dst_session status 0 log 0 nac 0 action 0 threshold 5000
          4 udp_flood status 0 log 0 nac 0 action 0 threshold 2000
          5 udp_scan status 0 log 0 nac 0 action 0 threshold 2000
          6 udp_src_session status 0 log 0 nac 0 action 0 threshold 5000
          7 udp_dst_session status 0 log 0 nac 0 action 0 threshold 5000
          8 icmp_flood status 0 log 0 nac 0 action 0 threshold 250
          9 icmp_sweep status 0 log 0 nac 0 action 0 threshold 100
          10 icmp_src_session status 0 log 0 nac 0 action 0 threshold 300
          11 icmp_dst_session status 0 log 0 nac 0 action 0 threshold 1000
          12 ip_src_session status 0 log 0 nac 0 action 0 threshold 5000
          13 ip_dst_session status 0 log 0 nac 0 action 0 threshold 5000
          14 sctp_flood status 0 log 0 nac 0 action 0 threshold 2000
          15 sctp_scan status 0 log 0 nac 0 action 0 threshold 1000
          16 sctp_src_session status 0 log 0 nac 0 action 0 threshold 5000
          17 sctp_dst_session status 0 log 0 nac 0 action 0 threshold 5000
        DoS id 1 proxy 0
          0 tcp_syn_flood status 1 log 1 nac 0 action 7 threshold 2000
          1 tcp_port_scan status 1 log 0 nac 0 action 0 threshold 1000
          2 tcp_src_session status 1 log 0 nac 0 action 0 threshold 5000
          3 tcp_dst_session status 1 log 0 nac 0 action 0 threshold 5000
          4 udp_flood status 1 log 1 nac 0 action 7 threshold 2000
          5 udp_scan status 1 log 0 nac 0 action 0 threshold 2000
          6 udp_src_session status 1 log 0 nac 0 action 0 threshold 5000
          7 udp_dst_session status 1 log 0 nac 0 action 0 threshold 5000
          8 icmp_flood status 1 log 1 nac 0 action 7 threshold 250
          9 icmp_sweep status 1 log 0 nac 0 action 0 threshold 100
          10 icmp_src_session status 1 log 0 nac 0 action 0 threshold 300
          11 icmp_dst_session status 1 log 0 nac 0 action 0 threshold 1000
          12 ip_src_session status 0 log 0 nac 0 action 0 threshold 5000
          13 ip_dst_session status 0 log 0 nac 0 action 0 threshold 5000
          14 sctp_flood status 0 log 0 nac 0 action 0 threshold 2000
          15 sctp_scan status 0 log 0 nac 0 action 0 threshold 1000
          16 sctp_src_session status 0 log 0 nac 0 action 0 threshold 5000
          17 sctp_dst_session status 0 log 0 nac 0 action 0 threshold 5000
        total # DoS sensors: 2.

Der nachfolgende Befehl listet alle IPv4 Adressen auf für die ein "match" für eine DDoS Policy ausgeführt wurde. Diese Liste zeigt nicht zwingend IPv4 Adressen die eine Attacke durchgeführt haben. Die Position "exp" (expiration) zeigt den Wert in Sekunden nachdem ein entsprechender Eintrag entfernt wird sofern kein weiterer "match" betreffend der IPv4 Adresse für diesen DDoS Policy Eintrag stattfindet. Die Position "pps" (packet per second) zeigt an wieviele Packet pro Sekunden für die IPv4 Adressen registriert wurde. Die Position "freq" (frequency) zeigt die Frequenz für eine spezifische IPv4 Adresse für die eine DDoS anomaly erkannt wurde:

        # diagnose ips anomaly list
        list nids meter:
        id=udp_flood          ip=198.41.0.4 dos_id=1 exp=988 pps=1 freq=6
        
        id=udp_dst_session    ip=198.41.0.4 dos_id=1 exp=5990 pps=0 freq=0
        
        id=udp_scan           ip=193.193.135.65 dos_id=1 exp=988 pps=2 freq=3
        
        id=udp_src_session    ip=193.193.135.65 dos_id=1 exp=5990 pps=0 freq=0
        
        id=udp_flood          ip=193.193.135.66 dos_id=1 exp=880 pps=3 freq=3
        
        id=udp_flood          ip=192.228.79.201 dos_id=1 exp=967 pps=0 freq=1
        
        id=udp_dst_session    ip=192.228.79.201 dos_id=1 exp=5969 pps=0 freq=0
        
        total # of nids meters: 7.

Wenn durch "list" eine grosse Liste von Informationen ausgegeben wird kann diese anhand des folgenden Befehls ein Filter gesetzt werden:

        # diagnose ips anomaly filter
        clear  Clear anomaly filter.
        id     Anomaly ID.
        ip     IP and subnet mask.
        pps    pps
        freq   frequency

Der Status des Filter kann mit folgenden Befehl aufgelistet werden:

        # diagnose ips anomaly filter
        anomaly filter:
        id any
        ip 0.0.0.0 mask 0.0.0.0
        nps 0 - 0
        freq 0 - 0 

Somit kann zB ein anhand eine Policy ID (id) oder zB anhand eine IPv4 Adresse (ip) ein Filter gesetzt werden:

        # diagnose ips anomaly filter id 1
        # diagnose ips anomaly filter
        anomaly filter:
        id 1
        ip 0.0.0.0 mask 0.0.0.0
        nps 0 - 0
        freq 0 - 0

        # diagnose ips anomaly filter ip 198.41.0.4 255.255.255.255
        # diagnose ips anomaly filter
        anomaly filter:
        id 1
        ip 198.41.0.4 mask 255.255.255.255
        nps 0 - 0
        freq 0 - 0   

Um den Filter zurück zu setzen führe ein "clear" aus:

        # diagnose ips anomaly filter clear
        # diagnose ips anomaly filter
        anomaly filter:
        id 0
        ip 0.0.0.0 mask 0.0.0.0
        nps 0 - 0
        freq 0 - 0

== Botnet ==

=== Wie kann ich unter FortiOS 5.4 für eine FortiGate Verbindungen zu "botnet" Servern blocken oder überwachen? ===

Unter FortiOS 5.2 wurde die "botnet" Funktion innerhalb des Antivirus Profiles konfiguriert. Dies steht unter FortiOS 5.4 nicht mehr zur Verfügung. Neu steht die "botnet" Funktion Hauptsächlich für ein Interface zur Verfügung und kann über das Mgmt. Web Interface konfiguriert werden:

        Network > Interfaces > [Markiere das entsprechende Interface zB "wan1"] > Edit > Scan Outgoing Connections to Botnet Sites > [Disable | Block | Monitor]

        [[Datei:Fortinet-1665.jpg]]

        [[Datei:Fortinet-1666.jpg]]

Wenn die Konfiguration für ein entsprechendes Interface auf der CLI durchgeführt werden möchte, muss folgendes durchgeführt werden:

        # config system interface
        # edit [Name des entsprechende Interface zB "wan1"]
        # set scan-botnet-connections [disable | block | monitor]
        # end

Durch diese Konfiguration wird der "outgoing" Traffic zB für "wan2" betreffend "botnet" Server kontrolliert dh. werden IP's betreffend "botnet" Server angegangen, werden diese gemäss Konfiguration geblockt und ein Log Eintrag geschrieben oder durch Monitor ein Log Eintrag geschrieben. Wenn Die Funktion aktiviert wird erscheint ein Hinweis, dass sich zB 9 "botnet" Server in der Liste befindet. Diese "botnet" Server Liste wird von der FortiCare Funktion auf den neusten Stand gebracht. Somit muss FortiCare lizensiert werden damit diese Funktion der "botnet" Server zur Verfügung steht. Um die aktive "botnet" Server Liste einzusehen steht auf dem Mgmt. Web Interface folgende Position zur Verfügung:

        System > FortiGuard > License Information > Botnet Definitions > View List

        [[Datei:Fortinet-1667.jpg]]

        [[Datei:Fortinet-1668.jpg]]

Wird die Funktion auf einem Interface zB "wan2" aktiviert kann diese nachträglich getestet werden. Dazu öffne einen Browser und gebe gemäss "botnet" Liste zB folgendes ein:

        http://46.166.135.177

Diese IP ist in der "botnet" Liste aufgeführt für Port 80. Ausgehend davon, dass für den Traffic und die entsprechende Firewall Policy das "log" aktiviert ist, wird im Antivirus Log ein entsprechender Eintrag geschrieben:

        Log & Report > Antivirus

        [[Datei:Fortinet-1669.jpg]]

Diese "botnet" Server Liste kann über CLI und "diagnose" Kommando eingesehen sowie manipuliert werden. Weitere Informationen dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_die_.22botnet.22_Informationen_auf_einer_FortiGate_auflisten.2C_suchen_usw.3F]]

Diese Liste wird innerhalb der Autoupdate Funktion von FortiGuard auf den neusten Stand gehalten. Um diese Liste manuell auf den neusten Stand zu bringen kann folgender Befehl auf der CLI ausgeführt werden:

        # execute update-now

Wie schon erwähnt wurde die "botnet" Funktion aus dem Antivirus Profile verschoben und als Funktion auf den Interfaces implementiert. Zusätzlich jedoch kann die Funktion, wenn diese nicht auf den Interfaces aktiviert werden kann, auf einer Firewall Policy, Explizit Proxy, Interface Policy oder Sniffer aktiviert werden um eine granularere Konfiguration zu erreichen. Dies kann über CLI konfiguriert werden:

        # config firewall policy
        # edit [Gebe eine entsprechende Policy ID an]
        # set scan-botnet-connections [disable | block | monitor]
        # end

        # config firewall explicit-proxy-policy
        # edit [Gebe eine entsprechende Policy ID an]
        # set scan-botnet-connections [disable | block | monitor]
        # end

        # Firewall interface policy
        # config firewall interface-policy
        # edit [Gebe eine entsprechende Policy ID an]
        # set scan-botnet-connections [disable | block | monitor]
        # end

        # Firewall sniffer
        # config firewall sniffer
        # edit [Gebe eine entsprechende Policy ID an]
        # set scan-botnet-connections [disable | block | monitor]
        # end

=== Wie kann ich unter FortiOS 5.4 die "botnet" Informationen auf einer FortiGate auflisten, suchen usw? ===

Wenn die "botnet" Server Liste auf einem FortiOS 5.4 aufgelistet werden soll, kann dies über Mgmt. Web Interface durchgeführt werden. Dazu wähle folgendes:

        System > FortiGuard > License Information > Botnet Definitions > View List

        [[Datei:Fortinet-1667.jpg]]

        [[Datei:Fortinet-1668.jpg]]

Ueber Mgmt. Web Interface ist es jedoch nicht möglich weitere Manipulationen betreffend dieser "botnet" Liste auszuführen. Neu unter FortiOS 5.4 steht ein entsprechendes "diagnose" Kommando auf der CLI zur verfügung das dies ermöglich:

        # diagnose sys botnet [stat | list | find | flush | reload | file]

Dies verschiedenen zur Verfügung stehenden Optionen haben folgende Bedeutung:

        • stat           the number of botnet entries in the kernel.
        • list           list the botnet entries.
        • find           find a botnet entry by ip address, port number, protocol etc.
        • flush          flush botnet entries from the kernel.
        • reload         reload botnet file into the kernel
        • file           botnet file diagnostics.

Somit wenn die Liste der "botnet" Server auf einem FortiOS für eine FortiGate eingesehen werden möchte kann folgendes ausgeführt werden:

        # diagnose sys botnet stat
        The amount of botnet entries in kernel is: 9

        # diagnose sys botnet list
        Read 9 botnet entry:
         0. proto=UDP ip=24.5.5.251, port=16471, name_id=2, rule_id=32
         1. proto=TCP ip=46.166.135.177, port=80, name_id=0, rule_id=12
         2. proto=UDP ip=67.190.137.250, port=16471, name_id=2, rule_id=32
         3. proto=UDP ip=75.74.227.4, port=16471, name_id=2, rule_id=32
         4. proto=UDP ip=108.131.43.62, port=27697, name_id=1, rule_id=2
         5. proto=TCP ip=113.38.129.254, port=16471, name_id=2, rule_id=4
         6. proto=UDP ip=113.38.129.254, port=16471, name_id=2, rule_id=32
         7. proto=UDP ip=160.79.57.246, port=16471, name_id=2, rule_id=32
         8. proto=TCP ip=178.162.183.185, port=80, name_id=0, rule_id=1

Möchte man diese "botnet" Liste komplett löschen resp. ein Flush durchführen, kann folgendes ausgeführt werden:

        # diagnose sys botnet flush

Danach erscheint in der "botnet" Liste kein Eintrag mehr:

        # diagnose sys botnet list

Um die aktuelle "botnet" Liste neu zu laden gebe folgendes ein:

        # diagnose sys botnet reload

Danach ist die "botnet" Liste wieder aktuell:

        # diagnose sys botnet list
        Read 9 botnet entry:
         0. proto=UDP ip=24.5.5.251, port=16471, name_id=2, rule_id=32
         1. proto=TCP ip=46.166.135.177, port=80, name_id=0, rule_id=12
         2. proto=UDP ip=67.190.137.250, port=16471, name_id=2, rule_id=32
         3. proto=UDP ip=75.74.227.4, port=16471, name_id=2, rule_id=32
         4. proto=UDP ip=108.131.43.62, port=27697, name_id=1, rule_id=2
         5. proto=TCP ip=113.38.129.254, port=16471, name_id=2, rule_id=4
         6. proto=UDP ip=113.38.129.254, port=16471, name_id=2, rule_id=32
         7. proto=UDP ip=160.79.57.246, port=16471, name_id=2, rule_id=32
         8. proto=TCP ip=178.162.183.185, port=80, name_id=0, rule_id=1

Anhand der "find" Option kann in der "botnet" Liste nach einem entsprechenden Eintrag gesucht werden:

        # diagnose sys botnet find [Entsprechende IPv4 Adresse "46.166.135.177"] [Botnet Port zB "80"] [Botnet Protokoll zB "6"]
        Read 1 botnet entry:
         0. proto=TCP ip=46.166.135.177, port=80, name_id=0, rule_id=12

Um zusätzliche Informationen über die verschiedenen "botnet" Einträge zu erhalten kann "file" benützt werden zB mit nachfolgenden Kommando kann das "botnet" File das als Grundlage dient für die Liste ausgelesen werden:

        # diagnose sys botnet file stat
        File name: /etc/idsbot.rules
        File format: Compressed(ZIP)
        File compressed size: 141
        File decompressed size: 204
        BOTNET version=01.000 2012-05-28 22:51:00
        Botnet name table id: 0x1
        Botnet name number: 3
        Botnet name size: 47(0x2f)
        Botnet TCP table id: 0x10002
        Botnet TCP entry number: 3
        Botnet TCP entry size: 36(0x24)
        Botnet UDP table id: 0x10003
        Botnet UDP entry number: 6
        Botnet UDP entry size: 72(0x48)

Für die verschiedenen "botnet" Einträge im "output" für "diagnose sys botnet list" werden "name_id's" vergeben. Diese "name_id" gibt Auskunft um welche Art es sich handelt. Um diese "name_id" auszulsen kann folgendes Kommando benutzt werden:

        # diagnose sys botnet list
        Read 9 botnet entry:
         0. proto=UDP ip=24.5.5.251, port=16471, name_id=2, rule_id=32
         1. proto=TCP ip=46.166.135.177, port=80, '''name_id=0''', rule_id=12
         2. proto=UDP ip=67.190.137.250, port=16471, name_id=2, rule_id=32
         3. proto=UDP ip=75.74.227.4, port=16471, name_id=2, rule_id=32
         4. proto=UDP ip=108.131.43.62, port=27697, '''name_id=1''', rule_id=2
         5. proto=TCP ip=113.38.129.254, port=16471, name_id=2, rule_id=4
         6. proto=UDP ip=113.38.129.254, port=16471, name_id=2, rule_id=32
         7. proto=UDP ip=160.79.57.246, port=16471, name_id=2, rule_id=32
         8. proto=TCP ip=178.162.183.185, port=80, '''name_id=0''', rule_id=1

        # diagnose sys botnet file botnet-name [Gebe eine entsprechende "name_id" an zB "1"]
        Botnet name (ID:1): zbot_udp
        
        # diagnose sys botnet file botnet-name [Gebe eine entsprechende "name_id" an zB "0"]
        Botnet name (ID:0): Spyeye

== Antivirus ==

=== Wie kann ich unter FortiOS 5.4 die Antivirus Database/Engine auf den neusten Stand bringen? ===

Alle UTM Databases werden auf einem FortiOS anhand der "autoupdate" Funktion auf den neusten Stand gebracht. Weitere Informationen dazu wie diese Funktion "autoupdate" zu konfigurieren ist und was dabei beachtet werden muss siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.4_die_.22autoupdate.22_Funktion_f.C3.BCr_UTM_Databases.3F]]

Um die Antivirus Database sowie Engine versions Informationen zu überprüfen siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_die_Versions_Informationen_.C3.BCberpr.C3.BCfen.3F]]

Für eine Antivirus Database kann ebenfalls ein Downgrade durchgeführt werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_ein_Downgrade_durchf.C3.BChren.3F]] 

=== Wo finde ich auf der FortiGuard Support Seite mehr Informationen betreffend Antivirus Database Inhalte? ===

Die Antivirus Definition Database von Fortinet resp. FortiGuard beinhaltet unzählig Virus Signaturen und deren Variationen. Um festzustellen ob eine bestimmte Virus Signature in der Antivirus Definition Database enthalten ist oder dessen Variationen gebe auf der folgende Seite den Namen der Virussignatur ein:

        http://www.fortiguard.com/encyclopedia/ 

Danach kann auf den entsprechenden Eintrag ein Mausklick ausgeführt werden und die Beschreibung über den angewählten Eintrag erscheint sowie Zusatzinformationen. Um festzustellen was einer Antivirus Database Version hinzugefügt worden ist kann folgendes durchgeführt werden:

        http://www.fortiguard.com/antivirus

Danach wähle oben Rechts die Position "Latest AV Database:". Danach werden die Antivirus Database Versionen unter "AntiVirus Service Updates" aufgelistet und können einzeln angewählt werden. Wenn eine Antivirus Database Version angwählt wird, sieht man welche Virus Signaturen hinzugefügt wurden! Die einzelnen Virus Signaturen können angewählt werden und es werden detaillierte Informationen zu diesem Eintrag aufgelistet. Zusätzlich kann über diese Seite ein entsprechendes File überprüft werden anhand eines "Online Virenscanners". Dazu wähle auf der Seite die Position "Online Virus Scan" oder wähle den folgenden Link:

        http://www.fortiguard.com/virusscanner

=== Wie kann ich unter FortiOS 5.4 für die Antivirus Engine die Maximale Filegrösse konfigurieren? ===

Die Maximale Filegrösse gibt die maximale Grösse an eines Files das durch die Antivirus Engine benutzt wird um dieses zu Scannen dh. grössere Files werden ignoriert und nicht gescannt! Diese Maximale Filegrösse steht im direkten Zusammenhang mit der Performance auf einer FortiGate dh. die Scan Funktion der Antivirus Engine wird direkt im Memory durchgeführt. Wird die Maximale Filegrösse erhöht, wird somit das Memory durch eine grösser Filegrösse bei Scans zusätzlich belastet. Aus diesem Grund ist es gut zu überlegen ob die Maximale Filegrösse höher gesetzt werden soll als per Standard definiert. Per Standard gilt auf kleineren Devices eine Maximale Filegrösse von 10 MB und auf grösseren Device eine Maximale Filegrösse von 15 MB. Der Unterschied des gefahren Potential zwischen 5 MB und zB 10 MB sind Minimal. Dies wird im nachfolgenden Dokument aufgezeigt:

        [[Datei:MalwareFileSize.pdf]]

Die Maximale Filegrösse der Antivirus Engine wird nicht im Antivirus Profile konfiguriert sondern innerhalb des Protocol Options. Die Konfiguration kann für jeden Service wie zB http, ftp usw. einzeln konfiguriert werden und steht nur unter CLI zur Verfügung:
             
        # config firewall profile-protocol-options
        # edit [Name des entsprechenden Profiles]
        # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
        # set oversize-limit [Maximale Grösse in Memory in MB; Standard 10]
        # set uncompressed-oversize-limit [Maximale Grösse in Memory in MB eines entpackten Archives; Standard 10]
        # set uncompressed-nest-limit [Maximale Tiefe von Archiven 2 - 100; Standard 12]
        # set scan-bzip2 [enable | disable]
        # set block-page-status-code [Setzt den Return Code für HTTP; Standard 200]
        # end
        # end

Grundsätzlich steht für "oversize-limit" auf einem FortiGate Device max. 10% des Memory zur Verfügung. Dies bedeutet: Um die Maximale Grösse von "oversize-limit" auf einem FortiGate Device abhängig vom zur Verfügung stehenden Memory zu ermitteln, kann folgendes durchgeführt werden:

        # config firewall profile-protocol-options
        # edit [Name des entsprechenden Profiles]
        # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
        # set oversize-limit ?
        <ingeger>    please input integer value (1-183)

Bei der Option "uncompressed-oversize-limit" handelt es sich um die Maximale Filegrösse im Memory eines entpackten Archives zB zip Files das durch die Antivirus Engine gescannt wird. Grundsätzlich kann dieser Konfigurationspunkt mit 0 = unlimited konfiguriert werden, was jedoch explizit durch Fortinet nicht empfohlen wird. Per Standard gilt hier die gleiche Maximale Filegrösse wie für "oversize-limit" konfiguriert dh. 10 MB! Bei der Option "uncompressed-nest-limit" handelt es sich um die maximale Tiefe eines Archives für ein File das durch die Antivirus Engine gescannt wird. Dabei wird als Archiv betreffend "uncompressed-nest-limit" folgendes Archive definiert:

        arj, bzip2, cab, gzip, lha, lzh, msc, rar, tar, zip. bzip2 (sofern aktiviert)

Die Option "block-page-status-code" definiert den HTTP Status Code der dem User über den Browser zurück gegeben wird sofern ein File geblockt wird. Wenn ein Maximale File Grösse überschritten wird gemäss Konfiguration "oversize-limit", kann dieses geblockt oder zugelassen werden. Diese Funktion wird gesteuert über die Option "options" innerhalb des Services der Konfiguriert wird für die Protocol Options:

        # config firewall profile-protocol-options
        # edit [Name des entsprechenden Profiles]
        # set oversize-log [enable | disable]
        # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
        # set options [Block Files grösser als Maximale Filegrösse "oversize"]
        # end
        # end

Möchte man die Files zulassen die grösser sind als "oversize-limit" kann folgendes konfiguriert werden:

        # config firewall profile-protocol-options
        # edit [Name des entsprechenden Profiles]
        # set oversize-log [enable | disable]
        # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
        # set options [Allow Files grösser als Maximale Filegrösse "clientcomfort"]
        # set comfort-interval [Zeit in Sekunden nachdem "clientcomfort" gestartet wird 1 - 900; Standard 10]
        # set comfort-amount [Bytes für "comfort-interval" 1 - 10240 Bytes; Standard 1]
        # end
        # end

=== Welche "compressed" Formate werden unter FortiOS 5.4 für die Antivirus Engine unterstützt? ===

Wenn auf einem FortOS die Antivirus Engine konfiguriert wird, fragt man sich welche "compressed" Formate die Antivirus Engine auf einem FortiOS unterstützt. Nachfolgendes offizielle Dokument von Fortinet zeigt welche "compressed" Formate in der Antivirus Engine unterstützt werden und liefert Wichtig Zusatzinformationen:

        [[Datei:fortios-scanning-of-archive-compressed-files.pdf]]

Nachfolgend ein Kurzüberblick über die unterstützten Formate:

        '''Archive / Compression Formats'''
        • ZIP
        • ZIPX (BZIP2, INFLATE64, LZMA, LZMA2)
        • JAR
        • RAR
        • 7Z
        • BZIP2
        • CAB
        • TAR
        • GZIP
        • ARJ
        • LZH
        • MSC (Microsoft Compress)
        • SIS (Symbian Installer Package)
        • SISX (Symbian Installer Package for 9.x)
        • SWF
        • NSIS (Nullsoft Installer Package)
        • E32Image (Symbian 9.x, compressed with custom LZW algorithm)
        • XZ (starting with AV engine v4.3)
        • CPIO (starting with AV engine v4.3)
        • AutoIt (starting with AV engine 5.0)
        • TNEF ( starting with AV engine 5.1)
        
        '''Self Extracting Formats'''
        • SFX ZIP
        • SFX RAR
        • SFX LZH
        • SFX ARJ
        • SFX CAB
        • SFX 7Z
        
        '''Static Packers'''
        • UPX
        • ASPACK
        • PETITE
        • FSG
        
        '''Generic/Custom Packers'''
        • UPACK
        • Mew
        • PECompact
        • ASProtect
        • PecBundle
        • PEncrypt
        • ACProtect
        
        '''Document Formats'''
        • PDF
        • MS OFFICE
        • RTF
        • WORDML
        • MIME

=== Welche Database und Funktionen können unter FortiOS 5.4 für die Antivirus Engine Aktiviert werden? ===

Für die Antivirus Engine stehen auf einem FortiOS folgende Databases und Funktionen zur Verfügung:

        • Normal Database            Beinhaltet die "Wild Virus" sowie die "Ueblichen Virus". Für eine normale Absicherung resp.
                                     Abdeckung gegen Virus sollte diese Database benutzt werden!
        
        • Extended Database          Beinhaltet "Wild Virus" sowie eine umfanggreiche Definition der "Zoo Virus". "Zoo Viruses" 
                                     sind in den normalen Studien nicht mehr aufgeführt da sehr selten. Dies bedeutet: diese
                                     Database sollte nur in High Security Umgebungen benutzt werden! 
        
        • Extrem Database            Beinhaltet "Wild Virus" sowie der "Zoo Virus". "Zoo-Viruses" sind in den normalen Studien 
                                     nicht mehr aufgeführt da sehr selten. Der Unterschied zum "extended"  Modus ist, dass in 
                                     der "extrem" alle "Zoo Virus" enthalten sind. Diese Database sollte nur in High Security 
                                     Umgebungen benutzt werden! 
        
        • Mobile Malware Database    Beinhaltet Mobile Malware for Android!
        
        • Grayware Funktion          Grayware binhaltet die Definitionen für Adware oder auch Dialer genannt!
        
        • Heuristic                  Verhaltensbasierende Analytische Antivirus Ueberprüfung!
        
        • Scan Mode (Flow Mode)      Benützt Flow-Mode mit kompakter Antivirus Database sowie Erweiterte Technik für Antivirus
                                     Scan!
        
        • Block Executables (Email)  Im Antivirus Profile können Executables Files (.exe) für IMAP, POP3, SMTP und MAPI geblockt
                                     werden!  

Um die entsprechende Database für Antivirus Engine zu konfigurieren kann über CLI folgendes durchgeführt werden:

        # config antivirus settings
        # set default-db [extended | extreme | normal]
        # set grayware [enable oder disable]
        # end

Dabei ist zu berücksichtigen, dass die "extreme" Database nicht auf kleineren FortiGate Devices zur Verfügung steht. Um die Heuristic zu konfigurieren kann folgendes auf CLI durchgeführt werden:

        # config antivirus heuristic
        # set mode [pass | block | disable]
        # end

Die zusätzliche Database für Mobile Malware kann über das entsprechende Antivirus Profile aktiviert werden. Dabei ist zu berücksichtigen, dass diese Database nur Mobile Malware für Android enthält:

        # config antivirus profile
        # edit [Name des entsprechenden Antivirus Profile]
        # set mobile-malware-db [enable | disable]
        # end

Beim Quick Mode handelt es sich um einen Antivirus Scan im Flow-Mode analog FortiOS 5.2. Dabei wird aber um die Performance im Antivirus Scan zu steigern eine kompakte Antivirus Database verwendet sowie eine erweiterte Technik im Antivirus Scan selber. Dieser Mode sollte nur dann genutzt werden, wenn Performance Probleme auftreten und der Flow-Mode bereits benutzt wird. Um den Quick Mode zu benutzen muss im entsprechenden Antivirus Profile die Funktion aktiviert werden:

        # config antivirus profile
        # edit [Name des entsprechenden Antivirus Profile]
        # set scan-mode [quick | full]
        # end

Möchte man im Antivirus Profile im Zusammenhang mit Email Attachement resp. mit den Services IMAP, POP3, SMTP und MAPI alle Executables dh. .exe Files per Standard blocken, kann diese Funktion für diese Services aktiviert werden dh. durch die Option "virus" wird ein Executable als Virus erkannt. Per Standard ist die Funktion "executables" als "default" konfiguriert dh. Executables werde nicht als Virus erkannt. Executables für andere Services wie zB HTTP zu blocken steht im Antivirus Profile nicht zur Verfügung:

        # config antivirus profile
        # edit [Name des entsprechenden Antivirus Profile]
        # config [imap | pop3 | smtp | mapi]
        # set executables [default | virus]
        # end
        # end

Per Standard ist die Heuristic auf "pass" konfiguriert dh. die Heuristic ist aktiviert jedoch wird kein File geblockt! Nachdem die Konfiguration durchgeführt wurde müssen die zusätzlichen Informationen resp. Database auf den neusten Stand gebracht werden. Dies kann anhand folgenden Kommandos durchgeführt werden:

        # execute update-now

Nachträglich können die verschiedenen Databases mit deren Versions Informationen überprüft werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_die_Versions_Informationen_.C3.BCberpr.C3.BCfen.3F]]

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device die Antivirus Funktion konfigurieren? ===

Wenn unter FortiOS 5.4 die Antivirus Funktion konfiguriert ist die Basis dazu folgende Profiles:

        • Proxy Options Profile      (Unverschlüsselter Traffic für HTTP, SMTP, POP3, IMAP, MAPI, FTP, DNS sowie NNTP)
        • SSL Inspection Profile     (Verschlüsselter Traffic für HTTPS, SMTPS, POP3S, IMAPS sowie FTPS)
        • Antivirus Profile          (Unverschlüsselter Traffic für HTTP, SMTP, POP3, IMAP, MAPI, FTP sowie NNTP)

Somit muss zu Beginn verifiziert werden ob verschlüsselter Traffic benutzt werden soll für die Antivirus Funktion. Ist dies der Fall, muss eine "Deep Inspection" konfiguriert werden anhand des SSL Inspection Profiles sowie das Fortinet_CA_SSLProxy Zertifikat des FortiGate Devices muss auf den Host/Clients als "Vertrauenswürdige Stammzertifikat" eingespielt werden. Damit ist gewährleistet das eine "Deep Inspection" angewendet werden kann. Ebenfalls als Grundvoraussetzung muss gewährleistet werden das eine "Deep Inspection" auf einem entsprechenden FortiGate Device betreffend Perfomance benutzt werden kann. Die "Deep Inspection" Funktion sollte aus Performance Gründen nicht für FortiGate Devices kleiner FG-90D konfiguriert resp. angewendet werden! Somit muss als Grundlage für die Antivirus Funktion im ersten Schritt ein Proxy Options Profile und/oder ein SSL Inspection Profile konfiguriert werden. In diesen Profiles sollten nur Services/Porst aktiviert werden für die die Antivirus Funktion aktiviert wird resp. in einer Firewall Policy Rule konfiguriert wird:

        '''Proxy Options Profile Konfiguration'''
        
        Security Profiles > Proxy Options > Create New
        
        [[Datei:Fortinet-2049.jpg]]
        
        # config firewall profile-protocol-options 
        # edit [Name des entsprechenden Proxy Options Profile zB "local-default.intra"]
        # set comment [Gebe einen Kommentar ein zB "Unencrypted default profile local-sg0e0"]
        # unset replacemsg-group
        # set oversize-log enable
        # set switching-protocols-log enable
        # config http
        # set ports 80
        # set status enable 
        # set inspect-all disable 
        # set options clientcomfort 
        # set comfort-interval 10
        # set comfort-amount 1
        # set range-block disable 
        # unset post-lang
        # set fortinet-bar disable 
        # set streaming-content-bypass enable 
        # set switching-protocols bypass 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # set block-page-status-code 200
        # set retry-count 0
        # end
        # config ftp
        # set ports 21
        # set status enable 
        # set inspect-all disable 
        # set options clientcomfort 
        # set comfort-interval 10
        # set comfort-amount 1
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config imap
        # set ports 143
        # set status enable 
        # set inspect-all disable 
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config mapi
        # set ports 135
        # set status enable
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config pop3
        # set ports 110
        # set status enable
        # set inspect-all disable 
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config smtp
        # set ports 25
        # set status enable
        # set inspect-all disable 
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # set server-busy disable 
        # end
        # config nntp
        # set ports 119
        # set status enable 
        # set inspect-all disable 
        # unset options
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config dns
        # set ports 53
        # set status enable 
        # end
        # config mail-signature
        # set status disable 
        # unset signature
        # end
        # set rpc-over-http enable 
        # end

        '''SSL Inspection Profile Konfiguration'''
        
        Security Profiles > SSL Inspection > Create New
        
        [[Datei:Fortinet-2050.jpg]]
        
        # config firewall ssl-ssh-profile 
        # edit [Wähle ein entsprechendes SSL Inspection Profile zB "local-default.intra"]
        # set comment [Gebe einen Kommentar ein zB "Encrypted default profile local-sg0e0"]
        # config ssl
        # set inspect-all disable 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config https
        # set ports 443
        # set status deep-inspection 
        # set client-cert-request bypass 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config ftps
        # set ports 990
        # set status deep-inspection 
        # set client-cert-request bypass 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config imaps
        # set ports 993
        # set status deep-inspection 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config pop3s
        # set ports 995
        # set status deep-inspection 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config smtps
        # set ports 465
        # set status deep-inspection 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # set whitelist disable
        # end 
        # config ssl-exempt
        # end
        # set server-cert-mode re-sign 
        # set caname Fortinet_CA_SSLProxy 
        # set untrusted-caname Fortinet_CA_Untrusted 
        # set certname Fortinet_CA_SSLProxy 
        # end
        # config ssl-server
        # end
        # set ssl-invalid-server-cert-log enable 
        # set rpc-over-https enable 
        # set use-ssl-server disable 
        # end

        '''Antivirus Profile Konfiguration'''
        
        Zusätzlich zur Antivirus Profile Konfiguration ist nachfolgender Artikel zu berücksichtigen der die zur Verfügung stehenden Funktionen 
        der Antivirus Engine zeigt:
        
        [[FortiGate-5.4:FAQ#Welche_Database_und_Funktionen_k.C3.B6nnen_unter_FortiOS_5.4_f.C3.BCr_die_Antivirus_Engine_Aktiviert_werden.3F]]
        
        Security Profiles > AntiVirus > Create New
        
        [[Datei:Fortinet-2051.jpg]]
        
        # config antivirus profile 
        # edit [Wähle das entsprechende Antivirus Profile zB "local-default.intra"]
        # set comment [Gebe einen Kommentar ein zB "Scan and delete default profile local-sg0e0"]
        # unset replacemsg-group
        # set inspection-mode proxy 
        # set mobile-malware-db enable 
        # config http
        # set options scan 
        # unset archive-block 
        # set archive-log encrypted corrupted multipart nested mailbomb unhandled 
        # set emulator enable 
        # end
        # config ftp
        # set options scan 
        # unset archive-block
        # set archive-log encrypted corrupted multipart nested mailbomb unhandled 
        # set emulator enable 
        # end
        # config imap
        # set options scan 
        # unset archive-block 
        # set archive-log encrypted corrupted multipart nested mailbomb unhandled 
        # set emulator enable 
        # set executables default 
        # end
        # config pop3   
        # set options scan 
        # unset archive-block
        # set archive-log encrypted corrupted multipart nested mailbomb unhandled 
        # set emulator enable 
        # set executables default 
        # end
        # config smtp
        # set options scan 
        # unset archive-block
        # set archive-log encrypted corrupted multipart nested mailbomb unhandled 
        # set emulator enable 
        # set executables default
        # end 
        # config mapi
        # set options scan 
        # unset archive-block 
        # set archive-log encrypted corrupted multipart nested mailbomb unhandled 
        # set emulator enable 
        # set executables default 
        # end
        # config nntp
        # set options scan 
        # unset archive-block 
        # set archive-log encrypted corrupted multipart nested mailbomb unhandled 
        # set emulator enable 
        # end
        # config nac-quar
        # set infected none 
        # set log enable 
        # end
        # set av-virus-log enable 
        # set av-block-log enable
        # end

Die entsprechenden Profiles sind nur konfiguriert und diese können nun zu einer entsprechenden Firewall Policy Rule hinzugefügt werden. Dabei ist folgendes zu beachten: In der Firewall Policy Rule sollten die entsprechenden Services/Ports explizit definiert werden dh. es sollte auf Service "All" verzichtet werden. Nachfolgendes Beispiel zeigt eine Firewall Policy Rule für HTTP/HTTPS in der für Unverschlüsselter Traffic (Proxy Options Profile) sowie Verschlüsselter Traffic (SSL Inspection Profile) für das Antivirus Profile aktiviert wurde:

        Policy & Objects > IPv4 Policy > Create New

        [[Datei:Fortinet-2052.jpg]]

Nachträglich sollte die Konfiguration getestet werden dh. über folgende Seite kann anhand der EICAR Informationen getestet werden ob ein Virus über die Konfiguration erkannt wird:

        http://www.eicar.org/85-0-Download.html

Ist die der Fall wird über den Web Browser folgende Meldung angezeigt:

        [[Datei:Fortinet-2053.jpg]]

=== Wie kann ich verhindern das unter FortiOS 5.4 für HTTP "Streaming Content" die Antivirus Funktion benützt wird? ===

Wenn über HTTP Streaming Content aufgerufen wird so versucht die Antivirus Engine diesen Streaming Content zu scannen sofern ein Antivirus Profile für HTTP in einer entsprechenden Firewall Policy Rule konfiguriert wurde. Möchte man dies verhindern so kann das Protocol Options Profile, das zusammen mit dem Antivirus Profile in der entsprechenden Firewall Policy Rule benutzt wird, durch folgende Konfiguration ein Antivirus Scan verhindert werden:

        # config firewall profile-protocol-options
        # edit [Name des entsprechenden Profiles]
        # config http
        # set streaming-contentbypass [enable | disable]
        # end
        # end

Diese Konfiguration gilt jedoch nur für HTTP und nicht für andere Protokolle resp. Services wie zB HTTPS. Eine andere Möglichkeit ein Scanning durch die Antivirus Engine zu verhindern ist den MIME Header heranzuziehen um einen Scan zu verhindern. Die Funktion ein Scan über MIME Header zu verhindern steht jedoch innerhalb der Antivirus Funktion nicht zur Verfügung. Ein MIME Header kann stattdessen über die "content-header" Funktion des WebFilter konfiguriert werden. Um die Konfiguration durchzuführen muss als erster Schritt der MIME Header des Content eruiert werden. Dies kann zB über WireShark durchgeführt werden. Nachfolgend die MIME Header Informationen aus WireShark betreffend YouTube:

        Hypertext Transfer Protocol
        HTTP/1.0 200 OK\r\n
        Request Version: HTTP/1.0
        Response Code: 200
        Server: DCLK-AdSvr\r\n
        '''Content-Type: video/x-ms-asf\r\n'''
        X-Google-Inred-Content-Type: video/x-ms-asf\r\n
        Content-Length: 410\r\n
        Content-Encoding: gzip\r\n

        Hypertext Transfer Protocol
        HTTP/1.1 200 OK\r\n
        Request Version: HTTP/1.1
        Response Code: 200
        Last-Modified: Mon, 14 Sep 2009 00:40:51 GMT\r\n
        '''Content-Type: video/x-flv\r\n'''
        Content-Length: 200994\r\n
        Connection: close\r\n
        Content-Disposition: attachment; filename="video.flv"\r\n
        Expires: Thu, 29 Oct 2009 09:06:24 GMT\r\n
        Cache-Control: public,max-age=3600\r\n
        Date: Thu, 29 Oct 2009 08:06:24 GMT\r\n
        Server: gvs 1.0\r\n

Die relevanten Informationen um einen "content-header" Konfiguration durchzuführen, sind die "Content-Type" Informationen. In unserem Beispiel sind das die folgenden Positionen:

        Content-Type: video/x-ms-asf\r\n
        Content-Type: video/x-flv\r\n

In der "content-header" Konfiguration muss anhand "Regex" die nötigen Informationen betreffend dem MIME Header der konfiguriert werden soll definiert werden. Möchte man alle video sowie audio MIME Header definieren so muss folgendes definiert werden:

        video\\/.*
        audio\\/.*

Das Zeichen "/" stellt im RegEx ein Sonderzeichen dar. Dadurch kann nicht einfach "video/" definiert werden da Sonderzeichen mit "\\" escaped werden müssen! Nun kann die "content-header" Konfiguration durchgeführt werden:

       # config webfilter content-header
       # edit [Gebe einen Integer an zB "1"]
       # set comment [Setze einen Kommentar zB "Exclude Video Audio Antivirus"]
       # config entries
       # edit "video\\/.*"
       # set action [allow | block | exempt]
       # next
       # edit "audio\\/.*"
       # set action [allow | block | exempt]
       # next
       # end
       # set name [Setze einen Namen für den "content-header" zB "video-audio-exempt"]
       # next
       # end

Durch die Konfiguration "exempt" wird der definierte MIME Header resp. "content-header" vom Antivirus Scan ausgeschlossen. Nun kan dieser "content-header" innerhalb eines WebFilters konfiguriert werden:

       # config webfilter profile
       # edit [Wähle den Namen des entsprechenden WebFilter Profiles]
       # config web
       # set content-header-list [Gebe den entsprechenden Integer an für "content-header"]
       # end
       # next
       # end

Nun kann der entsprechende WebFilter zu der entsprechenden Firewall Policy Rule hinzugefügt werden!

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device eine Antivirus Quarantine konfigurieren? ===

Ausgehend davon das ein FortiGate Device über eine Disk verfügt für die ein "disk" Logging aktiviert werden kann oder die Logs zu einem FortiAnalyzer übermittelt werden, kann eine Quarantine für Antivirus konfiguriert werden. Die Quarantine Funktion wird innerhalb des Antivirus Profiles für die verschiedenen Services/Ports mit folgenden Befehl aktiviert:

       # config antivirus profile
       # edit [Name des entsprechenden Antivirus Profile]
       # config [http | ftp | imap | pop3 | smtp | mapi | nntp]
       # set options [avmonitor | quarantine | scan]
       # end
       # end

Um eine Quarantine zu aktivieren muss "quarantine" für die Option "options" aktiviert werden wobei dies nur ermöglicht wird, wenn "disk" Logging aktiviert wird für den FortiGate Device und/oder ein Logging für FortiAnalyzer. Danach kann die Qurantine über folgende Kommandos in der CLI konfiguriert werden:

        # config antivirus quarantine
        # set agelimit [Maximale Zeitdauer in Stunden für Quarantine Files wenn "destination" NULL ist; 0 - 479]
        # set maxfilesize [Setze Maximale Filegrösse für Quarantine in MB 0 - 500 MB; 0 = Unlimited]
        # set quarantine-quota [Quota Space in MB 0 - 17599427]
        # set drop-infected [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
        # set store-infected [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
        # set drop-blocked [imap | smtp | pop3 | http | ftp | nntp | imaps | smtps | pop3s | ftps | mapi | mm1 | mm3 | mm4 | mm7]
        # set store-blocked [imap | smtp | pop3 | http | ftp | nntp | imaps | smtps | pop3s| ftps | mapi | mm1 | mm3 | mm4 | mm7]
        # set drop-heuristic [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
        # set store-heuristic [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
        # set lowspace [drop-new | ovrw-old]
        # set destination [NULL | disk | FortiAnalyzer]
        # end

Für die Konfigurtion "destination" gilt: NULL deaktiviert die Quarantine. Die Option "disk" steht nur dann zur Verfügung wenn der FortiGate Device für Logging die "disk" aktiviert werden kann. FortiAnalyzer steht dann zur Verfügung wenn Logging über FortiAnalyzer konfiguriert wurde.

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device die Antivirus Funktion vorübergehend deaktivieren? ===

Wenn aus irgendwelchen Gründen die konfigurierte Antivirus Funktion deaktiviert werden soll kann dies anhand folgenden CLI Kommandos durchgeführt werden:

        # diagnose antivirus bypass [on | off]

Durch dieses Kommando wird somit auf globaler Ebene einen Bypass für die Antivirus Funktion aktiviert resp. deaktiviert ohne die Konfiguration der Antivirus Funktion zu verändern!

== WebFilter ==

=== Was muss ich unter FortiOS 5.4 als Grundlage für eine WebFilter Konfiguration beachten? ===

Wenn ein WebFilter auf einem FortiOS 5.4 konfiguriert werden soll, muss zu Beginn die korrekte Zeitzone konfiguriert werden. Wenn die Zeitzone nicht korrekt konfiguriert wurde so benützt die WebFilter Funktion in FortiGuard die falsche Datenbank dh. zB US anstelle der Europäischen Datenbank. Um die korrekte Zeitzone zu konfigurieren siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_auf_einer_FortiGate_unter_FortiOS_5.4_die_Zeitzone_konfigurieren.3F]]

Ebenso gilt als Grundlage für die WebFilter Funktion einwanfrei konfigurierte DNS Server für das FortiOS um die entsprechenden FortiGuard Abfragen durchzuführen. Wie diese FortiOS DNS Server konfiguriert werden siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_konfiguriere_unter_FortiOS_5.4_auf_einer_FortiGate_die_System_DNS_Server.3F]] 

Die WebFilter Funktion eines FortiOS basiert auf einer Online Abfrage betreffend Kategorien für FortiGuard dh. es werden Informationen zu FortiGuard gesendet um die Kategorisierung zu überprüfen. Dabei werden vom FortiOS folgende Informationen zu FortiGuard für die Kategorisierung gesendet:

        • FortiGate Serien Nummer
        • FortiGate Source IP Adresse 
        • Website Komplette URL, inkl. Schema, Hostname und Pfad

Das Resultat der Abfrage dh. die Kategorisierung wird lokal auf dem FortiOS in einen Cache geschrieben. Die zuständige Position die dieses Verhalten steuert ist:

        # config system fortiguard 
        # set webfilter-force-off [enable | disable]
        # set webfilter-cache-ttl [TTL für WebFilter Cache in Sekunden 300 - 86400; Standard 3600]
        # set webfilter-cache [enable | disable]
        # set webfilter-timeout [Timout in Sekunden für FortiGuard Abfrage 1 - 30; Standard 15]
        # set 
        # end

Wenn die WebFilter Abfrage zu FortiGuard aus irgendwelchen Gründen gestoppt werden soll, kann die Option "webfilter-force-off" auf "enable" gesetzt werden. Die Konfiguration "webfilter-cache" steht ebenfalls in Zusammenhang mit der folgenden Konfiguration:

        # config webfilter fortiguard
        # set cache-mode [ db-ver | ttl; Standard ttl]
        # set cache-mem-percent [Prozent vom Memory 1 - 15; Standard 2]
        # set cache-prefix-match [enable | disable]
        # set ovrd-auth-port-http [Port für FortiGuard Web Filter HTTP override; Standard 8008]
        # set ovrd-auth-port-https [Port für FortiGuard Web Filter HTTPS override; Standard 8010]
        # set ovrd-auth-port-warning [Port für FortiGuard Web Filter Warning override; Standard 8020]
        # set ovrd-auth-https [enable | disable]
        # set warn-auth-https [enable | disable]
        # set close-ports [enable | disable]
        # set request-packet-size-limit [Maximum Packet Size in bytes für FortiGuard 576 - 10 000; Standard 0 = 1100 bytes]
        # end

Der "cache-mode" ist per Standard auf "ttl" gesetzt was wiederum dem Standard innerhalb der Konfiguration von "system fortiguard" entspricht. Dabei gilt folgendes: Ein entsprechender Eintrag im WebFilter Cache wird gelöscht nach Ablauf des Wertes "ttl" das unter FortiGuard gesetzt wird! Wird der "cache-mode" auf "db-ver" gesetzt anstelle "ttl", wird für den WebFilter Cache eine Datenbank im Memory angelegt in der Grösse des Werts "cache-mem-percent". Die WebFilter Cache Einträge verbleiben in der Datenbank, bis ein entsprechender Eintrag in der Datenbank durch FortiGuard geändert wird oder über FortiGuard verändert wird (force). 

=== Wie kann ich für FortiOS 5.4 für WebFilter Funktion eine URL/Site bei Fortinet Re-Kategoriesieren lassen? ===

Wenn in einer entsprechenden Firewall Policy ein WebFilter aktiviert ist und ein Host/Client eine Site/URL aufruft, wird diese Site/URL über FortiGuard überprüft. Handelt es sich um eine Site/URL die nicht Kategorisiert wurde fällt diese innerhalb der FortiGate Kategorien unter "Unrated". Wenn nun diese Site/URL Kategorisiert werden möchte in FortiGuard oder eine Site/URL Re-Kategorisiert werden soll da diese falsch Kategorisiert wurde, wähle folgenden Link:

        http://www.fortiguard.com/static/webfiltering.html

Gebe auf dieser Seite Rechts Oben unter "URL/IP Rating & Info" die entsprechende Site/URL ein mit dessen FQDN (Fully Qualified Domain Name):

        [[Datei:Fortinet-1124.jpg]]

Nachdem die Eingabe bestätigt wurde, wird das entsprechende Resultat angezeigt dh. in welcher Kategorie sich die Site/URL befindet sowie die Statistik der Abfragen in FortiGuard für diese Site/URL. Möchte man nun einen Anfrage für eine Kategorisierung/Re-Kategorisierung absetzen wähle am ende der Seite die endsprechenden Felder aus und bestätige anhand des Captcha:

        [[Datei:Fortinet-1125.jpg]]

Jede Anfrage sollte innerhalb von 24 Stunden von Fortinet beantwortet werden. Als Bestätigung erhält man von Fortinet folgendes Email:

        -------------- email outpout --------------
        
        Von: FortiGuard Web Filtering Service [mailto:fgweb@fortinet.com]
        
        Dear Fortinet customer,
        
        The website(s) you submitted below has been reviewed and updated:
        
        Submission Date:            Thu, 5 Apr 2012 12:08:11 -0700
        URL:                        http://baeurer.de/
        Suggested Category:         Information Technology
        Customer Comment:           Baeurer is a ERP wending company and not developing freeware downloads to the internet. Please re-categorize.
        Updated Category:           Information Technology
        Update Date:                Thu, 5 Apr 2012 19:21:01 -0700
        
        If the suggested category does not meet your expectation, kindly contact us through http://www.fortiguard.com/contactus.html, our Web 
        Filtering team would be happy to assist you.
        
        Note that FortiGuard Web Filtering Service categorizes websites, but it is your IT manager who decides what categories to block or allow. 
        Therefore, if you would like access to the site, please contact your IT manager.
        
        The rating update may not be effective immediately on your network because of the Web filtering cache. If you would like to have the 
        update effective immediately, please contact your network administrator.
        
        Thank you for using FortiGuard Web Filtering Service.
        
        Regards,
        
        FortiGuard Web Filtering Service
        Fortinet Inc.
        
        -------------- email outpout --------------

=== Wie kann ich unter FortiOS 5.4 ein WebFilter Profile mit Blacklisting/Whitelisting konfigurieren? ===

Wenn man unter FortiOS 5.4 einen WebFilter für HTTPS sowie HTTP konfiguriert, gelten folgende Profiles als Voraussetzung:

        • SSL Inspection Profile (HTTPS)
        
                - SSL Certificate Inspection (HTTPS basierend auf Zertifikat CN; Common Name)
                - Full SSL Inspection        (HTTPS Uneingeschränkte Funktion "deep inspection")
        
        • Proxy Options Profile (HTTP)

Wenn Full SSL Inspection dh. "deep inspection" durchgeführt wird gilt als Voraussetzung, dass das entsprechende Fortinet_CA_SSLProxy Zertifikat bei jedem Host/Client als Vertrauenswürdiges Stammzertifikat importiert wird. Nur so kann eine uneingeschränkte "deep inspection" durchgeführt werden dh. der verschlüsselte Traffic des Host/Client aufgebrochen und eine uneingeschränkte Inspection in allen Bereichen für diesen Traffic durchgeführt werden! Wird keine Full SSL Inspection durchgeführt, kann anhand der SSL Certificate Inspection für HTTPS eine Zertifikats Inspection durchgeführt werden. Dies bedeutet: Im "TLS Handshake" der HTTPS Verbindung wird der Hostname des Server Namens innerhalb der "Client Hello" Message herausgefiltert (CN = Common Name). Dies bedeutet wiederum: Wenn ein gültiger Hostname herausgefiltert werden kann, ist dieser Hostname Basis für die Abfrage für die FortiGuard WebFilter Kategorien. Wenn kein gültiger Hostname herausgefiltert werden kann, wird ein CN (Common Name) basierende Ueberprüfung durchgeführt dh. es wird der CN Name des Zertifikats benützt für die Abfrage für die FortiGuard Webfilter Kategorie. Wenn die Option "block-invalid-hostname" innerhalb  des WebFilters aktiviert ist und der CN Name des Zertifikates ist ein ungültiger Domain Name so wird die Seite geblockt und ein entsprechender Log Eintrag wird erstellt. Somit müssen zu Beginn die entsprechenden Profiles als Grundlage für einen WebFilter Funktion konfiguriert werden sowie entschieden werden ob für das Proxy Options Profile eine SSL Certificate Inspection oder Full SSL Inspection für HTTPS konfiguriert werden möchte:

        '''Proxy Options Profile Konfiguration (HTTP)'''
        
        Security Profiles > Proxy Options > Create New
        
        [[Datei:Fortinet-2049.jpg]]
        
        # config firewall profile-protocol-options 
        # edit [Name des entsprechenden Proxy Options Profile zB "local-default.intra"]
        # set comment [Gebe einen Kommentar ein zB "Unencrypted default profile local-sg0e0"]
        # unset replacemsg-group
        # set oversize-log enable
        # set switching-protocols-log enable
        # config http
        # set ports 80
        # set status enable 
        # set inspect-all disable 
        # set options clientcomfort 
        # set comfort-interval 10
        # set comfort-amount 1
        # set range-block disable 
        # unset post-lang
        # set fortinet-bar disable 
        # set streaming-content-bypass enable 
        # set switching-protocols bypass 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # set block-page-status-code 200
        # set retry-count 0
        # end
        # config ftp
        # set ports 21
        # set status enable 
        # set inspect-all disable 
        # set options clientcomfort 
        # set comfort-interval 10
        # set comfort-amount 1
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config imap
        # set ports 143
        # set status enable 
        # set inspect-all disable 
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config mapi
        # set ports 135
        # set status enable
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config pop3
        # set ports 110
        # set status enable
        # set inspect-all disable 
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config smtp
        # set ports 25
        # set status enable
        # set inspect-all disable 
        # set options fragmail 
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # set server-busy disable 
        # end
        # config nntp
        # set ports 119
        # set status enable 
        # set inspect-all disable 
        # unset options
        # set oversize-limit 10
        # set uncompressed-oversize-limit 10
        # set uncompressed-nest-limit 12
        # set scan-bzip2 disable 
        # end
        # config dns
        # set ports 53
        # set status enable 
        # end
        # config mail-signature
        # set status disable 
        # unset signature
        # end
        # set rpc-over-http enable 
        # end

        '''SSL Inspection Profile Konfiguration (HTTPS SSL Certificate Inspection)'''
        
        Security Profiles > SSL Inspection > Create New
        
        [[Datei:Fortinet-2059.jpg]]
        
        # config firewall ssl-ssh-profile 
        # edit [Wähle ein entsprechendes SSL Inspection Profile zB "local-default.intra"]
        # set comment [Gebe einen Kommentar ein zB "Encrypted default profile local-sg0e0"]
        # config ssl
        # set inspect-all disable 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config https
        # set ports 443
        # set status certificate-inspection 
        # set client-cert-request bypass 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config ftps
        # set ports 990
        # set status disable 
        # set client-cert-request bypass 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config imaps
        # set ports 993
        # set status disable 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config pop3s
        # set ports 995
        # set status disable  
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config smtps
        # set ports 465
        # set status disable 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # set whitelist disable
        # end 
        # config ssl-exempt
        # end
        # set server-cert-mode re-sign 
        # set caname Fortinet_CA_SSLProxy 
        # set untrusted-caname Fortinet_CA_Untrusted 
        # set certname Fortinet_CA_SSLProxy 
        # end
        # config ssl-server
        # end
        # set ssl-invalid-server-cert-log enable 
        # set use-ssl-server disable 
        # end

        '''SSL Inspection Profile Konfiguration (HTTPS Full SSL Inspection)'''
        
        Security Profiles > SSL Inspection > Create New
        
        [[Datei:Fortinet-2050.jpg]]
        
        # config firewall ssl-ssh-profile 
        # edit [Wähle ein entsprechendes SSL Inspection Profile zB "local-default.intra"]
        # set comment [Gebe einen Kommentar ein zB "Encrypted default profile local-sg0e0"]
        # config ssl
        # set inspect-all disable 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config https
        # set ports 443
        # set status deep-inspection 
        # set client-cert-request bypass 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config ftps
        # set ports 990
        # set status deep-inspection 
        # set client-cert-request bypass 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config imaps
        # set ports 993
        # set status deep-inspection 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config pop3s
        # set ports 995
        # set status deep-inspection 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # end
        # config smtps
        # set ports 465
        # set status deep-inspection 
        # set client-cert-request inspect 
        # set unsupported-ssl bypass 
        # set allow-invalid-server-cert disable 
        # set untrusted-cert block 
        # set whitelist disable
        # end 
        # config ssl-exempt
        # end
        # set server-cert-mode re-sign 
        # set caname Fortinet_CA_SSLProxy 
        # set untrusted-caname Fortinet_CA_Untrusted 
        # set certname Fortinet_CA_SSLProxy 
        # end
        # config ssl-server
        # end
        # set ssl-invalid-server-cert-log enable 
        # set rpc-over-https enable 
        # set use-ssl-server disable 
        # end

Wenn ein WebFilter konfiguriert wird, so ist es sinnvoll bei dieser Konfiguration ein Blacklisting/Whitelisting vorzukonfigurieren. Diese Konfiguration erlaubt es, WebSeiten direkt in diese lokalen Kategorieren für Blacklisting/Whitlisting zu verschieben resp. zu konfigurieren. Durch diese Konfiguration wird ein "override" der FortiGuard Kategorien durchgeführt. Per Standard existieren bereits zwei lokale Kategorieren (custome1/2) die herangezogen werden können um ein Blacklisting/Whitelisting zu konfigurieren. Dazu müssen diese zwei existieren lokalen Kategorieren umbenannt werden oder neue hinzugefügt werden. Diese Konfiguration kann über CLI durchgeführt werden:

        # config webfiler ftgd-local-cat
        # get
        == [ custome1 ]
        desc: custome1
        == [ custome2 ]
        desc: custome2
        # rename custome1 to whitelist
        # rename custome2 to blacklist
        # get
        == [ whitelist ]
        desc: whitelist
        == [ blacklist ]
        desc: blacklist
        # end

Um eine Neue lokale Kategorie zu erstellen führe folgendes durch:

        # config webfiler ftgd-local-cat
        # edit warning
        # end
        # edit authentication
        # end
        # end

Danach sind die neu Erstellten lokalen Kategorien über folgenden Menüpunkt im Mgmt. Web Interface ersichtlich:

        Security Profiles > Web Rating Overrides > Custom Categories

        [[Datei:Fortinet-2060.jpg]]

Eine Seite kann nachträglich folgendermassen einer lokalen Kategorie hinzugefügt werden:

        Security Profiles > Web Rating Overrides > Create New

        [[Datei:Fortinet-2066.jpg]]

        [[Datei:Fortinet-2067.jpg]]

Nun kann der WebFilter konfiguriert werden, in dem wir diese lokalen Kategorieren definieren dh. aktiviere die Position "FortiGuard category based filter" und innerhalb der "Local Categories" definiere mit einem rechten Mausklick für jeden Eintrag die entsprechende Aktion wie zB Block, Monitor usw.:

        Security Profiles > Web Filter > Create New

        [[Datei:Fortinet-2061.jpg]]

Danach konfiguriere für die FortiGuard Kategorien mit der gleichen Vorgehensweise deren Aktionen dh. Um eine entsprechende Kategorie zu erlauben sollte die Aktion "Monitor" gewählt werden damit für eine spätere Auswertung die entsprechenden Informationen zur Verfügung stehen. Innerhalb der Kategorien können granular wiederum andere Aktionen gewählt werden. Um einen WebFilter für FortiGuard Kategorien zu konfigurieren resp. eine Ausgangslage zu bieten empfehlen wir folgenden Grundkonfiguration:

        Potentially Liable             Alles auf Block
        Adult/Mature Content           Alles auf Block ausser Alcohol und Tabaco auf Monitor
        Bandwidth Consuming            Alles auf Monitor
        Security Risk                  Alles auf Block
        General Interest - Personal    Alles auf Monitor
        General Interest - Business    Alles auf Monitor
        Unrated                        Alles auf Monitor

Desweiteren empfehlen wir für eine WebFilter Konfiguration folgendes:

        [[Datei:Fortinet-2062.jpg]]
        [[Datei:Fortinet-2063.jpg]]
        [[Datei:Fortinet-2064.jpg]]

Nachfolgend die einzelnen Konfigurationspunkte innerhalb des WebFilters kurz erläutert:

        '''Log all URLs'''
        
        Durch die Aktivierung dieser Position wird für jede URL in jedem Fall ein Logging durchgeführt obwohl FortiGuard
        nicht zur Verfügung steht. Wir empfehlen innerhalb der FortiGuard Kategorieren dh. "FortiGuard category based 
        filter" für eine Kategorie die erlaubt wird anstelle "Allow" die Aktion "Monitor" zu konfigurieren da dadurch 
        jede einzelne URL in das WebFilter Log geschrieben wird und somit für eine spätere Auswertung sämtliche 
        Informationen zur Verfügung stehen!

        '''Category Usae Quota'''
        
        Diese Position erlaubt eine Zeitbasierende sowie Volumenbasierende Konfiguration für FortiGuard Kategorien. Dies 
        bedeutet: Für eine bestimmte Kategorie kann eine spezifische Zeit oder Volumen definiert werden!

        '''Allow users to override blocked categories'''
        
        Durch diese Konfiguration wird User einer spezifischen Gruppe erlaubt ein "override" durchzuführen. Erhält ein 
        entsprechender User der Mitglied ist für die definierte Gruppe eine "Block" für eine entsprechende Seite, kann 
        dieser User auf dieser geblockten Seite ein "override" ausführen. Ebenso kann ein anstelle eines "override" ein 
        "switch to" ausgeführt werden dh. dem User wird ermöglicht zu einem spezifischen WebFilter Profile zu wechseln.
        Dieser "switch to" kann anhand User, Gruppen, IP und "Ask" eingeschränkt und konfiguriert werden.

        '''Search Engines'''
        
        Durch die Aktivierung dieser Position versucht die WebFilter Funktion nur erlaubte Kategorien in den entsprechenden 
        Suchmaschinen Ergebnisse aufzulisten. Zusätzlich kann anhand "Log all search keyword" die Suchtexte für die Suche 
        geloggt werden! Bei beiden Funktionen ist folgendes zu berücksichtigen: Da die entsprechenden Suchmaschinen HTTPS 
        benutzen für eine Suche, kann die WebFilter Funktion die gewünschten Ergebnisse nur dann erreichen, wenn für HTTPS 
        Full SSL Inspection benutzt wird.
        
        Der YouTube Education Filter bietet eine Möglichkeit durch Aktivierung ein Passowrt zu definieren das eine
        Verbindung schafft zum YouTube Education Account. Dieser wiederum bietet die Möglichkeit YouTube Filme/Movies zu
        diesem YouTube Education Account hinzuzufügen. Somit sind nur diese definierten YouTube Filme/Movies erlaubt. Es
        ist nicht möglich basierend auf YouTube Kategorieren im YouTube Education Account eine Konfiguration zu erstellen
        da es keine offiziellen YouTube Kategorien existieren. Für diese Konfiguration ist ein Full SSL Inspection absolute 
        Voraussetzung da ansonsten die Konfiguration über HTTPS durch die User umgangen werden kann! Weitere Informationen
        zur Konfguration des YouTube Education Filters siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Was_bedeutet_unter_FortiOS_5.4_f.C3.BCr_ein_WebFilter_Profile_der_Konfigurationspunkt_.22YouTube_Education_Filter.22.3F]]

        '''Static URL Filter'''
        
        Durch "Block invalid URLs" werden Seiten blockiert die über einen nicht gültigen Domain Namen verfügen! Durch die
        Aktivierung des "URL Filter" Funktion wird über Wildcard, Simple sowie Regex ermöglicht Sites, URL sowie Domains 
        von einer UTM Aktion auszunehmen dh. "Exempt". Ebenso können Aktionen wie Monitor, Allow und Block konfiguriert
        werden. In dem hier gezeigten WebFilter wurden Sites wie *.apple.com, *.microsoft.com mit der Aktion "Exempt" 
        konfiguriert dh. für diese Seiten wird kein UTM Feature ausgeführt wie zB Antivirus! Weitere Inforamtionen zu
        dieser Konfiguration siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_WebFilter_Profile_bestimmte_URLs_von_UTM_Features_ausschliessen.3F]]
        
        Unter FortiOS 5.4 steht die Position "Block malicious URLs discovered by FortiSandbox" neu zur Verfügung und steht
        im Zusammenhang mit der FortiSandbox Funktion und kann nur dann genützt werden wenn die FortiSandbox Funktion auf
        dem FortiOS aktiviert und konfiguriert wurde.

        Durch Web Content Filter kann eine Seite entsprechend eine Sprache gefiltert werden durch die Definition des Pattern
        der anhand Wildcard oder Reg. Expression definiert werden kann. Aktionen wie Block oder Exempt sind möglich. Für 
        diese Funktion gilt Full SSL Inspection als Voraussetzung da ein Content Filter für verschlüsselten Traffic nur dann
        durchgführt werden kann, wenn eine "deep inspection" durchgeführt wird.

        '''Rating Options'''
        
        Die Position "Allow websites when a rating error occurs" steuert das Verhalten der WebFilter Funktion, wenn eine 
        Abfrage für die Kategorisierung des WebFilters in FortiGuard nicht durchgeführt werden kann. Ist diese Abfrage aus
        irgendwelchen Gründen nicht erfolgreich, wird der Zugriff des Users auf eine entsprechende Seite geblockt! Unter 
        normalen Umständen empfehlen wir diese Funktion zu aktivieren.
        
        Durch "Rate URLs by domain and IP Adress" wird zusätzlich zur Domaine für die Kategorisierung die Public IPv4 Adresse
        der entsprechenden Site/URL ebenfalls in FortiGuard überprüft. Wir empfehlen diese Funktion zu aktivieren um die 
        zusätzliche Ueberprüfung durchzuführen!   
        
        Durch die Funktion "Block HTTP redirects by rating" werden "redirects" ebenfalls in der Ueberprüfung durch den Web
        Filter berücksichtigt. Wir empfehlen diese Funktion zu aktivieren!
        
        Durch "Rate images by URL" werden die hinterlegten URLs der Images überprüft. Handelt es sich um eine URL für die
        betreffend Kategorisierung ein Block konfiguriert wurde, wird das entsprechende Image durch den Proxy entfernt und
        mit einem "blank" Image ersetzt.

        '''Proxy Options'''
        
        Durch Aktivierung von "Restrict Google account usage to specific domains" kann die entsprechende Goolge Domain
        konfiguriert werden und somit der Zugriff auf diese Domain eingeschränkt werden. Für diese Funktion gilt Full SSL 
        Inspection als Grundvoraussetzung.
        
        Durch die Aktivierung von "Provide details for blocked HTTP 4xx and 5xx errors" werden die Fehlermeldungen des Web
        Servers direkt zurück gegeben anstelle der Fehlermeldungen des FortiOS Proxy Servers. Um die detaillierten HTTP 
        errors des Server zu erhalten sollte diese Position aktiviert werden!
        
        Soll verhindert werden das eine HTTP Post Action durch einen User ausgeführt werden kann, muss die Position "HTTP 
        Post Action" auf Block gesetzt werden. Wenn dies durchgeführt wird kann zB ein User kein Upload auf eine Web Server 
        mehr durchführen. Für diese Funktion gilt Full SSL Inspection als Voraussetzung.
        
        Die die Aktivierung der Funktionen "Remove Java Applets, Remove AcitveX sowie Remove Cookies" wird dem Proxy Server
        ermöglicht diese Funktionen zu entfernen!

Die entsprechenden Profiles sind nur konfiguriert und diese können nun zu einer entsprechenden Firewall Policy Rule hinzugefügt werden. Dabei ist folgendes zu beachten: In der Firewall Policy Rule sollten die entsprechenden Services/Ports explizit definiert werden dh. es sollte auf Service "All" verzichtet werden. Nachfolgendes Beispiel zeigt eine Firewall Policy Rule für HTTP/HTTPS in der für Unverschlüsselter Traffic (Proxy Options Profile) sowie Verschlüsselter Traffic (SSL Inspection Profile) ein WebFilter Profile aktiviert wurde: 

        Policy & Objects > IPv4 Policy > Create New

        [[Datei:Fortinet-2065.jpg]]

=== Wie kann ich unter FortiOS 5.4 für ein WebFilter Profile einzelne URL/Sites vom Full SSL Inspection ausschliessen? ===

Wenn ein WebFilter Profile im Zusamenhang mit Full SSL Inspection konfiguriert wird, können Situationen eintreten in denen eine bestimmte URL/Site von der Full SSL Inspection ausgeschlossen werden müssen. Diese Funktion wird innerhalb des Full SSL Inspection Profile durch "ssl-exempt" zur Verfügung gestellt. Dabei können WebFilter lokale Kategorien, FortiGuard Kategorien sowie einzelne Adressen basierend auf IPv4 oder FQDN Adress Objekte von Full SSL Inspection ausgeschlossen werden. Die Konfiguration kann über Mgmt. Web Interface oder CLI durchgeführt werden:

        Security Profiles > SSL Inspection > [Wähle das entsprechende Full SSL Inspection Profile] > Edit > Exempt from SSL Inspection

        [[Datei:Fortinet-2069.jpg]]

        # config firewall ssl-ssh-profile
        # edit [Wähle das entsprechende Full SSL Inspection Profile]
        # set whitelist [enable | disable]
        # config ssl-exempt
        # edit [Gebe eine entsprechenden Integer an zB "1"]
        # set type [fortiguard-category | address]
        # set fortiguard-category [Gebe die entsprechende FortiGuard Kategorie an; Für eine Liste benütze ?]
        # set address [Gebe ein entsprechendes Adress Objekt an FQDN oder IPv4]
        # end

Der Position "Reputable Websites" was wiederum der Konfiguration in der CLI "whitelist" entspricht muss bei der "ssl-exempt" Konfiguration berücksichtigt werden! Dies bedeutet: Wenn diese Funktion deaktiviert wird so werden für die definierten Web Kategorieren und/oder Adressen unter der Menüposition "Exempt from SSL Inspection" keine SSL Inspection durchgeführt! Es wird jedoch für diese definierten Web Kategorien und Adressen UTM Funktionen ausgeführt sofern diese Konfiguriert wurden. Wird die Position "Reputable Websites" aktiviert so wird für die definierten Web Kategorien und/oder Adressen unter "Exempt from SSL Inspection" UTM Funktionen ausgeführt und/oder ausgeschlossen gemäss folgender Konfiguration in der CLI im WebFilter Profile:

        # config webfilter profile
        # edit [Name des entsprechenden WebFilter Profiles]
        # config web
        # set whitelist [exempt-av | exempt-webcontent | exempt-activex-java-cookie | exempt-dlp | exempt-rangeblock | extended-log-others]
        # end
        # end

Somit kann anhand "Reputable Website" die Funktion "ssl-exempt" erweitert werden um UTM Features wie zB Antivirus auszuschliessen! Bei der Konfiguration "ssl-exempt" ist ebenfalls folgendes zu berücksichtigen: Im WebFilter Profile können lokale Kategorien konfiguriert werden und der Funktion "ssl-exempt" über "type fortiguard-category" als FortiGuard lokale Kategorie hinzugefügt werden. Dadurch können die URL/Sites über das Mgmt. Web Interface zu dieser lokalen Kategorie hinzugefügt und somit automatisch zur "ssl-exempt" Funktion hinzugefügt werden. Wie lokale Kategorien konfiguriert werden siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_WebFilter_Profile_mit_Blacklisting.2FWhitelisting_konfigurieren.3F]]

=== Wie kann ich unter FortiOS 5.4 für ein WebFilter Profile bestimmte URLs von UTM Features ausschliessen? ===

Wenn ein WebFilter Profile konfiguriert wird, können innerhalb dieses WebFilter Profiles bestimmte URLs anhand Wildcard oder Regular Expression unter der Position "URL Filters" konfiguriert werden dh. anhand der folgenden Actions:

        Security Profiles > WebFilter > [Wähle das entsprechende WebFilter Profile] > Edit > URL Filter > Create

        [[Datei:Fortinet-2068.jpg]]

Dabei kommt der Action "Exempt" eine spezielle Funktion zu. Wird die Action "Exempt" gewählt so wird die definierte URL sei es als Wildcard oder Regular Expression von sämtlichen UTM Features wie zB Antivirus ausgeschlossen. Möchte man nur defnierte UTM Features ausschliessen, steht unter CLI diese Konfiguration Granular zur Verfügung:

        # config webfilter urlfilter
        # edit [Integer für URLFilter zB "1"]
        # config entries
        # edit [Gebe einen entsprechenden Integer an zB "1"]
        # set url [Gebe eine entsprechende URL an zB basierend auf Wildcard "*.apple.com"]
        # set type [simple | regex | wildcard]
        # set action [exempt | block | allow | monitor]
        # set exempt [Setze die entsprechenden ausgeschlossenen Option sofern "action exempt" gesetzt ist; av | web-content | activex-java-cookie | dlp | fortiguard | range-block all]
        # set status [enable | disable]
        # unset referrer-host
        # end
        # end

Somit steht für Action "Exempt" folgendes zur Verfügung um ein UTM Feature auszuschliessen:

       • activex-java-cookie     ActiveX, Java, and cookie filtering.
       • all                     Exempt from all.
       • av                      Antivirus filtering.
       • dlp                     DLP scanning.
       • filepattern             File pattern matching.
       • fortiguard              FortiGuard web filtering.
       • pass                    Pass single connection from all.
       • range-block             Exempt range block feature.
       • web-content             Web filter content matching.

Wird als Action "Exempt" gewählt wird "set exempt" im Hintergrund per Standard folgendermassen konfiguriert:

        # set exempt av web-content activex-java-cookie dlp fortiguard range-block all

=== Wie kann ich unter FortiOS 5.4 für ein WebFilter Profile bestimmte MIME Header blockieren? ===

Wenn man ein WebFilter Profile konfiguriert, kann innerhalb dieses WebFilters die "content-header" Funktion benutzt werden um bestimmte MIME Header zu blockieren oder zB verhindern das Antivirus für diesen MIME Header ausgeführt wird. Dabei ist folgendes zu berücksichtigen: Diese Konfiguration kann für HTTP durchgeführt werden. Wenn jedoch diese Konfiguration basierend auf HTTPS durchgeführt wird, so muss Full SSL Inspection konfiguriert werden um für den Traffic ohne Einschränkung eine "deep inspection" durchzuführen. Um die Konfiguration durchzuführen, muss als erster Schritt der MIME Header des Content eruiert werden. Dies kann zB über WireShark durchgeführt werden. Nachfolgend die MIME Header Informationen aus WireShark betreffend YouTube: 

        Hypertext Transfer Protocol
        HTTP/1.0 200 OK\r\n
        Request Version: HTTP/1.0
        Response Code: 200
        Server: DCLK-AdSvr\r\n
        '''Content-Type: video/x-ms-asf\r\n'''
        X-Google-Inred-Content-Type: video/x-ms-asf\r\n
        Content-Length: 410\r\n
        Content-Encoding: gzip\r\n

        Hypertext Transfer Protocol
        HTTP/1.1 200 OK\r\n
        Request Version: HTTP/1.1
        Response Code: 200
        Last-Modified: Mon, 14 Sep 2009 00:40:51 GMT\r\n
        '''Content-Type: video/x-flv\r\n'''
        Content-Length: 200994\r\n
        Connection: close\r\n
        Content-Disposition: attachment; filename="video.flv"\r\n
        Expires: Thu, 29 Oct 2009 09:06:24 GMT\r\n
        Cache-Control: public,max-age=3600\r\n
        Date: Thu, 29 Oct 2009 08:06:24 GMT\r\n
        Server: gvs 1.0\r\n

Die relevanten Informationen um einen "content-header" Konfiguration durchzuführen, sind die "Content-Type" Informationen. In unserem Beispiel sind das die folgenden Positionen:

        Content-Type: video/x-ms-asf\r\n
        Content-Type: video/x-flv\r\n

In der "content-header" Konfiguration muss anhand "Regex" die nötigen Informationen betreffend dem MIME Header hinzugefügt werden. Möchte man alle video sowie audio MIME Header definieren so muss folgendes definiert werden:

        video\\/.*
        audio\\/.*

Das Zeichen "/" stellt im RegEx ein Sonderzeichen dar. Dadurch kann nicht einfach "video/" definiert werden da Sonderzeichen mit "\\" escaped werden müssen! Nun kann die "content-header" Konfiguration durchgeführt werden:

       # config webfilter content-header
       # edit [Gebe einen Integer an zB "1"]
       # set comment [Setze einen Kommentar zB "Block Video Audio"]
       # config entries
       # edit "video\\/.*"
       # set action [allow | block | exempt]
       # next
       # edit "audio\\/.*"
       # set action [allow | block | exempt]
       # next
       # end
       # set name [Setze einen Namen für den "content-header" zB "video-audio-block"]
       # next
       # end

Wenn in der Konfiguration für die einzelnen Einträge "exempt" gewählt wird, wird der definierte MIME Header resp. "content-header" von Antivirus Funktionen ausgeschlossen. Nun kan diese "content-header" Konfiguration einem WebFilter Profile hinzugefügt werden:

       # config webfilter profile
       # edit [Wähle den Namen des entsprechenden WebFilter Profiles]
       # config web
       # set content-header-list [Gebe den entsprechenden Integer an für "content-header" zB "1"]
       # end
       # next
       # end

=== Was bedeutet unter FortiOS 5.4 für ein WebFilter Profile der Konfigurationspunkt "YouTube Education Filter"? ===

Der YouTube Education Filter ist eine Möglichkeit für ein Unternehmen wie zB Schulen einen Account auf YouTube anzulegen und dort anhand eines YouTube Accounts zu definieren, welche YouTube Movies/Videos freigegeben werden. Dabei ist zu berücksichtigen, dass wenn die Funktion eingesetzt wird eine SSL Full Inspection als Voraussetzung gilt. Dies bedeutet: Durch eine uneingeschränkte "deep inspection" wird ermöglicht für den Traffic ohne Einschränkungen eine Inspection durchzuführen. Ebenso ist zu berücksichtigen beim Einsatz des YouTube Education Filter, dass nur definierte YouTube Movies/Videos zum YouTube Account hinzugefügt werden können und nicht Kategorien für YouTube Videos da es keine Standard Kategorien für YouTube Movies/Videos existieren. Um auf YouTube einen Education Account anzulegen folge nachfolgenden Link:

        http://www.youtube.com/schools

Wenn man einen Education Account anlegt wird diese mit einem "YouTube Education Filter" Passwort verknüpft. Dieses "Passwort" wird dann benutzt um im entsprechenden WebFilter Profile unter folgender Position den "YouTube Education Filter" zu konfigurieren:

        Security Profiles > WebFilter > [Wähle ein entsprechendes WebFilter Profile] > Edit > [Aktiviere "YouTube Education Filter"] > Custom YouTube ID

Wenn man die Konfiguration in der CLI durchführen möchte wäre dies die folgenden Kommandos:

        # config webfilter profile
        # edit [Wähle ein entsprechendes WebFilter Profile]
        # config web
        # set youtube-edu-filter-id [Setze das entsprechende Passwort für den "YouTube Education Filter"]
        # end
        # end
        
Um zu verhindern das dieser YouTube Education Filter durch Host/Clients umgangen wird zB durch https, müssen bei der Konfiguration einige Punkte beachtet werden. Weitere Informationen dazu siehe nachfolgende Dokumente:
             
        [[Datei:Setting-up-YouTube-for-Education-Fortigate.pdf]]
        [[Datei:How-YouTube-for-Schools-Works-YouTube-Help.pdf]]

=== Wie kann ich unter FortiOS 5.4 für die WebFilter Funktion ein Troubleshooting durchführen? ===

Wenn betreffend WebFilter Funktion ein Troubleshooting durchgeführt werden soll, muss der WebFilter Cache berücksichtig werden, der durch die FortiGuard Abfragen zur Kategorisierung im Hintergrund erstellt wird. Um die WebFilter Cache Informationen anzuschauen, zu löschen, TTLs der Einträge anzuschauen usw. steht folgendes Kommando zur Verfügung:

        # diagnose test application urlfilter 
        1.   This menu
        2.   Clear WF cache
        3.   Display WF cache contents
        4.   Display WF cache TTL list
        6.   Display WF cache in tree format
        7.   Toggle switch for dumping unrated packet
        10.  Print debug values
        11.  Clear Spam Filter cache
        13.  Toggle switch for dumping expired license packets
        14.  Show running timers (except request timers)
        144. Show running timers (including request timers)
        15.  Send INIT requests.
        16.  Display WF cache contents of prefix type
        19.  Display object counts
        20.  Display FTGD TCP stats
        21.  Display FTGD quota list
        22.  Reset all user quotas
        99.  Restart the urlfilter daemon.
        
        Debug levels:
        Warning messages:             1   (0x001)
        Block events:                 2   (0x002)
        Pass events:                  4   (0x004)
        URL request events:           8   (0x008)
        Cache events:                 16  (0x010)
        Prefix events:                32  (0x020)
        Prefix delete subtree events: 64  (0x040)
        Add after prefix events:      128 (0x080)
        CMDB events:                  256 (0x100)
        DNS resolver messages:        512 (0x200)
        Keyword search messages:     1024 (0x400)
        INIT request messages:       2048 (0x800)
        Quota messages:              4096 (0x1000)

Somit kann zB anhand folgenden Befehls der Caches des WebFilters ausgelesen werden:

        # diagnose test application urlfilter 3
        
        Saving to file [/tmp/urcCache.txt]
        
        Cache Contents:
        -=-=-=-=-=-=-=-
        Cache Mode:   TTL
        Cache DB Ver: 17.33301
        
        Domain  |IP       DB Ver T URL
        '''34'''000000|'''34'''000000 17.33299 P Bhttp://www.ecall.ch/
        34000000|34000000 17.33296 P Chttps://apctrl1.fortinet.com/
        34000000|34000000 17.33295 P Chttps://logctrl1.fortinet.com/
        34000000|00000000 17.33292 P Bhttp://ocsp2.globalsign.com/
        34000000|00000000 17.33292 P Bhttp://ocsp.globalsign.com/
        29000000|29000000 17.33282 E Bhttp://yahoo.com/
        29000000|00000000 17.32731 E Dhttps://cse.google.com/

Die Spalte "Domain" sowie "IP" gibt die FortiGuard Kategorie wieder in "hexdecimalen" Wert! Um den Cache Inhalt des WebFilters zu löschen benutze folgende Befehl:

        # diagnose test application urlfilter 2

Eine andere Möglichkeit den Cache des WebFilters zu löschen ist den Deamon/Service des WebFilters neu zu starten:

        # diagnose test application urlfilter 99

Ebenso steht mit nachfolgenden Befehl betreffend WebFilter eine Statistik zur Verfügung:

        # diagnose webfilter fortiguard statistics list
        
        Rating Statistics:
        =====================
        DNS failures                     :          4
        DNS lookups                      :          9
        Data send failures               :          0
        Data read failures               :          0
        Wrong package type               :          0
        Hash table miss                  :          1
        Unknown server                   :          0
        Incorrect CRC                    :          0
        Proxy request failures           :          0
        Request timeout                  :         26
        Total requests                   :      23908
        Requests to FortiGuard servers   :       2535
        Server errored responses         :          0
        Relayed rating                   :          0
        Invalid profile                  :          0
        
        Allowed                          :          0
        Blocked                          :          1
        Logged                           :      23903
        Blocked Errors                   :          0
        Allowed Errors                   :          5
        Monitors                         :      23902
        Authenticates                    :          0
        Warnings:                        :          0
        Ovrd request timeout             :          0
        Ovrd send failures               :          0
        Ovrd read failures               :          0
        Ovrd errored responses           :          0
        
        Cache Statistics:
        =====================
        Maximum memory                   :   42284892
        Memory usage                     :      44832
        
        Nodes                            :          1
          Leaves                         :          0
          Prefix nodes                   :          0
          Exact nodes                    :          0
        
        Requests                         :          1
        Misses                           :          1
        Hits                             :          0
          Prefix hits                    :          0
          Exact hits                     :          0
        
        No cache directives              :          0
        Add after prefix                 :          0
        Invalid DB put                   :          0
        DB updates                       :          2
        
        Percent full                     :          0%
          Branches                       :        100%
          Leaves                         :          0%
            Prefix nodes                 :          0%
            Exact nodes                  :          0%
        
        Miss rate                        :        100%
        Hit rate                         :          0%
          Prefix hits                    :          0%
          Exact hits                     :          0%

Diese Statistik kann mit nachfolgenden Befehl zurück gesetzt werden:

        # diagnose webfilter fortiguard statistics flush

Möchte man den "Embeded Content" für eine Anfrage eines Host/Client im Zusammenhang mit dem WebFilter untersuchen weil zB teile einer Seite geblockt werden, kann dies anhand des Debug Befehls durchgeführt werden.

        1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
        2. Erstelle eine Consolen Verbindung zur FortiGate (RS232 basierend resp. Seriell)
        3. Führe ein Login durch und gebe folgendes ein:

           '''Setze den Debug Filter zurück'''
           
           # diagnose debug reset

           '''Aktiviere für den debug "output" den "timestamp"'''
           
           # diagnose debug console timestamp enable

           '''Setze einen neuen Debug Filter urlfilter'''
           
           # diagnose debug urlfilter src-addr [IPv4 Adressee des Host/Client von dem der Test ausgeführt wird zB "198.18.0.21"]
           # diagnose debug application urlfilter -1

Zusätzlich zu "src-addr" steht ebenfalls "test-url" zur Verfügung dh. durch Angaben einer entsprechenden URL für "test-url" werden die Resultate für FortiGuard Kategorisierung zurückgegeben!

        '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
        
        # diagnose debug enable

Nachfolgend ein Beispiel eines Outputs (Auschnitt) des obigen "debug" Filters anhand Source Adresse 198.18.0.21 sowie auf die Seite "www.also.com":

        --------------- output debug urlfilter src-addr / -1 ---------------
        
        # msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23940, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23941, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/en/6000/index.jsp"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23945, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/css/6000/print.css"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23943, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/css/6000/html5boilerplate/main.css"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23944, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/css/6000/screen.css"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23942, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/css/6000/html5boilerplate/normalize.css"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23947, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/css/6000/dev_also_com.css"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23946, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/css/6000/dev_also_com_2.css"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23951, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/js_1/6000_1/html5boilerplate_1/modernizr-262min.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=fonts.googleapis.com:80, id=23948, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/css?family=PT+Sans+Narrow|Raleway:400,500,600,700,800|Dancing+Script|Sanchez"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23950, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/css/1010_ctv/magnific-popup.css"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23952, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/js/jquery-core/1.11.2/jquery-1.11.2.min.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23953, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/js/jquery-core/2.1.3/jquery-2.1.3.min.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23954, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/js_1/6000_1/jquery/jquerywaypointsmin.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23955, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/js_1/6000_1/jquery/jquerytouchSwipemin.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23956, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/js_1/6000_1/bootstrap/bootstrap.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23957, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/js_1/6000_1/plugins.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23958, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/js_1/6000_1/metronome.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        msg="received a request /tmp/.proxyworker000_0_0.url.socket, addr_len=38: d=www.also.com:80, id=23959, vfname='root', vfid=0, profile='VDOM-root-default', type=0, client=198.18.0.21, url_source=1, url="/ec/cms2/media/js_1/knockout/knockoutmin.js"
        Not running keyword search.  It is not a supported search site site
        Checking urlfilter list 1
        Stop quota EP 198.18.0.21, cat 0
        Url filter exempt action (7f)
        
        --------------- output debug urlfilter src-addr / -1 ---------------

Nachdem der Debug ausgeführt wurde sollte dieser wieder deaktiviert sowie der Filter zurück gesetzt werden:

        '''Deaktiviere den Debug Modus:'''
        
        # diagnose debug disable

        '''Setze den Debug Filter zurück:'''
        
        # diagnose debug reset

        '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
        
        # diagnose debug info

== Traffic Shaper / TOS / DSCP ==

=== Was ist unter FortiOS 5.4 der Unterschied für eine Traffic Shaper Definition zwischen "Shared" und "Per-IP"? ===

Unter FortiOS 5.4 hat sich die Traffic Shaper Konfiguration grundlegend geändert! Was jedoch geblieben ist, ist die Definition eines Traffic Shapers anhand "Shared" und "Per-IP". Nachfolgende eine Visualisierung dieses Unterschieds zwischen diesen zwei Möglichkeiten:

        [[Datei:Fortinet-1421.jpg]]

Beide Varianten werden nicht mehr in der IPv4 Firewall Policy Rule definiert sondern in einer separaten "Traffic Shaping Policy". Somit umfasst die Definition dieser zwei Möglichkeiten die Folgende:

        • Shared        Ein "Shared" Traffic Shaper Konfiguration wird auf sämtlichen Traffic angewendet der durch die IPv4 Firewall Policy 
                        akzeptiert wird. Durch eine entsprechende Konfiguration in der "Traffic Shaper Policy" und Uebereinstimmung mit einer
                        IPv4 "Firewall Policy Rule" wird dieser  Traffic Shaper basierend auf "Shared" auf der entsprechenden IPv4 Firewall
                        Policy Rule angewendet.
         
        • Per-IP        Ein "Per-IP" Traffic Shaper Konfiguration wird anhand der Source IPv4 Adresse auf der bestehenden IPv4 "Firewall Policy
                        Rule" angewendet die über die "Traffic Shaping-Policy" ebenfalls anhand der Source IPv4 Adresse konfiguriert wird und
                        somit übereinstimmt.

Bei einem Traffic Shaper Definition anhand "Shared" ist desweiteren folgendes zu beachten: Per Standard wird ein Traffic Shaper Definition anhand "Shared" potentiell über die ganze IPv4 Firewall Policy gleichmässig angewandt sofern nicht explizit über die "Traffic Shaper Policy" zur IPv4 Firewall Policy eine Uebereinstimmung existiert (matching criterias)! Möchte man eine "Shared" Traffic Shaper Definition potentiell für jede IPv4 Firewal Policy Rule seperate anwenden, muss über CLI folgende Option für die Konfiguration eines Traffic Shapers aktiviert werden:

        # config firewall shaper traffic-shaper
        # edit [Name des Traffic Shapers]
        # set per-policy [enable | disable]
        # end

Aus diesem Grund muss bei der Konfiguration einer Traffic Shaper Policy bei "Shared" darauf geachtet werden, dass eine Uebereinstimmung (matching criterias) mit einer enstprechenden IPv4 Firewall Policy Rule existiert damit die potentiell die Traffic Shaper Konfiguration nicht über die ganze IPv4 Firewall Policy angewendet wird. Weitere Informationen dazu wie unter FortiOS 5.4 ein Traffic Shaper Konfiguration durchgeführt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_wird_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_und_eine_Firewall_Policy_Rule_ein_Traffic_Shaper_Konfiguriert.3F]]

=== Wie wird unter FortiOS 5.4 für ein FortiGate Device und eine Firewall Policy Rule ein Traffic Shaper Konfiguriert? ===

Die Konfiguration eines Traffic Shaper unter FortiOS 5.4 hat sich Grundlegend geändert! Dies bedeutet: In FortiOS 5.0 sowie 5.2 wurde ein Traffic Shaper Konfiguration direkt in der IPv4 Firewall Policy Rule anhand der Traffic Shaper Profile konfiguriert. Diese Konfiguration existiert unter FortiOS 5.4 nicht mehr, sondern die Konfiguration eines Traffic Shapers wird separat in der neuen "Traffic Shaper Policy" konfiguriert. Dabei ist Folgendes wichtig: Die Konfiguration der "Traffic Shaper Policy" muss über eine entsprechende Uebereinstimmung (matching criterias) mit der entsprechenden IPv4 Firewall Policy Rule verfügen für die ein Traffic Shaping durchgeführt werden soll. Dies bedeutet: wenn eine IPv4 Firewall Policy Rule existiert mit der Source "host-local-198.18.0.94-32" und zB "net-local-all-0.0.0.0-00" als Destination sowie Service "SIP", muss die "Traffic Shaper Policy" dementsprechend mit der Source "host-local-198.18.0.94-32" sowie Destination "net-local-all-0.0.0.0-00" sowie "SIP" konfiguriert werden! Dabei ist die Uebereinstimmung (matching criteria) entscheidend dh. existiert in der gesmaten IPv4 Firewall Policy nur eine Rule mit Service "SIP", reicht es in der "Traffic Shaper Policy" als Service "SIP" zu definieren da somit eine Uebereintstimmung mit der entsprechenden IPv4 Firewall Policy Rule durchgeführt werden kann. Um eine "Traffic Shaper Policy" zu Konfigurieren muss in erster Stelle eine "Traffic Shaper" Konfiguration erstellt werden. Diese kann Grundsätzlich im folgender Definition erstellt werden:

        • Shared 
        • Per-IP

Weitere Informationen betreffend dieser zwei Definitionen siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_der_Unterschied_f.C3.BCr_eine_Traffic_Shaper_Definition_zwischen_.22Shared.22_und_.22Per-IP.22.3F]]

Desweiteren wird ein "Traffic Shaper" für folgende Queus Konfiguriert:

        • Traffic Priority [High | Medium | Low]
        • Maximum Bandwidth
        • Guaranteed Bandwidth

Im Gesamten existieren 6 Queus pro Interface dh. 0-5. Weitere Informationen zu diesen 6 Queus siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Was_wird_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_durchgef.C3.BChrt_wenn_kein_Traffic_Shaper_konfiguriert_wurde.3F]]

Somit kann für verschiedener Traffic/Service für ein entsprechende IPv4 Firewall Policy Rule resp. "Traffic Shaper Policy" verschiedenen Prioritäten anhand High, Medium und Low vergeben werden. Bei der maximalen Bandbreite und garantierten Bandbreite können verschiedenen Werte benutzt werden wobei zu berücksichtigen ist, dass für die verschiedenen garantierten Bandbreiten nicht mehr als die maximal zur Verfügung stehende Bandbreite definiert werden darf ansonsten eine Ueberbuchung stattfindet. Zusätzlich zu dieser Traffic Shaper Konfiguration, können die entsprechenden Interfaces mit der zur Verfügung stehender "inbandwith/outbandwith" konfiguriert werden. Dies ist jedoch nur in Ausnahmefällen durchzuführen und ist für eine Traffic Shaper Policy/Funktion kein technische Voraussetzung. Die Interface "inbandwith/outbandwith" wird folgendermassen konfiguriert:

        # config system interface
        # edit [Name des Interface zB "wan1"]
        # set inbandwidth [Definiton in "Kbit/sec" zB 1 Mbit "1024"; Standard 0 dh. "unlimited"; Möglicher Wert in Kbit/sec "0-16776000"]
        # set outbandwidth [Definiton in "Kbit/sec" zB 1 Mbit "1024"; Standard 0 dh. "unlimited"; Möglicher Wert in Kbit/sec "0-16776000"]]
        # end

Desweiteren ist folgendes zu beachten beim Einsatz eines FortiGate Devices der über einen NP6 Prozessor verfügt: Ein NP6 Prozessor führt innerhalb eines Traffic Shapings ein "offloading" durch wie für jeden anderen Traffic mit der Ausnahme des "inbandwidth". Dies bedeutet: Die Limite für "set inbandwidth" für ein Interface im Zusammenhang mit einem Traffic Shaping hat keinen Effekt auf "inbandwidth" resp. eingehender Traffic für das Interface. Ausgehender Traffic resp. "set outbandwith" Limit wird über den NP6 Prozessor voll unterstützt! Ein Traffic Shaper Konfiguration betreffend maximaler und garantierter Bandbreite wird anhand Kb/s definiert. Die Definition für maximale sowie garantierter Bandbreitet ist die Folgende:

        rate (kilobits per second; Kb/s) = amount / time

Nachfolgend eine Tabelle die helfen soll die richtigen Werte für Kb/s zu verwenden:

        [[Datei:Fortinet-181.jpg]]

Um eine Traffic Shaper zu definieren kann das Mgmt. Web Interface oder CLI benutzt werden. Im nachfolgenden Beispiel wird gezeigt wie für Eingehend sowie Ausgehend für VoIP ein Traffic Shaper Konfiguration durchgeführt wird. Ausgangslage dabei ist die entsprechende ISP Bandbreite die zu Grunde liegt. Für dieses Beispiel gehen wir von einem Bandbreite von 30 Mbit Download und 5 Mbit Upload aus. Ueber Mgmt. Web Interface wird die Konfiguration folgendermassen durchgeführt:

        Policy & Objects > Traffic Shapers > Create New

        [[Datei:Fortinet-2120.jpg]]

        [[Datei:Fortinet-2121.jpg]]

        [[Datei:Fortinet-2122.jpg]]

Bevor nun eine entsprechende "Traffic Shaper Policy" Konfiguriert wird, muss überprüft werden ob eine entsprechende IPv4 Firewall Policy Rule existiert für den eingehenden sowie ausgehenden Traffic. Wie schon erwähnt muss die "Traffic Shaper Policy" so konfiguriert werden damit ein Uebereinstimmung (matching criteria) erreicht wird damit die "Traffic Shaper Policy" auf der/den entsprechende Firewall Policy Rules angewendet werden. In unserem Beispiel existiert für eingehenden und ausgehenden Traffic folgende IPv4 Firewall Policy Rules für VoIP:

        [[Datei:Fortinet-2123.jpg]]
        [[Datei:Fortinet-2124.jpg]]

Nun kann dementsprechend eine "Traffic Shaper Policy" für eingehenden und ausgehenden Traffic über Mgmt. Web Interface über folgende Position konfiguriert werden:

        Policy & Objects > Traffic Shaping Policy > Create New

        [[Datei:Fortinet-2125.jpg]]

        '''Eingehende Verbindung'''
        
        [[Datei:Fortinet-2126.jpg]]

        '''Ausgehende Verbindung'''
        
        [[Datei:Fortinet-2127.jpg]]

Wie hier in diesem Beispiel gezeigt wird eine Uebereinstimmung für Eingehend und Ausgehend erreicht durch die Definition des VoIP Servers/Controllers anhand des Objekts "host-local-198.18.0.94-32" der sich im Segment des Interfaces "internal1" befindet sowie zusätzlich anhand des Service "SIP". Die Destination in diesem Beispiel ist definiert anhand des Objekts "net-local-all-0.0.0.0-00" das die IPv4 Adresse des VoIP Providers darstellt. Somit korrespondiert die "Traffic Shaper Policy" mit der entsprechenden IPv4 Firewall Policy Rule für VoIP in mehreren Belangen. Um ein "Traffic Shaper Policy" zu kontrollieren benötigt es in erster Linie entsprechenden Traffic damit das FortiOS ein Shaping durchführen kann. Aus diesem Grund sollte erst nach einigen Minuten eine Kontrolle durchgeführt werden für eine entsprechende "Traffic Shaper Policy". Eine Kontrolle kann über folgende Position durchgeführt werden:

        FortiView > Traffic Shaping

In der "Traffic Shaper Policy" kann anhand der Positionen "Application Category" eine Applikations Basierendes Traffic Shaping durchgeführt werden. Grundvoraussetzund dafür ist jedoch das in den entsprechenden IPv4 Firewall Policy Rule die Funktion "Application Control" aktiviert wurde und ein entsprechendes "Application Control" Profile konfiguriert wurde. Dabei muss das Profile so konfigurirt sein damit dieses die Applikationen überwacht dh. erkannt werden kann. Wenn diese Grundvoraussetzung gegeben ist, kann in der "Traffic Shaper Policy" Applikationsbasierend ein Traffic Shaping durchgeführt werden. Nachfolgend basierend auf unserem Beispiel die Konfiguration:

        '''Eingehende Verbindung'''
        
        [[Datei:Fortinet-2128.jpg]]

        '''Ausgehende Verbindung'''
        
        [[Datei:Fortinet-2129.jpg]]

Zusätzlich kann in einer "Traffic Shaper Policy" die Position "URL Category" benutzt werden. Anhand dieser lassen sich die üblichen WebFilter Kategorien konfigurieren, die für ein Traffic Shaping herangezogen werden. Dies wird jedoch nur dann durchgeführt, wenn in der entsprechenden IPv4 Firewall Policy Rule kein WebFilter Funktion aktiviert ist und das URL Rating dazu = 0 ist. Um ein Troubleshooting durchzuführen für einen Traffic Shaper siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_und_ein_Traffic_Shaper_Konfiguration_ein_Debug_durchf.C3.BChren.3F]]

Wenn die hier gezeigte Konfiguration auf CLI durchgeführt werden soll kann folgendes durchgeführt werden:

        # config firewall shaper traffic-shaper
        # edit [Name des Traffic Shapers zB "shaping-outgoing-voip"]
        # set diffserv [enable | disable]
        # set diffservcode [Sofern "diffserv enable" definiere einen 6 Stellingen Binären DSCP Service Code]
        # set priority [high | medium | low]
        # set guaranteed-bandwidth [Setze die entsprechende Bandbreite in Kb/s 0 - 16776000 zB "128"]
        # set maximum-bandwidth [Setze die entsprechende Bandbreite in Kb/s 0 - 16776000 zB "3840"]
        # set per-policy [enable | disable]
        # set diffserv [enable | disable]
        # end

        # config firewall shaper traffic-shaper
        # edit [Name des Traffic Shapers zB "shaping-incoming-voip"]
        # set diffserv [enable | disable]
        # set diffservcode [Sofern "diffserv enable" definiere einen 6 Stellingen Binären DSCP Service Code]
        # set priority [high | medium | low]
        # set guaranteed-bandwidth [Setze die entsprechende Bandbreite in Kb/s 0 - 16776000 zB "128"]
        # set maximum-bandwidth [Setze die entsprechende Bandbreite in Kb/s 0 - 16776000 zB "640"]
        # set per-policy [enable | disable]
        # set diffserv [enable | disable] 
        # end

        # config firewall shaping-policy
        # edit [Vergebe einen entsprechenden Integer zB "1"]
        # set status [enable | disable] 
        # set ip-version [Setze die IP Version zB "4"]
        # set service [Konfiguriere ein entsprechendes Service Objekt zB "SIP"]
        # set users [Konfiguriere ein entsprechende Usernamen]
        # set users [Konfiguriere einen entsprechenden Gruppen Name]             :
        # set application [Definiere eine entsprechende Applikation dh zB VoIP "34640"]
        # set app-category [Definiere eine entsprechende Applikations Kategorie dh. zB SIP "3"]
        # set url-category [Definiere eine entsprechende WebFilter Kategorie]
        # set dstintf [Definiere ein Destination Interface zB "internal1"]
        # set traffic-shaper [Definiere einen Traffic Shaper zB "shaping-incoming-voip"]
        # set traffic-shaper-reverse [Definiere einen Traffic Shaper für Reverse zB "shaping-incoming-voip"]
        # set per-ip-shaper [Definiere die entsprechende Per-IP Traffic Shaper Konfiguration]
        # set srcaddr [Definiere ein entsprechendes Source Object zB "net-local-all-0.0.0.0-00"]
        # set dstaddr [Definiere ein entsprechendes Destination Object zB "host-local-198.18.0.94-32"]
        # end

        # config firewall shaping-policy
        # edit [Vergebe einen entsprechenden Integer zB "2"]
        # set status [enable | disable] 
        # set ip-version [Setze die IP Version zB "4"]
        # set service [Konfiguriere ein entsprechendes Service Objekt zB "SIP"]
        # set users [Konfiguriere ein entsprechende Usernamen]
        # set users [Konfiguriere einen entsprechenden Gruppen Name]             :
        # set application [Definiere eine entsprechende Applikation dh zB VoIP "34640"]
        # set app-category [Definiere eine entsprechende Applikations Kategorie dh. zB SIP "3"]
        # set url-category [Definiere eine entsprechende WebFilter Kategorie]
        # set dstintf [Definiere ein Destination Interface zB "wan1"]
        # set traffic-shaper [Definiere einen Traffic Shaper zB "shaping-outgoing-voip"]
        # set traffic-shaper-reverse [Definiere einen Traffic Shaper für Reverse zB "shaping-outgoing-voip"]
        # set per-ip-shaper [Definiere die entsprechende Per-IP Traffic Shaper Konfiguration]
        # set srcaddr [Definiere ein entsprechendes Source Object zB "host-local-198.18.0.94-32"
        # set dstaddr [Definiere ein entsprechendes Destination Object zB "net-local-all-0.0.0.0-00"
        # end

Für eine Per-IP Shaper Traffic Konfiguration stehen folgende Kommandos zur Verfügung:

        # config firewall shaper per-ip-shaper
        # edit [Name des Traffic Shapers]
        # set diffserv-forward [enable | disable]
        # set diffserv-reverse [enable | disable]
        # set diffservcode-forward [Sofern "diffserv-forward enable" definiere einen 6 Stellingen Binären DSCP Service Code]
        # set diffservcode-rev [Sofern "diffserv-rev enable" definiere einen 6 Stellingen Binären DSCP Service Code]
        # set maximum-bandwidth [Setze die entsprechende Bandbreite in Kb/s 0 - 16776000]
        # set max-concurrent-session [Maximal erlaubte Sessions pro IP Adresse 0 - 2097000; 0 = no sessions]
        # end

=== Was wird unter FortiOS 5.4 für ein FortiGate Device durchgeführt wenn kein Traffic Shaper konfiguriert wurde? ===

Ein FortiOS 5.4 führt sofern kein Traffic Shaper konfiguriert ist keine Limitierung oder Garantierung der Bandbreite durch. Somit benützt eine Session unter FortiOS 5.4 ohne konfigurierten Traffic Shaper die "Queue Priorisierung" um einzelne Packete zu verarbeiten. Diese "Queue Priorisierung" benützt in den IP Packeten die ToS/DSCP bit Informationen und Priorisiert diese in der Queue gemäss konfigurierten ToS/DSCP Priorisierung High, Medium und Low. Ist in den IP Packeten keine ToS Information vorhanden gilt 0 und es wird somit keine Priorisierung in der Queue durchgeführt. Somit gilt:

        packet priority = ToS/DSCP-based priority

Wenn somit ein "Traffic Shaper" Konfiguriert wird anhand der Konfigurationspunkte "Traffic Priority", "Maximum Bandwith" sowie "Guaranteed Bandwith" werden nicht 3 Queues verarbeitet sondern effektiv 6 (0 - 5). Dies bedeutet wiederum:

        packet priority = ToS/DSCP-based priority + security policy-based priority (Traffic Shaper)

Konkret bedeutet dies für die 6 Queus folgendes:

        • Administrative Access benützt immer die Queue 0.
          
        • Traffic für eine IPv4 Firewall Policy ohne Traffic Shaper kann Queue 0, 1 oder 2 benützen. Welche Queue benutzt
          wird hängt ab von den IP Packet Informationen ob diese ToS/DSCP Informationen enthalten und ob die entsprechenden
          Prioritäten High, Medium sowie Low mit den entsprechenden Werten konfiguriert wurden!
          
        • Traffic für eine IPv4 Firewall Policy für die ein Traffic Shaper konfiguriert wurde kann alle Queues benutzen. 
          Welche Queues benutzt werden hängt davon ab ob das IP Packet im Zeitpunkt der Uebermittlung unter der garantierten
          Bandbreite liegt (Queue 0) oder über dieser garantierten Bandbreite. Packete mit Werten über der maximalen Bandbreite
          werden verworfen!
         
        • Wenn die globale "tos/dscp-based-priority" Low (3) ist und die "Traffic Priority" für einen Traffic Shaper auf Medium (2),
          wird ein IP Packet für eine entsprechende Firewall Policy für die dieser Traffic Shaper definiert wurde mit der 
          Priorität Medium verarbeitet (2)! 

Um die globale ToS/DSCP Konfiguration durchzuführen kann folgendes über CLI durchgeführt werden:

        # config system global
        # set traffic-priority [tos | dscp ; Standard "tos"]
        # set tos-based-priority [high | low | medium ; Standard "medium"]
        # end

        # config system tos-based-priority
        # edit [Gebe einen entsprechenden Integer ein zB "1"]
        # set priority [Definiere die entsprechende Priorität für Integer "1" dh high | medium | low]
        # set tos [Definiere die Priorität 0-15 für die Definierte "priority"]
        # next
        # end

        # config system dscp-based-priority
        # edit [Gebe einen entsprechenden Integer ein zB "1"]
        # set priority [Definiere die entsprechende Priorität für Integer "1" dh high | medium | low]
        # set ds [Definiere die Priorität 0-64 für die Definierte "priority"]
        # next
        # end

Um ein Troubleshooting für ToS/DSCP durchzuführen siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_und_ein_Traffic_Shaper_Konfiguration_ein_Debug_durchf.C3.BChren.3F]]

=== Kann ich unter FortiOS 5.4 auf einem FortiGate Device den IP Packeten DSCP Informationen hinzufügen? ===

In verschiedenen Situationen werden den IP Packeten in einem internen Netzwerk ToS/DSCP Informationen hinzugefügt um zB anhand diesen ToS/DSCP Informationen einem bestimmten Traffic wie zB VoIP eine bestimmte Bandbreite resp. Priorität zu verleien. Solche Markierungen werden unter normalen Umständen über einen Core Switch durchgeführt. Wenn jedoch eine Markierung über eine Switch nicht möglich ist und die Markierung der IP Packete Grundvoraussetzung ist damit diese im Backbone Bereich des ISP's Priorisiert werden, kann dieser Vorgang ebenfalls über das FortiOS durchgeführt werden. ToS wird in RFC 791 definiert und erweitert durch RFC 1349. DSCP ist die Ablösung von ToS und wird im RFC 2474 definiert. Nachfolgende Link geben Auskunft über ToS und DSCP:

        http://bogpeople.com/networking/dscp.shtml
        http://en.wikipedia.org/wiki/Differentiated_Services_Code_Point#Classification_and_marking

Grundvoraussetzung um IP Packete zu markieren sind die entsprechenden Informationen zB des Providers/Service wie ein IP Packet markiert werden soll. Wenn nun ein Provider zB "AF41" verlangt wäre dies "Precedence 4" was wiederum "Class Selector 4" entspricht. Nachfolgend eine Tabelle für DSCP betreffend dieser Informationen:

        [[Datei:Fortinet-324.jpg]]

Gemäss dieser DSCP Tabelle bedeutet dies wiederum für unser Beispiel "AF41" Folgendes:

        Class Selector 4 = 100xxx 
        AF41             = xxx010
        
        Ergiebt          = '''100010''' (oder Dezimal 34)

Anhand dieser Informationen kann nun ein entsprechender Traffic Shaper konfiguriert werden damit dieser in der entsprechenden Traffic Shaper Policy benutzt wird um den entsprechenden Traffic mit DSCP Informationen zu markieren:

        Policy & Objects > Traffic Shapers > Create New

        [[Datei:Fortinet-2130.jpg]]

Möchte man die Konfiguration über Kommandozeile durchführen so benütze folgende Kommandos:

        # config firewall shaper traffic-shaper
        # edit [Name für das Profile zB "Citrix-CS4-AF41"]
        # set priority high
        # set diffserv [enable | disable]
        # set diffservcode [Setze den entsprechenden DSCP Code zB "100010"]
        # end

Danach muss der neu konfigurierte "Traffic Shaper" in einer "Traffic Shaper Policy" definiert werden. Dabei ist zu beachten das die Traffic Shaper Policy so definiert wird, dass diese mit der entsprechenden IPv4 Firewall Policy Rule korrespondiert dh. über eine entsprechende Uebereinstimmung verfügt (matching criteria). Als Beispiel möchten wir ausgehender VoIP Traffic markieren und es existieren folgende IPv4 Firewall Policies:

        [[Datei:Fortinet-2123.jpg]]
        [[Datei:Fortinet-2124.jpg]]

Somit ergiebt sich folgende Traffic Shaper Policy die über eine entsprechende Uebereinstimmung verfügt (matching criteria):

        Policy & Objects > Traffic Shaping Policy > Create New

        [[Datei:Fortinet-2131.jpg]]

Durch diese Konfiguration werden nun IP Packete für die entsprechende IPv4 Firewall Policy durch den Traffic Shaper der über die entsprechende Traffic Shaper Policy eingebunden wurde und mit der IPv4 Firewall Policy Uebereinstimmt (matching criteria) markiert!

=== Kann ich unter FortiOS 5.4 auf einem FortiGate Device DSCP Informationen für ein Shaping benutzen? ===

DSCP Informationen in verschiedener Klassen und Bandbreiten können auf einem FortiOS nicht benutzt werden um ein Shaping auf dem FortiOS durchzuführen. IP Packete können mit den entsprechenden DSCP Informationen versehen resp. markiert werden. Dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Kann_ich_unter_FortiOS_5.4_auf_einem_FortiGate_Device_den_IP_Packeten_DSCP_Informationen_hinzuf.C3.BCgen.3F]]

DSCP sowie ToS Prioritäten können auf einem FortiOS Device dazu benützt werden eine Priorisierung durchzuführen dh. High, Medium sowie Low. Dazu siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Was_wird_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_durchgef.C3.BChrt_wenn_kein_Traffic_Shaper_konfiguriert_wurde.3F]]

Desweiteren kann auf einem FortiOS DSCP Werte über eine IPv4 Firewall Policy verändert werden! Dazu muss in der entsprechenden IPv4 Firewall Policy Rule die "DiffServer" aktiviert werden für eingehender sowie ausgehender Traffic sowie einen entsprechenden "DiffServerCode" (DSCP oder ToS). Diese Konfiguration ist nur über Kommandozeile möglich und wird folgendermassen durchgeführt:

        # config firewall policy
        # edit [Gebe die entsprechende Policy-ID an]
        # diffserv-forward [enable | disable]
        # diffservercode-forward [Definiere einen entsprechenden 6 stelligen Binären Code für DSCP]
        # diffserv-reverse [enable | disable]
        # diffservcode-rev [Definiere einen entsprechenden 6 stelligen Binären Code für DSCP]
        # end

Für diese Konfiguration kann ebenfalls eine ToS Definition als "DiffServerCode" benutzt werden. Nachfolgend eine Tabelle die ein Mapping zeigt zwischen DSCP sowie ToS:

        [[Datei:Fortinet-2132.jpg]]

Bei der Konfiguration ist zu berücksichtigen, dass auf der entsprechende IPv4 Firewall Policy kein UTM Profile benutzt werden kann da in so einem Fall der DSCP Wert = 00 ist. Weitere Informationen zu dieser IPv4 Firewall Policy im Zusammenhang mit DSCP siehe nachfolgender Artikel:

        http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=13587&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=38530996&stateId=0%200%2038532675

=== Wie kann ich unter FortiOS 5.4 für ein FortiGate Device und ein Traffic Shaper Konfiguration ein Debug durchführen? ===

Ausgangslage um ein Traffic Shaping zu überprüfen ist festzustellen ob auf den entsprechenden Interfaces "errors" oder "collisions" exisiteren. Weitere Informationen wie dies durchgeführt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_kontrollieren_ob_irgendwelche_.22errors.22_auf_einem_Interface_existieren.3F]]

Um die einzelnen Traffic Shaper über CLI sei es "Per-IP" und/oder "Shared" aufzulisten benütze folgendes Kommando:

        # get firewall shaper traffic-shaper
        == [ shaping-outgoing-voip ]
        name: shaping-outgoing-voip   
        == [ shaping-incoming-voip ]
        name: shaping-incoming-voip 

        # get firewall shaper per-ip

Danach stehen unter CLI verschiedenen Kommandos zur Verfügung um den Traffic Shaper Vorgang zu verifizieren. Wenn zB die ToS/DSCP Priority benutzt wird kann folgendes ausgeführt werden:

        # diagnose sys traffic-priority list
        Traffic priority type is set to TOS.
        00:medium 01:medium 02:medium 03:medium 04:medium 05:medium 06:medium 07:medium 
        08:medium 09:medium 10:medium 11:medium 12:medium 13:medium 14:medium 15:medium 

        # diagnose sys traffic-priority list
        Traffic priority type is set to DSCP (DiffServ).
        00:medium 01:medium 02:medium 03:medium 04:medium 05:medium 06:medium 07:medium 
        08:medium 09:medium 10:medium 11:medium 12:medium 13:medium 14:medium 15:medium 
        16:medium 17:medium 18:medium 19:medium 20:medium 21:medium 22:medium 23:medium 
        24:medium 25:medium 26:medium 27:medium 28:medium 29:medium 30:medium 31:medium 
        32:medium 33:medium 34:medium 35:medium 36:medium 37:medium 38:medium 39:medium 
        40:medium 41:medium 42:medium 43:medium 44:medium 45:medium 46:medium 47:medium 
        48:medium 49:medium 50:medium 51:medium 52:medium 53:medium 54:medium 55:medium 
        56:medium 57:medium 58:medium 59:medium 60:medium 61:medium 62:medium 63:medium 

Weitere Informationen betreffend ToS/DSCP Priority Konfiguration siehe auch nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Was_wird_unter_FortiOS_5.4_f.C3.BCr_ein_FortiGate_Device_durchgef.C3.BChrt_wenn_kein_Traffic_Shaper_konfiguriert_wurde.3F]]

Der nachfolgende Befehl listet ein konfigurierter "Shared" Shaper Traffic auf mit dessen Werte:

        # diagnose firewall shaper traffic-shaper list
        
        name shaping-incoming-voip
        maximum-bandwidth 80 KB/sec
        guaranteed-bandwidth 16 KB/sec
        current-bandwidth 0 B/sec
        priority 2
        tos ff 
        packets dropped 0
        bytes dropped 0

        name shaping-outgoing-voip
        maximum-bandwidth 480 KB/sec
        guaranteed-bandwidth 16 KB/sec
        current-bandwidth 0 B/sec
        priority 2
        tos ff 
        packets dropped 0
        bytes dropped 0

        # diagnose firewall shaper per-ip-shaper list

Um eine komplett Uebersicht für die "Shared" Traffic Shaper zu erhalten benütze folgendes Kommando:

        # diagnose firewall shaper traffic-shaper state
        shapers 2

        # diagnose firewall shaper traffic-shaper stats
        shapers 2 ipv4 0 ipv6 0 drops 0 dropped bytes 0

Die nachfolgenden Kommandos listen ein konfigurierter "Per-IP" Shaper Traffic auf mit dessen Werte:

        # diagnose firewall shaper per-ip-shaper list

        # diagnose firewall shaper per-ip-shaper stats
        memory allocated 0 packet dropped: 0

        # diagnose firewall shaper per-ip-shaper state
        memory allocated 0

        # diagnose firewall shaper per-ip-shaper clear

Ueber das Kommando "flow" kann überprüft werden ob das Limit eines Traffic Shaper erreicht wurde und somit Packete verworfen werden:

        # diagnose debug flow show console enable
        # diagnose debug flow filter addr [Entsprechende IPv4 Adresse für das Filtering zB "10.143.0.5"]
        # diagnose debug flow trace start [Anzahl der Packete die aufgezeichnet werden sollen zB "1000"]

Danach werden die Anzahl Packete die definiert wurden aufgezeichnet und im Output wird für das erreichen der Limite des Traffic Shapers folgendes ausgegeben:

        id=20085 trace_id=11 msg="vd-root received a packet(proto=17, 10.141.0.11:3735->10.143.0.5:5001) from port5."
        id=20085 trace_id=11 msg="Find an existing session, id-0000eabc, original direction"
        id=20085 trace_id=11 msg="exceeded shaper limit, drop"

Wenn ein Traffic Shaper für inbandwith/outbandwith mit verschiedenen Werten resp. Bandbreiten definiert wurden so wird dies innerhalb der "session" Liste ausgegeben:

        # diagnose sys session list
        origin-shaper=Limit_25Mbps prio=1 guarantee 25600/sec max 204800/sec traffic 48/sec
        reply-shaper=Limit_100Mbps prio=1 guarantee 102400/sec max 204800/sec traffic 0/sec

Weitere Informationen dazu wie "session" aufgelistet, gefiltert sowie was die einzelnen Informationen bedeuten siehe auch nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Welche_Informationen_werden_f.C3.BCr_eine_einzelne_Session_unter_FortiOS_5.4_in_der_.22Session.22_Liste_aufgef.C3.BChrt_und_was_bedeuten_diese.3F]]

== SIP / VoIP ==

=== Was ist unter FortiOS 5.4 als "SIP ALG" zu verstehen und soll ich diese Funktion benutzen? ===

In den meisten Fällen sollte anstelle des "SIP Session Helpers" der "SIP ALG" (SIP Application Layer Gateway) benutzt werden. Der "SIP Session Helper" ist eine frühere Implementierung betreffend SIP Support (Standard bis FortiOS 5.0). Der "SIP ALG" (Standard ab FortiOS 5.2) unterstützt die gleichen Funktionen wie im "SIP Session Helper" jedoch zusätzlich wird das SIP Protokoll im "SIP ALG" geschützt vor Angriffen im SIP Bereich. Dies bedeutet zB Sessions werden limitiert, Syntax betreffend SIP sowie SDP Inhalte der Nachrichten werden überprüft usw. Zusätzlich wird über den "SIP ALG" ein detailiertes Logging sowie Reporting zur Verfügung gestellt. Nachfolgende Darstellung zeigt wie der "SIP ALG" om seinem Grundkonstrukt implementiert ist:

        [[Datei:Fortinet-715.jpg]]

Der SIP ALG unterstützt folgende Funktionen:

        • Alle Features implementiert im "Session Helper" sowie NAT, SIP und RTP Pinholes (Real Time Protocoll Pinholes)
        • Zusätzlich im Gegensatz zum Session Helper kann auf dem SIP ALG folgendes durchgeführt werden:
        • SIP TCP und UDP Support
        • SIP Message Order Ueberprüfung
        • Konfigurierbare Header Line Length Maximum 
        • Message Fragment Assembly (TCP) 
        • Wenn SIP Nachrichten Fragmentiert sind (vers. Packete) fügt der SIP ALG diese wieder zusammen und schickt diese als Ganzes weiter.
        • L4 Protocol Translation 
        • Message Flood Protection 
        • DoS Protection für "flooding INVITE, REGISTER" und andere Methoden
        • SIP message Type Filtering 
        • SIP Statistik und Logging 
        • SIP über IPv6
        • SIP über SSL/TLS
        • Deep SIP Message Syntax Checking (SIP Header Inspection oder SIP Fuzzing Protection
        • Hosted NAT Traversal 
        • SIP High Availability (HA). 
        • Geographical Redundancy (HA)
        • SIP Per Request Method Message Rate Limitation (Schützt SIP Server vor SIP Ueberlastung und DoS Attacken)
        • RTP Bypass (RTP Pinholing)
        • SIP NAT
        • IP Topology Hiding

Diese Aufstellung zeigt das hinter "SIP" (VoIP) mehr steckt als man glaubt und aus diesem Grund komplizierter als eine normale TCP/UDP-basierte Anwendung ist. Aufgrund der Komplexität der Signalisierung und der Protokolle bei "SIP" sowie der Inkonsistenzen die sich ergeben, wenn eine Firewall die Source-Adresse und Source-Port Daten mit NAT ändert, ist es schwierig für "SIP" eine Firewall ungehindert zu überwinden. "SIP" (VoIP) verwendet zwei verschiedene Protokolle: eines für die Signalisierung (zwischen dem Client und dem SIP/VoIP-Server) und eines für die Medien (zwischen den Clients). Die Port/IP-Adresspaare, die von den Medienprotokollen (RTP/RTCP) für jede Sitzung verwendet werden, werden von den Signalisierungsprotokollen dynamisch verhandelt. Firewalls müssen diese Informationen dynamisch mitverfolgen und warten und zum entsprechenden Zeitpunkt ausgewählte Ports für die Sitzungen auf sichere Weise öffnen und wieder schließen. Mehrere Medienports werden über die Signalisierungssitzung dynamisch verhandelt; die Verhandlungen über die Medienports sind in der Nutzlast der Signalisierungsprotokolle enthalten (IP-Adress- und Port-Informationen). Firewalls müssen für jedes Packet eine "Deep Inspection" durchführen, um diese Informationen zu erhalten und die Sitzungen dynamisch zu warten; dies erfordert zusätzliche Verarbeitungskapazitäten der Firewall. Die Source- und Destination-IP-Adressen sind in die SIP/VoIP-Signalisierungspackete eingebettet. Eine Firewall mit NAT-Unterstützung übersetzt IP-Adressen und -Ports auf IP-Header-Ebene für Packete. Vollsymmetrische NAT-Firewalls passen ihre NAT-Bindungen häufig neu an und können so zufällig die "Pinholes" schließen, über die eingehende Packete in das zu schützende Netzwerk gelangen. In diesem Fall kann der Dienstanbieter keine eingehenden Anrufe an den Kunden weiterleiten. Für die erfolgreiche Unterstützung von "SIP" muss eine NAT-Firewall eine "Deep Packet Inspection" durchführen und eingebettete IP-Adress- und Portinformationen bei der Weiterleitung über die Firewall transformieren können. Genau hier setzt der "SIP ALG" an und übernimmt diese Arbeit in verschiedenen Bereichen dh. Analysiert SIP und SDP Informationen, passt die Packete an (zB für NAT), schützt das Protokoll auf DoS sowie IPS Ebene usw. Bei einigen SIP Implementierungen die von Hersteller zu Hersteller verschieden sein können kann es zu Problemen kommen dh. zB weil über SIP Befehle gesendet werden die durch den "SIP ALG" nicht erkannt werden. Diese Befehle - da nicht erkannt - werden als "unknown" eingestuft sowie geblockt. Um zB dies zu verhindern kann diese spezifische Funktion zu Erkennung der Befehle resp SIP Funktion deaktiviert werden damit "unknown" nicht geblockt werden. Wie hier aufgezeigt ist "SIP" resp. "VoIP" eine komplexe Materie und es existieren etliche verschiedenen Provider mit eigenen Implementierungen usw. Security Technisch gesehen ist/wäre es Sinnvoll den "SIP ALG" anhand eines "VoIP Profiles" zu benutzen jedoch höchst Anspruchsvoll und Komplex. Aus diesem Grund empfehlen wir die Funktion des "SIP Session Helpers" auf einer FortiGate in normalen Umgebungen zu löschen/deaktivieren und die Funktion des "SIP ALG" nicht zu benutzen. Wie der "SIP Session Helper" zu löschen/deaktiveren ist und "SIP ALG" nicht benutzt wird siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_zu_beachten_wenn_SIP_.28VoIP.29_.C3.BCber_eine_Fortigate_implementiert_wird.3F]]

Nichts desto trotz nachfolgend einige Hinweise auf was geachtet werden muss wenn zwar der "SIP Session Helper" gelöscht wird jedoch dennoch der "SIP ALG" anhand eines "VoIP Profiles" benutzt wird:

        '''Deaktiviere "unknown" SIP Befehle'''
        
        # config voip profile
        # edit [Name des VoIP Profiles]
        # config sip 
        # set block-unknown disable
        # end

        '''Deaktiviere NAT Funktion innerhalb SIP'''
        
        # config voip profile
        # edit [Name des VoIP Profiles]
        # config sip 
        # set nat-trace disable
        # end

        '''Aktiviere NAT Register Funktion innerhalb SIP'''
        
        # config voip profile
        # edit [Name des VoIP Profiles]
        # config sip 
        # set register-contact-trace enable
        # end

Für eine Implementierung stellt Fortinet ein spezielles Dokument zur Verfügung das auf die SIP (VoIP) Problematik eingeht:

        [[Datei:Fortigate-sip-54.pdf]]

=== Was ist unter FortiOS 5.4 zu beachten wenn SIP (VoIP) über eine Fortigate implementiert wird? ===

Wenn SIP resp. VoIP über eine FortiGate unter FortiOS 5.4 implementiert/konfiguriert wird ist folgendes Wichtig: Auf einem FortiOS 5.4 gibt es zwei Funktionen die den SIP Traffic manipulieren. Diese sind:

        Session Helper
        ALG (Application Layer Gateway)

Diese zwei Funktionen werden gesteuert über eine globale Einstellung/Konfiguration und zwar:

        # config system settings
        # set default-voip-alg-mode [proxy-based | kernel-helper-based]
        # end
        
        '''NOTE''' Die Optionen "proxy-based" und/oder "kernel-helper-based" haben folgende Bedeutung:
            
             proxy-based          = Default VoIP ALG is "proxy-based" (SIP ALG läuft im User Space)
             kernel-helper-based  = Default VoIP ALG is "kernel-helper-based" (SIP Helper läuft im Kernel Mode)
             
             Somit wird durch folgende Konfiguration entweder der "ALG" oder der "Session Helper" als Standard
             aktiviert:
             
             proxy-based          = ALG
             kernel-helper-based  = Session Helper

Somit um den "ALG" als Standard zu deaktivieren und den "Seesion Helper" ebenfalls zu deaktivieren führe folgendes aus:

        '''Setze als Standard "Session Helper"'''
        
        # config system settings
        # set default-voip-alg-mode kernel-helper-based
        # end

        '''Lösche den Session Helper'''
        
        # show system session-helper
        
        Suche im "output" folgenden Eintrag dh. dieser identifiziert den "Integer" (12) für "sip":
        
        edit 12
        set name sip
        set port 5060
        set protocol 17
        next
        
        Lösche diesen "Integer" dh. in unserem Beispiel wäre dies:
        
        # config system session-helper
        # delete [Gebe den entsprechenden "Integer" an für unser Beispiel "12"]
        # end

        '''Deaktiviere Global "sip" Funktionen'''
        
        # config system settings
        # set sip-helper disable
        # set sip-nat-trace disable
        # end
        
        '''Führe einen Neustart aus'''
        
        Damit die Konfiguration aktiviert wird "muss" ein Neustart des Devices durchgeführt werden:
        
        # execute reboot

Danach wird SIP resp. VoIP nicht mehr durch die FortiGate speziell durch den "ALG" oder "Session Helper" verarbeitet da der "Session Helper" nicht mehr existiert und der "ALG" nur dann benützt wird, wenn auf einer Firewall Policy ein "VoIP Profile" konfiguriert wird. Aus diesem Grund sollte darauf geachtet werden, dass "kein" VoIP Profile auf einer entsprechenden Firewall Policy Rule konfiguriert wurde damit gewährleistet ist das die FortiGate betreffend SIP resp. VoIP den Traffic normal verarbeitet ohne in den SIP resp. VoIP Traffic einzugreifen. Wenn dennoch ein "VoIP Profile" benutzt wird sollte man sich der Problematik bewusst sein und folgenden Artikel berücksichtigen:

        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_als_.22SIP_ALG.22_zu_verstehen_und_soll_ich_diese_Funktion_benutzen.3F]]

Ausgehend davon das SIP (VoIP) nicht benutzt wird resp. die Konfiguration zur Nichtbenutzung korrekt durchgeführt wurde, kann mit nachfolgenden Befehlen dies bestätigt werden dh. Die nachfolgenden Befehle können durchgeführt werden um festzustellen ob der "Session Helper" und/oder der "ALG" für SIP (VoIP) benutzt werden. Wurde die Konfiguration korrekt durchgeführt, bestätigen diese Kommandos das SIP (VoIP) nicht über den "Session Helper" noch über den "ALG" verarbeitet werden da die "counter" im Output für diese Kommandos auf Null stehen. Damit diese Ueberprüfung korrekt durchgeführt werden kann, muss dementsprechend SIP (VoIP) Traffic durchgeführt werden:

        '''SIP Session Helper'''
        
        # diagnose sys sip status
        dialogs: max=131072, used=0
        mappings: used=0
        dialog hash by ID: size=8192, used=0, depth=0
        dialog hash by RTP: size=8192, used=0, depth=0
        mapping hash: size=8192, used=0, depth=0
        count0: 0
        count1: 0
        count2: 0
        count3: 0
        count4: 0

        '''SIP ALG'''
        
        # diagnose sys sip-proxy stats
        sip stats
        
        vdom name: root
        ---------------------------
             active-sessions: 0
             calls-attempted: 0
             calls-established: 0
             calls-failed: 0
        
             calls-active: 0
             registers-active: 0
                      |     received  |     blocked   |  unknown form |  long headers
             req-type |    req    resp|    req    resp|    req    resp|    req    resp
             UNKNOWN         0       0       0       0       0       0       0       0
             ACK             0       0       0       0       0       0       0       0
             BYE             0       0       0       0       0       0       0       0
             CANCEL          0       0       0       0       0       0       0       0
             INFO            0       0       0       0       0       0       0       0
             INVITE          0       0       0       0       0       0       0       0
             MESSAGE         0       0       0       0       0       0       0       0
             NOTIFY          0       0       0       0       0       0       0       0
             OPTIONS         0       0       0       0       0       0       0       0
             PRACK           0       0       0       0       0       0       0       0
             PUBLISH         0       0       0       0       0       0       0       0
             REFER           0       0       0       0       0       0       0       0
             REGISTER        0       0       0       0       0       0       0       0
             SUBSCRIBE       0       0       0       0       0       0       0       0
             UPDATE          0       0       0       0       0       0       0       0
             PING            0       0       0       0       0       0       0       0
             YAHOOREF        0       0       0       0       0       0       0       0

=== Wie konfiguriere ich unter FortiOS 5.4 ein "VoIP Profile" und was muss ich dabei beachten? ===

Bevor ein "VoIP Profile" konfiguriert wird unter FortiOS 5.4 sollte man sich der Problematik bewusst sein dh. dazu sollte folgende zwei Artikel konsultiert werden:

        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_als_.22SIP_ALG.22_zu_verstehen_und_soll_ich_diese_Funktion_benutzen.3F]]
        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_zu_beachten_wenn_SIP_.28VoIP.29_.C3.BCber_eine_Fortigate_implementiert_wird.3F]]

Wenn ein "VoIP Profile" konfiguriert werden möchte muss das entsprechende Feature resp. Menü auf dem Mgmt. Web Interface aktiviert werden. Wie dieses Feature aktiviert wird siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]

Wenn das Menü für "VoIP" aktiviert wurde ist dieses im Mgmt. Web Interface über folgende Position ersichtlich:

        Security Profiles > VoIP

        [[Datei:Fortinet-1635.jpg]]

        '''NOTE''' Die Positionen "REGISTER" und "INVITE" geben an wieviele Requests per Second und Policy über SIP akzeptiert werden wobei
             "REGISTER" der Wert der Verbindungen darstellt die benützt werden um Geräte am Controller anzumelden. Der Wert "INVITE" 
             stellt den effektiven Call dar. Dies bedeutet wenn der Wert 100 gesetzt wird so können sich über das entsprechende 
             konfigurierte "VoIP Profile" das für eine Firewall Policy konfiguriert wurde nicht mehr als zB 100 Devices am Controller 
             registrieren (REGISTER). Wenn "INVITE" auf 100 gesetzt wird können sich über die entsprechende Policy nicht mehr als 100 
             Anrufe (INVITE) durchgeführt werden. Die Position "SCCP" steht für das proprietäre CISCO Protokoll und wird nur im 
             Zusammenhang mit diesem benutzt.

Nachdem ein entsprechendes "VoIP Profile" konfiguriert wurde kann dieses in einer entsprechenden Firewall Policy eingebunden werden:

        [[Datei:Fortinet-1636.jpg]]
        
        '''NOTE''' Achte bei der Implementierung, dass für "outgoing" sowie "incoming" ein korrektes NAT (Network Address Translation) für den
             Traffic für "VoIP" Verbindung konfiguriert wird!

Auf der CLI stehen für das "VoIP Profile" unzählige Optionen zur Verfügung:

        # config voip profile
        # edit [Name des entsprechenden Profile]
        # set comment [Gebe einen entsprechenden Kommentar an]
        # config sip
        # set status [disable | enable]
        # set rtp [disable | enable]
        # set open-register-pinhole [disable | enable]
        # set open-contact-pinhole [disable | enable]
        # set strict-register [disable | enable]
        # set register-rate [Integer]
        # set invite-rate [Integer]
        # set max-dialogs [Integer]
        # set max-line-length [Integer]
        # set block-long-lines [disable | enable]
        # set block-unknown [disable | enable]
        # set call-keepalive [Integer]
        # set block-ack [disable | enable]
        # set block-bye [disable | enable]
        # set block-cancel [disable | enable]
        # set block-info [disable | enable]
        # set block-invite [disable | enable]
        # set block-message [disable | enable]
        # set block-notify [disable | enable]
        # set block-options [disable | enable]
        # set block-prack [disable | enable]
        # set block-publish [disable | enable]
        # set block-refer [disable | enable]
        # set block-register [disable | enable]
        # set block-subscribe [disable | enable]
        # set block-update [disable | enable]
        # set register-contact-trace [disable | enable]
        # set open-via-pinhole [disable | enable]
        # set open-record-route-pinhole [disable | enable]
        # set rfc2543-branch [disable | enable]
        # set log-violations [disable | enable]
        # set log-call-summary [disable | enable]
        # set nat-trace [disable | enable]
        # set subscribe-rate [Integer]
        # set message-rate [Integer]
        # set notify-rate [Integer]
        # set refer-rate [Integer]
        # set update-rate [Integer]
        # set options-rate [Integer]
        # set ack-rate [Integer]
        # set prack-rate [Integer]
        # set info-rate [Integer]
        # set publish-rate [Integer]
        # set bye-rate [Integer]
        # set cancel-rate [Integer]
        # set preserve-override [disable | enable]
        # set no-sdp-fixup [disable | enable]
        # set contact-fixup [disable | enable]
        # set max-idle-dialogs [Integer]
        # set block-geo-red-options [disable | enable]
        # set hosted-nat-traversal [disable | enable]
        # set hnt-restrict-source-ip [disable | enable]
        # set max-body-length [Integer]
        # set unknown-header [discard | pass | respond]
        # set malformed-request-line [discard | pass | respond]
        # set malformed-header-via [discard | pass | respond]
        # set malformed-header-from [discard | pass | respond]
        # set malformed-header-to [discard | pass | respond]
        # set malformed-header-call-id [discard | pass | respond]
        # set malformed-header-cseq [discard | pass | respond]
        # set malformed-header-rack [discard | pass | respond]
        # set malformed-header-rseq [discard | pass | respond]
        # set malformed-header-contact [discard | pass | respond]
        # set malformed-header-record-route [discard | pass | respond]
        # set malformed-header-route [discard | pass | respond]
        # set malformed-header-expires [discard | pass | respond]
        # set malformed-header-content-type [discard | pass | respond]
        # set malformed-header-content-length [discard | pass | respond]
        # set malformed-header-max-forwards [discard | pass | respond]
        # set malformed-header-allow [discard | pass | respond]
        # set malformed-header-p-asserted-identity [discard | pass | respond]
        # set malformed-header-sdp-v [discard | pass | respond]
        # set malformed-header-sdp-o [discard | pass | respond]
        # set malformed-header-sdp-s [discard | pass | respond]
        # set malformed-header-sdp-i [discard | pass | respond]
        # set malformed-header-sdp-c [discard | pass | respond]
        # set malformed-header-sdp-b [discard | pass | respond]
        # set malformed-header-sdp-z [discard | pass | respond]
        # set malformed-header-sdp-k [discard | pass | respond]
        # set malformed-header-sdp-a [discard | pass | respond]
        # set malformed-header-sdp-t [discard | pass | respond]
        # set malformed-header-sdp-r [discard | pass | respond]
        # set malformed-header-sdp-m [discard | pass | respond]
        # set provisional-invite-expiry-time [Integer]
        # set ips-rtp [disable | enable]
        # set ssl-mode [off | full]
        # set ssl-send-empty-frags [enable | disable]
        # set ssl-client-renegotiation [allow | deny | secure]
        # set ssl-algorithm [high | medium | low]
        # set ssl-pfs [require | deny | allow]
        # set ssl-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
        # set ssl-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
        # set ssl-client-certificate [string]
        # set ssl-server-certificate [string]
        # set ssl-server-certificate [string]
        # set ssl-auth-client [string]
        # set ssl-auth-server [string]
        # end
        # config sccp
        # set status [disable | enable]
        # set block-mcast [disable | enable]
        # set verify-header [disable | enable]
        # set log-call-summary [disable | enable]
        # set log-violations [disable | enable]
        # set max-calls [Integer]
        # end
        # end

Weitere Informationen welche Option welche Funktion besitzt siehe nachfolgendes Dokument:

        [[Datei:Fortigate-CLI-Ref-54.pdf]]

Ebenso gibt nachfolgendes Dokument speziell Auskunft über das "VoIP Profile" und dessen Funktionen als Referenz:

        [[Datei:Fortigate-sip-54.pdf]

== Zeit / Datum ==

=== Wie kann ich auf einer FortiGate die Zeit sowie das Datum überprüfe sowie konfigurieren? ===

Die Zeit sowie das Datum lassen sich über Web Mgmt. Interface überprüfen sowie über CLI. Um die Zeit sowie das Datum über Web Mgmt. zu überprüfen sowie zu konfigurieren wähle folgendes:

        Dashboard > [Widget Systeminformation] > System Time > Change
        
        [[Datei:Fortinet-1612.jpg]]

Unter dieser Position kann die Zeit und das Datum manuell überprüft sowie konfiguriert werden! Um die Zeit und das Datum über die CLI zu überprüfen kann folgendes Kommando benutzt werden:

        # execute time
        current time is: 19:23:51
        last ntp sync:Wed Dec 23 18:55:08 2015

        # execute date
        current date is: 2015-12-23

Um die Zeit sowie das Datum über CLI zu konfigurieren kann folgendes durchgeführt werden:

        # execute time hh:mm:ss

        # execute date yyyy-mm-dd

=== Wie kann ich auf einer FortiGate unter FortiOS 5.4 die Zeitzone konfigurieren? ===

Die Definition der Zeitzone auf einer FortiGate kommt eine "wichtige" Funktion zu dh. FortiGuard benützt die Zeitzone für verschiedenen Konfigurationen. Die Zeitzone auf einer FortiGate ist per Standard auf "US&Canada" gesetzt. Somit benützt "FortiGuard" für dessen Service Server aus dieser Zeitzone "US&Canada". Das gleiche gilt für den WebFilter dh. wenn die Zeitzone nicht angepasst wird so benützt FortiGuard die WebFilter Datenbank der Zeitzone "US&Canada". Um die Zeitzone über Web Mgmt. Interface zu konfigurieren benütze folgende Position:

        Dashboard > [Widget Systeminformation] > System Time > Change

Um die Zeitzone über CLI zu konfigurieren kann folgendes durchgeführt werden:

        # config system global
        # set timezone ?
        01    (GMT-11:00)Midway Island, Samoa
        02    (GMT-10:00)Hawaii
        03    (GMT-9:00)Alaska
        04    (GMT-8:00)Pacific Time(US&Canada)
        05    (GMT-7:00)Arizona
        81    (GMT-7:00)Baja California Sur, Chihuahua
        06    (GMT-7:00)Mountain Time(US&Canada)
        07    (GMT-6:00)Central America
        08    (GMT-6:00)Central Time(US&Canada)
        09    (GMT-6:00)Mexico City
        10    (GMT-6:00)Saskatchewan
        11    (GMT-5:00)Bogota,Lima,Quito
        12    (GMT-5:00)Eastern Time(US & Canada)
        13    (GMT-5:00)Indiana(East)
        74    (GMT-4:30)Caracas
        14    (GMT-4:00)Atlantic Time(Canada)
        77    (GMT-4:00)Georgetown
        15    (GMT-4:00)La Paz
        16    (GMT-3:00)Santiago
        17    (GMT-3:30)Newfoundland
        18    (GMT-3:00)Brasilia
        19    (GMT-3:00)Buenos Aires
        20    (GMT-3:00)Nuuk(Greenland)
        75    (GMT-3:00)Uruguay
        21    (GMT-2:00)Mid-Atlantic
        22    (GMT-1:00)Azores
        23    (GMT-1:00)Cape Verde Is.
        24    (GMT)Monrovia
        80    (GMT)Greenwich Mean Time
        79    (GMT)Casablanca
        25    (GMT)Dublin,Edinburgh,Lisbon,London
        26    (GMT+1:00)Amsterdam,Berlin,Bern,Rome,Stockholm,Vienna
        27    (GMT+1:00)Belgrade,Bratislava,Budapest,Ljubljana,Prague
        28    (GMT+1:00)Brussels,Copenhagen,Madrid,Paris
        78    (GMT+1:00)Namibia
        29    (GMT+1:00)Sarajevo,Skopje,Warsaw,Zagreb
        30    (GMT+1:00)West Central Africa
        31    (GMT+2:00)Athens,Sofia
        85    (GMT+2:00)Istanbul
        32    (GMT+2:00)Bucharest
        33    (GMT+2:00)Cairo
        34    (GMT+2:00)Harare,Pretoria
        35    (GMT+2:00)Helsinki,Riga,Tallinn
        36    (GMT+2:00)Jerusalem
        37    (GMT+3:00)Baghdad
        38    (GMT+3:00)Kuwait,Riyadh
        83    (GMT+3:00)Moscow
        84    (GMT+3:00)Minsk
        40    (GMT+3:00)Nairobi
        41    (GMT+3:30)Tehran
        42    (GMT+4:00)Abu Dhabi,Muscat
        43    (GMT+4:00)Baku
        39    (GMT+3:00)St.Petersburg,Volgograd
        44    (GMT+4:30)Kabul
        46    (GMT+5:00)Islamabad,Karachi,Tashkent
        47    (GMT+5:30)Kolkata,Chennai,Mumbai,New Delhi
        51    (GMT+5:30)Sri Jayawardenepara
        48    (GMT+5:45)Kathmandu
        45    (GMT+5:00)Ekaterinburg
        49    (GMT+6:00)Almaty,Novosibirsk
        50    (GMT+6:00)Astana,Dhaka
        52    (GMT+6:30)Rangoon
        53    (GMT+7:00)Bangkok,Hanoi,Jakarta
        54    (GMT+7:00)Krasnoyarsk
        55    (GMT+8:00)Beijing,ChongQing,HongKong,Urumgi,Irkutsk
        56    (GMT+8:00)Ulaan Bataar
        57    (GMT+8:00)Kuala Lumpur,Singapore
        58    (GMT+8:00)Perth
        59    (GMT+8:00)Taipei
        60    (GMT+9:00)Osaka,Sapporo,Tokyo,Seoul
        62    (GMT+9:30)Adelaide
        63    (GMT+9:30)Darwin
        61    (GMT+9:00)Yakutsk
        64    (GMT+10:00)Brisbane
        65    (GMT+10:00)Canberra,Melbourne,Sydney
        66    (GMT+10:00)Guam,Port Moresby
        67    (GMT+10:00)Hobart
        68    (GMT+10:00)Vladivostok
        69    (GMT+10:00)Magadan
        70    (GMT+11:00)Solomon Is.,New Caledonia
        71    (GMT+12:00)Auckland,Wellington
        72    (GMT+12:00)Fiji,Kamchatka,Marshall Is.
        00    (GMT+12:00)Eniwetok,Kwajalein
        82    (GMT+12:45)Chatham Islands
        73    (GMT+13:00)Nuku'alofa
        86    (GMT+13:00)Samoa
        76    (GMT+14:00)Kiritimati
        # set timezone 26
        # end

== NTP ==

=== Wie kann ich auf einer FortiGate die NTP Zeitsynchronisierung aktiviren und konfigurieren? ===

Um die NTP Zeitsynchronisierung über Web Mgmt. Interface zu aktivieren und zu konfigurieren wähle folgendes:

        Dashboard > [Widget Systeminformation] > System Time > Change

        [[Datei:Fortinet-1612.jpg]]

        '''NOTE''' Per Standard ist für die NTP Zeitsynchronisierung "FortiGuard" aktiviert. Dies ist nicht zu empfehlen. Es sollte
             ein "öffentlichen" NTP Server konfiguriert werden. Wir empfehlen "ch.pool.ntp.org" da dieser ein "öffentlicher"
             NTP Server ist und über mehrer "Stratum" Server verfügt! Wenn dennoch "FortiGuard" benutzt wird muss berücksichtig
             werden, dass diese NTP Server für "FortiGuard" nicht kostenlos zur Verfügung stehen sondern ein Service ist der unter
             der "FortiCare" Lizensierung zur Verfügung steht. Weitere Informationen dazu siehe nachfolgenden Artikel:
             
             [[Fortinet:FortiCare-FortiGuard#Wenn_ich_.22nur.22_DDNS_.28Dynamic_DNS.29.2C_GeoIP.2C_NTP_und_DNS_Service_von_FortiGuard_benutze_was_muss_ich_im_Minimum_lizensieren.3F]]

Wenn man die NTP Zeitsynchronisierung über CLI konfigurieren möcht kann folgendes durchgeführt werden:

        # config system ntp
        # set ntpsync enable
        # set type custom
        # set syncinterval 360
        # set server-mode enable
        # set interface "internal"
        # config ntpserver
        # edit 1
        # set server "ch.pool.ntp.org"
        # set ntpv3 disable
        # next
        # end
        # end

Bei diesem Beispiel wird zusätzlich zur NTP Synchronisierung über "ch.pool.ntp.org" die Option "server-mode" aktiviert sowie das "internal" Interface. Dies bedeutet: Auf dem "internal" Interface wird durch die Aktivierung von "server-mode" ein NTP Dienst aktiviert der in diesem Segment den Clients für eine NTP Zeitsynchronisierung zur Verfügung gestellt wird. Dabei ist zu beachten, dass diese Konfiguration keine zusätzliche "Firewall Policy Rule" benötigt da im Hintergrund eine automatische "Firewall Policy Rule" hinzugefügt wird durch das FortiOS (Local-In Policy). Diese erlaubt den Zugriff auf das definierte "Interface" aus diesem Segement. Diese "Local-In Policy" ist über Web Mgmt. Interface ersichtlich sofern das entsprechende Feature aktiviert ist:

        System > Feature Select > Additional Features > Local In Policy

Wenn dieses Feature aktiviert ist, sind die entsprechenden "Local In Policy" über folgende Position ersichtlich:

        Policy & Objects > Local In Policy

== PCI Compliance ==

=== Was ist "PCI Compliance" und wie kann ich unter FortiOS 5.4 einen "PCI Compliance" Report ausführen? ===

Die "PCI Compliance" Definition ist eine Beschreibung von Standards denen ein Implementer zB ISP, Finanzinstitute usw. folgend sollte. Somit bietet die Definion "PCI Compliance" Richtlinien an denen sich diese Implementer halten muss um als "PCI Compliance" zu gelten. Dies ist speziell im Zahlungsverkehr dh. Kreditkarten ein "muss". Weitere Informationen siehe nachfolgenden Link:  

        https://www.pcisecuritystandards.org/

Unter FortiOS 5.4 wurde dem Rechnung getragen dh. verschiedenen Positionen in verschiedenen Konfigurationen lehnen sich an diesen "PCI Compliance" an. Ein Beispiel wäre zB die Position "Name" innerhalb eine "Firewall Policy Rule". Weitere Informationen dazu siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Unter_FortiOS_5.4_f.C3.BCr_eine_.22Firewall_Policy_Rule.22_existiert_die_Position_.22Name.22_um_was_handelt_es_sich_dabei.3F]]

Somit kann unter FortiOS 5.4 auch ein "PCI Compliance" Report ausgeführt werden dh. dieser überprüft die vorhandenen Konfiguration nach "PCI Compliance" Standard. Der Report resp. die Funktion ist jedoch per Standard deaktiviert und kann über Web Mgmt. Interface aktiviert und über einen "schedule" konfiguriert werden. Dabei wird "täglich" durch die Definition des "schedules" ein Report generiert in Form eines Logs. Um die entsprechende Konfiguration durchzuführen wähle im Web Mgmt. Interface folgende Position:

        System > Advanced > Compliance

        [[Datei:Fortinet-1618.jpg]]

Der "PCI Compliance" Report kann ebenfalls nach der Aktivierung direkt ausgeführt werden mit "run now". Wird dies durchgeführt ist der Report in Form von Log's unter folgender Position verfügbar:

        Log & Report > Compliance Events

        [[Datei:Fortinet-1619.jpg]]
        
        '''NOTE''' Diese Konfiguration über Web Mgmt. Interface ist VDOM basierend dh. wenn der VDOM Mode benutzt wird so muss unter
             "global" generell die Funktion zur Verfügung gestellt werden. Dabei wird der "schedule" Global konfiguriert und 
             in der VDOM entweder aktiviert oder deaktiviert!

Um auf der CLI die Konfiguration des "PCI Compliance" Report durchzuführen führe folgendes aus:

        # config system global
        # set compliance-check enable 
        # set compliance-check-time 09:00:00 
        # end

        # config system settings
        # set compliance-check enable
        # end

Dabei ist folgendes zu berücksichtigen: Bei kleineren Devices wie zB FG-60D kann nicht auf "disk" geloggt werden. Somit stehen für die Logs lokal nur "memory" zur Verfügung sofern nicht Remote zB auf einen FortiAnalyzer geloggt wird. Da für das "memory" Logging 10% des vorhandenen Memory genutzt wird sind diese "Compliance Events" nicht "persistent" sondern sind nach kurzer Zeit nicht mehr verfügbar. Ebenso ist folgendes zu berücksichtigen: Jede Meldung des Reports resp. jeder Eintrag unter "Compliance Events" muss analysiert werden um zu bestimmen ob der Eintag ein Problem für die "PCI Compliance" darstellt. Dies bedeutet auch: Der nachfolgende Eintrag weist daraufhin, dass "deep inspection" für SSH nicht aktiviert wurde. Diese Funktion jedoch steht auf einem FG-60D nicht zur Verfügung also ist dieser Log Eintrag ein Hinweis jedoch kann nicht durch eine entsprechende Konfiguration behoben werden:

        [[Datei:Fortinet-1616.jpg]]

Es ist somit anzufügen, dass diese Funktion Hinweise liefert im "PCI Compliance" Bereich und nicht im allgemeinen "security" technische Bereich! Für dei "PCI Compliance" Funktion steht ebenfalls unter CLI ein "debug" Mode zur Verfügung. Dieser kann folgendermassen ausgeführt werden:

        '''Setze alle Debug Filter zurück'''
        
        # diagnose debug reset

        '''Setze einen Debug Filter für die Applikation "dssccd"'''
        
        # diagnose debug application dssccd -1

        '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
        
        # diagnose debug enable 

Um den Debug Modus zu beenden und alle Filter zurück zu setzen führe folgendes aus:

        # diagnose debug disable
        # diagnose debug reset

== Wireless-Controller ==

=== Wo finde ich Informationen betreffend FortiGate Wireless Controller und Forti Access Points? ===

Nachfolgender Artikel gibt Auskunft über die verschiedenen Konfigurationen und Betrieb von Forti Access Points im Zusammenhang mit dem FortiGate Wireless Controller:

        [[FortiAP:FAQ]]

== Log ==

=== Wie sieht eine vollständige Log Konfiguration für FortiOS 5.4 aus und wie wird diese durchgeführt? ===

Wenn man mit einer Firewall arbeitet ist die absolute Grundvoraussetzung ein zur Verfügung stehendes Log um anhand dessen Analysen durchzuführen. Desweiteren sind die enthaltenen Informationen in den Logs dh. Funktionen die man für die Log Details aktivieren kann unumgänglich und absolut Fundamental. Um eine vollständige Log Konfiguration durchzuführen unter FortiOS 5.4 führe folgendes aus:

        <big>'''Globale Log Konfiguration'''</big>
        
        # config log setting
        # set resolve-ip [enable | disable]
        # set resolve-port [enable | disable]
        # set log-user-in-upper [enable | disable]
        # set fwpolicy-implicit-log [enable | disable]
        # set fwpolicy6-implicit-log [enable | disable]
        # set log-invalid-packet [enable | disable]
        # set local-in-allow [enable | disable]
        # set local-in-deny-unicast [enable | disable]
        # set local-in-deny-broadcast [enable | disable]
        # set local-out [enable | disable]
        # set daemon-log [enable | disable]
        # set neighbor-event [enable | disable]
        # set brief-traffic-format [enable | disable]
        # set user-anonymize [enable | disable]
        # set fortiview-weekly-data [enable | disable]
        # end
        
        '''NOTE''' Die Option "fortiview-weekly-data" steht nur Devices zur Verfügung die über ein "disk" Logging verfügen!
        
        Wir empfehlen für eine komplette Grundkonfiguration folgendes auszuführen:
        
        # config log setting
        # set resolve-ip enable 
        # set resolve-port enable 
        # set log-user-in-upper disable 
        # set fwpolicy-implicit-log enable 
        # set fwpolicy6-implicit-log disable 
        # set log-invalid-packet disable 
        # set local-in-allow enable 
        # set local-in-deny-unicast disable 
        # set local-in-deny-broadcast disable 
        # set local-out enable 
        # set daemon-log disable 
        # set neighbor-event disable 
        # set brief-traffic-format disable 
        # set user-anonymize disable 
        # end

        <big>'''Globale Network Visibility Log Konfiguration'''</big>
        
        Aktiviere/Deaktivieren Network Visibility
        
        # config system network-visibility 
        # set destination-visibility [enable | disable]
        # set source-location [enable | disable]
        # set destination-hostname-visibility [enable | disable]
        # set hostname-ttl [Definiere TTL Standard 86400]
        # set hostname-limit [Definiere Anzahl Hostname Limit Standard 5000]
        # set destination-location [enable | disable]
        # end
        
        Wir empfehlen für eine Konfiguration folgendes:
        
        # config system network-visibility 
        # set destination-visibility enable
        # set source-location enable
        # set destination-hostname-visibility enable
        # set hostname-ttl 86400
        # set hostname-limit 5000
        # set destination-location enable
        # end

        <big>'''Globale Eventfilter Log Konfiguration'''</big>
        
        # config log eventfilter
        # set event [enable | disable]
        # set system [enable | disable]
        # set vpn [enable | disable]
        # set user [enable | disable]
        # set router [enable | disable]
        # set wireless-activity [enable | disable]
        # set wan-opt [enable | disable]
        # set endpoint [enable | disable]
        # set ha [enable | disable]
        # set compliance-check [enable | disable]
        # end
        
        Wir empfehlen für eine Konfiguration folgendes:
        
        # config log eventfilter
        # set event enable
        # set system enable
        # set vpn enable
        # set user enable
        # set router enable
        # set wireless-activity enable
        # set wan-opt enable
        # set endpoint enable
        # set ha enable
        # set compliance-check enable
        # end

        <big>'''Globale Gui Log Konfiguration'''</big>
        
        # config log gui-display
        # set resolve-hosts [enable | disable]
        # set resolve-apps [enable | disable]
        # set fortiview-unscanned-apps [enable | disable]
        # set fortiview-local-traffic [enable | disable]
        # set location [memory | disk | fortianalyzer | fortiguard]
        # end
        
        '''NOTE''' In dieser Konfiguration muss darauf geachtet werden, dass für die Option "location" der Device definiert ist 
             der als "Log Device" definiert wird. Dies bedeutet: Wird als "Log Device" das Memory definiert so muss als
             "location" ebenfalls "memory" definiert werden. Durch "location" wir die API Schnittstelle definiert für den
             Zugriff auf die Datenbank die benützt wird für das Logging!
        
        Wir empfehlen für eine Konfiguration ausgehend davon, dass "memory" Logging benutzt wird folgendes:
        
        # config log gui-display
        # set resolve-hosts enable
        # set resolve-apps enable
        # set fortiview-unscanned-apps enable
        # set fortiview-local-traffic enable
        # set location memory
        # end

        <big>'''Device Log Konfiguration'''</big>
        
        '''NOTE''' Bei dieser Konfiguration ist zu berücksichtigen, dass nur grösseren Geräten die "disk" für das Logging zur Verfügung steht.
             Kleineren Devices steht nur das "memory" für das Logging zur Verfügung. Wird "memory" benutzt wird 10% des Memory herangezogen
             um ein "memory" Logging durchzuführen. Diese 10% Memory werden immer wieder überschrieben um ein kontinuierliches Logging zu
             gewährleisten. Somit steht im Zusammenhang mit "memory" Logging keine History zur Verfügung. Wir empfehlen ein "Logging" auf
             FortiAnalyzer um eine History zu gewährleisten und das Memory nicht zusätzlich mit einem "memory" Logging zu belasten! Um zu
             verfizieren ob ein Device über die Möglichkeit verfügt auf "disk" zu "Loggen" kann die "Software Matrix" herangezogen werden:
             
             [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]
                
        '''Device Log Konfiguration "Null-Device"'''
        
        Diese Konfiguration ist zuständig, das Devices die nicht für "Remote Logging" (FortiAnalyzer) konfiguriert wurde dh. zB für "memory"
        dennoch über "statistics" verfügen. Dies bedeutet: Diese Funktion steht nur im Zusammenhang mit Lokalen Logging!
         
        # config log null-device setting
        # set status [enable | disable]
        # end
        
        Zu diesem Device dh. "null-device" existiert ebenfalls ein entsprechender Filter:
        
        # config log null-device filter 
        # set severity [emergency | alert | critical | error | warning | notification | information | debug]
        # set forward-traffic [enable | disable]
        # set local-traffic [enable | disable] 
        # set multicast-traffic [enable | disable] 
        # set sniffer-traffic [enable | disable]
        # set anomaly [enable | disable] 
        # set voip [enable | disable] 
        # set filter [Benütze ? für weitere Informationen]
        # set filter-type [include | exclude]
        # end
               
        Wir empfehlen folgende Konfiguration unter der Voraussetzung, dass "memory" oder "disk" als "Device Konfiguration" benutzt wird:
        
        # config log null-device setting
        # set status enable
        # end
        
        # config log null-device filter 
        # set severity information 
        # set forward-traffic enable
        # set local-traffic enable 
        # set multicast-traffic enable 
        # set sniffer-traffic enable
        # set anomaly enable 
        # set voip enable
        # unset filter
        # set filter-type include
        
        '''Device Log Konfiguration "Memory"'''
        
        # config log memory setting 
        # set status [enable | disable]
        # set diskfull overwrite 
        # end 
        
        # config log memory filter
        # set severity [emergency | alert | critical | error | warning | notification | information | debug]
        # set fortward-traffic [enable | disable]
        # set local-traffic [enable | disable]
        # set multicast-traffic [enable | disable]
        # set sniffer-traffic [enable | disable]
        # set anomaly [enable | disable]
        # set voip [enable | disable]
        # set set filter [Benütze ? für weitere Informationen]
        # set set filter-type [include | exclude]
        # end
        
        Wir empfehlen folgende Konfiguration unter der Voraussetzung, dass "memory" als "Device Konfiguration" benutzt wird:
        
        # config log memory setting 
        # set status enable
        # set diskfull overwrite 
        # end 
        
        # config log memory filter
        # set severity information
        # set fortward-traffic enable
        # set local-traffic enable
        # set multicast-traffic enable
        # set sniffer-traffic enable
        # set anomaly enable
        # set voip enable
        # unset filter
        # set filter-type include
        # end
        
        '''Device Log Konfiguration "FortiAnalyzer"'''
        
        # config log fortianalyzer setting 
        # set status [enable | disable] 
        # set ips-archive [enable | disable] 
        # set server [FortiAnalyzer IP] 
        # set enc-algorithm [default | high | low | disable] 
        # set conn-timeout [Buffer in Sekunden; Standard 10 ]
        # set monitor-keepalive-period [OFTP keepalive für Buffer und Status in Sekunden; Standard 5 ]
        # set monitor-failure-retry-period [Retry für keepalive und Buffer in Sekunden; Standard 5 ]
        # set source-ip 0.0.0.0 
        # set upload-option realtime 
        # set upload-interval [Frequenz für Upload; Standard daily]
        # set upload-day [Tag in der Woche/Monat für den Upload; Standard "Kein Wert"]
        # set upload-time [Zeit Definition für Upload zB 00:00]
        # set reliable [enable | disable]
        # end
        
        '''NOTE''' Die Optionen "upload-interval, upload-day sowie upload-tim" stehen nur dann zur Verfügung wenn die "disk" für das 
             Logging konfiguriert werden kann!
        
        # config log fortianalyzer filter
        # set severity [emergency | alert | critical | error | warning | notification | information | debug]
        # set fortward-traffic [enable | disable]
        # set local-traffic [enable | disable]
        # set multicast-traffic [enable | disable]
        # set sniffer-traffic [enable | disable]
        # set anomaly [enable | disable]
        # set voip [enable | disable]
        # set dlp-archive [enable | disable]
        # set filter [Benütze ? für weitere Informationen]
        # set filter-type [include | exclude]
        # end
        
        Wir empfehlen folgende Konfiguration unter der Voraussetzung, dass "fortianalyzer" als "Device Konfiguration" benutzt wird:
        
        # config log fortianalyzer setting 
        # set status enable
        # set ips-archive enable 
        # set server [FortiAnalyzer IP] 
        # set enc-algorithm default 
        # set conn-timeout 10
        # set monitor-keepalive-period 5
        # set monitor-failure-retry-period 5
        # set upload-option realtime 
        # set reliable enable
        # end
        
        # config log fortianalyzer filter
        # set severity information
        # set fortward-traffic enable
        # set local-traffic enable
        # set multicast-traffic enable
        # set sniffer-traffic enable
        # set anomaly enable
        # set voip enable
        # set dlp-archive enable
        # unset filter
        # set filter-type include
        # end
        
        '''Device Log Konfiguration "Disk"'''
        
        '''NOTE''' Ein Logging auf "disk" ist in allen Bereichen nicht empfohlen wenn der FortiGate Device über eine "Flash Disk" verfügt.
             Ob ein Device über "disk" Logging verfügt, kann der "Software Matrix" entnommen werden:
             
             [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]
        
        # config log disk setting
        # set status [enable | disable]
        # set ips-archive [enable | disable]
        # set max-log-file-size [Maximum Log Grösse bevor ein "Rolling" durchgeführt wird in MB; Standard 20]
        # set max-policy-packet-capture-size [Max Grösse für Capturing in MB; Standard 10]
        # set roll-schedule [daily | weekly]
        # set roll-day [sunday | monday | tuesday | wednesday | thursday | friday | saturday]
        # set roll-time [Zeit Definition für "Rolling" zB 00:00]
        # set diskfull [overwrite | nolog]
        # set log-quota [Grösse der Log Quota in MB; Standard 0]
        # set dlp-archive-quota [Grösse der DLP Archiv Quota in MB; Standard 0]
        # set report-quota [Grösse der Report Quota in MB; Standard 0]
        # set maximum-log-age [Löschen von Logs die älter sind als X Tage; Standard 7]
        # set upload [enable | disable]
        # set upload-destination [ftp-server]
        # set uploadip [IPv4 Adresse des FTP Servers]
        # set uploadport [FTP Server Port; Standard 21]
        # set source-ip [IPv4 Source Adresse der Anfrage an FTP Server]
        # set uploaduser [FTP Server Username]
        # set uploadpass [FTP Server Passwort]
        # set uploaddir [FTP Server Upload Verzeichnis]
        # set uploadtype [traffic | event | virus | webfilter | IPS | spamfilter | dlp-archive | anomaly | voip | dlp | app-ctrl | waf | netscan | gtp]
        # set uploadzip [enable | disable]
        # set uploadsched [enable | disable]
        # set uploadtime [Zeit Definition für Upload auf FTP Server zB 00:00]
        # set upload-delete-files [enable | disable]
        # set upload-ssl-conn {default | high | low | disable}
        # set full-first-warning-threshold [Erste Log Device Full Warnung in % 1 - 98, Standard 75]
        # set full-second-warning-threshold [Zweite Log Device Full Warnung in % 2 - 99, Standard 90]
        # set full-final-warning-threshold [Finale Log Device Full Warnung in % 3 - 100, Standard 95]
        # end
        
        # config log disk filter
        # set severity [emergency | alert | critical | error | warning | notification | information | debug]
        # set fortward-traffic [enable | disable]
        # set local-traffic [enable | disable]
        # set multicast-traffic [enable | disable]
        # set sniffer-traffic [enable | disable]
        # set anomaly [enable | disable]
        # set voip [enable | disable]
        # set dlp-archive [enable | disable]
        # set filter [Benütze ? für weitere Informationen]
        # set filter-type [include | exclude]
        # end
        
        '''NOTE''' Wenn eine Konfiguration betreffend "Rolling" durchgeführt werden möchte siehe nachfolgender Artikel:
             
             [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_eine_.22Log_Rotation.22_konfigurieren.3F]]
        
        Wir empfehlen folgende Konfiguration unter der Voraussetzung, dass "disk" als "Device Konfiguration" benutzt wird:
        
        # config log disk setting
        # set status enable
        # set ips-archive enable
        # set max-log-file-size 512
        # set max-policy-packet-capture-size 10
        # set diskfull overwrite
        # set log-quota 2048
        # set dlp-archive-quota 256
        # set maximum-log-age 7
        # set full-first-warning-threshold 75
        # set full-second-warning-threshold 90
        # set full-final-warning-threshold 95
        # end
        
        # config log disk filter
        # set severity information
        # set fortward-traffic enable
        # set local-traffic enable
        # set multicast-traffic enable
        # set sniffer-traffic enable
        # set anomaly enable
        # set voip enable
        # set dlp-archive enable
        # unset filter
        # set filter-type include
        # end
        
        '''Device Log Konfiguration "Syslog"'''
        
        Für eine Konfiguration betreffend "syslog" Server siehe nachfolgender Artikel:
        
        [[FortiGate-5.4:FAQ#Wie_wird_auf_einer_Fortigate_unter_FortiOS_5.4_eine_Log_Konfiguration_f.C3.BCr_einen_.22Syslog_Server.22_durchgef.C3.BChrt.3F]]
        
        '''Device Log Konfiguration "FortiGuard"'''
        
        # config log fortiguard setting 
        # set status [enable | disable]
        # set upload-option [store-and-upload | realtime]
        # set upload-interval [daily | weekly | monthly]
        # set upload-day [Definition des Tages der Woche um ein Rolling der Logs durchzuführen]
        # set upload-time [Definition der Zeit für den Uploade zB 00:00]
        # set enc-algorithm [default | high | low | disable]
        # set source-ip [Definition der Source IPv4 Adresse für die Anfrage]
        # end
        
        '''NOTE''' Wenn "fortiguard" Logging konfiguriert wird muss vorgängig ein ForitCloud Account ID konfiguriert werden. Dies kann unter
             folgender Position im Mgmt. Web Interface durchgeführt werden:
             
             Dashboard > License Information Widget > FortiCloud Account > Activate
                
        Weitere Informationen zu FortiGuard "Logging" sowie FortiCloud siehe nachfolgender Artikel:
       
        [[FortiCloud:FAQ]]

Zusätzlich existieren in den verschiedenen "Security Profiles" Logs die aktiviert werden können. Nachfolgend eine Aufstellungen dieser Logs betreffend "Security Profiles":

       '''SSL Inspection Profile'''
       # config firewall ssl-ssh-profile
       # edit [Name des Profiles] 
       # set ssl-invalid-server-cert-log [enable | disable] 
       # end

       '''Proxy Option Profile'''
       # config firewall profile-protocol-options 
       # edit [Name des Profiles] 
       # set oversize-log [enable | disable] 
       # set switching-protocols-log [enable | disable] 
       # end 

       '''Antivirus Profile'''
       # config antivirus profile 
       # edit [Name des Profiles] 
       # config http
       # set archive-log [encrypted | corrupted | multipart | nested | mailbomb | unhandled]
       # end
       # config ftp
       # set archive-log [encrypted | corrupted | multipart | nested | mailbomb | unhandled]
       # end
       # config imap
       # set archive-log [encrypted | corrupted | multipart | nested | mailbomb | unhandled]
       # end
       # config pop3
       # set archive-log [encrypted | corrupted | multipart | nested | mailbomb | unhandled]
       # end
       # config smtp
       # set archive-log [encrypted | corrupted | multipart | nested | mailbomb | unhandled]
       # end
       # config mapi
       # set archive-log [encrypted | corrupted | multipart | nested | mailbomb | unhandled]
       # end
       # config nntp
       # set archive-log [encrypted | corrupted | multipart | nested | mailbomb | unhandled]
       # end
       # config nac-quar
       # set log [enable | disable]
       # end
       # set av-block-log [enable | disable] 
       # set av-virus-log [enable | disable] 
       # end

       '''WebFilter Profile'''
       # config webfilter profile 
       # edit [Name des Profiles] 
       # config web
       # set log-search [enable | disable] 
       # end
       # set log-all-url [enable | disable] 
       # set web-content-log [enable | disable] 
       # set web-filter-activex-log [enable | disable] 
       # set web-filter-command-block-log [enable | disable] 
       # set web-filter-cookie-log [enable | disable] 
       # set web-filter-applet-log [enable | disable] 
       # set web-filter-jscript-log [enable | disable] 
       # set web-filter-js-log [enable | disable] 
       # set web-filter-vbs-log [enable | disable] 
       # set web-filter-unknown-log [enable | disable]
       # set web-filter-referer-log [enable | disable] 
       # set web-filter-cookie-removal-log [enable | disable] 
       # set web-url-log [enable | disable] 
       # set web-invalid-domain-log [enable | disable] 
       # set web-ftgd-err-log [enable | disable] 
       # set web-ftgd-quota-usage [enable | disable]       
       # end

       '''Data Leak Prevention Profile'''
       # config dlp sensor 
       # edit [Name des Profiles]  
       # set dlp-log [enable | disable] 
       # set nac-quar-log [enable | disable] 
       # end 

       '''Application Control Profile'''
       # config application list 
       # edit [Name des Profiles] 
       # set other-application-log [enable | disable] 
       # set unknown-application-log [enable | disable] 
       # config entries
       # edit [Gebe einen entsprechenden Integer an zB "1"]
       # set log [enable | disable]
       # set log-packet [enable | disable]
       # end
       # end 

       '''Anti-Spam Profile'''
       # config spamfilter profile 
       # edit [Name des Profiles] 
       # set spam-log [enable | disable] 
       # config imap
       # set log enable
       # end
       # config pop3
       # set log enable
       # end
       # config smtp
       # set log enable
       # end
       # config mapi
       # set log enable
       # end
       # config msn-hotmail
       # set log enable
       # end
       # config yahoo-mail
       # set log enable
       # end
       # config gmail
       # set log enable
       # end
       # end

       '''DNS Filter Profile'''
       # config dnsfilter profile
       # edit [Name des Profiles] 
       # set log-all-url [enable | disable]
       # end

       '''Cloud Access Security Inspection Profile'''
       # config application casi profile
       # edit [Name des Profiles]
       # config entries
       # edit [Gebe einen entsprechenden Integer an zB "1"]
       # set log [enable | disable]
       # end

       '''Intrustion Protection Profile'''
       # config ips sensor
       # edit [Name des Profiles]
       # config entries
       # edit [Gebe einen entsprechenden Integer an zB "1"]
       # set log [enable | disable]
       # set log-packet [enable | disable]
       # set log-attack-content [enable | disable]
       # end

       '''VoIP Profile'''
       # config voip profile
       # edit [Name des Profiles]
       # config sip
       # set log-violations [enable | disable]
       # set log-call-summary [enable | disable]
       # end
       # config sccp
       # set log-violations [enable | disable]
       # set log-call-summary [enable | disable]
       # end
       # end

       '''Web Application Firewall'''
       # config waf profile
       # edit [Name des Profiles]
       # config constraint
       # config header-length
       # set log [enable | disable]
       # end
       # config content-lenght
       # set log [enable | disable]
       # end
       # config param-lenght
       # set log [enable | disable]
       # end
       # config line-length
       # set log [enable | disable]
       # end
       # config url-param-lenght
       # set log [enable | disable]
       # end
       # config version
       # set log [enable | disable]
       # end
       # config method
       # set log [enable | disable]
       # end
       # config hostname
       # set log [enable | disable]
       # end
       # config malformed
       # set log [enable | disable]
       # end
       # config max-cookie
       # set log [enable | disable]
       # end
       # config max-header-line
       # set log [enable | disable]
       # end
       # config max-url-param
       # set log [enable | disable]
       # end
       # config max-range-segment
       # set log [enable | disable]
       # end
       # end
       # config method
       # set log [enable | disable]
       # end
       # config address-list
       # set blocked-log [enable | disable]
       # end
       # config url-access
       # edit [Gebe einen entsprechenden Integer an zB "1"]
       # set log [enable | disable]
       # end
       # end

       '''FortiClient Profile'''
       # config endpoint-control profile
       # edit [Name des entsprechenden Profiles]
       # config forticlient-winmac-settings
       # set forticlient-log-upload [enable | disable]
       # end
       # end

Desweiteren stehen auf "Globaler" sowie "System" Ebene folgende Logs zur Verfügung:

       # config system global
       # set cli-audit-log [enable | disable]
       # set log-uuid [poliy-only | extended | disable]
       # end

       # config system settings
       # set vpn-stats-log [ipsec | pptp | l2tp | ssl]
       # end

Für die "DoS-Policy" kann für jede "anomaly" ein Log aktiviert resp. deaktiviert werden:

       # config firewall DoS-policy
       # edit [Gebe einen entsprechenden Integer an zB "1"]
       # config anomaly
       # edit [Name der "anomaly"]
       # set log [enable | disable]
       # end
       # end

=== Wie wird auf einer Fortigate unter FortiOS 5.4 eine Log Konfiguration für einen "Syslog Server" durchgeführt? ===

Das nachfolgend Beispiel zeigt wie auf einer FortiGate unter FortiOS 5.4 eine Log Konfiguration durchgeführt basierend auf einem "Syslog Server". Als "Syslog Server" wurde unter CentOS 5.x und/oder 6.x der integrierte "syslog" benutzt. Als ersten Schritt wird die FortiGate für den "Syslog Server" konfiguriert:

        <big>'''FortiGate Konfiguration'''</big>
        # config log syslogd setting
        # set status enable
        # set server [FQDN Syslog Server]
        # set reliable [Aktiviere TCP-514 Verbindung; Per Standard deaktiviert resp. UDP-514]
        # set port [Standard 514]
        # set csv [enable | disable]
        # set facility [Per Standard local0]
        # set source-ip [Source IP der FortiGate; Standard 0.0.0.0]
        # end
        
        # config log syslogd filter
        # set severity information
        # set fortward-traffic enable
        # set local-traffic enable
        # set multicast-traffic enable
        # set sniffer-traffic enable
        # set anomaly enable
        # set voip enable
        # unset filter
        # set filter-type include
        # end
        
        '''NOTE''' Achte bei der Konfiguraiton des "filter" darauf das die "severity" auf "information" gesetzt wird!

        <big>'''Syslog Server Konfiguration CentOS 5.x / 6.x'''</big>
        
        Als Erstes muss auf dem CentOS der "syslog" Server so konfiguriert werden, damit er von einem Remote Server "syslog" 
        Nachrichten überhaupt annimmt. Führe auf der Shell folgendes durch:
        
        # vi /etc/sysconfig/syslogd
        
        --------------- /etc/sysconfig/syslogd ---------------
        
        # Options to syslogd
        # -m 0 disables 'MARK' messages.
        # -r enables logging from remote machines
        # -x disables DNS lookups on messages recieved with -r
        # See syslogd(8) for more details
        SYSLOGD_OPTIONS="-m 0 '''-r'''"
        # Options to klogd
        # -2 prints all kernel oops messages twice; once for klogd to decode, and
        #    once for processing with 'ksymoops'
        # -x disables all klogd processing of oops messages entirely
        # See klogd(8) for more details
        KLOGD_OPTIONS="-x"
        #
        SYSLOG_UMASK=077
        # set this to a umask value to use for all log files as in umask(1).
        # By default, all permissions are removed for "group" and "other".
        
        --------------- /etc/sysconfig/syslogd ---------------
        
        '''NOTE''' Achte und aktiviere unter "SYSLOGD-OPTIONS" den Schalter "-r" denn dieser ist zuständig damit von "Remote" Syslog Nachrichten 
             entgegengenommen werden! Ist diese Option nicht gesetzt lehnt der "Syslog Server" auf dem CentOS die "syslog" Nachrichten von
             Remote ab!
        
        Nun legen wir ein neues Log File an und konfigurieren im "Syslog Server" welche Nachrichten entgegengenommen werden sollen. Zu diesem
        Zweck definieren wir die "facility" dh. "local0.*. Diese "facility" wurde ebenfalls auf der FortiGate als "local0" definiert. Durch die 
        Differenzierung über die "facility" können vers. Fortigate's diesem "Syslog Server" Nachrichten senden und somit die vers. Log's der
        FortiGate Device's unterschieden werden!
        
        # vi /etc/syslog.conf
        
        --------------- /etc/syslog.conf ---------------
        
        # Log all kernel messages to the console.
        # Logging much else clutters up the screen.
        kern.*                                                  /dev/console
        
        # Log anything (except mail) of level info or higher.
        # Don't log private authentication messages!
        local0.none;*.info;mail.none;authpriv.none;cron.none      /var/log/messages
        
        # The authpriv file has restricted access.
        authpriv.*                                              /var/log/secure
        
        # Log all the mail messages in one place.
        mail.*                                                  /var/log/maillog
        
        # Log cron stuff
        cron.*                                                  /var/log/cron
        
        # Everybody gets emergency messages
        *.emerg                                                 *
        
        # Save news errors of level crit and higher in a special file.
        uucp,news.crit                                          /var/log/spooler
        
        # Save boot messages also to boot.log
        local7.*                                                /var/log/boot.log
        
        # Save Fortigate log messages to fortigate.log
        local0.*                                                /var/log/fortigate.log
        
        #*.*                                                    @loghost
        
        --------------- /etc/syslog.conf ---------------
        
        '''NOTE''' Beachte bei der Konfiguration, dass die Leerschläge/Zwischenräume "gezwungenermassen" (Fileformat) Tabulatoren sein müssen! 
             Um das Format zu überprüfen kann folgender Befehl abgesetzt werden:
             
             # m4 -D LOGHOST /etc/syslog.conf
        
        Nun legen wir das entsprechende Log File an, dass der "Syslog Server" benutzt um die "local0" Nachrichten des FortiGate Device, in das 
        Log zu schreiben. Danach kann der "syslog" Service neu gestartetn werden um die Konfiguration zu aktivieren:
        
        # touch /var/log/fortigate.log
        # chmod 644 /var/log/fortigate.log
        # chown root:root /var/log/fortigate.log
        
        # service syslog stop
        # service syslog start
        
        Um das Log in "realtime" anzuschauen führe folgenden Befehl aus (um abzubrechen benütze Ctrl + C):
        
        # tail -f /var/log/fortigate.log

Die Konfiguration ist abgeschlossen dh. um die Konfiguration zu testen kann folgendes auf der FortiGate durchgeführt werden:

        # diagnose log test

Dieses Kommando erstellt Test Log Einträge für jeden Bereich wie Authentication, SSL-VPN, Antivirus usw. Diese Test Log Einträge werden nun durch die Konfiguration für "log syslogd setting" zum "Syslog Server" gesendet und sollten im entsprechenden Log File "/var/log/fortigate.log" ersichtlich sein. Kommt es dabei zu Problem und es muss verifiziert werden "ob" die Fortigate diese "syslog" Nachrichten überhaupt sendet resp. die Log's auf dem CenOS ankommen benütze folgenden Befehl:
          
        # tcpdump -nnp -i eth0 ip dst [Syslog Server IP] and port 514
          
Um das Log File "/var/log/fortigate.log" Täglich zu rotieren auf dem CentOS erstelle das folgende File:
            
        # vi /etc/logrotate.d/fortigate
        
        --------------- /etc/logrotate.d/fortigate ---------------
        
        /var/log/fortigate.log {
                rotate 30
                daily
                sharedscripts
                postrotate
                nomail
                        /usr/bin/killall -HUP syslogd
                endscript
        }
        
        --------------- /etc/logrotate.d/fortigate ---------------

Die Konfiguration kann getestet werden mit folgenden Befehl:

        # logrotate --force /etc/logrotate.d/fortigate

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device eine "Log Rotation" konfigurieren? ===

Die Voraussetzung das auf einem FortiGate Device eine "Rotation" für das Log konfiguriert werden kann ist ein "disk" Logging. Ob ein FortiGate Device über diese Möglichkeit verfügt kann der "Software Matrix" entnommen werden:

        [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]

Ein Log eines FortiGate Device's wird per Standard nicht "rotiert" dh. zum Beispiel auf täglicher Basis. Möchte man dies Konfigurieren führe folgendes durch:

        # config log disk setting
        # set status enable
        # set diskfull overwrite
        # set max-log-file-size [Max Grösse in MB bevor ein neues Log erstellt wird; Standard 20]
        # set log-quota [Grösse für gesamter Log Speicher; Standard 0]
        # set roll-schedule [daily oder weekly]
        # set roll-day [sunday | monday | tuesday | wednesday | thursday | friday | saturday]
        # set roll-time [Gebe die Zeit an im Format hh:mm]
        # set maximum-log-age [Gebe an nach wieviel Tagen ein Log gelöscht werden soll; Standard 7]
        # end

Berücksichtige dabei folgendes: Die Logs die "rotiert" werden können im Web Mgmt. Interface nicht explizit gewählt werden! Möchte man die Logs zusätzlich auf einen FTP Server überspielen siehe nachfolgenden Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_die_Logs_eines_FortiGate_Devices_automatisiert_einem_FTP_Server_.C3.BCbermitteln.3F]]

=== Wie kann ich unter FortiOS 5.4 die Logs eines FortiGate Devices automatisiert einem FTP Server übermitteln? ===

Wenn unter FortiOS 5.4 die Logs eines FortiGate Devices automatisiert auf einen FTP Server übermittelt werden soll, muss muss zuerst eine Log "Rotation" konfiguriert werden. Die nötige Voraussetzung damit dies durchgeführt werden kann ist ein "disk" Logging. Ob ein "disk" Logging für einen FortiGate Device zur Verfügung steht, kann der "Software Matrix" entnommen werden:

        [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]

Um eine Log "Rotation" zu konfigurieren siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_eine_.22Log_Rotation.22_konfigurieren.3F]]

Für die Konfiguration um die Logs automatisiert einem FTP Server zu übermitteln stehen folgende Optionen zur Verfügung:

        # set upload [Aktiviere oder Deaktiviere einen Upload der File anhand "enable oder disable"]
        # set upload-delete-files [Aktiviere oder Deaktiviere die Löschung der Logs lokal auf der Fortigate "nach" dem Upload anhand "enable oder disable"]
        # set upload-destination [Gebe das Ziel an für den Upload dh. "rortianalyzer oder "ftp-server"]
        # set upload-ssl-conn [Gebe an sofern ein FortiAnalyzer für den Upload benutzt wird wie Verschlüsselt werden soll dh. "default | high | low | disable"]
        # set uploaddir [Gebe das Upload Verzeichnis an in der Form zB /Log-Archiv/ ]
        # set uploadip [Wenn ein FTP Server benutzt wird für den Upload gebe die IP Adresse des FTP Server an]
        # set uploaduser [Wenn ein FTP Server benutzt wird für den Upload gebe den Usernamen des FTP Server an]
        # set uploadpass [Wenn ein FTP Server benutzt wird für den Upload gebe das Passwort des FTP Server an]
        # set uploadport [Wenn ein FTP Server benutzt wird für den Upload gebe den benutzten Port des FTP Server an]
        # set uploadsched [Aktiviere oder Deaktiviere den Upload zu einer bestimmten Zeit dh. anhand "disable | enable"]
        # set uploadtime [Definiert den Zeitpunkt (hh:mm) des Uploads sofern "uploadsched" aktiviert wurde]
        # set uploadtype [Gebe an "welche" File berücksichtigt werden; traffic | event | virus | webfilter | IPS | spamfilter | dlp-archive | anomaly | voip | dlp | app-ctrl | waf | netscan | gtp]
        # set uploadzip [Gebe an ob die Log Files "nach" dem Upload anhand ZIP Komprimiert werden sollen dh "disable | enable"]
        # set source-ip [Definiert die Source IPv4 Adresse für den Upload auf den FTP Server]
        
        '''NOTE''' Wenn "uploadsched" deaktiviert ist wird per Standard der Upload "nach" dem rotieren den Log Files ausgeführt!

Aus diesen zur Verfügung stehenden Optionen kann als Beispiel folgendes konfiguriert werden:

        # config log disk setting
        # set upload enable
        # set upload-delete-files disable
        # set upload-destination ftp-server
        # set uploaddir /log-archive/
        # set uploadip 193.193.135.65
        # set uploaduser local.intra
        # set uploadpass only4also
        # set uploadport 21
        # set uploadsched disable
        # set uploadtype traffic traffic event virus webfilter IPS spamfilter dlp-archive anomaly voip dlp app-ctrl waf netscan gtp
        # set uploadzip enable

Nach der Uebermittlung der Log Files auf den FTP Server werden diese in folgender Art und Weise auf dem FTP Server gespeichert (Beispiel Traffic Log):

        tlog.FGT60D3G12013754.root.20120927000000.zip

Bei diesem Vorgehen ist folgendes zu berücksichtigen: Werden Logs vom FortiGate Device auf den FTP Server übermittelt, gibt es keine Möglichkeit diese für zB einer Analyse auf den FortiGate Device wieder einzuspielen.

=== Wie beeinflusst unter FortiOS 5.4 das Kommando "system network-visibility" die Logs und die enthaltenen Informationen? ===

Das Kommando "system network-visibility" steht im Zusammehang mit der "Geo IP Location". Diese bedeutet: Werden diese Optionen aktiviert (ist per Standard der Fall) so werden betreffend den einzelnen enthaltenen Optionen wie zB "source" Geo Location Informationen in den Logs zu den IP's angezeigt/hinzugefügt:

        # config system network-visibility 
        # destination-visibility [enable | disable]
        # source-location [enable | disable]
        # destination-hostname-visibility [enable | disable]
        # hostname-ttl [Definiere TTL Standard 86400]
        # hostname-limit [Definiere Anzahl Hostname Limit Standard 5000]
        # destination-location [enable | disable]
        # end
        
        '''NOTE''' Wenn die Option "source-location" aktiviert wird so wird für "internal" Resourcen zB LAN anstelle der Geo Location die
             Information "reserved" in den Logs angezeigt. Ebenso steht das nachfolgenden Kommando im direkten Zusammenhang mit der
             "network-visibility" resp. muss aktiviert werden damit die Geo Location in den Logs angezeigt/hinzugefügt werden:
             
             # config log gui-display
             # set resolve-hosts [enable | disable]
             # end

=== Wenn ein Prozess "crashed" gib es unter FortiOS 5.4 ein Log das nähere Informationen enthält über den "crash"? ===

Nun wenn unter einem Linux/Unix System ein "crash" (Absturz) durch einen Prozess durchgeführt wird, dann führt das Betriebssystem - sofern konfiguriert - ein "dump" durch. Die Information des "dump" werden in ein "core" File geschrieben! Der gleiche Vorgang resp. in einer ähnlich Form wird auch auf einem FortiOS durchgeführt dh. das File in dem die Informationen geschrieben werden ist das "crashlog". Dieses kann auf der CLI anhand des nachfolenden Befehls eingesehen werden:

        # diagnose debug crashlog read

Dieses "crashlog" File kann ebenfalls zurückgesetzt resp. gelöscht werden. Dazu benütze folgenden Befehl:

        # diagnose debug crashlog clear

In diesem "crashlog" File sind Informationen enthalten über die "termination" resp. das benutzte Signal um einen Prozess zu beenden. Wird zB im "crashlog" File folgendes angezeigt wurde der Prozess mit dem Signal "11" beendet:

       application sslvpnd
       *** signal 11 (Segmentation fault)

Das Signal "11" wird als "Invalid memory refrence" definiert dh. Nachfolgend eine Liste verschiedenster Signale:

        4     Illegal instruction
        6     Abort command from FortiOS
        7     Bus error
        9     Unconditional kill
       11     Invalid memory refrence
       14     Alarm clock
       15     Graceful kill

Grundsätzlich werden diese "termination" Signal ebenfalls benutzt um einen Prozess zu beenden resp. neu zu starten (Kill Level). Dies ist jedoch nur dann durchzuführen wenn die Auswirkung 100% klar ist. Ein Prozess kann zB mit einem "termination" Signal 9 neu gestartet werden da der Level 9 ein Prozess unweigerlich beendet und diesen neu startet. Wird dies beim einem Prozess angewandt zB "cmdbsvr" so wird/kann die Konfiguration korrumpiert werden da dieser Prozess für die Konstistenz der Konfiguration sorgt. Nachfolgendes Beispiel zeigt wie anhand dieser "termination" Signale ein Prozess zB "ipsengine" gezwungen wird neu zu starten. Als erstes muss die PID (Process ID) des Prozesses "ipsengine" eruiert werden:

        # diagnose sys top
        Run Time:  9 days, 6 hours and 56 minutes
        3U, 7N, 0S, 90I; 1839T, 1406F
                 miglogd       55      S       7.8     1.3
                  newcli    12572      R <     1.4     0.8
               ipsengine      '''114'''      S <     0.0     3.8
                  httpsd      119      S       0.0     1.9
                  httpsd      162      S       0.0     1.9
                 pyfcgid    12531      S       0.0     1.4
                 pyfcgid    12532      S       0.0     1.4
                 pyfcgid    12533      S       0.0     1.4
                 cmdbsvr       38      S       0.0     1.4
                 pyfcgid    12529      S       0.0     1.4
               ipshelper       69      S <     0.0     1.2
                 sslvpnd       73      S       0.0     1.2
                  httpsd       57      S       0.0     1.1
                  httpsd      118      S       0.0     1.0
                  cw_acd      108      S       0.0     0.9
               forticron       66      S       0.0     0.9
                     wad       99      S       0.0     0.8
                   fgfmd      107      S       0.0     0.8
               scanunitd      110      S <     0.0     0.8
                  newcli    12561      S <     0.0     0.8

Die "ipsengine" läuft über die PID "114". Dieser Prozess zwingen wir nun einen Neustart auszuführen anhand des Signal 9 (Unconditional kill; Neustart erzwigen):

        # diagnose sys kill [Definiere das "termination" Signal zB "9"] [Definiere die PID für die ein "kill" ausgeführt werden soll zB "114"]

Es wird für dieses Kommando keine Rückmeldung ausgegeben dh. wenn das Kommando erfolgreich läuft nun die "ipsengine" über eine neue PID. Dies kann wiederum mit "sys top" überprüft werden:

        # diag sys top
        Run Time:  9 days, 6 hours and 57 minutes
        13U, 75N, 0S, 12I; 1839T, 1439F
               ipsengine    '''12574'''      R <    79.4     1.8
                 miglogd       55      S       7.8     1.3
                  newcli    12575      R <     1.4     0.8
                  httpsd      119      S       0.0     1.9
                  httpsd      162      S       0.0     1.9
                 pyfcgid    12531      S       0.0     1.4
                 pyfcgid    12532      S       0.0     1.4
                 pyfcgid    12533      S       0.0     1.4
                 cmdbsvr       38      S       0.0     1.4
                 pyfcgid    12529      S       0.0     1.4
               ipshelper       69      S <     0.0     1.2
                 sslvpnd       73      S       0.0     1.2
                  httpsd       57      S       0.0     1.1
                  httpsd      118      S       0.0     1.0
                  cw_acd      108      S       0.0     0.9
               forticron       66      S       0.0     0.9
                     wad       99      S       0.0     0.8
                   fgfmd      107      S       0.0     0.8
               scanunitd      110      S <     0.0     0.8
                  newcli    12561      S <     0.0     0.8  

Wir weisen nochmals daraufhin diese Art einen Prozess neu zu starten nur dann zu benutzen, wenn die Auswirkungen 100% klar sind. Regulär sollten immer die "build-in" Funktionen des FortiOS benutzt werden dh. wenn eine "ipsengine" neu gestartet werden sollte wäre folgender Befehl der Reguläre:

        # diagnose test application [Prozess- oder Applikationsname zB "ipsengine"] [Test Level zB für Neustart "99"]

=== Wie kann ich Lokale Logs unter FortiOS 5.4 von einem FortiGate Device auf einen USB Stick kopieren? ===

Damit Lokale Logs von einem FortiGate Device auf USB Stick kopiert werden können ist aktiviertes "disk" Logging Voraussetzung! Als Grundlage muss ein entsprechender USB Stick korrekt formatiert werden. Die einfachste Art ist die Formatierung über den FortiGate Device selber durchzuführen:

        # execute usb-disk format
        This operation will ERASE all data in USB disk!
        Do you want to continue? (y/n)y
        
        Format USB disk /dev/sdc1 ...
        Create file system on /dev/sdc1 ...

Weitere Informationen zur Formatierung eines USB Sticks der für einen FortiGate Device benutzt werden kann siehe nachfolgender Artikel:

        [[FortiGate-5.4:FAQ#Was_ist_unter_FortiOS_5.4_beim_Ben.C3.BCtzen_eines_USB_Sticks_an_eine_Fortigate_zu_ber.C3.BCcksichtigen.3F]]

Danach können die Logs über Mgmt. Web Interface oder über CLI auf den USB Stick kopiert werden. Dabei wird "Lz4" Komprimierung für die Logs die auf den USB Stick gespeichert werden benutzt! Sobald ein USB Stick der korrekt Formatiert wurde an einen FortiGate Device angeschlossen wird, steht unter FortiOS 5.4 über das Mgmt. Web Interface folgende Menüposition zur Verfügung:

        [[Datei:Fortinet-2054.jpg]]

Wenn dieses USB Symbole gewählt wird, so wird ebenfalls die Log Size angezeigt und anhand des Menüpunktes "Copy to USB" kann die Log Size resp. die Logs auf den USB Stick kopiert werden. Ueber die CLI können die Logs folgendermassen auf den USB Stick kopiert werden:

        # execute backup disk alllogs usb

Dieses Kommando kopiert alle verfügbaren Logs auf den USB Stick. Möchte man nur die Traffic Logs auf den USB Stick kopieren, führe folgendes aus:

        # execute backup disk log usb traffic

== CLI ==

=== Wie kann ich auf einer FortiGate "sämtliche" zur Verfügung stehenden Befehle/Konfiguration aufzulisten? ===

Die CLI einer FortiGate ist umfassend und ist Hierachisch strukturiert. Diese Hierachie kann auf einer FortiGate anhand des nachfolgenden Befehls ausgegeben werden um einen Ueberblick zu erhalten:

        # tree

Wenn dieser Befehl abgesetzt wird sollte dieser innerhalb eine SSH Verbindung abgesetzt werden und nicht innerhalb einer RS-232 Verbindung über den Mgmt. Port. Nachfolgend ein Beispiel des Output:

        Output basierend auf FortiOS 5.4.0 [[tree-5.4.0]]
        Output basierend auf FortiOS 5.4.1 [[tree-5.4.1]]

=== Kann ich unter FortiOS 5.4 Linux/Unix basierenden Befehl "grep" auf der Kommandozeile benützen? ===

Die Kommandozeile von FortiOS 5.4 ist keine Shell im klassischen Sinne! Dennoch kann "grep" benutzt werden um Informationen des Outputs zu durchsuchen. Wenn ein Befehl auf der Kommandozeile ausgeführt wird kann der Output anhand "pipe" ("|") in einen Zwischenspeicher geschrieben werden. Anhand der Anweisung "grep" kann danach dieser Zwischenspeicher durchsucht werden nach Informationen (Parsing). Ein Beispiel wäre zB folgendes:

        Wenn nachdem Login auf der Kommandozeile folgender Befehl eingegeben wird so zeigt Fortinet die gesamte Konfiguration an:
        
        # show

        Möchte man nun diesen Output der sehr lange sein kann nach einer bestimmten Information durchsuchen wie einer IP Adresse zB 
        192.168.1.1 kann folgender Befehl ausgeführt werden:
        
        # show | grep 192.168.1.1
        
        Der Output wird nun Zeile für Zeile gefiltert und nach "192.168.1.1" durchsucht. Alle Zeilen die diese Informatione enthalten
        werden als Resultat ausgegeben!

Zusätzlich stehen dem Befehl "grep" folgende Optionen zur Verfügung:

          Usage: grep [-invfcABC] PATTERN
          Options:
                  -i      Ignore case distinctions
                  -n      Print line number with output lines
                  -v      Select non-matching lines
                  -f      Print fortinet config context
                  -c      Only print count of matching lines
                  -A      Print NUM lines of trailing context
                  -B      Print NUM lines of leading context
                  -C      Print NUM lines of output context

=== Wie kann ich unter FortiOS 5.4 für einen FortiGate Device einen "daily-reboot" (Neustart) konfigurieren? ===

Bei Problemen in verschiedenster Art kann es vorkommen, dass man auf einem FortiGate Device einen "daily-reboot" durchführen resp. konfigurieren muss zB wenn durch einen "bug" ein FortiGate Device "high cpu" erreicht oder nach einiger Zeit eine hohe Auslastung zeigt. Einen "daily-reboot" als "die" Lösung zu konfigurieren kann jedoch keine Lösung sein. Jedoch diese Art als vorübergehende Lösung zu konfigurieren ist akzeptabel. Ein "daily-reboot" wird auf dem FortiGate Device folgendermassen konfiguriert:

        # config system global
        # set daily-restart [enable | disable]
        # set restart-time [Gebe die Zeit in hh:mm an für den Neustart zB "05:00"]
        # end

Zu dem definierten "restart-time" wird der FortiGate Device neu gestartet. Voraussetzung das dies zum definierten Zeitpunkt geschieht, ist das Zeit/Datum sowie die Zeitzone korrekt konfiguriert wurde. Wie dies durchzuführen ist siehe nachfolgende Artikel:

        [[FortiGate-5.4:FAQ#Wie_kann_ich_auf_einer_FortiGate_die_Zeit_sowie_das_Datum_.C3.BCberpr.C3.BCfe_sowie_konfigurieren.3F]]
        [[FortiGate-5.4:FAQ#Wie_kann_ich_auf_einer_FortiGate_unter_FortiOS_5.4_die_Zeitzone_konfigurieren.3F]]

Wird zum gegebenen Zeitpunkt der Neustart des FortiGate Devices durchgeführt wird in den entsprechenden Logs folgendes angzeigt:

        Console                   The system will reboot due to scheduled daily restart. Current time is 05:00
        Syslog                    5: 2009-09-21 05:00:00 log_id=0104041990 type=event subtype=admin pri=information fwver=040000 vd=root msg="Fortigate started"
        Gui Event Log             2 2009-09-21 05:00:00 information admin 41990     Fortigate started

=== Kann ich unter FortiOS 5.4 für einen FortiGate Device ein Script erstellen und dieses automatisch ausführen lassen? ===

Unter FortiOS 5 sowie 5.2 war es nicht möglich ein automatisiertes Script auf dem FortiOS zu konfigurieren. Unter FortiOS 5.4 ist dies nun möglich. Die Anwendungszwecke können dabei vielfälltig sein. Ein Script das konfiguriert wird besteht im einzelnen aus FortiOS CLI Kommandos dh. es können verschiedenen Kommandos nacheinander an ein Script hinzugefügt werden. Ebenso sind mehrer Scripts möglich. Die Konfiguration eines Scripts wird folgendermassen durchgeführt:

        # config system auto-script
        # edit [Name des Scripts zB "backup"]
        # set interval [Interval zur Ausführung des Scripts in Sekunden 0-4294967295 ; Beispiel 1 Tag 86400]
        # set repeat [Wiederholungs Interval 0-4294967295; 0 = Unendlich]
        # set start [manual | auto]
        # set script [FortiOS CLI Kommandos]
        # end
        
        '''NOTE''' Die effektive Zeit zur Ausführung des Scriptes kann nicht definiert werden dh. es steht nur "manual" oder "auto" zur
             Verfügung. Dies bedeutet: Nach Abschluss der Definierung des Scripts beginnt der "interval" in Sekunden zu laufen!
             Für die Position "script" können mehrere CLI Kommandos definiert werden. Dabei muss pro Zeile ein CLI Kommando definiert
             werden dh. um einen Zeilenumbruch durchzuführen benütze "Ctrl + Enter". Das "gesamte" Script resp. Kommandos müssen 
             innerhalb " " definiert werden. Folgendes Beispiel eines Backup Scripts auf TFTP Server mit zusätzlichen "system status:
             
             set script "get system status[Führe durch Ctrl + Enter]
             >execute backup full-config tftp [Pfad für TFTP zB /path] [IPv4 Adresse TFTP] ["Optional" Password für Backup File]"

Nach der Definition für unser Beispiel ergiebt sich folgende Konfiguration:

        # show system auto-script
        config system auto-script
            edit "backup"
                set interval 86400
                set repeat 0
                set start auto
                set script "get system status
        execute backup full-config /path 192.168.1.10 password"
            next
        end

Wenn das Script zum entsprechenden Zeitpunkt ausgeführt wird so wird das Resultat zB für "get system status" in ein "result" File geschrieben das den gleichen Namen trägt wie das Script selber dh. in unserem Beispiel "backup". Zu dieser Script Funktion stehen verschiedenen Optionen zur Verfügung um zB das "result" File einzusehen oder das Script manuell auszuführen:

        backup     backup
        delete     Delete output of executed scripts.
        result     Display output of executed scripts.
        start      Start script.
        status     List of scripts currently running or executed.
        stop       Stop script.
        stopall    Stop all scripts currently running.

Somit kann zB "result" des Scripts "backup" mit folgenden Befehl eingesehen werden. Nachfolgend ein Beispiel anhand des Kommandos "get system status":

        # execute auto-script result [Name des Scripts zB "backup"]
        ========== #0, 2016-01-05 19:56:14 ==========
        local-sg0e0 $  get system status
        Version: FortiGate-60D v5.4.0,build1011,151221 (GA)
        Virus-DB: 16.00560(2012-10-19 08:31)
        Extended DB: 1.00000(2012-10-17 15:46)
        IPS-DB: 6.00741(2015-12-01 02:30)
        IPS-ETDB: 0.00000(2001-01-01 00:00)
        Serial-Number: FGT60D4613048017
        IPS Malicious URL Database: 1.00001(2015-01-01 01:01)
        Botnet DB: 1.00000(2012-05-28 22:51)
        BIOS version: 04000022
        System Part-Number: P14482-03
        Log hard disk: Not available
        Hostname: local-sg0e0
        Operation Mode: NAT
        Current virtual domain: root
        Max number of virtual domains: 10
        Virtual domains status: 1 in NAT mode, 0 in TP mode
        Virtual domain configuration: disable
        FIPS-CC mode: disable
        Current HA mode: standalone
        Branch point: 1011
        Release Version Information: GA
        System time: Tue Jan  5 19:56:14 2016
        ========== #1, 2016-01-05 19:56:20 ==========

Ebenso kann der Status eines Scripts abgefragt werden:

        # exeute auto-script status
          backup <-- not executed yet; no result

Der "result" eines Scripts kann mit nachfolgenden Befehl zurückgesetzt werden resp. gelöscht werden:

        # execute auto-script delete backup

Zum Schluss muss folgendes erwähnt werden: Diese Script Funktion ist nicht als "backup" Script Funktion zu sehen sondern einfach ein hier gezeigtes Beispiel. Anhand dieses Scripts können zB Applikationen in definierten "interval" neu gestartet werden oder "cache" Informationen zurückgesetzt werden. Ebenso ist zu beachten, dass FortiOS CLI Kommandos nur dann funktionieren wenn diese nicht einen weitere Eingabe Voraussetzen wie zB "execute reboot".