temuco
Goto Top

VPN-Anbindung zweier Netzwerke mit einer Fortigate 60C

Hallo!

Ich habe einige Male in diesem Forum Hilfe gesucht und fast immer eine sehr gute Unterstützung von euch erhalten. Dafür zunächst vielen Dank!

Nun habe ich den Auftrag bekommen, unsere Fortigate 60C so einzurichten, dass unser Netzwerk mit dem des Haupsitzes der Gesellschaft über VPN verbunden wird. Dazu habe ich einfach eine E-Mail mit folgenden Parametern erhalten (Adressen und Key entfremdet):

IPSec-Parameter

Gegenstelle: abc.def.ghi.jkl
Zielnetz: rst.uvw.xyz.0/24
PSK: ich-bin-der-key
Phase 1: 3des/sha1
DH-Gruppe: 5
Lifetime: 2160s

Phase 2: 3des/sha1
DH-Gruppe: 5

PFS DH- Gruppe: 5
Mode: main mode

Ich habe jetzt die FG-60C soweit konfiguriert, allerdings bin ich mir nich zu 100% sicher, ob das OK ist. Klar könnte ich jetzt mit der Zentrale testen, aber bevor ich das tue, würde ich gerne wissen, ob die Konfiguration in Ordnung ist. Ich möchte nämlich aus politischen Gründen vermeiden, die Zentrale zu verärgern – Wir hängen leider ganz am Ende der Kette face-sad

Folgendes habe ich gemacht:

VPN -> Auto Key (IKE)

  • Phase 1:

      • Name: VPN-Ph1
      • IP-Adress: abc.def.ghi.jkl
      • Local Interface: wan1
      • Mode: Main (ID Protection)
      • Pre-shared key: ich-bin-der-key
      • Encryption: 3DES/SHA1
      • DH Group: 5
      • Keylife: 2160s
      • XAUTH: Disable
      • NAT Transversal:Enable
      • Keepalive Frequency: 10s
      • Dead Peer Detection: Enable

  • Phase 2:

      • Name: VPN-Ph2
      • Phase 1: VPN-Ph1
      • Encryption: 3DES/SHA1
      • Replay Detection: Enable
      • Perfect Forward Secrecy (PFS): Enable
      • DH Group: 5
      • Keylife: 1800s
      • Autokey Keep Alive: Enable

Dann Habe ich im Bereich Firewall -> Firewall -> Address zwei Adressen definiert:

  • VPN-Local

      • Address: lmn.opq.rst.0/255.255.255.0
      • Interface: internal

  • VPN-Remote

      • Address: rst.uvw.xyz.0/255.255.255.0
      • Interface: wan1

Und schließlich eine ausgehende Regel im Bereich Firewall -> Policy -> Policy:

    • Source Interface/Zone: internal
    • Source Address: VPN-Local
    • Destination Interface/Zone: wan1
    • Destination Address: VPN-Remote
    • Schedule: always
    • Service: ANY
    • Action: IPSEC
    • VPN Tunnel: VPN-Ph1
    • Allow inbound: Enable
    • Allow outbound: Enable

Was mir nichts sagt und auch keine Entsprechung in der FG-60C fand, ist folgende Zeile in der erhaltenen E-Mail:

PFS DH-Gruppe: 5

Was ist PFS?

Die Zentrale verwendet eine andere´Firewall als Fortigate. Erst morgen ergahre ich, welche Marke und welches Modell.

Auf jeden Fall wäre ich euch sehr dankbar, wenn ihr die Einstellungen überprüfen könntet. Wie gesagt, als kleine Filiale haben wir es nicht leicht und wollen der Zentrale keinen Grund zum Meckern geben.

Im Voraus möchte ich mich bei euch herzlich bedanken.

Content-ID: 177025

Url: https://administrator.de/forum/vpn-anbindung-zweier-netzwerke-mit-einer-fortigate-60c-177025.html

Ausgedruckt am: 22.12.2024 um 17:12 Uhr

