[Problem] FortiGate hinter FB7390 -> VPN Problem

[Zeihold_von_SSL]

Hallo zusammen,

ich habe ein kleines Problem.

Ich habe Zuhause an meinem ADSL2+ Anschluss (ein reiner IP Anschluss der DTAG) eine FritzBox 7390 (als Telefonanlage und für Telekom IPTV) angeschlossen. WLAN z.B. ist abgeschaltet. DynDNS wird von der FritzBox erledigt. An einem der LAN Interface (ich glaube NR. 1) hängt nun eine richtige Firewall (FortiWifi 60C von Fortinet).

Diese Box erhält wahlweise per DHCP, per DHCP Reservierung oder eben feste IP-Adresse Verbindung zur FritzBox und somit zum Internet.

In der FritzBox ist die Fortigate Box als Exposed Host eingetragen um z.B. das Webfrontend der Fortigat Box über das Internet erreichbar zu machen UND (so war zumindest der Plan) um eine IPSec VPN Verbindung in unsere Firma aufzubauen.

Die Fortigate ist so konfiguriert, dass Sie als dynamischer IPSec Client arbeitet und sich mit dem "Server" in unserer Firmenzentrale verbindet.

NAT-T ist auch auf beiden Seiten supportet und eingeschaltet.

Ich Log der Box sehe ich auch, dass Sie versucht über Port 4500 mit dem Server zu kommunizieren. Allerdings wird der Tunnel nicht aufgebaut.

Die gleiche Konstellation (identische Konfiguration) fahren wir auch bei einem Kollegen in Österreich an einem Kabelanschluss. Dort kommt jedoch ein Cisco WLAN Router (mit integriertem Kabelmodem) zum Einsatz. Dort wird der Tunnel erfolgreich aufgebaut.

Daher schließe ich momentan darauf, dass es ein Problem mit der FritzBox gibt.

Ist Bekannt ob die FritzBox eventuell hier Probleme hat und falls ja wie man das erledigen kann?

Ich finde zwar immer wieder Artikel die sich über IPSec Probleme beschweren, meist lag/liegt dies aber eben daran, dass NAT-T nicht verwendet wird.

Doch wir nutzen NAT-T ganz sicher. Trotzdem haben wir Probleme mit der Verbindung.

Daher würde mich freuen, wenn mir jemand auf die Sprünge helfen könnte.

Vielen Dank im voraus.

René

 

[doc456]

Hallo,

kommst du denn auf das Webinterface der Fortinet?

Die Forti sollte zudem immer eine feste IP haben.

EDIT: ach noch was, wo hast du das LAN-Kabel an der Fortinet verbunden? An WAN1?

 

[Zeihold_von_SSL]

Hallo,

kommst du denn auf das Webinterface der Fortinet?

Die Forti sollte zudem immer eine feste IP haben.

Ja ich komme dank "Exposed Host" sowohl auf das Webinterface als auch per SSH an die Box. Prinzipiell auf per Fortimanager.

Der Forti ist es prinzipiell egal ob Sie eine feste IP hat oder nicht. Lediglich bestimmte Features wie HA verbieten halt eine dynamische IP an bestimmten Interfaces bzw. generell.

Für die Einsatzzwecke als VPN Zugang für unsere Außenstellen ist das aber prinzipiell kein Problem. Ich gebe dir allerdings recht, dass es kein guter Stil ist.

Normalerweise haben auch alle unsere Fortis eine feste IP-Adresse auf WAN Seite. Unabhängig ob Sie direkt am Internet hängen (geht halt bei DSL Anschlüssen nicht bzw. nicht immer) oder
ob Sie wie in diesem Fall hinter einem anderen Router hängen.

Ich wollte oben nur verdeutlichen, dass das Problem unabhängig davon auftritt ob die Forti eine IP von der FritzBox per DHCP bezieht bzw. eine feste IP-Adresse am WAN Interace eingestellt hat.

Gruß
René

 

