FRITZ!OS ab 06.23: IPsec P2 Proposals erweitert

Es geht in eine weitere Runde bei den VPNs von und zur FRITZ!Box. Nach den unglücklichen Änderungen in Version 06.20 hat AVM wieder ein paar Phase 2 Proposals hinzugenommen, die komplett ohne Kompression laufen. Somit ist es wieder möglich, die FRITZ!Box im Aggressive Mode VPN-Verbindungen zu diversen Firewalls aufbauen zu lassen. Komisch nur, dass noch nicht alles ganz wie erwartet funktioniert. Hier kommen meine Testergebnisse.

[This is one of many VPN tutorials on my blog. Please look here find the appropriate one.]

IPsec Proposals

Auf Anfrage hat mir AVM die “Strategien” für IPsec in der Version 06.23 zur Verfügung gestellt. Diese sind wie folgt:

Phase 1:

  • dh5/aes/sha
  • dh14/aes/sha
  • dh15/aes/sha
  • def/all/all
  • alt/all/all
  • all/all/all
  • LT8h/all/all/all

Phase 2:

  • esp-aes-sha/ah-all/comp-lzjh-no/pfs
  • esp-all-all/ah-all/comp-all/pfs
  • esp-all-all/ah-all/comp-all/no-pfs
  • esp-all-all/ah-none/comp-all/pfs
  • esp-3des-sha/ah-no/comp-no/no-pfs
  • esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs
  • esp-all-all/ah-none/comp-all/no-pfs
  • LT8h/esp-all-all/ah-none/comp-all/pfs
  • LT8h/esp-all-all/ah-none/comp-all/no-pfs

Mein Ziel war es also, in beiden Phase möglichst DH-14 und AES-256 einzusetzen, wobei Phase 1 gerne eine Lifetime von 8 Stunden haben darf, während Phase 2 nur eine Stunde laufen soll. (Hintergrund: Da es ständig zu Verbindungsabbrüchen beim Rekeying kommt, sind längere Lifetimes hier wohl besser.) Leider hat das nicht exakt so geklappt…

Tests

Die folgenden Tests habe ich extra alle im Aggressive Mode laufen lassen, so dass stets die FRITZ!Box (hinter einer dynamischen IP) die VPN-Verbindung initiiert. Bei einigen Kunden scheint das Voraussetzung zu sein. Als Gegenstelle hatte ich eine Juniper ScreenOS SSG 5 mit Version 6.3.0r18.0 im Labor (siehe hier). Die FRITZ!Box ist eine 7390 und wie gesagt mit FRITZ!OS Version 06.23.

Folgende Tabelle zeigt immer zweizeilig die Einstellungen für Phase 1 und 2:

#FRITZ!BoxJuniperLäuft?Kommentar
1dh14/aes/shapre-g14-aes256-sha1-3600sJaLeider nur mit 1 h bei Phase 1.
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfsg14-esp-aes256-sha1-3600sJa
2LT8h/all/all/allpre-g14-aes256-sha1-28800sNeinPhase 1 Mismatch, also scheint DH-14 hier nicht zu klappen
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfsg14-esp-aes256-sha1-3600s
3LT8h/all/all/allpre-g2-aes256-sha1-28800sJaAha, also mit DH-2 und 8 h klappt es
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfsg14-esp-aes256-sha1-3600sNeinThere were no acceptable Phase 2 proposals. WARUM?
4LT8h/all/all/allpre-g2-aes256-sha1-28800sJa
esp-aes256-3des-sha/ah-no/comp-lzs-no/pfsg2-esp-aes256-sha1-3600sJaMit DH-2 klappt es auch hier. Komisch, weil es bei Test 1 ja exakt mit diesem Proposal lief.

Sehr komisch ist also zum Beispiel, dass bei Tests 1 und 3 für Phase 2 jeweils das gleiche Proposal seitens der FRITZ!Box verwendet wurde, es aber in Test 1 mit DH-14 funktioniert hat, in Test 3 aber nicht. Hm.

Bei Variante 1 sah es auf der Juniper SSG also so aus:

 

Variante 4 entsprechend so:

 