aqui
aqui 30.11.2011 um 08:34:14 Uhr
Goto Top
PFS DH beschreibt den Diffie Hellman Algorythmus zum Schlüsselaustausch:
http://en.wikipedia.org/wiki/Perfect_forward_secrecy
In der Regel musst du dir darüber keine Gedanken machen, da kümmert sich IPsec selber drum. Wichtig ist das remote lokale Netz und die öffentliche IP der gegenüberliegenden Firewall. Alles das hast du ja bekommen.
Deine Konfig sieht soweit sauber aus und sollte problemlos funktionieren mit deiner Zentrale !
temuco
temuco 01.12.2011 um 13:23:38 Uhr
Goto Top
Vielen Dank für deine Antwort.

Ich habe die Einstellungen mit Hilfe des Handbuches "FortiGate™ IPSec VPN" erneut überprüft und auch von einem Kollegen überprüfen lassen. Wir konnten dabei keine Unstimmigkeiten finden, so dass wir es heute der Zentrale mitgeteilt haben. Von ihr haben wir immer noch keine Antwort erhalten, dafür mehrere Meldungen der Fortigate, die immer paarweise auftreten. Hier ein Beispiel, wobei ich die Adressen verfremdet habe:

Message meets Alert condition
date=2011-12-01 time=11:24:36 devname=FGT60C3G11002764 device_id=FGT60C3G11002764 log_id=0101037128 type=event subtype=ipsec pri=error vd="root" msg="progress IPsec phase 1" action="negotiate" rem_ip=abc.def.ghi.jkl loc_ip=opq.rst.uvw.xyz rem_port=500 loc_port=500 out_intf="wan1" cookies="5e8486df30e924a6/0000000000000000" user="N/A" group="N/A" xauth_user="N/A" xauth_group="N/A" vpn_tunnel="VPN-Ph1" status=failure init=remote mode=main dir=inbound stage=1 role=responder result=ERROR

Message meets Alert condition
date=2011-12-01 time=11:24:36 devname=FGT60C3G11002764 device_id=FGT60C3G11002764 log_id=0101037124 type=event subtype=ipsec pri=error vd="root" msg="IPsec phase 1 error" action="negotiate" rem_ip=abc.def.ghi.jkl loc_ip=opq.rst.uvw.xyz rem_port=500 loc_port=500 out_intf="wan1" cookies="5e8486df30e924a6/0000000000000000" user="N/A" group="N/A" xauth_user="N/A" xauth_group="N/A" vpn_tunnel="VPN-Ph1" status=negotiate_error error_reason=peer SA proposal not match local policy peer_notif=NOT-APPLICABLE

"abc.def.ghi.jkl" ist die öffentliche Remotadresse der Zentrale
"opq.rst.uvw.xyz" ist unser öffentliche IP-Adresse

Wie es aussieht, kommt keine Verbindung zustande. Die zweite Meldung sagt "peer SA proposal not match local policy", hilft mir aber nicht wirklich weiter, denn ich wüsste nicht, was an der einzigen angelegten (ausgehende) Policy falsch sein sollte. Hier diese nochmals:

    • Source Interface/Zone: internal
    • Source Address: VPN-Local
    • Destination Interface/Zone: wan1
    • Destination Address: VPN-Remote
    • Schedule: always
    • Service: ANY
    • Action: IPSEC
    • VPN Tunnel: VPN-Ph1
    • Allow inbound: Enable
    • Allow outbound: Enable

Ich warte natürlich auf die Zentrale, kann mir aber gut vorstellen, dass die alles richtig gemacht haben und wir hier unten die Fehler verursachen...

Gibt es sonst was, was ich noch überprüfen sollte oder hast du mir einen Tipp, wie hier vorgehen? Vielleicht hat aber auch die Zentrale einen Fehler gemacht, aber woran kann ich das erkennen?

Nochmals vielen Dank für deine Hilfe!

Herzliche Grüße