[doc456]

Ok, es scheint dann so, das z.B. GRE nicht an die Forti weitergegeben wird, denn es läüft ja über den DynDNS der FritzBox.

Leite das Protokoll GRE (47) mal an die Forti, eventuell noch 50 (ESP) und 51 (AH). Wobei 51 nicht NAT-fähig ist, aber als exposed Host müßte es funktionieren...

 

[Zeihold_von_SSL]

Das hatte ich alles schon gemacht.

Ich habe damals (ist schon ein paar Monate her) angefangen nur die Forti als Exposed Host zu betreiben. Da das nicht funktioniert hat habe ich tatsächlich GRE, ESP sowie die Ports 500 und 4500 sowie 50 und 51 an die Forti explizit weiter zu leiten.
Alles bisher ohne Erfolg. Dann dachte ich es läge ggf. an der Forti Firmware bzw. an der der FritzBox. Bei der FritzBox bin ich auf der aktuellsten. Bei der Forti habe ich von OS 4 MR2 Patch XX über OS4 MR3 Patch XX bis zum aktuellen Release Candidate 2 von OS5 alles ausprobiert ohne Änderung (bin in der Beta Test Gruppe für OS5).

Wie gesagt läuft die identische FortiKonfig in Österreich hinter einem Kabelmodem einwandfrei. Die anderen Außenstellen die wir haben nutzen alle noch echte Kabelmodems (also ohne NAT und Co). Daher sind die nicht vergleichbar und die dortigen Fortis laufen daher auch mit einem "echten" Site-to-Site VPN Tunnel.

Deswegen bin ich ja so perplex wieso es hier an einem DSL Anschluss mit einer FritzBox nicht geht. Nehme ich anstatt der FritzBox ein popliges ADSL2+ Modem geht das einwandfrei. Nur leider dann eben auch kein Telefon und IPTV (weshalb ich so ungerne auf die Fritzbox verzichte).

Daher auch meine Frage ob bekannt ist, dass es mit den Boxen bei IPsec Passthrough Probleme gibt...

 

[doc456]

Hmmm...., merkwürdig.

Was meinst du mit "dynamischer IPSec Client"? Wechselnde Keys?

Na ja, du arbeitest ja nicht mit dem VPN der FritzBox, sondern du leitest ja eigentlich nur an die Forti weiter. Von daher hat die Fritz nichts mit IPsec Passthrough zu tun...

M.M. nach solltest du auf deinem Server mal das Log prüfen.

 

[Zeihold_von_SSL]

Ja, merkwürdig trifft es in diesem Fall gut.

Die Forti unterstützt 3 grundsätzliche Modi für IPSec VPN. Einmal "Static IP-Address" dann "Dynamic DNS" und "Dialup User".

Static IP Address wird verwendet wenn die Gegenstelle eine feste IP-Adresse hat (und nicht genanntet ist!). In der Regel nur in Verbindung mit reinen Site to Site Verbindungen.

Dynamic DNS wird dann verwendet wenn die Gegenstelle eine wechselnde IP-Adresse hat (aber nicht genanntet ist!). In der Regel nur in Verbindung mit reinen Site to Site Verbindungen.

Dialup User wird verwendet, wenn die Gegenstelle a) dynamische IP-Adressen verwendet und b) hinter einem Device sitzt das NAT-T macht. Außerdem kann man hiermit sowohl Site-to-Site Verbindungen aufbauen (wie von mir gewünscht) oder auch mehrere mobile Clients (unter Verwendung des zusätzlichen xAuth Systems) anbinden. Es dient also für Site to Site Verbindungen als auch für Client to Site Verbindungen.

Die Gegenstelle in der zentrale ist also als "Dialup User" konfiguriert. Meine FortiGate die hinter der FritzBox betrieben wird ist als "Static IP-Address" konfiguriert.

Um einen vollwertigen Debug auf beiden Seiten werde ich wohl nicht rum kommen. Wollte mir nur die Arbeit ersparen wenn klar ist, dass das Problem auf AVM Seite liegt.

