IPsec Site-to-Site VPN Juniper ScreenOS <-> AVM FRITZ!Box

Hier kommen die Einstellungen die nötig sind, um ein Site-to-Site VPN zwischen einer AVM FRITZ!Box und einer Juniper ScreenOS Firewall herzustellen. Neben einigen Anleitungen im Netz habe ich selber ein paar Einstellungen getestet, um eine möglichst detaillierte *.cfg Datei zu haben. Außerdem ist erfreulicherweise anzumerken, dass die Juniper auch ein statisches VPN zu einer dynamischen Adresse erlaubt und somit sogar beide Seite einen Verbindungsaufbau initiieren können. Mit dem VPN Monitor von Juniper wird der Tunnel konstant “up” gehalten.

Aufbau und Infos

So sieht mein Aufbau aus. Anzumerken ist, dass ich meine öffentliche IP nicht direkt an der Juniper anliegen habe, sondern sie per statischem NAT auf die untrust aber private IP-Adresse der Juniper weiterleite.

S2s VPN Juniper SSG - FritzBox Laboratory

Des Weiteren habe ich noch folgende Anmerkungen zur FRITZ!Box Konfiguration:

  • mode = phase1_mode_idp: Ja, das ist der Main Mode. Und das funktioniert trotzdem, weil die Juniper ein “statisches” VPN zu einer FQDN Adresse erlaubt. Sprich: Obwohl die FRITZ!Box definitiv hinter einer dynamischen IP Adresse hängt (was eigentlich den Aggressive Mode erfordern würde), funktioniert hier der Main Mode, da die Juniper den FQDN einfach auflöst. Das hat folgenden großen Vorteil: VPN Verbindungen können von beiden Seiten initiiert werden, also auch von der Juniper aus. Das ist für mich sehr praktisch, da ich hinter der Juniper ein Monitoring-Server habe, der Geräte hinter der Fritz!Box abfragt. Könnte die Juniper nicht den Tunnel von sich aus aufbauen, würde es nur über Umwege funktionieren. Im Log der Juniper taucht dabei übrigens folgende Zeile auf: IKE gateway fdorf.webernetz.net has been enabled. The peer address fdorf.webernetz.net has been resolved to 95.116.50.62.
  • phases1ss: Viele andere Anleitungen haben hier schlichtweg “all/all/all” stehen. Ich wollte es aber etwas fester zurren, so dass ich es auf “alt/aes/sha” angepasst habe. Sprich: Diffie-Hellman group 2, AES-256 und SHA-1. Ich habe leider keine Einstellung gefunden, die DH group 5 erlaubt hätte. Gruppe 2 macht bei AES-256 ja eigentlich wenig Sinn, da das Security-Niveau von group 2 einfach zu niedrig ist um ein AES-256 zu rechtfertigen. Aber okay, es ist ja kein Hochsicherheitstrakt hinter meiner FRITZ!Box. 😉
  • ike_forward_rules: Obwohl es in meinem Szenario nicht nötig ist, habe ich das udp:4500 drin gelassen. Es wäre nötig für NAT-Traversal, bei welchem die ESP Pakete in UDP-4500 gepackt werden. Ich habe es drin gelassen, damit man diese *.cfg Datei auch für andere Szenarien später mal verwenden kann.

Zur Juniper ist noch folgendes zu sagen:

  • Gateway Local ID: Diese ID muss ich hier spezifizieren, da sonst der Aufbau von der Juniper zur FRITZ!Box nicht geklappt hat. Das liegt allerdings an meinem spezifischen Aufbau, da nicht die Juniper selbst die öffentliche IP-Adresse hat, sondern sie noch mal geNATet ist.

Auf der SSG lief Version “6.3.0r15a.0”. Bei der FRITZ!Box habe ich es auf vier verschiedenen Hardwares getestet: 7240, 7270, 7312, 7390. Die Versionen waren alle aus dem 5.5x Tree, bis auf die 7390, die bereits FRITZ!OS 6 drauf hatte.

Juniper ScreenOS (SSG 5)

Als erstes wird ein neues Tunnel-Interface angelegt und in eine (vorher angelegte) Security Zone gesteckt. In meinem Fall heißt sie “vpn-s2s”. Es muss ein unnumbered Tunnel-Interface sein. Als “Interface” Angabe habe ich das untrust Interface gewählt:

S2S-FB-ScreenOS_Juniper-01_Tunnel-Interface

Dann wird das Gateway angelegt:

S2S-FB-ScreenOS_Juniper-02_Gateway

Im Advanced Bereich muss man den PSK, die Local ID sowie das Custom P1 Proposal von “pre-g2-aes256-sha” auswählen. Da dieses standardmäßig nicht auf der Juniper installiert ist, muss man es vorher noch angelegen.

S2S-FB-ScreenOS_Juniper-03_GatewayAdvanced

Nun folgt das AutoKey IKE Profil und die Advanced Einstellungen. Es wird das P2 Proposal “g2-esp-3des-sha” ausgewählt und weiter unten auf das eben erstellte Tunnel-Interface verwiesen. Wichtig ist außerdem der Proxy-ID Check. Den VPN Monitor aktiviert man, wählt als Source Interface jenes aus, das dem getunnelten IP-Bereich entspricht und wählt als Destination IP die der remote FRITZ!Box aus. Das Rekey Häkchen kann man anhaken. Es bewirkt, dass der VPN Tunnel automatisch aufgebaut wird, was bei der 24-Stunden Zwangstrennung von DSL-Anschlüssen in Deutschland durchaus praktisch ist.

S2S-FB-ScreenOS_Juniper-04_AutoKeyIKES2S-FB-ScreenOS_Juniper-05_AutoKeyIKEAdvanced

Nun muss man noch die Proxy ID konfigurieren. In meinem Beispiel hier ein etwas größerer IP-Bereich als normal, da ich hinter der Juniper noch einige Netze route. Sehr oft dürfte hier ein “/24” Bereich zur Verwendung kommen. Als Service wird ANY ausgewählt:

S2S-FB-ScreenOS_Juniper-06_ProxyID

Zum Schluss wird noch das remote Netz in den Tunnel geroutet (ohne Gateway IP-Adresse):

S2S-FB-ScreenOS_Juniper-07_Route

(Natürlich muss noch eine Policy von “trust” nach “vpn-s2s”, oder wie auch immer sie heißt, eingerichtet werden, die den gewünschten Traffic erlaubt.)

FRITZ!Box

Für die FRITZ!Box ist folgende *.cfg Datei nötig, welche man über die GUI importieren kann. Kommentare sind entsprechend vermerkt. Überall wo ANPASSEN steht, muss man selber noch Hand anlegen:

 

Wenn es funktioniert

Dann sieht man im Monitor Status der Juniper in etwa so etwas:

S2S-FB-ScreenOS_Juniper-08_MonitorStatus

Auf der FRITZ!Box sieht man im Bereich Freigaben -> VPN einen grünen Status-Bubble. 😉

S2S-FB-ScreenOS_FritzBox_Status

Links

Neben dem Testen von diversen Einstellungen hatte ich natürlich auch Google bemüht. Zum Beispiel gibt es hier eine Erklärung von den FRITZ!Box Attributen und hier eine längere Diskussion über die Einstellungen von einem VPN zwischen ScreenOS und der FB. Eine Auflistungen der IKE Fehlermeldungen der FRITZ!Box findet man hier.

AVM hat ebenfalls ein VPN Service-Portal, bei dem allerdings (noch) keine Rede von der Juniper Firewall ist.