temuco
aqui
aqui 01.12.2011 um 14:01:20 Uhr
Goto Top
Das ist ein Phase 1 Negotiation Error ! Der Tunnel kommt gar nicht erst zustande schon in der Anfangsphase.
Ist bei euch oder in der Zentrale noch irgendwo ein NAT Router zwischen Internet und Firewall oder "sehen" sich beide Firewalls direkt mit einer öffentlichen IP Adresse ?? Die Fehlermeldung deutet eher auf ein NAT Problem.
Wichtig wäre auch mal das Errorlog aus der Zentrale.
temuco
temuco 01.12.2011 um 14:27:30 Uhr
Goto Top
Bei uns ist kein NAT-Router dazwischen geschaltet. Die FG hängt direkt am Internet.

Bei Phase 1 ist NAT Transversal abgehackt. Macht das vielleicht Probleme? Ich dachte aber, es müsste eigentlich so sein. Wenn nicht, dann habe ich was missverstanden.

Die Einstellungen von Phase 1 findest du hier:

http://www.temuco.de/temp/phase1.png

Edit: Wo bleiben meine Manieren? Entschuldige! Ich vergaß mich zu bedanken, was ich hiermit nachhole.

_______________________________________

Wie kann ich hier Bilder laden, damit diese im Beitrag direkt sichtbar sind?
aqui
aqui 01.12.2011 um 15:05:36 Uhr
Goto Top
Was meinst du mit "abgehackt" ??? Kommen die Fehlermeldungen abgehackt an oder die Pakete nicht vollständig ??? Das ist irgendwie unverständlich.
Wenn du einen HW Paket Loss da hast hast du ein ganz anderes Problem...
Einne Fehler hat deine o.a. Konfig.
Du solltest zwingen den Agressive Mode aktivieren wenn du auf einen andere FW gehst ! Das solltest du also ändern !
Der Rest ist soweit OK und kann so bleiben !
Bitte keine externen Bilderlinks !!

Wenn du auf "Meine Beiträge" gehst, deinen obigen Beitrag anklickst und auf "Bearbeiten" klickst siehst du dort den Bilder Upload Knopf.
Den klicken, das Bild hochladen und den dann erscheinenden Bilder URL mit einem Rechtsklick cut and pasten.
Den URL kannst du dann in jeglichen text hier bringen sei es Antworten PMs usw. Es erscheint dann immer das Bild !
So einfach ist das....!
temuco
temuco 01.12.2011 um 15:29:14 Uhr
Goto Top
Zitat von @aqui:
Was meinst du mit "abgehackt" ??? Kommen die Fehlermeldungen abgehackt an oder die Pakete nicht vollständig ??? Das
ist irgendwie unverständlich.

Habe mich verschrieben, entschuldige! Ich meine, dass die Option "NAT Transversal" angehakt ist, also enabled bzw. aktiviert. Das siehst du auch am Bild, wo ich diese Option extra als Hervorhebung eingekreist habe.

Muss die Aktivierung von "Aggressive Mode" an beiden Firewalls vorgenommen werden?

Nun bin ich dabei, meine Defizite in diesem Bereich ein wenig auszubügeln, was mit Sicherheit auch lange dauern wird, aber ich auch gerne mache. Dabei wird immer wieder vom "Aggressive Mode" abgeraten, da dieser angeblich nicht sicher genug sei. Ich werde mich damit weiter auseinandersetzen, aber möchte ich diesbezüglich dennoch eine Frage stellen: Birgt dieser Modus wirklich Sicherheitsrisiken, auch wenn man einen sehr komplexen PSK verwendet?

Ach ja, danke auch für den Hinweis auf die Bilder!

temuco
harald21
harald21 01.12.2011 um 15:36:53 Uhr
Goto Top
Hallo zusammen,

deine Config schaut soweit ganz gut aus - wenn am anderen Ende ebenfalls eine Fortigate steht.
Falls du am anderen Ende eine "Fremdfirewall" hast, so solltest du in der Phase2 noch Source- und Destination-Subnetze definieren (nach einem Klick auf "Advanced").