Ich melde mich wieder sobald ich es zeitlich geschafft habe das IKE Debug laufen zu lassen.

 

[doc456]

Hallo,

Meine FortiGate die hinter der FritzBox betrieben wird ist als "Static IP-Address" konfiguriert.

da liegt imho dein Problem. Stell doch testweise auf "Dynamic DNS"...

 

[Zeihold_von_SSL]

Nein, das ist es sicher nicht. Die Fortinet werden immer mit Blick auf ihre Gegenstelle konfiguriert.

Die Box in der Unternehmenszentrale (die am Company Connect Anschluss mit ferster IP hängt) wird also als "Dialup User" konfiguriert (Dynamic DNS geht nicht, denn sonst kriegt Sie die statt der offiziellen IP die IP mit die die kleine Fortigate von der Fritzbox erhalten hat).
Die Box hinter der FritzBox wird als "Static IP-Address" konfiguriert da ihre Gegenstelle (in der Unternehmenszentrale) eine feste IP.Adresse verwendet.

 

[doc456]

(Dynamic DNS geht nicht, denn sonst kriegt Sie die statt der offiziellen IP die IP mit die die kleine Fortigate von der Fritzbox erhalten hat).

Hmmm..., aber so ist das doch gedacht, denn deine DynDNS-IP (deine öffentliche IP) wird doch durch die Fritzbox gehandelt und wie soll denn dann eine Verbindung etabliert werden, wenn der Weg zurück nicht bekannt ist?

 

[Zeihold_von_SSL]

Nein, das Feature "Dynamic DNS" ist zumindest auf Fortinet Seite so gedacht, dass die Fortigate selbst DynDNS macht.

Denn sonst klappt der Handshake nicht. Die FritzBox muss ja zwingend DynDNS machen. Andernfalls würde die Fortigate
die Adresse ihres WAN Interfaces an den DynDNS Account melden (was in diesem Fall der privaten RFC Adresse 192.168.X.X entspricht).

In jedem Fall schickt die Fortigate aber bei Dynamic DNS IPSec die IP-Adresse ihres IPSec Interaces (in meinem Fall WAN1 und somit die private RFC Adresse) und den DynDNS Namen
als Authentifizierungsparameter beim Verbindungsaufbau mit.

Die Fortigate in der Zentrale vergleicht nun ob die IP-Adresse im Verbindungsaufbau mit der IP-Adresse die bei einer Reverse Auflösung des DynDNS Namens raus kommt.

Sind die Werte nicht identisch wird der Verbindungsaufbau gedroppt.

Das ganze ist also so definitiv richtig.

Vor allem für die Box hier hinter der Fritzbox. Sie verhält sich so wie ein beliebiger Software Client.

 

[doc456]

Na dann bin ich mal auf das Debug-Log gespannt...

 

[Zeihold_von_SSL]

So, da ich gestern in den Abendstunden noch eine Wartung mit unserem externen Network und Security Consultant gemacht habe, haben wir uns auch dieses Thema noch einmal angeschaut.

Dazu haben wir auf Seiten meiner privaten Fortinet Box (die hinter der Fritzbox) als auch auf der Fortigate in der Unternehmenszentrale ein IKE Debug laufen lassen.

Interessant daran war, dass die Phase 1 ohne Probleme durchläuft und es "nur" Probleme bei der Phase 2 gibt. Wir konnten uns beide nicht erklären wieso.

Unsere einzige Vermutung ist, dass auf der 7390 irgendwie doch noch der IPsec Deamon aktiv ist und uns trotz Exposed Host ins Handwerk pfuscht.

Ich werde heute (wir hatten gestern nicht genug Zeit) das Testszenario jedoch noch einmal nachstellen und die Logs aufzeichnen.

Muss allerdings bevor ich die Logs poste zunächst alle relevanten Infos per Search and Replace aus dem Log entfernen.

