Migrate Fortigate Configurations with FortiConverter

fortinet logo

Fortinet has published a very nice and helpful tool for converting firewall configs from other vendors into a Fortigate configuration file. Also an old Fortigate config file can also be used as the source file.

So if you are going to replace an old Fortigate model with a new one and you want use the old config file (instead of configuring the new Fortigate from the scratch) you can use the FortiConverter as an alternative to the procedure we have described in one of our former blog post „How to transfer a FortiGate configuration file to a new FortiGate unit of a different model“.

„Migrate Fortigate Configurations with FortiConverter“ weiterlesen

Problem beim Service-Transfer von Trade-Up Geräten

fortinet logo

In unserer Supportabteilung werden wir oft mit dem Problem konfrontiert, dass Trade-Up Fortinet-Geräte falsch registriert werden und damit wertvolle Services verloren gehen.

Zugegeben – das Ganze ist auch etwas kompliziert und deshalb möchten wir hier ein paar Infos zur Situation und zur Lösung des Problems geben:

Trade-Up Programm:

Fortinet-Kunden haben die Möglichkeit, End-of-order Geräte mit einem sehr netten Rabatt gegen ein neues Gerät einzutauschen. Hinsichtlich der FortiGuard-Services gibt es dabei zwei Varianten:

„Problem beim Service-Transfer von Trade-Up Geräten“ weiterlesen

Die Fortigate Cluster ID und allfällige Probleme mit dem ISP

fortinet logo

Das proprietäre FortiGate Clustering Protocol (FGCP) ist ein effektives und pragmatisches Clustering-Protokoll. Fortinet verzichtet dabei auf die Verwendung von dedizierten Interface-IPs und einer zusätzlichen Cluster IP pro Interface. Stattdessen wird pro Cluster-Interface mit nur einer IP gearbeitet und dafür aber mit einer eigenen virtuellen MAC-Adresse pro Cluster-Interface. Nur der Cluster-Master darf diese virt. MAC-Adresse nutzen, um produktiven Traffic zu senden (oder zu empfangen). Die phys. MAC-Adressen werden (ausser für spezielle Kommunikation im A/A-Cluster) nicht genutzt.

Folgendes Bild veranschaulicht das Prinzip: „Die Fortigate Cluster ID und allfällige Probleme mit dem ISP“ weiterlesen

FortiOS v5.4 CheatSheet

fortinet logo

Das Tech Team der BOLL Engineering darf bereits seit mehr als 14 Jahren Erfahrung im Troubleshooten der Fortinet Produkte, vornehmlich der Fortigates sammeln. Über alle Mitglieder gesehen kommen fast 50 Jahre Forti-Erfahrung zusammen.

Zusätzlich sind alle sechs Mitglieder des Teams NSE7 oder NSE8 zertifiziert!

Scheint fast so, als ob sich hier ein kleines Bündelchen an Wissen und Knowhow angesammelt hat.

Für uns ist das Grund genug, dieses Wissen ein wenig zusammen zu fassen und mit Euch zu teilen.

Ladet Euch doch unser praktisches FortiOS v5.4 CheatSheet herunter. Hier sind die wichtigsten CLI Befehle zum Troubleshooten der Fortigates unter v5.4 zusammen gefasst.

All members of the BOLL system engineering team have many years of experience in troubleshooting the Fortinet products – especially the Fortigates. Overall there are almost 50 years of experience in the team. Additionally all of the six team memerbs are NSE-7 or NSE-8 certified.

So it seems that there is a good deal of knowhow and competence at BOLL.
That’s reason enough to summarize all the important CLI commands that are so helpful in our daily work of troubleshooting.
And to share this stuff with you.

Please download our FortiOS v5.4 Cheatsheet!

WAN-Failover ist leicht gemacht. Aber warum funktioniert der Fallback nicht so ganz? Und vorallem – wie kann man das lösen?

fortinet logo

Auf den Fortigates ist es recht einfach, ein automatisches WAN-Failover zu konfigurieren, wenn man zwei ISP-Leitungen auf der Fortigate anbinden kann.

Durch die entsprechende Konfiguration der Distances und Priorities der Default Routen zu den beiden ISPs kann das Routing automatisch vom Haupt-ISP zum Backup-ISP wechseln, sobald die Anbindung zum Haupt-ISP aus irgendeinem Grund nicht mehr funktioniert. Wie das WAN-Failover konfiguriert wird, ist bestimmt geläufig. Der Vollständigkeit halber haben wir das im Anhang weiter unten noch einmal aufgeführt.

Über das so konfigurierte Failover werden Sessions automatisch auf den zweiten WAN-Link umgeleitet (oder genauer gesagt: über den zweiten WAN-Link neu aufgebaut), sobald der Haupt WAN Link nicht mehr zur Verfügung steht.

Doch was passiert, wenn der Haupt WAN-Link wieder zurück kommt? Eigentlich ganz einfach – neue Sessions werden automatisch wieder über die Haupt-Leitung ins Internet geroutet. Dieses passiert ebenfalls automatisch, ohne dass man manuell eingreifen muss.

Das Problem ist aber, dass das nur für „neue“ Sessions passiert – nicht aber für bestehende Sessions. Und das bekommen z.B. viele VoIP Nutzer leidvoll zu spüren. Diese bemerken nämlich, dass die VoIP Session auch lange nachdem die Hauptleitung wieder zurück kommt, immer noch über die Backup-Leitung läuft und dieses ohne manuelles Eingreifen (also das explizite Löschen der Session auf der Fortigate oder das Rebooten des internen Telefons) auch weiterhin tun wird.

Schauen wir uns das einmal genauer an.

„WAN-Failover ist leicht gemacht. Aber warum funktioniert der Fallback nicht so ganz? Und vorallem – wie kann man das lösen?“ weiterlesen

„Finger weg von HTTPS?“ – Ist SSL Interception fahrlässig?

fortinet logo

Kürzlich wurden wir von einem Reseller zu unserer Meinung zu folgendem Heise-Artikel gefragt: Sicherheitsforscher an AV-Hersteller: „Finger weg von HTTPS“.

Der Artikel klingt zugegebenermassen wirklich nicht gerade vertrauenserweckend. Die Fortigates sind im Artikel namentlich nicht benannt. Und eine Konfigurationsmöglichkeit haben wir auf der Fortigate hierfür auch nicht gefunden. So stellt sich natürlich die Frage, wie die Fortigate sich bei der SSL Interception genau verhält. Ist es „fahrlässig“ die SSL Interception („deep inspection“) der Fortigate zu aktivieren? Führt diese Konfiguration zu „dramatischen Sicherheitsproblemen“?

„„Finger weg von HTTPS?“ – Ist SSL Interception fahrlässig?“ weiterlesen