Nun zu den Details der Phase1:
- Wenn ihr (Zentrale und Außenstelle) feste IP's habt, so könnt ihr den Main Mode verwenden, bei DynDNS-Records dann den Aggressive Mode.
- Die Parameter sollten natürlich auf beiden Seiten des Tunnels identisch sein (PSK, Encryption, Authentication, DH-Group, Keylife und DPD)
- Welche Firmware verwendest du (die FGT-60C ist hier sehr sensibel), ich würde FortiOS 4.00 MR2patch9 empfehlen.

mfg
Harald
temuco
temuco 01.12.2011 um 15:59:24 Uhr
Goto Top
Hallo Harald,

vielen Dank für die Hilfe. Ich versuche, die Fragen zu beantworten:

Die Zentrale verwendet eine Firewall eines anderen Herstellers. Nun habe ich unter Phase 2 5 Felder, die ich bisher nicht beachtet hatte (Standardwerte in Klammern):

  • Source address (0.0.0.0/0)
  • Source Port (0)
  • Destination address (0.0.0.0/0)
  • Destination Port (0)
  • Protocol (0)

Welche Adressen, Ports und Protokolle sind hier gemeint? Die öffentlichen IP-Adressen oder die internen (unser Netz und das der Zentrale)? Und welche Ports? Etwa 500? Und Protokoll? – Ich sehe es schon, viel zum Nachlesen und verstehen...

Zu den Details der Phase 1:

  • Wir haben feste IP-Adressen d. h. doch Main- anstelle von Aggressive-Mode, wie von "aqui" vorgeschlagen. Richtig?

  • Die Parameter sollte gleich sein. Ich habe von der Zentrale diese erhalten und in die Fortigate eingetragen.

  • Die FG meldet mir folgende Firmware: "v4.0,build5367,101109 (MR2)"

Nochmals danke für die Hilfe!

temuco
harald21
harald21 02.12.2011 um 15:44:50 Uhr
Goto Top
Hallo temuco,

Source address = dein interner IP-Adressbereich (z. B. 192.168.2.0/24)
Pource Port = 0 (any)
Destination address = der interne IP-Adressbereich der Zentrale (z. B. 192.168.1.0/24)
Destination Port = 0 (any)
Protocol = 0 (any)

FortiOS 4.00 build 5367 ist sehr alt und fehlerbehaftet.
Die aktuellste stabile Version ist FortiOS 4.00 MR2patch9 (build 334). Die Firmware für die FGT-60C wird aus einem speziellen Ebntwicklungszweig erstellt, deshalb ist hier die build 5875.

Gib einfach mal auf der Konsole "get system status" ein und poste das Ergebnis hier.

mfg
Harald
temuco
temuco 02.12.2011 um 16:25:16 Uhr
Goto Top
Hallo Harald,

vielen Dank für deine Geduld. Hier die Daten:

Version: Fortigate-60C v4.0,build5367,101109 (MR2)
Virus-DB: 14.00423(2011-12-01 23:28)
Extended DB: 0.00000(2001-01-01 00:00)
IPS-DB: 3.00115(2011-11-30 16:49)
FortiClient application signature package: 1.444(2011-12-02 11:25)
Serial-Number: FGT60C3G11002764
BIOS version: 04000010
Log hard disk: Available
Internal Switch mode: switch
Hostname: FGT60C3G11002764
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
Distribution: International
Branch point: 291
Release Version Information: MR2
System time: Fri Dec 2 16:23:22 2011


Grüße

temuco
temuco
temuco 02.12.2011 um 16:39:36 Uhr
Goto Top
Nachtrag:

Was ist mit der Option "NAT Transversal"? Zwischen der FG und unserem Netz sitz kein NAT-Gerät mehr. Sollte man sie nicht abwählen?
harald21
harald21 05.12.2011 um 08:10:27 Uhr
Goto Top
Hallo,