Als nächstes werde ich dann probieren ein VPN zwischen der Fritzbox und der Fortigate in der Unternehmenszentrale aufbauen und schauen ob das funktioniert.

Allerdings ist das nur ein Test, denn nicht überall haben wir Zugriff auf die Fritzboxen. Einige unserer Kollegen für die dieses Szenario künftig interessant ist haben so tolle ferngewartete Boxen von 1&1 bzw. Unitymedia und Co.

 

[doc456]

Nee, der Dämon sollte nicht laufen, es sei denn du hattest mal eine VPN in der Box etabliert. Ansonsten kannst du per Telnet nachsehen...

EDIT: bei mir läuft der Dämon unter /bin/avmike

BtW, hattest du das Forwarden von GRE und den Ports auf die Forti eingerichtet?

 

[Zeihold_von_SSL]

Öhm ja, ich hatte auf der Box mal ein VPN eingerichtet. Ist das ausschlaggebend? Ist aber schon seit etwa 6 Monaten gelöscht.

GRE Forwarding hatte ich zwischenzeitlich explizit aktiviert. Mittlerweile bin ich quasi runter auf den Exposed Host.

Ich schaue nach deiner Formulierung aber wohl doch besser zuerst mal via Telnet auf der FritzBox ob sich mein verdacht bestätigt.

 

[Zeihold_von_SSL]

Hmmmm,

also hier mal die Prozessliste. Dummerweise sieht es nicht so aus als ob der VPN Deamon der Fritzbox gestartet wäre...

# ps
PID USER VSZ STAT COMMAND
1 root 1428 S init
2 root 0 SW< [kthreadd]
3 root 0 SW< [ksoftirqd/0]
4 root 0 SW< [watchdog/0]
5 root 0 SW< [events/0]
6 root 0 SW< [khelper]
7 root 0 SW< [CPMAC workqueue]
8 root 0 SW< [kblockd/0]
10 root 0 SW [pdflush]
11 root 0 SW< [kswapd0]
12 root 0 SW< [aio/0]
13 root 0 SW< [nfsiod]
21 root 0 SWN [avmdebug]
22 root 0 SW [pm_info]
23 root 0 SW< [mtdblockd]
26 root 0 SW< [rpciod/0]
27 root 0 SW [tffsd_mtd_0]
87 root 0 SW [cleanup_timer_f]
199 root 0 SW< [yaffs-bg-1]
212 root 0 SW [pdflush]
215 root 0 SW< [capi_oslib]
216 root 0 SW< [capi_oslib/0]
217 root 0 SW [capitransp]
220 root 0 SW< [avm_dect_thread]
221 root 0 SW [ksock tcp worke]
222 root 0 SW [ksock tcp serve]
302 root 1252 S < /sbin/udevd --daemon
333 root 0 SW< [khubd]
381 root 1252 S < /sbin/udevd --daemon
383 root 1252 S < /sbin/udevd --daemon
406 root 2740 S /bin/configd
478 root 5312 S /usr/bin/vdsld ats
493 root 5312 S /usr/bin/vdsld ats
494 root 5312 S /usr/bin/vdsld ats
495 root 5312 S /usr/bin/vdsld ats
496 root 5312 S /usr/bin/vdsld ats
497 root 5312 S /usr/bin/vdsld ats
498 root 5312 S /usr/bin/vdsld ats
499 root 5312 S /usr/bin/vdsld ats
500 root 5312 S /usr/bin/vdsld ats
616 root 0 SWN [dectuart_route]
623 root 11460 S ctlmgr
627 root 4316 S upnpd
645 root 3472 S wland -B
660 root 11460 S ctlmgr
661 root 11460 S ctlmgr
662 root 11460 S ctlmgr
672 root 4048 S pbd
673 root 4048 S pbd
675 root 4048 S pbd
676 root 4048 S pbd
708 root 5540 S telefon a127.0.0.1
711 root 5540 S telefon a127.0.0.1
712 root 5540 S telefon a127.0.0.1
715 root 4944 S dect_manager
717 root 5580 S < voipd
729 root 1428 S /usr/sbin/inetd
739 root 1136 S /bin/run_clock -c /dev/tffs -d
753 root 1428 S init
760 root 4128 S /usr/bin/faxd -a
829 root 4316 S upnpd
830 root 4316 S upnpd
831 root 4316 S upnpd
835 root 0 SW [avmcsrpc]
837 root 2164 S pictured -Dpicserver -Dhandheld -Dsequence -Dpicdb -Djpegconvert
929 root 3120 S audiod
2344 root 4964 S multid
2355 root 4964 S multid
2358 root 4816 S dsld -i -n
2361 root 0 SWN [kdsld_token]
2405 root 1472 S /sbin/chronyd -n -f /var/tmp/chrony.conf
3556 root 1420 S telnetd -l /sbin/ar7login
3561 root 1448 S -sh
3613 root 1420 R ps