Und hier noch ein Screenshot von einem Test zur Cisco ASA Version 8.4(7). Hier wurde ebenfalls die Variante mit einer IKE Lifetime von 8 h verwendet. Die Gegenstelle hatte sogar bereits FRITZ!OS 06.24 installiert:

Cisco ASA FRITZ!Box 06.24

Fazit

So ganz eindeutig scheint es noch nicht zu sein. Die “all/all/all” Varianten decken doch nicht alles ab und die anderen klappen manchmal und manchmal aber auch nicht. Man hat aktuell die Wahl, ob man DH-14 in beiden Phasen verwenden möchte (was aus sicherheitstechnischer Sicht Sinn macht) oder lieber auf eine Lifetime von 8 h in Phase 1 zurückgreift, dann aber nur DH-2 zum Laufen bekommt.

Templates

Hier noch mal zwei komplette Templates, so wie ich sie aktuell verwende. Bei beiden wird davon ausgegangen, dass die FRITZ!Box eine dynamische IP Adresse hat, also der Aggressive Mode verwendet wird.

DH-14 mit Lifetime 1 h

 

Lifetime 8 h aber nur DH-2

 

21 thoughts on “FRITZ!OS ab 06.23: IPsec P2 Proposals erweitert

  1. Hallo,

    haben Sie es wieder geschafft eine Verbindung von der FritzBox Seite aus zu initieren oder besteht auch weiterhin die ” IKE-Error 0x2027″ Problematik?

    Viele Grüße und Danke im Voraus für die Antwort

    1. Ja, genau das hat hiermit wieder geklappt. Wie im Post beschrieben initiiert die FRITZ!Box die VPN-Verbindung. Dies ist durch das Vorhandensein der “comp-no” Proposals wieder möglich.

      1. Danke für die super Arbeit. Gibts schon etwas neues dazu. Würde auch gerne mit DH14 arbeiten, aber nach 1h +/- 30min bricht es immer ab.

  2. Sei gegrüßt.
    Ich habe folgende Konstellation an einer Sonic Wall mit einer Fritz Box, siehe bitte weiter weiter unten.
    Ich habe das Problem, dass die VPN nach einer Stunde trennt und dann wieder aber reconnected. Noch heute morgen, hatte ich das Pech, dass diese Strecke nach einer Stunden trennte, aber nicht mehr verbunden werden konnte.
    Dank dieser Seite, habe ich noch diese LT8H hinzugefügt, dass wenigstens die Verbindung nach einer Stunde wieder zustande kommt. Was kann ich da noch optimieren, dass diese Reconnect, zu einer schlechten Erinnerung wird?

    Viele Grüße, und über Ideen würde ich mich freuen.

    PS= Eine tolle Seite.

    SONICWALL Seite sieht so aus:
    Sonic Wall Einstellungen
    IKE Phase 1 Proposal

    Exchange= Main Mode
    DH Group = Group 2
    Encyription= 3DES
    Authentication= SHA1
    Life Time in Seconds = 28800

    Ip Sec Phase 2 Proposal
    Protocol= ESP
    Encyription= 3DES
    Authentication= SHA1
    Perfect Forward Secrecy = Enabled

    DH Group = Group 2
    Life Time in Seconds = 28800

    FRITZBOX SEITE SIEHT SO AUS:

    // BEISPIEL DATEI FÜR SONIC WALL
    vpncfg {
    connections {
    enabled = yes;
    conn_type = conntype_lan;
    name = “*************”; //NAME DER VERBINDUNG
    always_renew = yes; // UMSTELLEN AUF YES
    reject_not_encrypted = no;
    dont_filter_netbios = yes;
    localip = 0.0.0.0;
    local_virtualip = 0.0.0.0;
    remoteip = REMOTE EXTERN IP; //REMOTE NETZWERK FESTE IP
    remote_virtualip = 0.0.0.0;
    localid {
    ipaddr = LOKAL EXTERN IP; // LOKALE NETZWERK FESTE IP
    }
    remoteid {
    ipaddr = REMOTE EXTERN IP;//REMOTE NETZWERK FESTE IP
    }
    mode = phase1_mode_aggressive;
    phase1ss = “LT8h/all/all/all”; //LT8H bedeutet Lifetime von 8 Stunden
    keytype = connkeytype_pre_shared;
    key = “gd/ena”; //SCHLÜSSEL HIER EINTRAGEN
    cert_do_server_auth = no;
    use_nat_t = no; // NO BEI FESTE IP, YES BEI DYNDNS o. ä.
    use_xauth = no;
    use_cfgmode = no;
    phase2localid {
    ipnet {
    ipaddr = Lokale Interne IP Adresse; //LOKALE INTERNE IP ADRESSE
    mask = 255.255.255.0;
    }
    }
    phase2remoteid {
    ipnet {
    ipaddr = Entfernte interne IP Adresse; //ENTFERNTE INTERNE IP ADRESSE
    mask = 255.255.255.0;
    }
    }
    phase2ss = “esp-all-all/ah-none/comp-all/pfs”;
    accesslist = “permit ip any Entfernte interne IP Adresse 255.255.255.0”; //ENTFERNTE INTERNE IP ADRESSE
    }
    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”;
    }

    // EOF

    1. Hi Salih,
      ich habe in den letzten Wochen auch nicht mehr mit der FRITZ!Box herumexperimentiert. Daher kann ich ad-hoc auch nichts dazu sagen.

      Kannst du den VPN-Tunnel auch von der Sonicwall aufbauen? Dann könntest du mal mit dem Phase 2 Proposal “LT8h/esp-all-all/ah-none/comp-all/pfs” herumtesten. Falls das klappt hättest du immerhin eine Lifetime von beiden Phasen mit 8 h. (Da dieses Proposal allerdings kein “comp-no” beinhält, wird es vermutlich nicht klappen, wenn die FRITZ!Box das VPN aufbaut. Dieses Problem hatte ich in einem vorherigen Blogpost beschrieben.)

      Bezüglich des Reconnects kann ich immerhin sagen, dass das bei mir nie ein Problem war. Es hatte halt nur immer kurz geruckelt, was ich auf die nicht so gute Leistungsfähigkeit der FRITZ!Box zurückführe. Also “eigentlich” sollte das klappen. Klappt der Reconnect denn wirklich gar nicht? Erst nach einem Reboot der FRITZ!Box, oder wie?

      1. Oh das mit dem Reconnect klappt nunmehr, Gott sei Dank. Und Deine Hinweise hier, waren ein Segen.
        Noch heute morgen bis Mittag ging gar nichts.
        Hatte letzten Freitag die alten Router entfernt und anstelle dessen, eben diese Fritzbox gesetzt. Die Tests waren einwandfrei, natürlich komme ich nicht auf die Idee, dass die Verbindung nach einer Stunden abreisst und danach kein Reconnect mehr zustanden kommt.
        Mit der oben mitgeteilte Datei, kommt die Verbindung schwupps zustande und nach einer Stunde reisst die Verbindung wegen lifetime Fehler ab um dann sofort wieder eine Verbindung herzustellen. Und das nur, ich vermute da ich diese LT8H noch davor gesetzt habe.

        Leider kann ich den Tunnel von drüben nicht testen, da Fremd Betreut und nicht von mir. Der Initiator ist tatsächlich der Fritzbox, und da komme ich nicht drumrum.
        Wenn also diese eine Stunde Reconnect nicht zu beseitigen ist, weil die zweite Phase nicht auf 8 Stunden getrimmt werden kann, ich hatte das auch schon probiert, bin gescheitert, und diese Eine Stunden Aussetzer sowie Logs weiter und wirklich als Ruckler anzusehen sind, lasse ich das so. Seit drei Stunden sind die Reconnects wirklich eine Sekunde und damit können die leben. Vorher nach der eine Stunde ging nichts.

        Siehe unten bitte logs, das grad von jetzt stammt. Bin grad auf FB drauf

        20.04.15 18:36:05 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
        20.04.15 17:49:56 VPN-Verbindung zu xxxxxxxxxxxxxxx wurde erfolgreich hergestellt.
        20.04.15 17:49:56 VPN-Verbindung zu xxxxxxxxxxx wurde getrennt. Ursache: 1 Lifetime expired
        20.04.15 16:59:51 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
        20.04.15 16:55:56 VPN-Verbindung zu xxxxxxxxxx wurde erfolgreich hergestellt.
        20.04.15 16:55:56 VPN-Fehler: xxxxxxxxxxxxxxxx, IKE-Error 0x2026
        20.04.15 16:55:12 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xxxxxxxxxxxxxx, DNS-Server: xxxxxxxxxxxx und xxxxxxxxxxx, Gateway: xxxxxxxxxxxx, Breitband-PoP: MUNX47-erx
        20.04.15 16:55:10 Internetverbindung wurde getrennt.
        20.04.15 16:54:57 VPN-Verbindung zuxxxxxxxxxxxx wurde getrennt. Ursache: 12 SA loss
        20.04.15 16:54:57 Die FRITZ!Box-Einstellungen wurden über die Benutzeroberfläche geändert.
        20.04.15 16:52:25 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
        20.04.15 16:42:08 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.1.200.
        20.04.15 16:27:45 VPN-Verbindung zu xxxxxxxxxxxx wurde erfolgreich hergestellt.
        20.04.15 16:27:45 VPN-Fehler: xxxxxxxxxxxxxx, IKE-Error 0x2026
        20.04.15 16:27:29 VPN-Fehler: xxxxxxxxxxxxxxx, IKE-Error 0x2027
        20.04.15 16:26:59 VPN-Verbindung zu xxxxxxxxxxxxxxxxxx wurde getrennt. Ursache: 12 SA loss
        20.04.15 16:26:29 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xxxxxxxxxxxxxxx6, DNS-Server: xxxxxxxxxxxxxxx und xxxxxxxxxxxx, Gateway:xxxxxxxxxxxxxx, Breitband-PoP: MUNX47-erx
        20.04.15 16:26:26 Internetverbindung wurde getrennt.

  3. Hallo, vielen Dank für die klasse Anleitung. Wir haben unteranderen eine FB7490 mit FritzOS 6.30 und einen PaloAlto Cluster 3020 mit Software 6.1.6.
    Es funktionierte auf anhieb nur konnte nach der 1.Stunde keine Verbindung mehr aufgebaut werden, Fritzbox VPN ausschalten und wieder anschalten, dann ging es wieder. Mit der Config oben bzw. LT8h/all/all/all funktionierte es auf anhieb. Danke, Klasse Blog.

  4. Hallo Herr Weber,

    zunächst mal: sehr gute Dokumentation. Danke dafür. Frage:

    Haben Sie eine funktionierende Konfiguration bzw. Tips für VPN SonicWALL 8aktuelles OS) Fritzbox (OS 6.51) mit statischer IP? Einige der obigen VPNs laufen stabil, andere brechen nach 1 h ab ohne erneuten Verbindungsaufbau. Rekeying von SonicWALL-Seite möglich, von Fritzbox nicht. Danke für einen Tip.

    Gruß
    Roland Wächter

  5. Hallo,

    vielen Dank für die guten Informationen.
    Hat jemand schonmal Verbindungen zwischen zwei Fritzbox-Modellen ausprobiert?
    Was wären dann die optimalen Parameter für phase1ss und phase2ss,…?

    Viele Grüße
    Cord

  6. Guten Tag zusammen,

    danke für die optimalen Anleitungen, die zu einem erfolgreichen S2S-Tunnel zwischen der Fritzbox (6490) und eine Cisco ASA 5515-X Firewall geführt haben.

    Leider scheint es mit dem rekey Verfahren in Phase2 noch insofern Probleme zu geben, dass alle 3600 Sekunden, die Verbindung kurz unterbrochen wird.

    Phase 1 konnte dank LT8h erfolgreich auf 28800 Sek. erhöht werden.

    Mit den Einstellungen für phase 2 …
    LT8h/esp-all-all/ah-none/comp-all/pfs
    LT8h/esp-all-all/ah-none/comp-all/no-pfs
    … konnte kein VPN-Tunnel mehr aufgebaut werden.

    Jemand noch einen Tipp ?

  7. Hallo,

    vielen Dank für die Informationen!
    Haben Sie Informationen, ob man VPN-Bridge-Interfaces (zur VPN Abkapselung) auch über eine VPN-Konfigurationsdatei hinzuladen kann ? Im Webinterface ist es ja möglich, separate Interfaces anzugeben.

    1. Hallo Fabius,
      uh, solche VPN-Bridge-Interfaces sagen mir gar nichts. Kann ich dir leider nichts zu sagen. ;(

      Was du aber selber ausprobieren kannst: Lege mal eines an, mache ein Backup der FRITZ!Box, öffne es in einem Notepad++ und suche nach “vpncfg”. Alles was in diesem Bereich steht kann auch über solche Konfigurationsdateien kommen. So habe ich immer einiges herausgefunden.

  8. Hallo,

    ich muss mit einer Fritzbox 7490 ein VPN gegen einen ( unbekannten ) Cisco-Router im Rechenzentrum aufbauen. Die notwendigen Parameter sin :

    #1: Internet Key Exchange Configuration
    ==================================
    – Authentication Method : Pre-Shared Key
    – Pre-Shared Key :
    – Authentication Algorithm : sha1
    – Encryption Algorithm : aes-128-cbc
    – Lifetime : 28800 seconds
    – Phase 1 Negotiation Mode : main
    – Perfect Forward Secrecy : Diffie-Hellman Group 2

    #2: IPSec Configuration
    ====================
    – Protocol : esp
    – Authentication Algorithm : hmac-sha1-96
    – Encryption Algorithm : aes-128-cbc
    – Lifetime : 3600 seconds
    – Mode : tunnel
    – Perfect Forward Secrecy : Diffie-Hellman Group 2

    – DPD Interval : 10
    – DPD Retries : 3

    – TCP MSS Adjustment : 1387 bytes
    – Clear Don’t Fragment Bit : enabled
    – Fragmentation : Before encryption

    Frage : Wie müssten die Phase1SS und Phhase2SS aussehen, um diese Parameter zu verwenden ? Wie kann ich die DeadPeerdetection konfigurieren ?

    Vielen Dank für Hilfe !

    Robert

    1. Hi Robert-Peter,

      du musst “eigentlich” nur die von mir gelisteten Phase1SS und Phase2SS irgendwie auf deine Anforderungen mergen. Zugegebenermaßen ist das unter Umständen nicht so einfach. ;)

      Für Phase 1 würde ich mal folgenden probieren: def/all/all
      Für Phase 2 diesen: esp-all-all/ah-none/comp-all/pfs
      oder diesen: esp-aes-sha/ah-all/comp-lzjh-no/pfs

      Ansonsten musst du einfach viel der Reihe nach ausprobieren. Außerdem wirst du nicht drum herum kommen, mit der Gegenseite zu reden. Aus einem Cisco Router lassen sich viel aussagekräftigere Logs auslesen als das Orakeln bei einer FRITZ!Box.
      Bzgl der DPD: Die lässt sich meines Wissens nach bei der FRITZ!Box nicht direkt einstellen. Ist aber zunächst auch nicht so wichtig. Also es sollte nicht direkt zu einem Problem führen, wenn du es nicht eingerichtet hast.

      Viel Glück!
      Johannes

  9. Guten Morgen,
    ich bin seit ca. 2 Tagen mit dem VPN Tunnel zwischen:
    FritzBox 3390 – OS: 06.54 und
    TERRA Black Dwarf – Securepoint V. 11.6.10
    beschäfdtigt und erhalte ja nach Anpassung die Fehler:
    IKE-Error 0x2031 – unspecified error
    IKE-Error 0x2026 – no proposal chosen
    IKE-Error 0x2027 – timeout
    im Log der FritzBox 3390
    und
    im Log der Securepoint V. 11.6.10
    initial Main Mode message received ***:* but no connection has been autorized with policy=PSK
    no config named ‘FritzBox3390’

    Die Konfig der Fritzbox:
    vpncfg {
    connections {
    enabled = yes;
    conn_type = conntype_lan;
    name = “VPN”;
    always_renew = yes;
    reject_not_encrypted = no;
    dont_filter_netbios = yes;
    localip = 0.0.0.0;
    local_virtualip = 0.0.0.0;
    remoteip = 0.0.0.0;
    remote_virtualip = 0.0.0.0;
    remotehostname = “AAAA”;
    localid {
    fqdn = “BBBB”;
    }
    remoteid {
    fqdn = “AAAA”;
    }
    mode = phase1_mode_idp;
    phase1ss = “all/all/all”;
    keytype = connkeytype_pre_shared;
    key = “pwd”;
    cert_do_server_auth = no;
    use_nat_t = yes;
    use_xauth = no;
    use_cfgmode = no;
    phase2localid {
    ipnet {
    ipaddr = CCCC;
    mask = DDDD;
    }
    }
    phase2remoteid {
    ipnet {
    ipaddr = EEEE;
    mask = FFFF;
    }
    }
    phase2ss = “esp-all-all/ah-all/comp-all/pfs”;
    accesslist = “permit ip any EEEE FFFF”;
    }
    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”;
    }

    Securepoint V11.6.10:
    Phase 1:
    IKEv1
    pre shared key
    Start: incoming
    dead peer detection = yes
    compression = no
    AES256
    SHA1
    MODP1536
    3600 sec.

    Phase 2:
    3DES
    SHA1
    MODP1536
    28.800 sec.
    perfect forward secrecy = yes

    Hat jemand eine Hilfestellung für mich?

    Danke für die Unterstützung im Voraus.

    Gruß Lars

    1. Hi Lars,
      ich habe es zwar nicht komplett durchdacht, aber hier ein paar Fragen, die dir vielleicht weiterhelfen könnten:
      – Du verwendest ein phase2ss mit “…comp-all…”. Damit hatte ich immer Probleme. Nimm bitte mal eines mit “…comp-lzs-no…”. Auf der SecurePoint hast du ja “compression = no” ausgewählt.
      – Sind beide Kisten hinter dynamischen IPs mit DynDNS Namen? Wenn ja, dann könnte es evtl nicht klappen, weil deine SecurePoint auf eingehende VPN Verbindungen wartet (Start: incoming). Es gibt Firewalls, die mögen keine VPNs wenn beide Seiten dynamisch sind.
      – Sollte die SecurePoint statische IPs haben, dann verwende bei der FRITZ!Box mal anstelle das “remotehostname = “AAAA”;” ein “remoteip = 80.154.108.232;”.
      – Achso, außerdem ist dein Mode falsch: “mode = phase1_mode_idp;” <- geht nur bei festen IPs. Du brauchst (auch wenn nur eine Seite dynamische IPs hat) immer: "mode = phase1_mode_aggressive;" Viel Erfolg beim weiteren Durchprobieren. ;) Johannes

  10. Hallo, vielen Dank für die vielen Infos und Tipps.

    Ich habe sehr viel probiert, bekomme aber noch immer einen hash mismatch (IKE-Error 0x2020 “hash mismatch in received packet”), gibt’s da vielleicht einen Trick?

    Danke

    vpncfg {
    connections {
    enabled = yes;
    conn_type = conntype_lan;
    name = “…”;
    always_renew = no;
    reject_not_encrypted = no;
    dont_filter_netbios = yes;
    localip = 0.0.0.0;
    local_virtualip = 0.0.0.0;
    remoteip = …;
    remote_virtualip = 0.0.0.0;
    remoteid {
    key_id = “…”;
    }
    mode = phase1_mode_aggressive;
    phase1ss = “all/all/all”;
    keytype = connkeytype_pre_shared;
    key = “…”;
    cert_do_server_auth = no;
    use_nat_t = yes;
    use_xauth = yes;
    xauth {
    valid = yes;
    username = “…”;
    passwd = “…”;
    }
    use_cfgmode = no; // dont set default route
    phase2localid {
    ipnet {
    ipaddr = 192.168.179.0;
    mask = 255.255.255.0;
    }
    }
    phase2remoteid {
    ipnet {
    ipaddr = 178.16.50.0;
    mask = 255.255.255.0;
    }
    }
    phase2ss = “esp-aes-sha/ah-all/comp-lzjh-no/pfs”;
    accesslist =
    “permit ip any any”;
    }
    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”;
    }

  11. Mit def/all/all bekomme ich IKE-Error 0x2026 “no proposal chosen”.
    Mit alt/all/all wieder 2020.
    Mit dh5/aes/sha wieder 2026.

    OK, es lag doch an der Authentifizierung. Bei Cisco auf der Gegenseite musste ich den Gruppennamen hier eintragen: localid {
    key_id = “gruppenname”;
    }
    und nicht in remoteid.

Leave a Reply

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