die Zeile "Branch point: 291" zeigt, das du noch ein FortiOS 4.00 MP2 Patch2 installiert hast. Du solltest wirklich dringend updaten. Beim Wechsel auf eine neue Firmware innerhalb einer MR-Serie ändern sich die Konfigurationsoptionen nicht, deshalb kannst du direkt von 4.00 MR2p2 auf 4.00 MR2p9 aktualisieren.
Mach zur Sicherheit aber trotzdem zuerst ein Backup deiner Config. Auf FortiOS 4.00 MR3 (aktuell MR3patch3) solltest du aber noch nicht updaten, die MR3-Serie ist noch zu instabil.

"NAT Traversal" kannst du problemlos aktiviert lassen..

mfg
Harald
temuco
temuco 06.12.2011 um 11:00:12 Uhr
Goto Top
Hallo Harald,

vielen Dank nochmals. Ich konnte nicht antworten, da ich etwas gestresst war/bin. Ich werde die Firmware updaten, entweder heute Abend oder am Wochenende.

Leider kann ich nicht viel berichten, da wir noch keine Antwort von der Zentrale erhalten haben. Lediglich gestern fanden wieder ein Paar Versuche statt, den Logs nach aber erfolglos. Hier ein Auszug, wobei beide Meldungen immer paarweise erscheinen:

Message meets Alert condition
date=2011-12-05 time=11:00:00 devname=FGT60C3G11002764 device_id=FGT60C3G11002764 log_id=0101037128 type=event subtype=ipsec pri=error vd="root" msg="progress IPsec phase 1" action="negotiate" rem_ip=abc.def.ghi.jkl loc_ip=opq.rst.uvw.xyz rem_port=500 loc_port=500 out_intf="wan1" cookies="825d711e0c337e0b/0000000000000000" user="N/A" group="N/A" xauth_user="N/A" xauth_group="N/A" vpn_tunnel="VPN-Ph1" status=failure init=remote mode=main dir=inbound stage=1 role=responder result=ERROR

Message meets Alert condition
date=2011-12-05 time=11:00:00 devname=FGT60C3G11002764 device_id=FGT60C3G11002764 log_id=0101037124 type=event subtype=ipsec pri=error vd="root" msg="IPsec phase 1 error" action="negotiate" rem_ip=abc.def.ghi.jkl loc_ip=opq.rst.uvw.xyz rem_port=500 loc_port=500 out_intf="wan1" cookies="825d711e0c337e0b/0000000000000000" user="N/A" group="N/A" xauth_user="N/A" xauth_group="N/A" vpn_tunnel="VPN-Ph1" status=negotiate_error error_reason=peer SA proposal not match local policy peer_notif=NOT-APPLICABLE

Ansonsten habe ich Phase 2 um die von dir empfohlenen Parameter erweitert (Source/Destination Adrdess/Port Protocol).

Nochmals herzlichen Dank und ich werde mich mit Sicherheit nochmals melden.

Grüße

temuco
temuco
temuco 06.12.2011 um 17:51:57 Uhr
Goto Top
Nun habe ich keine Ahnung, was die Gegenstelle gemacht hat, aber seit heute steht der Tunnel – die Kommunikation (nicht die technische) könnte besser sein und sie ist verbesserungswürdig...

Ich möchte mich daher herzlich bei allen bedanken, die mir hier geholfen haben.

Grüße

temuco
harald21
harald21 07.12.2011 um 22:50:19 Uhr
Goto Top
Hallo,

als Nachtrag: Falls es dich interessiert, was die Ursache war:

1. Laut deinen Logs war der Fehler in der Phase 1 (msg="IPsec phase 1 error")
2. Du kannst auf der Fortigate das erweiterte Debugging anstellen, um die Details der IPSec-Negotiation nachzuverfolgen:
a) Du verbindest dich am Besten per SSH auf der CLI (z. B. mit Putty). Dabei solltest du das Logging in Putty aktivieren, da der Output sehr schnell mehrere Bildschirmseiten ausmachen kann, so kannst du später im Putty-Log in Ruhe nachlesen, was denn da eigentlich passiert ist.
b) Auf der Console gibst du nacheinander die Befehle ein "diag vpn ike log-filter dst-addr4 <IP Adresse der Gegenstelle>" "diag deb app ike -1" und abschließend "diag deb enable"
c) Wenn du das Debugging wieder deaktivieren willst, gibst du die folgenden Befehle ein "diag deb disable" (Einfach drauflos tippen, auch wenn der Bildschirminhalt weiterscrollt) und danach "diag deb reset"

mfg
Harald
temuco
temuco 09.12.2011 um 11:15:52 Uhr
Goto Top
Vielen Dank! Wirklich nett, dass du deine Zeit für andere opferst.

Um nicht ständig hier reinfunken zu müssen, würde ich gerne wissen, ob es eine Wissensdatenbank von Fortigate gibt, die die Fehler richtig erklärt. Ich habe zwar eine Auflistung aller Fehler gefunden, allerdings ist deren Aussagekraft nicht größer als die der Fehlermeldungen – es steht im Grunde genommen dasselbe.

Ich frage deswegen, denn ich bekam heute erneut Fehlermeldungen:


Message meets Alert condition
date=2011-12-08 time=09:46:54 devname=FGT60C3G11002764 device_id=FGT60C3G11002764 log_id=0101037136 type=event subtype=ipsec pri=error vd="root" msg="IPsec DPD failure" action="dpd" rem_ip=w.x.y.z loc_ip=a.b.c.d rem_port=500 loc_port=500 out_intf="wan1" cookies="da9070827b7efb44/f13689fcb7017d90" user="N/A" group="N/A" xauth_user="N/A" xauth_group="N/A" vpn_tunnel="VPN-Ph1" status=dpd_failure

und

Message meets Alert condition
date=2011-12-09 time=10:52:20 devname=FGT60C3G11002764 device_id=FGT60C3G11002764 log_id=0101037131 type=event subtype=ipsec pri=error vd="root" msg="IPsec ESP" action="error" rem_ip=w.x.y.z loc_ip=a.b.c.d rem_port=500 loc_port=500 out_intf="wan1" cookies="68ffa32609c36765/3a9c077e9ed2e503" user="N/A" group="N/A" xauth_user="N/A" xauth_group="N/A" vpn_tunnel="N/A" status=esp_error error_num=Received ESP packet with unknown SPI. spi=9eb41f3b seq=00000001

Danach steht der Tunnel aber wieder.

Im Übrigen sehe ich sehr viele Events, die die FG protokolliert. Ist das in Ordnung so oder läuft da was falsch?

235b193c1042823d43dec8d7ed2f983c

Auf jeden Fall vielen Dank!

temuco
harald21
harald21 12.12.2011 um 11:35:20 Uhr
Goto Top
Hallo,

Infos findest du hier:

1. Die offizielle Doku: http://docs.forticare.com/fgt.html
2. Die Knwoledgebase: http://kb.fortinet.com/kb/microsites/microsite.do
3. Das Forum: http://support.fortinet.com/forum/default.asp
3. Die Support-Seite: https://support.fortinet.com/Login/UserLogin.aspx

Das ab und zu Fehler auftreten ist eigentlich normal (je nach Stabilität der Netzwerkverbindungen der beiden VPN-Partner).
Noch eine abschließende Bemerkung: Für das Memory-Log solltest du eine höhere Log-Schwelle einstellen (.B. Warning) ansonsten wird zuviel RAM für das Logging benutzt.

mfg
Harald
temuco
temuco 15.12.2011 um 10:16:54 Uhr
Goto Top
Vielen Dank für deine Hilfe, die mir wirklich weitergeholfen hat. Auch die Memory-Logs habe ich runter auf "Warning" gestellt. Nun funktioniert bisher alles gut und ohne Probleme. Auch ein Dank an "aqui" (heißt das nicht "hier" in Spanisch?).

Herzliche Grüße

temuco