Aber ich habe auch nicht erwartet, dass es mir AVM/Fortinet hier einfach machen den Fehler zu finden.

 

[Zeihold_von_SSL]

Es ist echt merkwürdig. An 2 Abenden Logfiles gezogen und miteinander verglichen und 2 verschiedene Ergebnisse bekommen. So langsam komme ich mich verar*** vor von meiner Infrastruktur.

Die Logs von gestern Abend zeigen, dass überhaupt kein IPSec Traffic in der Unternehmenszentrale ankommt. Die Logs von vorgestern zeigen aber eindeutig Traffic.

So langsam aber sicher kriege ich so ein Bauchgefühl, dass eventuell auch der DSL (rein IP basierter Entertain Anschluss) Anschluss das Problem sein könnte.

Ich kann mir zwar nicht erklären woran das liegen sollte aber bei den anderen beiden Möglichkeiten (FritzBox und Fortigate) gibt es ebenfalls keinen Anhaltspunkt der
dieses Verhalten erklären würde.

Ich tappe daher weiter im Dunkeln. Allerdings werde ich das Thema wohl beerdigen. Es kostet mich momentan schlicht zu viel Zeit und nerven, daher lasse ich das Thema ruhen und hoffe es erledigt sich irgendwann von selbst...

Danke für die Hilfe.

 

[doc456]

Gerne!

Hast du nicht auch den VPN-Client für die Zentrale? Wenn ja, hättest du noch die Möglichkeit den Traffic zu prüfen.

 

[Zeihold_von_SSL]

Sooo, ich habe es jetzt ENDLICH geschafft. Ich habe noch ein bisschen an den Einstellungen auf der Fortigate bei mir Zuhause getweakt.
Die Box lässt sich mit ein paar Handgriffen vollständig in einen VPN Client verwandeln. Sprich Sie bezieht auch über den VPN Server in der Zentrale eine IP-Adresse usw.

Somit verhält Sie sich 1:1 so wie ein Software VPN Client und siehe da: Es funktioniert!!!

Das ganze funktioniert sogar so gut, dass ich alle unsere aktuellen NAT Boxen in den Außenstellen auf diese Methode umgestellt habe. Denn auf diese Art habe ich

a) in der Zentrale nur noch einen VPN Tunnel zu konfigurieren
b) ein deutlich kleineres Regelwerk in der Zentrale
c) Ich kann auf diese Weise endlich auch OSPF mit den NAT Boxen machen und kann darauf verzichten meine Routen auf diesen Boxen von Hand zu pflegen.

Fazit: Works like a charm.

Noch einmal Danke für deine Hilfe/Tipps/Anregungen...

 

[doc456]

Na, da hat sich der Tip mit Client ja gelohnt!

Wußte gar nicht, das das auch geht. :rock:

Wenn du Lust hast, denn lass mich per PM an deiner Solution teilhaben, dann kann ich deine Lösung mal versuchen!
Versuch macht nämlich Kluch! :mrgreen: