AVM Fritzbox Kopplung (neuere FritzOS)


  • LAYER 8 Moderator

    Aloha,

    nachdem wir das jetzt mehrfach durchexerziert haben und einige Probleme hatten und auch AVM mit involviert, wollte ich hier kurz mal zusammenstellen, was gebraucht wird um eine Site2Site Kopplung mit einer Fritte hinzubekommen:

    Zuerst: Mehrere Netze oder Phase 2 Geschichten - ist nicht. Hier gehts eher um den üblichen Kram mit "Netz hinter Fritzbox" mit "Netz hinter pfSense" verbinden.
    Was es zusätzlich schwierig gemacht hat:

    1. AVM hat Anleitungen online, die Dinge suggerieren, die ihre Boxen gar nicht tun. Ob das am OS liegt oder ob da einfach die eine Hand nicht weiß was die andere tut - keine Ahnung. Auch sind die Informationen leider nicht wirklich vollständig.
    2. Die Fehlermeldungen sind nicht wirklich aussagekräftig ;)
    3. AVM hat im Reiter VPN jetzt selbst eine Möglichkeit implementiert mit dem man - angeblich einfach - eine Site2Site Kopplung machen kann. Mit anderer Fritte oder Firmen Netz. Beide können allerdings keinen Tunnel zu Strongswan auf der Sense aufbauen.
    4. Die unterstützten Cipher und Hash Algos sind selbst 2020 unterirdisch :(

    Wegen dieser Punkte wurde viel getestet und gerade wegen 4) nochmal verifiziert. Obwohl AVM bpsw. unter:

    https://avm.de/service/vpn/tipps-tricks/fritzbox-mit-einem-firmen-vpn-verbinden/

    angibt, dass die Box inzwischen AES bis 256 und SHA-512 sowie DH Gruppen 14/15 unterstützt, ist davon nur der erste Part wahr. Es wird tatsächlich AES-128/192/256 sowie SHA-512 (und NUR 512, ansonsten nur SHA-1 oder MD5...) unterstützt aber die versprochenen DH Gruppen 14/15 sind nirgendwo zu finden. Nichtmal die angegebene DH Group 5 (1536) wird gefunden. Aus dem übermittelten Proposal der Box kann man herauslesen, dass das Einzige Crypto-Set, das 2020 halbwegs vernünftig ist, folgende Einstellungen enthält:

    • AES-256 (oder 128) / SHA-512 / DH Group 2 (seufz)

    Desweiteren wird keine Perfect Forward Secrecy unterstützt (doppelseufz). Statt dessen wird tatsächlich immer noch 3DES oder sogar DES(!) im Proposal angeboten. Security ... klar!

    Der Knackpunkt ist aber, dass wie beschrieben man mit Bordmitteln der Fritte keine Tunnelverbindung hinbekommt. Entweder bekommt man Authentifizierungsfehler oder gar keinen Aufbau. Weder mit Punkt 2 noch mit Punkt 3 haben wir eine sinnvolle/stabile Verbindung hinbekommen.

    c69fe81f-8931-41cc-9010-5b118726fe8f-image.png

    Das Einzige was nach wie vor stabil klappt ist mit dem Fernzugangs-Assistent (dem Programm) eine Konfiguration zu generieren (oder sich selbst zu schreiben) und diese zu importieren. Damit hat es dann auch sofort auf Anhieb funktioniert.

    Fritz!Box Konfiguration: fritz-vpn.cfg

    vpncfg {
            connections {
                    enabled = yes;
                    conn_type = conntype_lan;
                    name = "<NAME_DER_VERBINDUNG>";
                    always_renew = yes;
                    reject_not_encrypted = no;
                    dont_filter_netbios = yes;
                    localip = 0.0.0.0;
                    local_virtualip = 0.0.0.0;
                    remoteip = <IP_der_Gegenstelle>;
                    remote_virtualip = <IP_der_Gegenstelle>;
                    localid {
                            fqdn = "<DYNDNS_NAME>";
                    }
                    remoteid {
                            ipaddr = <IP_der_Gegenstelle>;
                    }
                    mode = phase1_mode_aggressive;
                    phase1ss = "all/all/all";
                    keytype = connkeytype_pre_shared;
                    key = "<IPSEC_PSK>";
                    cert_do_server_auth = no;
                    use_nat_t = yes;
                    use_xauth = no;
                    use_cfgmode = no;
                    phase2localid {
                            ipnet {
                                    ipaddr = <FB_LAN_IP_RANGE>;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2remoteid {
                            ipnet {
                                    ipaddr = <PFSENSE_LAN_IP_RANGE>;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                    accesslist = "permit ip any <PFSENSE_LAN_IP_RANGE> 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";
    }
    
    // EOF
    

    Als localid haben wir einen dyndns Namen genutzt, da die Test-FB hinter einem dynamsichen Anschluß steht. Die Gegenstelle mit pfSense hatte eine statische IP. Ansonsten sollten die Platzhalter in der Konfiguration selbsterklärend sein :)

    Die andere Seite - pfSense - war konfiguriert wie folgt:

    IPSEC Einstellungen Phase 1:

    • IKEv1
    • IPv4
    • Interface WAN (oder was bei euch entsprechend passt)
    • Remote Gateway: <DYNDNS_NAME>
    • Description: Site2Site Tunnel xy
    • Authentication: Mutual PSK
    • Negotiation Mode: Aggressive (ja leider - wurde leider nirgends dokumentiert)
    • My Identifier: My IP address
    • Peer Identifier: Distinguished Name: <DYNDNS_NAME>
    • Pre-Shared Key: <IPSEC_PSK>
    • Phase 1 Proposal: AES | 256 bits | SHA512 | 2 (1024 bit)
      (das ist nebenbei auch das erste Proposal das die Box sendet)
    • Lifetime: 28800 ist standard, allerdings scheint die Box lediglich stupid 3600 zu nutzen

    alles "advanced" bleibt auf Standard. Wir hatten nur bei einigen Gegenstellen das Verhalten, dass die Verbindung alle paar Minuten neu aufgebaut wurde, anscheinend mit einem DPD Fehler. Offenbar macht dann wohl die Dead Peer Detection auf der FB schlapp und pfSense baut den Tunnel neu auf. Sollte das vorkommen, schaltet auf der pfSense die DPD ab und stellt ggf. in der Phase 2 dann einen Host ein, der zum Aufrechterhalten der Verbindung angepingt wird.

    IPSEC Phase 2:

    • Tunnel IPv4
    • Local Network: <PFSENSE_LAN_IP_RANGE> / 24
    • NAT/BINAT: None
    • Remote Network: <FB_LAN_IP_RANGE> / 24
    • Description: <irgendwas sinnvolles ;)>
    • Protocol: ESP
    • Encryption Algos: AES | 256 bits
    • Hash: SHA512
    • PFS key group: 2 / off -> sollte beides gehen, da offiziell PFS nicht unterstützt wird. Wir stellen sicherheitshalber das Gleiche wie bei Phase 1 ein
    • Lifetime: 3600

    Wie oben gesagt ggf. noch auto ping host konfigurieren. Aber vorsicht, nicht die andere Firewall/FB anpingen, das klappt bei IPsec oft nicht. Ihr müsst schon einen Host aus dem LAN der Gegenseite wählen, der auf Pings antwortet.
    Dann natürlich noch die Regeln und ggf NAT Settings auf der pfSense nicht vergessen und ihr solltet online sein.

    Aber ganz ehrlich: Am besten nehmt ihr euch eine kleine Streichholzschachtel-Router-Box wie bspw. Netgates SG1100 Mini ARM Box und hängt die hinter die Fritzbox und macht den Tunnel damit ;) Oder als FB Ersatz eine SG3100 (die hat dann auch den gleichen 4-Port Switch wie die Fritte - schöner Home-Ersatz).

    Nur wenn es eben dann doch irgendwo mal eine FB sein muss - vielleicht hilft euch das hier dann weiter :)



  • Mein SG-1100 hat zur 6490 mit den Einstellung zuverlässig funktioniert, jedoch ist das mit 6Mbit am rum gurken. Da hat auch die neue 7.19 Beta nix gerissen.

    Jetzt SG-3100 zu SG-1100 welche die 6490 abgelöst hat und der Tunnel rennt als IKEv2 mit 128Bit AES in Hardware mit den vollen 50Mbit in beiden Richtungen.
    Bin gespannt wann hier 256Bit in Hardware geht, dann stelle ich den Tunnel drauf um.

    Ich habe auf Fritz Seite den Tunnel jedoch so über die GUI hin bekommen, da war kein Configfile für notwendig.


  • LAYER 8 Moderator

    Anscheinend klappt es manchmal auch über die Oberfläche, wir hatten gestern nochmal einen längeren Test und dort hatte es ein von drei Mal dann doch funktioniert, allerdings eben dadurch nicht wirklich stabil und die Optionen sind zudem natürlich stark begrenzt.

    Das HauptManko der Konfig-Datei war bislang, dass man danach den Tunnel nicht mehr editieren konnte und nur löschen und neu importieren. Wir haben dafür die Konfig-Variable aber gefunden womit nach dem Einspielen das Editieren wieder möglich wird. Sobald ich wieder am Testrechner bin, kann ich da die Änderungen mit einbauen. Dazu haben wir auch durch manuelles editieren geschafft, den dämlichen Agressive Mode loszuwerden und den Tunnel mit AES-SHA512-DH2 mit normalen Main Mode aufzubauen. Warum AVM das SO stark verdummt und verkompliziert und dabei die Sicherheit vernachlässigt, kann ich allerdings nicht nachvollziehen. Finde das sehr bedauernswert.



  • Bin ich gespannt das zu lesen, das ist echt cool wenn man den sauber mit Main Mode zum laufen bringen könnte.

    Denn ich habe hier noch einige Fbox User die man dann ggf. mal sauber anbinden könnte.


  • Rebel Alliance

    @JeGr said in AVM Fritzbox Kopplung (neuere FritzOS):

    Aus dem übermittelten Proposal der Box kann man herauslesen, dass das Einzige Crypto-Set, das 2020 halbwegs vernünftig ist, folgende Einstellungen enthält:

    AES-256 (oder 128) / SHA-512 / DH Group 2 (seufz)
    

    Habe den Verdacht, die Kompatibilität zu den älteren Gerätschaften aufrecht zu erhalten, nicht jede Kiste von denen läuft mit 1Ghz und 512MB RAM (FB7590).

    Die ersten Fritzen konnten kein VPN, dann kam wahrscheinlich der Druck von den Kunden, dies zu Implementieren, auch wenn recht halbherzig, und jetzt kann damit beworben werden. :)

    Aber anders herum, wenn eine Fritze das gut sicher und schnell kann, würden weniger in Richtung Sense abwandern, imho...🖖

    Mike


  • LAYER 8 Moderator

    Hier nochmal die modifizierte Datei zum Einspielen.

    vpncfg {
            connections {
                    enabled = yes;
    		editable = yes;
                    conn_type = conntype_lan;
                    name = "<NAME_DER_VERBINDUNG>";
                    always_renew = yes;
                    reject_not_encrypted = no;
                    dont_filter_netbios = yes;
                    localip = 0.0.0.0;
                    local_virtualip = 0.0.0.0;
                    remoteip = <IP_der_Gegenstelle>;
                    remote_virtualip = 0.0.0.0;
    		keepalive_ip = <Keepalive_IP>;
                    localid {
                            fqdn = "<DYNDNS_NAME>";
                    }
                    remoteid {
                            ipaddr = <IP_der_Gegenstelle>;
                    }
                    mode = phase1_mode_idp;
                    phase1ss = "all/all/all";
                    keytype = connkeytype_pre_shared;
                    key = "<IPSEC_PSK>";
                    cert_do_server_auth = no;
                    use_nat_t = yes;
                    use_xauth = no;
                    use_cfgmode = no;
                    phase2localid {
                            ipnet {
                                    ipaddr = <FB_LAN_IP_RANGE>;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2remoteid {
                            ipnet {
                                    ipaddr = <PFSENSE_LAN_IP_RANGE>;
                                    mask = 255.255.255.0;
                            }
                    }
                    phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                    accesslist = "permit ip any <PFSENSE_LAN_IP_RANGE> 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";
    }
    
    // EOF
    

    Wichtig waren die Änderungen bzw. Neuerungen:

    • editable=yes -> interessant, dass AVM das per default unterbindet. Eigentlich unsinnig.
    • keepalive_ip = <Keepalive_IP> -> Dieses Feld tauchte im Export nur auf, wenn man die Verbindung über die UI erstellt hat. Dafür war dann aber der automatische renewal mit "always_renew" auf no. Soll einer verstehen warum man den Renew abschaltet nur um dann zum Offenhalten der Verbindung ständig einen Host anzupingen. Außer natürlich, dass die Config Option mal wieder ganz andere Dinge tun, als eigentlich beschrieben ;)
    • IKE Modus: phase1_mode_idp vs phase1_mode_aggressive -> egal welches Setup über UI oder mit Konfigurator, AES Setups wurden immer mit mode agressive erstellt. Warum ist uns nicht klar. Nur alte Setups mit 3DES oder dem was die Fritte Standard nennt, wurden im Main Mode aufgebaut. Bei einem Full Export fiel uns dann der Unterschied von idp vs agressive aus. Wir haben die Konfiguration so in die Box eingespielt und den Tunnel aufbauen lassen -> Tada, plötzlich ging AES auch im main mode.

    Seit gestern läuft das Setup und laut FB wurde der Tunnel gestern 14:24 aufgebaut, seither gab es keine weiteren Log Einträge dass er abgebaut worden wäre. Status ist auch nach wie vor up.

    a58dc2fd-1385-4a1a-9390-98bddd0af8f1-image.png

    Dabei ist 172.22.181 unser Testnetz auf pfSense Seite, das andere erkennbar das Standard FB LAN.
    Beim Erstellen in AVMs Windows Tool wird dieses Netz (192.168.178) übrigens abgelehnt, man solle ein anderes LAN nutzen um Kollisionen zu vermeiden. Dabei wird die Gegenseite erst danach abgefragt. Quark sowas. Man muss dann erst ein falsches LAN angeben und das Netz manuell in der Konfiguration ändern 🤦

    Einzige Auffälligkeit ist nach wie vor, dass sich die FB um die 28800 Timeout von Phase 1 nicht schert und nach wie vor nach 3600s (1h) ein Renew von Phase 1 macht. Das sollte laut Vorgaben von BSI und anderen Security Guidelines übrigens nicht der Fall sein, Phase 1 soll hier eindeutig länger als Phase 2 gehalten und rotiert werden. Wunsch ist eigentlich zwischen 8-24h - länger wäre wegen PFS dann nicht anzuraten.


Log in to reply