IPsec Site-to-Site VPN Cisco ASA <-> AVM FRITZ!Box

Mit diesem Beitrag möchte ich zeigen, wie man ein Site-to-Site VPN von der FRITZ!Box zu einer Cisco ASA Firewall aufbaut. Mein Laboraufbau entspricht dabei dem typischen Fall, bei dem die FRITZ!Box hinter einer dynamischen IP hängt (klassisch: DSL-Anschluss), während die ASA eine statische IP geNATet bekommt.

Beide Geräte habe ein policy-based VPN implementiert, so dass das hier endlich mal ein Fall ist, wo man nicht durch den Mix einer route-based VPN-Firewall und einer policy-based VPN-Firewall durcheinander kommt. Man muss bei beiden Geräten einfach das eigene sowie das remote Netzwerk eintragen, ohne weitere Routen zu ändern.

This is one of many VPN tutorials on my blog. –> Have a look at this full list. <–

Hinweis: Eine etwas detaillierte Beschreibung bezüglich der VPN-Einstellungen der FRITZ!Box habe ich hier bei meinem Blogbeitrag beim VPN zur Juniper Firewall beschrieben. Für weitere Informationen also bitte diesen Link verwenden.

Aufbau und Infos

So sieht mein Aufbau konkret aus:

S2S VPN Cisco ASA - FritzBox Laboratory

Auf der Cisco ASA 5505 lief Version 9.1(4), während auf meiner FRITZ!Box 7270 das FRITZ!OS 05.53 installiert war.

Leider habe ich es nicht geschafft auf der FRITZ!Box auch für die Phase 2 (IPsec) die Verschlüsselung mit AES-256 und DH-5 zu verwenden. Auch die Phase 1 (IKE) verwendet lediglich DH-2. Das ist insofern suboptimal, da bei DH-5 ein deutlich besserer Session-Key verwendet werden würde (höhere Sicherheitsstufe). Naja, immerhin kann man Perfect Forward Secrecy (PFS) mit DH-2 nutzen. Trotzdem: Falls jemand andere Einstellungen auf der FRITZ!Box hinbekommen hat: Bitte melden!

Cisco ASA

Der VPN-Tunnel bei der ASA wird mit einer Group Policy und einem Connection Profile realisiert. Siehe dazu die folgenden Screenshots inkl. der zusätzlichen Kommentare.

Als IKE Policy muss AES-256, DH-2, SHA-1, pre-share und eine Lifetime von 86400 Sekunden ausgewählt werden. Das IPsec Proposal braucht den Tunnel Mode mit 3DES und SHA-1. In der Crypto Map wird dann noch PFS mit DH-2 ausgewählt. Die Bennenung der Group Policy und des Connection Profiles spielt keine Rolle. Ich habe der Einfachheit halber den FQDN meiner FRITZ!Box gewählt. Das ist für die VPN Einstellungen an sich aber irrelevant.

FRITZ!Box

Folgend ist die Konfigurationsdatei welche ich für das VPN zur Cisco ASA gebaut habe. (Und wie bereits oben geschrieben: Ein paar mehr Details zur Konfigurationsdatei habe ich hier bei einem meiner anderen VPN Beiträge zur FRITZ!Box aufgelistet.)

 

Status der VPN Session

Der Tunnel wird nur dann aufgebaut, wenn initialer Traffic von dem Netz hinter der FRITZ!Box in Richtung Cisco ASA läuft. Ist dann der VPN-Tunnel aufgebaut, sehen die Session Details auf der ASA in etwa so aus:

S2S ASA-FB - ASA 07 VPN Session Details

Bei der FRITZ!Box sieht man in dem VPN Bereich dann folgenden grünen Bubble:

S2S ASA-FB - FB 01 VPN-Verbindungen

Mission completed! ;)

