Schlagwort-Archiv: Fortinet

Fortinet – ein bisschen Shell für alle

Auch Fortinet kocht nur mit Wasser und man kann einen eingeschränkten Blick hinter die Kulissen werfen:


FG100A############ # fnsysctl ls -al
drwxr-xr-x 14 0 0 Sun Oct 4 21:42:01 2015 320 .
drwxr-xr-x 14 0 0 Sun Oct 4 21:42:01 2015 320 ..
drwxr-xr-x 2 0 0 Sun Oct 4 21:41:44 2015 2740 bin
drwxr-xr-x 8 0 0 Sun Oct 4 21:41:56 2015 1024 data
drwxr-xr-x 2 0 0 Wed Sep 4 10:38:16 2013 40 data2
drwxr-xr-x 5 0 0 Sun Oct 4 21:42:21 2015 16920 dev
lrwxrwxrwx 1 0 0 Sun Oct 4 21:41:31 2015 8 etc -> data/etc
lrwxrwxrwx 1 0 0 Sun Oct 4 21:41:31 2015 1 fortidev -> /
drwx------ 2 0 0 Sun Oct 4 21:42:01 2015 40 ipc_quar
drwx------ 2 0 0 Sun Oct 4 21:42:01 2015 40 ipc_quar_backup
drwxr-xr-x 2 0 0 Sun Oct 4 21:41:32 2015 380 lib
drwxr-xr-x 38 0 0 Sun Oct 4 21:41:44 2015 2280 migadmin
dr-xr-xr-x 74 0 0 Sun Oct 4 21:41:27 2015 0 proc
drwxr-xr-x 2 0 0 Sun Oct 4 21:41:44 2015 60 sbin
drwxrwxrwt 9 0 0 Wed Oct 28 06:32:41 2015 2260 tmp
drwxr-xr-x 9 0 0 Sun Oct 4 21:42:01 2015 180 var

Fortigate: Firewall debuggen und sessions löschen

diag debug flow show console enable
diag debug flow filter addr 
diag debug enable
diag debug flow trace start 100

o.g. zeigt die nächsten 100 Flows wo die Adresse beteiligt ist.

den Filter kann man natürlich auch auf andere Sachen anwenden:

diagnose debug flow filter 
addr      IP address.
clear     Clear filter.
daddr     Destination IP address.
dport     Destination port.
negate    Inverse filter.
port      port
proto     Protocol number.
saddr     Source IP address.
sport     Source port.
vd        Index of virtual domain.

Achtung: Sessions werden gecacht, wenn man also den Aufbau sehen will muss man uU die bestehenden Sessions löschen, auch hier kann man per filter nur bestimmte löschen, statt alle Sessions wegzuschmeissen:
http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD31635

diagnose sys session filter ?
clear      clear session filter
dport      dest port
dst         dest ip address
negate    inverse filter
policy     policy id
proto      protocol number
sport      source port
src         source ip address
vd          index of virtual domain. -1 matches all

z.B.:

diagnose sys session filter src 10.160.0.1  10.160.0.10
diagnose sys session filter dport 80  888
diagnose sys session filter  session filter:
        vd: any
        proto: any
        source ip: 10.160.0.1-10.160.0.10
        dest ip: any
        source port: any
        dest port: 80-888
        policy id: any
        expire: any
        duration: any

mit

diagnose sys session list

sieht man die sessions, die den Filter matchen mit

diagnose sys session clear

löscht man die gematchten Sessions.

ACHTUNG: ohne einen Filter schmeisst ein clear ALLE sessions der FGT weg.

Fortigate: Debug eines bestimmten VPN Tunnels

Wenn man eine gut bestückte Fortigate hat muss man hin und wieder auch mal Fehler suchen.
Z.B. warum kommt ein VPN Tunnel nicht hoch.

Der „einfache“ Weg
diag debug enable
diag debug console
diag debug ike -1

gibt natürlich Daten über alle VPN Verbindungen, was schnell unübersichtlich wird.

Man kann das ganze aber auch beschränken um z.B. nur Daten für eine Gegenstelle oder eine Phase2 zu sehen:

Zur Auswahl stehen:
diag vpn ike log-filter
clear Erase the current filter.
dst-addr4 IPv4 destination address range to filter by.
dst-addr6 IPv6 destination address range to filter by.
dst-port Destination port range to filter by.
interface Interface that IKE connection is negotiated over.
list Display the current filter.
name Phase1 name to filter by.
negate Negate the specified filter parameter.
src-addr4 IPv4 source address range to filter by.
src-addr6 IPv6 source address range to filter by.
src-port Source port range to filter by.
vd Index of virtual domain. -1 matches all.

z.B.

diag vpn ike log-filter dst-addr4 10.10.10.10
diag debug enable
diag debug console
diag debug app ike -1

Fortigate: Zwei WAN Schnittstellen/ISPs nutzen, einen default Weg haben

Möchte man bei einer Fortigate zweit WAN Zugänge oder ISPs anschliessen, z.B. für Backup oder Lastverteilung kommt man zu dem Punkt: Wie geht das?

Szenario:
Einen Provider am WAN1 (schnelle Leitung)
zweiten Provider am WAN2 (langsamere Verbindung)

Wie kann man vorgehen?
Legt man zwei default Routen mit unterschiedlichen Metriken an ist nur die mit der besseren Metrik in der Routingtabelle, d.h. es wird nur die bessere Route genutzt, Verbindungen über die andere Leitung schlägt fehl (RPF wird das wohl verhindern).

Also trägt man zwei default Routen mit gleicher Metrik an!
Jetzt macht die Fortigate standardmäßig ECMP – also Lastverteilung. Beide Leitungen werden genutzt. Leider schert sich die Fortigate nicht um die Bandbreite (ggf kann man da in den aktuellen Versionen mit weightend ECMP was drehen), wird also recht fix die langsamere Leitung überlasten.

Die Lösung: Prioritäten für Routen. Das ist ähnlich wie Metriken, verhindert aber nicht das die Route aus der Routing Tabelle verschwindet. Sind zwei Routen zum Ziel da wird die mit der niedrigeren Priorität gewählt. bei gleicher Prio greift wieder ECMP.
Dadurch die Route in der Routing Tabelle vorhanden ist kann man Sessions über beide WAN Verbindungen aufbauen und mittel Policy Routing auch einzelnen Traffic über eine WAN Strecke forcieren (z.B. http Traffic über die langsamere Verbindung).

Die Prioritäten kann man nur über die CLI einrichten.
Beispiel:

config router static
show

Die entsprechenden Einträge anpassen
edit 1
" set device ""wan1"""
set gateway 192.168.1.100
set priority 1
next
edit 2
" set device ""wan2"""
set priority 5
set gateway 172.16.31.254
next

In diesem Fall würde der Traffic defaultmäßig über WAN1 gehen (niedrigere Priorität), aber eingehender Verkehr über WAN2 wird erlaubt. Fällt WAN1 weg geht der Verkehr über WAN2.

Natürlich muss man sich noch um passende VIPs/ACLs an den entsprechenden Interfaces kümmern und auch DNS im Hinterkopf behalten.

Die ASA von Cisco hat sowas meines Wissens nicht, es gibt immer nur eine aktive Defaultroute Loadbalancing kann sie nicht. Ein Failover kann man ggf mit SLAs.