26 thoughts on “IPsec Site-to-Site VPN Juniper ScreenOS <-> AVM FRITZ!Box

  1. Dieser Blog ist eine wohltat, führt er doch nachhaltig zum Ziel mit fundierten Infos, Kenntnissen und weiterführenden Links.

    Wir haben nun Probleme mit VPN von Fritz zur Juniper Netscreen. . und vielleicht liest ja der ein/andere dieses Problem, kann sich indentifizieren und hat vielleicht sogar eine Lösung. .

    Wir nutzen bei einigen SoHo Kunden die 7390 als VPN Anbindung zu einer Juniper Netscreen. Wir haben nun Probleme nach dem aktuellen Update auf 6.20 mit den VPN Anbindungen. Zur Qualitätssicherung machen wir die Updates zum testen auf intern genutzten Geräten, um Probleme im Echtbetrieb zu vermeiden.

    Hierbei ist uns nun aufgefallen das vorher eingerichtete VPN-Tunnel mit IPSec
    nicht mehr laufen. Wir sind dem auf den Grund gegangen und haben 2 Dinge im Debubg Modus auf unseren Firewalls von Juniper herausgefunden.

    – die Phase 2 Proposals werden anscheinend nicht wie in der FritzConfig angegeben gesendet. Mit AES256 angegebene Phase 2 werden im Dialog doch als 3DES z.B. gesendet. Nach einigem Probieren konnten wir die richtige Kombination einstellen.

    – Nachdem dann die “Kein passendes Phase 2 Proposal verfügbar” geregelt war, wurde der Tunnel trotzdem nicht aufgebaut. Grund dafür sind die offenbar seit dem Update von der Fritzbox übermittelten “Phase 2 Attribute” wie z.B. Compression, die Juniper (und viele weitere Hersteller wie Cisco etc) nicht unterstützen. .
    Siehe hierzu auch http://kb.juniper.net/InfoCenter/index?page=content&id=KB12238

    Da wir gerne weiterhin von den AVM-Updates vor allem in Punkto security partizipieren würden, wäre eine Klärung dieser Problematik schön! Vielleicht hat jemand eine Lösung..!

    Axel

    1. Hallo Axel,

      genau das gleiche Problem habe ich auch, seit 6.20 funktioniert das VPN mit einer SSG140 nicht mehr, mit FritzOS 6.05 läuft es aber ohne Probleme.
      Habt ihr schon eine Lösung gefunden?

      1. Hallo Andreas,
        nein, leider haben wir noch keine Lösung gefunden.

        Ich habe bei AVM ein Supportticket offen (wir sind AVM Partner). . jedoch seit 2 Wochen auf die Anfrage KEINERLEI Feedback erhalten.

        Ich werde das noch einmal aktivieren. . vielleicht regt sich dann bei AVM etwas. . Lösungen poste ich hier dann mit. . 😉

        Bis dahin werden wir Kunden nicht updaten, meine eigene Box zu Hause werde ich gegebenenfalls downgraden. .

        Gruß
        Axel

    2. Hallo zusammen,

      hm, also bei mir gehts. 😉 Habe eine FRITZ!Box 7390 auf Version 06.20 upgedated. VPN zur Juniper SSG 5 mit 6.3.0r17 läuft ohne Probleme.
      –> Habt ihr bei der Config in der FRITZ!Box exakt die zu verwendenden Parameter für Phase 1 und Phase 2 angeben (so wie ich hier im Template), oder “all/all/all” Zeilen gewählt? Vielleicht könnte das daran liegen, dass der automatische Security Association Abgleich einfach nur fehlschlägt?
      Was mich darüber hinaus noch interessiert: In den Release Notes von FRITZ!OS 06.20 heißt es ja: “NEU – VPN-Verbindungen unterstützen jetzt zusätzliche Diffie-Hellman-Gruppen 5, 14 und 15”. Für welche Phasen denn? Was sind die nötigen Parameter Angaben bei der VPN-Konfigurationsdatei? Da werde ich wohl noch etwas herumprobieren müssen.

      Bis die Tage. 🙂

  2. Hallo Johannes,
    ich werde das dann mal genau nach Deinen Parametern komplett neu machen und hier berichten. Von AVM habe ich mittlerweile Feedback. . infos dazu später. Die sind “hilflos” da die FritzBox kein Debug hat (!?) und brauchen “unsere” Hilfe. . 😉
    Axel
    (Sorry, war falsche Mailadresse..)

  3. Läuft ! :-))

    Tja, wenn man sauber liest klappt es auch. . Danke Dir!

    Von AVM habe ich noch infos zu den neuen “Strategien” erhalten, schicke ich Dir mal per Mail gegebenenfalls zum veröffentlichen. .

    Vielen Dank für das Blog vom Profi!

    Gruß
    Axel

  4. Hallo Axel, Hallo Johannes,

    bei mir läuft 6.20 auf der 7390 (als Initiator) zur SSG-5 (6.3.0r17) leider nicht. Das im Blog stehende Config mit phase2ss = “esp-3des-sha/ah-no/comp-no/pfs”
    wird in 6.20 automatisch durch phase2ss = “esp-all-all/ah-none/comp-all/pfs”
    und dann wird die Verbindung wegen der Proposals betreffend Kompression nicht aufgebaut.

    Könnt ihr bitte mal prüfen, was bei euch jetzt im Config für die VPN-Verbindung auf der Fritzbox mit OS 6.20 wirklich drin steht?

    Vielen Dank und viele Grüße

    Guido S

    1. Hi Guido,

      wie schaue ich das auf der FRITZ!Box denn nach? Wenn die Konfigdatei einmal eingelesen ist, sehe ich sie ja nicht mehr.

      Auf der SSG habe ich gerade mal ein paar CLI Befehler abgesetzt. “get ike gateway” liefert folgendes Proposal “pre-g2-aes256-sha1-28800s”. “get vpn auto” zeigt mir dieses verwendete Proposal an “g2-esp-3des-sha”. Also immer genau die, die ich manuell und eindeutig konfiguriert habe. Daher weiß ich gerade nicht, wieso die FRITZ!Box ein anderes nehmen sollte. Hm.

      Bei mir ist es nur in der Tat so, dass die SSG fast immer die Verbindung aufbaut! Das geht ja, da sie trotz Main Mode einen FQDN akzeptiert. Hast du das ebenso aufgebaut? Vielleicht liegt da auch das Problem, welche der beiden Seiten anfängt, die SA auszuhandeln?

      1. Hi Johannes,
        die einfachste Möglichkeit ist von der FB eine Sicherung ohne Passwort zu machen und diese in einem UNIX-Datei-fähigem Editor anzuschauen. Unter VPNCFG findest Du dann deine aktuellen VPN-Konfigs. Der konvertierte Inhalt würde mich sehr interessieren.

        Du hast den VPN-Monitor eingeschaltet und der pingt bei Dir auf 192.168.9.1 und das müsste bedeuten, das deine Juniper die Verbindung öffnet und nicht die Fritzbox, so wie Du auch schreibst. Da mir das nichts nützen würde (dauerhafte Verbindung ist nicht akzeptiert) habe ich das auch noch nicht getestet. Ich glaube aber das das auf jeden Fall geht. Im Moment funktioniert die Verbindung mit V6.04 wunderbar mit der Startegie “esp-3des-sha/ah-no/comp-no/pfs” von der Fritzbox als Initiator Es gibt leider in der V6.20 keine Strategie mit “comp-no” mehr. Es läuft auch noch ein Ticket bei AVM, bei dem auch ein reger Informationsaustausch stattfindet. Aber noch keine Lösung-

        Das Problem ist defacto die Kompression: Die Compression-Proposals sind definitiv abzuschalten, wenn die Verbindung vom Client zur Juniper aufgebaut werden soll.

        1. Ah, cool. Man kann den *.export ja einfach in Notepad++ oder so öffnen. Und tatsächlich sieht die Konfig bei mir (obwohl ich sie so wie hier im Blog eingefügt hatte) wie folgt aus:
          phase1ss = “alt/all/all”;
          phase2ss = “esp-all-all/ah-none/comp-all/pfs”;

          Auf der SSG in Phase 2 (AutoKey IKE) sehe ich aber aktuell keine Einstellungen für Compression. Hm.
          Gut, also ich muss die Tage mal ein bisschen Troubleshooting betreiben. Vielleicht kann ich das einseitige Aufbauen von der FRITZ!Box auch mal nachstellen. Mal gucken, wie ich das zeitlich unterbringen kann.

          1. Also ich würde einfach die Config von Johannes nehmen (Siehe oben), die anzupassenden Teile anpassen und die Netscreen auch entsprechend den Screenshots anpassen. .

            Ich hatte 3 Boxen die alle unterschiedlich konfiguriert waren. . und alle haben bis zum Update auf 6.20 funktioniert. Nun laufen sie wieder, weil ich es genau so gemacht habe.

            Zudem ist die Umstellung auf AES256 noch eine verbesserung zu allem anderen 😉
            Gruß
            Axel

          2. @Axel:
            vielleicht hast Du es überlesen: Wegen VPN-Monitor macht die Juniper die Verbindung dauerhaft auf und das ist nicht akzeptabel. Die VPN-Verbindung darf nur on-demand von der Fritzbox geöffnet werden. Deshalb kann ich die SSG-5 so nicht einstellen.

            Gruß Guido

    2. Danke Guido, für die Aufklärung, genauso geht es mir auch.
      Man muss wohl schon irgendetwas auf der Juniper Seite ändern, oder nicht?

      1. Hallo Andreas,

        auf der Juniper-Seite kann man das leider nicht ausschalten. Man muss am Initiator die Kompression abschalten und genau das geht mit V6.20 nicht mehr, weil es keine “comp-no”- oder “comp-none”-Strategie mehr gibt. AVM räumt auch ein, dass da kräftig ausgedünnt wurde.

        Gruß Guido

  5. Juchu, ich habs! (Es hat mich ja jetzt doch nicht in Ruhe gelassen…)
    –> Die FRITZ!Box kann wirklich für beide Phasen jetzt DH-14 und AES-256 sprechen. Ich habe meine Konfig mit folgenden Werten in die Box geladen:
    phase1ss = “dh14/aes/sha”;
    phase2ss = “esp-all-all/ah-none/comp-all/pfs”;
    –> Auf der SSG muss man folgende Profile konfigurieren (halt die Optionen entsprechend anlegen):
    pre-g14-aes256-sha1-28800s (Phase 1)
    g14-esp-aes256-sha1-3600s (Phase 2)
    –> Und schon läuft es. Interessanterweise hatte ich bei anderen Phase 2 Proposals nämlich immer folgende Fehlermeldung auf der SSG bekommen:
    “Received a notification message for DOI 1 14 NO-PROPOSAL-CHOSEN.”
    Erst als ich hart die Gruppe 14 Proposal ausgewählt hatte, ging es.

    Wie siehts bei euch aus? 😉

    1. Hallo Johannes,

      ja, du hast recht, mit eben diesen Einstellungen funktioniert es reibungslos und die von dir genannte Fehlermeldung ist weg.
      Und für die, die es nicht wissen, der FBEditor leistet hier wunderbare Dienste um die Konfig per Hand zu bearbeiten.

      1. Zu früh gefreut 🙁
        Jetzt habe ich auf einmal (nach ungeplantem Reset des Internetanschlusses) folgenden Fehler: IKE-Error 0x2027 aka TimeOut.
        Hat jemand eine Idee?

  6. @Guido S – Der ständige Tunnel ist in meinem (und Business-Technisch ebenfalls) kein Problem. Aber ich gebe Dir recht, das wäre sicherlich besser, sicherer und effizienter. Vielleicht bessert AVM da noch nach irgendwann. . und das erklärt zumindest weshalb meine alten Konfigs nicht mehr liefen. . denn die hatten allesamt KEIN VPN Moni an. .

    @Johannes: Ich werde DH14 beizeiten dann mal ergänzen und testen. Bericht folgt dann 😉 Ich bin derzeit Happy das alles so klappt!

    Axel

  7. Versucht es doch mal damit:

    Phase1: pre-g2-aes256-sha1
    Phase2: g2-esp-aes256-sha1

    Hat bei mir funktioniert.

    Knut

  8. Hi,

    zunächst einmal vielen Dank für diese guten Arbeiten auf der Webseite. Ich habe nun ein Szenario in dem ich eine SSG5 und eine FB im VPN betreiben will. Der Tunnel kommt auch hoch, jedoch verstehe ich nicht, wie ich seitens der FB Routen soll.

    Könnt Ihr mir da helfen?

    Vielen Dank

    1. Hi Sven,

      also eigentich must du keine zusätzlichen Routen auf der FRITZ!Box eintragen. Wenn du die vpncfg Datei richtig gebaut hast (was ja wohl sein wird, da dein Tunnel hoch kommt), dann sollte der IP-Bereich des remote-Netzwerks automatisch in den Tunnel gerouted werden.

      (Oder möchtest du versuchen, weitere Netze, die nicht in der cfg Datei angegeben sind, in den Tunnel zu routen? Das geht meines Wissens nach nicht so ohne Weiteres…)

  9. Hallo,

    nachdem ich Ihren Blog durch die Googlesuche aufgrund meiner Probleme mit IPSec gefunden habe und diese nicht zufriedenstellend lösen konnte (die Fritzbox baut nach einer Zwangstrennung die Verbindung nicht wieder auf) wollte ich bei Ihnen nachfragen, ob Ihnen hier eventuell etwas einfällt.

    Dies ist meine vpncfg in der Fritzbox: (die Grundconfig habe ich aus einem anderen Guide übernommen und durch eine bessere Verschlüsselung erweitert, vielen Dank hier auch an ihre Tipps) (ich habe es im main mode und im aggressive mode getestet, das resultat ist das gleiche, starte ich manuell entweder ipsec auf der pfsense oder in der fritzbox neu geht es sofort, aber automatisch passiert nichts)
    vpncfg {
    connections {
    enabled = yes;
    conn_type = conntype_lan;
    name = “VPN pfsense”; // NAME der Verbindung
    always_renew = yes; // Verbindung immer herstellen
    reject_not_encrypted = no;
    dont_filter_netbios = yes;
    localip = 0.0.0.0;
    local_virtualip = 0.0.0.0;
    remoteip = 5.9.214.230; // Feste oeffentliche IP der pfSense Firewall
    remote_virtualip = 0.0.0.0;
    localid {
    fqdn = “presidente.adiumentum.de”; // dyndns name der FritzBox
    }
    remoteid {
    ipaddr = 5.9.214.230; // Feste oeffentliche IP der pfSense Firewall
    }
    mode = phase1_mode_aggressive; // Alt, machte Probleme mit pfSense 2.2
    // mode = phase1_mode_idp;
    phase1ss = “LT8h/all/all/all”;
    keytype = connkeytype_pre_shared;
    key = “ja-gibt-es”;
    cert_do_server_auth = no;
    use_nat_t = no;
    use_xauth = no;
    use_cfgmode = no;
    phase2localid {
    ipnet {
    ipaddr = 10.0.0.0;
    mask = 255.255.0.0;
    }
    }
    phase2remoteid {
    ipnet {
    ipaddr = 192.168.50.0; // Das interne Netzwerk LAN hinter der pfSense
    mask = 255.255.255.0; // inklusive Subnetmask
    }
    }
    phase2ss = “esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs”; // wichtig, da sonst kein Datenaustausch
    accesslist = “permit ip any 192.168.50.0 255.255.255.0”,
    “permit ip any 192.168.51.0 255.255.255.0”,
    “permit ip any 192.168.52.0 255.255.255.0”; // Firewall Einstellungen für pfSense Subnetz
    }
    ike_forward_rules = “udp 0.0.0.0:500 0.0.0.0:500”,
    “udp 0.0.0.0:4500 0.0.0.0:4500”;
    }

    Bei der Konfiguration der pfsense habe ich mich an ihre Verschlüsselungswerte aus ihren Blogeinträgen gehalten, ansonsten diesen Guide verwendet. http://znil.net/index.php?title=FritzBox_-_Site_to_Site_VPN_zu_pfSense_2.2
    phase 1 AES 256Bit / SHA1 / DH2 / Lifetime 28800 / Nat Traversal Forced / DPD 60 5 /
    phase 2 Network 192.168.48.0/21 (ich muss in mehrere Netze) / ESP / AES 256 / SHA1 / PFS 2 / Lifetime 3600

    Vielleicht haben Sie ja eine Idee, denn soweit ich es bisher testen konnte bleibt die Verbindung bis zur Zwangstrennung stabil.
    Den Dyndns für presidente.adiumentum.de verwalte ich selbst und hier dauert das Update max. zwei Minuten der DNS Eintrag aktualisiert wurde.

    Diese Fehler Treten Auf:
    22.07.15 05:08:29 VPN-Fehler: VPN pfsense, IKE-Error 0x2026
    22.07.15 05:08:25 VPN-Fehler: VPN pfsense, IKE-Error 0x203f
    22.07.15 05:08:23 VPN-Fehler: VPN pfsense, IKE-Error 0x203f
    22.07.15 05:08:22 VPN-Fehler: VPN pfsense, IKE-Error 0x2026
    22.07.15 05:08:21 VPN-Fehler: VPN pfsense, IKE-Error 0x203f
    22.07.15 05:08:18 VPN-Fehler: VPN pfsense, IKE-Error 0x2027

    Ich habe ein /21er Netz gewählt, damit ich die 192.168.50.0 51.0 und 52.0 erreichen kann. auf der pfsense sind LAN DMZ und SRV, so heißen sie, reguläre /24er Netze.

    In der PFsense habe ich die externe IP in der Konfiguration angegeben (my identifer), da die Verbindung sonst überhaupt nicht funktioniert hätte (habe nämlich 2 WANs) für den und “presidente.adiumentum.de” habe ich auch in der pfsense gesetzt (peer identifer). als auswahloptionen habe ich hier: “peer ip address” “ip address” “distinguished name” “user distinguished name” “asn.1 distinguished name” und “keyid tag”

    Hier noch ein Auszug aus dem “Fehlerlog” der PFSense

    Jul 22 14:04:35 charon: 10[KNL] creating acquire job for policy 5.9.214.230/32|/0 === 93.215.60.155/32|/0 with reqid {6}
    Jul 22 14:04:35 charon: 15[ENC] generating QUICK_MODE request 3095426350 [ HASH SA No KE ID ID ]
    Jul 22 14:04:35 charon: 15[NET] sending packet: from 5.9.214.230[500] to 93.215.60.155[500] (396 bytes)
    Jul 22 14:04:35 charon: 15[NET] received packet: from 93.215.60.155[500] to 5.9.214.230[500] (76 bytes)
    Jul 22 14:04:35 charon: 15[ENC] parsed INFORMATIONAL_V1 request 789699501 [ HASH N(INVAL_ID) ]
    Jul 22 14:04:35 charon: 15[IKE] received INVALID_ID_INFORMATION error notify
    Jul 22 14:04:35 charon: 15[IKE] received INVALID_ID_INFORMATION error notify
    Jul 22 14:04:57 charon: 10[KNL] creating acquire job for policy 5.9.214.230/32|/0 === 93.215.60.155/32|/0 with reqid {6}
    Jul 22 14:04:57 charon: 10[ENC] generating QUICK_MODE request 2772999983 [ HASH SA No KE ID ID ]
    Jul 22 14:04:57 charon: 10[NET] sending packet: from 5.9.214.230[500] to 93.215.60.155[500] (396 bytes)
    Jul 22 14:04:57 charon: 10[NET] received packet: from 93.215.60.155[500] to 5.9.214.230[500] (76 bytes)
    Jul 22 14:04:57 charon: 10[ENC] parsed INFORMATIONAL_V1 request 4188504668 [ HASH N(INVAL_ID) ]
    Jul 22 14:04:57 charon: 10[IKE] received INVALID_ID_INFORMATION error notify
    Jul 22 14:04:57 charon: 10[IKE] received INVALID_ID_INFORMATION error notify

    1. Hi Martin,

      sorry für die verzögerte Antwort. Also eine gute Idee habe ich leider auch nicht. Aber ein paar Fragen:
      – Verstehe ich es richtig, dass lediglich nach der Zwangstrennung die Verbindung nicht mehr geht? Wie lange dauert es denn, bis es dann doch wieder geht? Oder wie machst du das?
      – Du redest von einem /21er Netz, hast in der cfg Datei der FRITZ!Box habe eine 255.255.255.0=/24er Maske angegeben (phase2remoteid). Vielleicht hat das damit etwas zu tun?
      – Ich hatte mal einen ähnlichen Fall, wo die FRITZ!Box zu einer FortiGate ein VPN aufbauen konnte, anders herum aber nicht. Das lag an den nicht eindeutig vergebenen IDs (phase 1) der Endpunkte. Diese müssen exakt gleich konfiguriert sein. In deinem Fall also “ip address” (oder so) seitens der pfSense, und ein “distinguished name” seitens der FRITZ!Box. Die Error-Meldung mit dem “received INVALID_ID_INFORMATION” klingt ja irgendwie danach, als ob da was mit den IDs nicht stimmt.
      – Wer ist denn der Initiator der Verbindung? Die FRITZ!Box, oder die pfSense? Kannst du mal von der anderen Seite aufbauen lassen (zum Beispiel einen ping über Nacht laufen lassen)?

      Ciao,
      Johannes

  10. Ich habe das Problem jetzt so umgangen dass ich auf meiner NAS einen Cronjob eingerichtet habe, der alle 5 minuten 10 pings an meinen Server schickt, dadurch baut sich die Verbindung ca 10-15 Min nach der Zwangstrennung selbst wieder auf.

    1. Hi Andy,

      ich habe es zwar selber noch nie getestet, aber es gibt anstelle der “remoteip” bei der FRITZ!Box einen Parameter namens:
      remotehostname = “domain.der.anderen.seite.de”;
      Das müsstest du mal ausprobieren.
      (Seitens der Juniper ist es ja zum Glück kein Problem, ein VPN zu einem DynDNS Namen aufzubauen.)

Leave a Reply

Your email address will not be published. Required fields are marked *