33 thoughts on “IPsec Site-to-Site VPN Cisco ASA <-> AVM FRITZ!Box

  1. Hallo, großartige Anleitung.
    Der IPSec Tunnel steht auch.
    Allerdings werden keine Pakete über den Tunnel geroutet.
    Sind noch weitere Einstellungen auf Seiten der ASA nötig?

    1. Hm, also wenn der Tunnel steht ist das aus Sicht von IKE und IPsec schon mal gut. ;) Routing-technisch muss auch nichts mehr passieren, da die ASA ja nie eine “Route” für ihre VPNs braucht, sondern ihr “policy-based VPN” umsetzt, also die Netze hinter einem Tunnel per policy in den Tunnel routed.

      Ich vermute dein Problem eher im Bereich von den NAT Regeln auf der ASA. Die machen ja leider häufig Probleme. Hast du ein generelles Outgoing NAT auf der ASA, was alle Pakete in Richtung outside auf die Interface-IP des outside Interfaces NATen? Wenn ja, dann brauchst du vorher eine Art No-NAT Regel, bei der du von dem inside-Netz nach Netz-hinter-VPN ein “Original” Packet auswählst. Spiel einfach damit herum. Bzw. google nach anderen Site-to-Site Anleitung zwischen zwei ASAs. Dort sollten solchen NAT-Regeln auch beschrieben sein.
      Wird denn bei deinem Tunnel nur in eine Richtung keine Pakete verschickt (also nur Tx oder Rx), oder gehen wirklich gar keine Pakete drüber?

      Achso, und die Access Rules auf der ASA müssen natürlich auch Pakete in Richtung Netz-hinter-dem-VPN zulassen. Aber das sollte klar sein. ;)

      Ciao, Johannes

      1. Hi!

        Danke für die Anleitung, aber ich kriege nur eine “PHASE 1” aufgebaut. Der meckert immer über die Crypto Map: no matching crypto map entry for remote proxy… . Ich habe die Crypto Map schon mehrfach überprüft, aber ohne Erfolg! :-(

        Hast Du noch einen Tipp für mich?

        Danke und Grüße,
        André

        1. Hm, das könnte auch am Connection Profile liegen. Dort wird ja der Link zur Crypto Map gebaut. Wichtig beim Connection Profile ist, dass das “Static” Häkchen NICHT drin ist, damit es eine “dynamic” Crypto Map ergibt (also für den Fall, dass deine FRITZ!Box hinter einer dynamischen IP hängt). In der Cypto Map müssen dann natürlich die richtigen IP-Netze spezifiziert sein. Daran könnte es auch liegen.

          Überprüfe zur Sicherheit halber noch mal deine Netze in der FRITZ!Box Konfig. Diese müssen 1 zu 1 mit der in der ASA übereinstimmen!

          1. Danke! Werde ich überprüfen, sobald ich wieder beim Kunden bin. Ich habe schon viele Tunnel aufgebaut, aber noch nie mit einer Fritzbox. ;-)

            Die Crypto-Map hat eigentlich die korrekten Netze und das Static ist definitiv nicht gesetzt! Die Topologie sieht in etwa so aus:

            Standort A ist mit Fritzbox direkt über dynamischer IP im Netz.
            Standort B ist mit einem NoName Router direkt mit einer festen IP im Netz und leitet die Ports 500 und 4500 an die Cisco ASA im internen Netz weiter. Normale VPNs funktioniern tadellos, nur mit der Fritzbox komme ich über die PHASE 1 nicht hinaus… :-(

  2. Hi,

    ich wollte mich noch einmal kurz melden!
    Soeben habe ich den Tunnel erfolgreich aufgebaut. Habe dazu noch einmal alles neu eingerichtet (VPN- Profile)… hatte anscheinend nur irgendwo etwas vergessen gehabt.

    Das Problem mit den Paketen hatte ich letztendlich auch, habe dementsprechend ein Static-NAT eingerichtet und in die richtige Reihenfolge gebracht, denn beim Neu erstellen eines Eintrage sitzt dieser immer automatisch am Ende. Das muss korrigiert werden! Dann flutscht dit ooch… ;-)

  3. Hallo,
    diese Anleitung hat mir ungemein geholfen. Da ich jedoch statische IP-Adressen an beiden Endpunkten habe, ist meine Peer IP Address in der Cisco ASA statisch und die localid in der FRITZ!Box-Konfiguration ist über den ipaddr-Wert definiert.

    Nachdem mein VPN schließlich stand, habe ich etwas herum experimentiert. Und es gelang mir, die Verschlüsselung in Phase 2 von 3DES auf AES-256 umstellen. Dazu habe ich nur noch im Connection Profile der Cisco ASA den IPSEC Proposal-Wert auf “ESP-AES-256-SHA” abgeändert und in der FRITZ!Box-Konfiguration den phase2ss-Wert auf “esp-aes-sha/ah-all/comp-lzjh-no/pfs” gesetzt, den ich in einem AVM-Dokument “Sicherheitsstrategien für VPN-Verbindungen IKE PHase 2” gefunden hatte.

    Übrigens wird mit der aktuellen Labor-Firmware von FRITZ!Box 7390/7490 auch die DH Gruppe 5 unterstützt, was bestimmt in eine der nächsten freigegebenen Firmware-Releases einfließen wird. Der phase1ss-Wert muss dazu auf “dh5/aes/sha” gesetzt sein.

  4. Hallo,
    hat das ganze schon mal jemand im Main Mode von der IKE-Phase 1 zum laufen bekommen? Also statt mit dem Parameter mode = phase1_mode_aggressive; mit mode = phase1_mode_idp; die VPN aufbauen zu können?

    Wir haben es bis jetzt nicht geschafft die VPN zwischen ASA und Fritzbox im Main Mode laufen zu lassen. :(

    1. Hi Alex,
      nein, mit einer ASA habe ich das noch nicht getestet. Mit Juniper Firewalls schon oft (siehe meine anderen Blogposts).

      Die ASA unterstützt im Main Mode ja nur IP-Adressen für den Peer. (Die Juniper verkraftet dort auch einen FQDN.) Das heißt, die FRITZ!Box muss eine statische IP-Adresse haben, damit das funktionieren kann. Ist das bei euch so?

  5. Hi Johannes,
    Danke für die super Anleitung. Bevor ich mich gross an die Konfiguration mache wollte ich fragen, ob auch eine dynamische IP seitens der ASA möglich ist? Wie müsste ich das anpassen?

    Danke und Grüsse
    Ben

    1. Jein. Also die Cisco ASA kann generell von sich aus nur VPNs zu einer statischen IP Adresse aufbauen, auch wenn sie selber eine dynamische hat. Sprich: Wenn deine FRITZ!Box ein statische Adresse hat (was ich nicht vermute), dann wird es klappen. Die Konfiguration sieht dann natürlich bei beiden Seiten etwas anders aus. Da müsstest du mal etwas testen. ;)
      Wenn die FRITZ!Box ebenfalls eine dynamische Adresse hat, somit also beide Seiten dynamisch sind, dann wird es mit der ASA nichts. Dort bräuchtest du dann eine vernünftige Firewall, wie zum Beispiel eine FortiGate. Oder eben zwei FRITZ!Boxen, die können das ebenfalls.

      Ciao,
      Johannes

      1. Vielen Dank für die Antwort. Mittlerweile steht die Verbindung mit einer fixen IP (ASA) und einer dynamischen IP (Fritzbox) und die Daten fliessen in beide Richtungen. Leider wird der Tunnel aber alle ca 90 Minuten wieder neu aufgebaut (LT8h/all/all/all). Hat jemand eine Idee wie man das Problem beheben kann da VoIP davon betroffen ist?

        Vielen Dank

        1. Okay, das ist ja schon mal ein guter Anfang. Hast du mal mit verschiedenen Proposals rumgespielt? Siehe hier: https://weberblog.net/fritzos-ab-06-23-ipsec-p2-proposals-erweitert/
          Du kannst in der ASA ja ganz schön sehen, welches Proposal im Endeffekt ausgehandelt wurde, also wie lange das Intervall bis zum nächsten Rekey ist.
          Wird denn der ganze Tunnel neu aufgebaut (was wohl eher ein Fehler wäre), oder wird nur eine der Phasen neu ausgehandelt (Rekey), was einfach leider einen kurzen Timeout verursacht?

          Cu,
          Johannes

  6. hi there
    Is it possible for fritzbox to connect to vpn with both vpn sites on dynamic dns using fQDN???

    1. Hi Steven,
      yes, on the FRITZ!Box side this is possible. (But not on the Cisco ASA side, if you want to terminate your VPN there.)
      Cheers,
      Johannes

      1. How do I make fritzbox VPN to another site that has dynamic up address??? I am not using Cisco at the other end. If I make the remoteip = 0.0.0.0 it doesn’t work. I am not sure how to put fqdn in on the fritzbox

        1. I managed to set up a tunnel between a Cisco ASA and a Fritzbox which are both using dynamic IP´s. This is my config:

          vpncfg {
          connections {
          enabled = yes;
          conn_type = conntype_lan;
          name = “fritz_ASA”;
          always_renew = yes;
          reject_not_encrypted = no;
          dont_filter_netbios = yes;
          localip = 0.0.0.0;
          local_virtualip = 0.0.0.0;
          remoteip = 192.168.172.2;
          remotehostname = “asa.xxx.com”;
          remote_virtualip = 0.0.0.0;
          localid {
          fqdn = “fritz.xxx.com”;
          }
          remoteid {
          fqdn = “asa.xxx.com”;
          }
          mode = phase1_mode_aggressive;
          phase1ss = “LT8h/all/all/all”;
          keytype = connkeytype_pre_shared;
          key = “secretkey”;
          cert_do_server_auth = no;
          use_nat_t = no;
          use_xauth = no;
          use_cfgmode = no;
          phase2localid {
          ipnet {
          ipaddr = 192.168.0.0;
          mask = 255.255.255.0;
          }
          }
          phase2remoteid {
          ipnet {
          ipaddr = 192.168.172.0;
          mask = 255.255.255.0;
          }
          }
          phase2ss = “esp-all-all/ah-none/comp-all/pfs”;
          accesslist = “permit ip any 192.168.172.0 255.255.255.0”;
          } 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”;
          }

          1. Ben you are genius!!!! thank you so much!!!
            that is what i needed
            remotehostname = “asa.xxx.com”;

    1. Yeah, this would be a good idea. Unluckily I don’t have this scenario anymore, so I cannot “show” the configuration. I am sorry. You must use ASDM for your own config and generate an template, or the like.
      Johannes

  7. Is there a way to route a LAN traffic from teh FritzBox into the VPN tunnel. So no “local outbreak” to internet for the LAN-Users.

    1. Hi J,
      I am not sure whether I fully understood your problem. You just want to add another route into the FRITZ!Box, e.g., for all RFC1918 subnets in order to prevent connections to these IP ranges to the ISP? If so, I don’t know how. Sorry. ;(
      Workaround: Create a dummy (but running) VPN to the required IP spaces.

  8. The ASA uses access control lists (ACLs) to differentiate the traffic to be protected with IPSec encryption from traffic that does not require protection. Protects outbound packets that match a Permission Application Control (ACE) engine and ensures that incoming packets that match an ACE permit are protected.

    object-group network local-network
    network-object 10.10.10.0 255.255.255.0
    object-group network remote-network
    network-object 10.20.10.0 255.255.255.0

    access-list asa-router-vpn extended permit ip object-group local-network
    object-group remote-network

  9. Hello, I set up like yours and it’s working well. But I have two networks on two separate interfaces behind the ASA I need to reach from behing the FritzBox.

    How can I tell FritzBox that there are not one but two networks to be reached?

    Tried something like this:

    phase2remoteid {
    ipnet {
    ipaddr = 192.168.1.0;
    mask = 255.255.255.0;
    }
    ipnet {
    ipaddr = 192.168.2.0;
    mask = 255.255.255.0;
    }
    }

    accesslist = “permit ip any 192.168.1.0 255.255.255.0”,
    accesslist = “permit ip any 192.168.2.0 255.255.255.0”;

    the accesslist actually works, because its syntax is also suggeste on AVM website. But it’s the phase2remoteid { I can’t manage to get it working…

    Do you have any suggestion? thanks

    1. Hi Mark,

      I know that request – but I don’t have a solution right now. I don’t know if you can actually use the “ipnet {}” statement more than once in the FRITZ!Box.
      Please try the following: Use a single ipnet statement with a bigger IP subnet. Of course the same subnet should be configure in the ASA VPN tunnel settings. For example:
      ipnet {
      ipaddr = 192.168.0.0;
      mask = 255.255.252.0;
      }
      This would tunnel all four /24 between 192.168.0.0 and 192.168.3.0. Maybe that’ll work?
      Cheers
      Johannes

      PS: Here is alomst the same question, but also without an answer: https://www.heise.de/forum/c-t/Kommentare-zu-c-t-Artikeln/VPN-Fritzboxen-mit-Profi-Firewalls-vernetzen/Mehrere-Zielnetze-erreichen/posting-31022894/show/

      1. Hi and thanks for the answer. I already tried that. But unfortunately, network behind FritzBox will overlap the supernetted network behind ASA.

        Behind Fritzbox: 192.168.1.0/24
        Behind ASA: 192.168.0.0/24 and 192.168.250.0/24

        I will try to change the network behind FritzBox to something in the 172.16.0.0/12 network and I’ll let you know.

        Thanks

  10. So question is, can a laymen with no CLI configure the ASA5505 to join VPN into a Fritzbox using the GUI??

  11. Hallo Johannes,

    leider funktioniert das nur im Aggressive Mode. Im Main Mode ist die IKE Identity ja verschlüsselt und da die IP eben dynamisch ist, hat die ASA kein Merkmal, welcher PSK zu verwenden ist. Man könnte höchstens die DefaultL2LGroup verwenden. Dann müssten aber alle dynamischen Peers den gleichen PSK haben. Das möchte man eigentlich auch nicht haben.

    IKEv2 macht das besser: Hier wird eine Mischung beider Modi verwendet. Aber das kann die FB ja nicht.

    Hast du zufällig noch die CLI Konfig für die ASA? Ich hatte das so ähnlich auch mal zum laufen gebracht, musste dann aber feststellen, dass das dynamische Peer der ASA im Prinzip alle möglichen Traffic Selektoren “einreden” konnte…

    Lukas

    1. Hallo Lukas. Ich musste gerade erst mal lachen, dass dieser Blogpost schon 10 Jahre alt ist. Hahaha. Wow.

      Ich arbeite ehrlich gesagt seit Jahren schon nicht mehr mit der ASA. (Und ich kennen auch nicht mehr wirklich Leute, die das noch tun. Es scheint mir schon eher untypisch zu sein dieser Tage.)

      Anyway: Du hast natürlich recht, dass man den Main-Mode bei IKEv1 nur dann nutzen kann, wenn man *feste* IP-Adressen auf beiden Seiten hat. Sonst ist der Aggressive Mode nötig. ABER: Hier gibt es generell die Peer ID, die genau dafür sorgt, dass man verschiedene Peers (mit verschiedenen unbekannten IP-Adressen) der jeweils richtigen/eindeutigen Phase 1 Konfiguration zuordnen kann. Das ist der Standard auf allen Firewalls wie der Palo Alto oder der FortiGate. Evtl. lässt sich das auf einer Cisco ASA aber nicht konfigurieren? Das weiß ich ehrlich gesagt gerade nicht und kann es auch leider nicht mehr selbst herausfinden. Also außer Google halt, aber das wirst du auch selbst können. ;) Die Peer ID ist tatsächlich auch *nicht* verschlüsselt. Ich nutze daher dafür immer einen zufällig generierten String. Dann passt das schon. Die Authentifizierung hängt sowieso vom PSK ab.

      Gib mal Bescheid, falls du das hinbekommen hast. Ich nehme an, dass du dafür konkret einen Use Case hast?

  12. Hi Johannes,

    dann sind wir wohl eher untypisch unterwegs. Aber das wusste ich auch schon vorher. ;-) Spaß beiseite: Man kann ja immer noch ASAs kaufen. Der Trend geht natürlich in Richtung Firepower OS, aber auch das Legacy OS ist noch supported.

    Ich glaube, du liegst falsch. Im Main Mode sind die Identities / Peer IDs verschlüsselt, daher nennt man diesen Modus auch Identity Protection. Um die Identities zu entschlüsseln braucht man den richtigen Schlüssel. Aber welcher ist das? Als Merkmal zur Auswahl des Schlüssels habe ich nur die IP-Adresse und die ist eben dynamisch, also nicht Bestandteil der Konfig. Somit bleiben nur zwei Wege:

    1. Alle Schlüssel durchprobieren.
    oder
    2. Ein gemeinsamer Schlüssel für alle unbekannten Peers (DefaultL2LGroup auf der ASA).

    Beides nicht gerade tolle Lösungen… RFC 2409 äußert sich dazu wie folgt:

    “When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. Aggressive Mode allows for a wider range of identifiers of the pre-shared secret to be used. In addition, Aggressive Mode allows two parties to maintain multiple, different pre-shared keys and identify the correct one for a particular exchange.” (Seite 16).

    Es geht also prinzipbedingt nicht. Man könnte eben maximal auf Aggressive Mode wechseln. (Du solltest nochmal prüfen, ob die Palo Alto und FortiGate das nicht auch tun!? Anders kann ich es mir nicht erklären.)

    Alternativ besteht die Möglichkeit
    5.1 Authentication with Digital Signatures
    oder
    5.2 Authentication with Public Key Encryption
    zu verwenden. Die kommen, sofern ich die Zusammenhänge richtig verstanden habe, mit dynamischen IPs im Main Mode klar.

    Oder aber du wechselst gleich zu IKEv2. Hier werden die Identities ebenfalls verschlüsselt übertragen. Als Schlüssel dient aber das DH-Secret. Ist also eher “Identity Protection für Arme” :-D Das sagt der Standard aber auch klar: “A man-in-the-middle attacker who cannot complete the IKE_AUTH exchange can nonetheless see the identity of the initiator.” (RFC 7296, Seite 10) Dafür funktioniert aber ein PSK mit dynamischer IP. ;-) Hier hat die ASA dann aber wirklich eine Einschränkung, was die Konfiguration betrifft: Es funktioniert zwar, aber das dynamische Peer kann der ASA quasi beliebige IPsec Policies / Traffic Selektoren “einreden”. Mit einer ACL kann man den Traffic wegfiltern, aber schön ist das nicht.

    Für die Fritz!Box ist der Lösungsraum leider äußerst beschränkt: Zwar sind Main Mode und Aggressive Mode einstellbar, aber eben nur mit PSK Auth. IKEv2 kann die Fritz!Box auch nicht. Somit bleibt für eine Fritz!Box mit dynamischer IP meiner Ansicht nach nur der Aggressive Mode. Unabhängig von der Hardware auf der Gegenseite. Gern kannst du mich vom Gegenteil überzeugen. :-)

    Ich habe vor, das Ganze in einem Blog-Beitrag nochmal etwas anschaulicher zu beschreiben.

    LG Lukas

    P.s. eine Möglichkeit fiele mir ein, wie das Palo Alto bzw. FortiGate machen könnten: Sofern ein Reverse DNS Eintrag der Peer IP auf einen bekannten FQDN gesetzt ist, wäre das machbar. Aber wer hat schon Einfluss auf der Reverse DNS seiner dynamischen IP?

    1. Hey Lukas.

      “Für die Fritz!Box ist der Lösungsraum leider äußerst beschränkt: Zwar sind Main Mode und Aggressive Mode einstellbar, aber eben nur mit PSK Auth.” –> Ich sehe hier aber kein Problem. Die “Sicherheit” der Authentifizierungsmethode, also PSK vs. Zertifikat, hängt ja von der Entropie ab. Wenn dein PSK lang genug ist und echt zufällig generiert wurde, kannst du ihn auch ohne Sicherheitsbedenken einsetzen. Siehe dazu auch: https://weberblog.net/passwords-vs-private-keys/

      Der Nachteil am Aggressive Mode ist ja noch, dass dich ein Angreifer von gespooften Source Adressen halt DDOSen kann, weil es ja von vornherein keine Einschränkung der IP-Adressen gibt. Mir ist aber bisher noch kein Fall bekannt, wo längerfristig damit wirklich VPN-Gateways abgeschossen wurden.

      “P.s. eine Möglichkeit fiele mir ein, wie das Palo Alto bzw. FortiGate machen könnten: Sofern ein Reverse DNS Eintrag der Peer IP auf einen bekannten FQDN gesetzt ist, wäre das machbar. Aber wer hat schon Einfluss auf der Reverse DNS seiner dynamischen IP?” –> Ich weiß nicht genau, ob ich deine Idee richtig verstehe. Was ich aber schon seit Jahren mache, ist, die Fritzbox per DynDNS einen Hostnamen zu verpassen, und dann das Site-to-Site VPN sehr wohl als “Main” (und nicht Aggressive” aufzubauen. Die FortiGate kann das zB schon ewig, dass ein VPN zu einem “Dynamic DNS” aufgebaut wird, wo dann tatsächlich der Main Mode genutzt wird. Siehe: https://weberblog.net/ipsec-site-to-site-vpn-fortigate-fritzbox/ Die Palo konnte das lange nicht, hat es aber vor ein paar Jahren auch dazu bekommen: Im IKE Gateway kann man beim “Peer IP Address Type” zwischen “IP | FQDN | Dynamic” wählen. ✅

Leave a Reply

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