IPsec VPN mit strongSwan und FRITZ!Box Fon WLAN 7270 v3

Gestern musste ich eine VPN-Verbindung zwischen strongSwan (4.1.11) und einer FRITZ!Box 7270 v3 (74.04.80) einrichten. Die Einrichtung von VPN auf der FRITZ!Box ist etwas ungwöhnlich: Die Konfiguration findet nicht wie üblich über das Web Interface oder die Kommandozeile statt, sondern muss über das AVM eigene Windows-Programm “FRITZ!Fernzugang einrichten” erstellt werden.

Nach der Installation des entsprechenden Programms wird zunächst ausgewählt, dass eine Verbindung zwischen zwei FRITZ!Box-Netzwerken eingerichtet werden soll:

Danach wird entweder die IP-Adresse oder der DynDNS-Name der FRITZ!Box angegeben:

…und das interne Netzwerk hinter der FRITZ!Box:

Im nächsten Schritt fragt der Assistent exakt dieselben Daten für die Gegenstelle ab und erzeugt zwei entsprechende Konfigurationsdateien. Bevor die Konfigurationsdatei für die FRITZ!Box importiert werden kann, müssen allerdings noch einige Einstellungen angepasst werden.

Im Fall von strongSwan auf der Gegenseite betrifft das einmal den Austausch vom IKEv1 Aggressive Mode gegen den Main Mode und das Ersetzen des vorgegebenen Pre Shared Keys. Am Ende sollte die Konfigurationsdatei wie folgt aussehen (Änderungen rot markiert):

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "193.99.144.85";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 193.99.144.85;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "layer9.dyndns.org";
                }
                remoteid {
                        ipaddr = 193.99.144.85;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "Dh9tgxD8p5HNhQedKfiDoA93";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.100.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 172.16.0.0;
                                mask = 255.255.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 172.16.0.0 255.255.0.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

Anschließend kann die Datei auf der FRITZ!Box unter Erweiterte Einstellungen -> Internet -> Freigaben -> VPN importiert werden. Weitere Informationen zur Anpassung der Konfigurationsdateien gibt es übrigens hier und hier.

Die Tunneldefinition in der ipsec.conf von strongSwan sieht folgendermaßen aus:

conn berlin-layer9
        left=193.99.144.85
        leftsubnet=172.16.0.0/16
        #
        ike=aes128-sha-modp1024
        esp=aes128-sha1
        #
        right=layer9.dyndns.org
        rightid=@layer9.dyndns.org
        rightsubnet=192.168.100.0/24
        #
        ikelifetime=4h
        keylife=1h
        #
        authby=secret
        auto=add

Wird wie hier in der FRITZ!Box Konfigurationsdatei der DynDNS Name angegeben, muss dies unter strongSwan sowohl in der Tunnelkonfiguration mittels rightid=@layer9.dyndns.org als auch beim Eintrag des PSK in der ipsec.secrets berücksichtigt werden. Andernfalls erwartet strongSwan trotz Angabe von right=layer9.dyndns.org die IP-Adresse als Peer ID:

debian:~# ipsec up berlin-layer9

002 "berlin-layer9" #30802: initiating Main Mode
104 "berlin-layer9" #30802: STATE_MAIN_I1: initiate
003 "berlin-layer9" #30802: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
003 "berlin-layer9" #30802: received Vendor ID payload [XAUTH]
003 "berlin-layer9" #30802: received Vendor ID payload [Dead Peer Detection]
003 "berlin-layer9" #30802: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
003 "berlin-layer9" #30802: ignoring Vendor ID payload [a2226fc364500f5634ff77db3b74f41b]
002 "berlin-layer9" #30802: enabling possible NAT-traversal with method RFC 3947
106 "berlin-layer9" #30802: STATE_MAIN_I2: sent MI2, expecting MR2
003 "berlin-layer9" #30802: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
108 "berlin-layer9" #30802: STATE_MAIN_I3: sent MI3, expecting MR3
003 "berlin-layer9" #30802: ignoring informational payload, type IPSEC_INITIAL_CONTACT
002 "berlin-layer9" #30802: Peer ID is ID_FQDN: '@layer9.dyndns.org'
003 "berlin-layer9" #30802: we require peer to have ID '72.14.221.104', but peer declares '@layer9.dyndns.org'
218 "berlin-layer9" #30802: STATE_MAIN_I3: INVALID_ID_INFORMATION
002 "berlin-layer9" #30802: sending encrypted notification INVALID_ID_INFORMATION to 72.14.221.104:4500

Bleibt im Fall von DynDNS noch das Problem, dass strongSwan den DNS-Eintrag nur beim Starten oder Aktualisieren der Konfiguration neu auflöst. Offenbar kann man strongSwan aber so konfigurieren, dass die Konfiguration in gewissen Abständen automatisch aktualisiert wird (Stichwort ipsec starter –auto-update). Getestet habe ich das bis jetzt noch nicht; wir haben dem Betreiber der FRITZ!Box stattdessen eine feste IP-Adresse empfohlen.

About these ads

18 Responses to “IPsec VPN mit strongSwan und FRITZ!Box Fon WLAN 7270 v3”


  1. 1 Renne August 29, 2010 um 11:26 nachmittags

    Hi,

    ich versuche seit zwei Tagen einen IPSec-Tunnel von einem Ubuntu-10.04-LTS-Server zu einer Fritzbox 7170 zu konfigurieren, aber es funktioniert weder mit StrongSWAN noch mit OpenSWAN. Wie müßte denn eine Konfiguration auf dem Ubuntu-Server aussehen?

    Netzstruktur:

    Server:
    eth0:0 xxx.xxx.xxx.102/24 (public IP)
    dummy0 192.168.176.1/32

    Fritzbox:
    DynDNS: .dnsalias.net
    lokal: 192.168.178.1/24

    Alle Hosts in 192.168.178.0/24 an der Fritzbox sollen mit allen Diensten auf der Server-IP 192.168.176.1 kommunizieren können und umgekehrt, aber aus dem öffentlichen Netz darf kein Zugriff auf 192.168.178.1 möglich sein.

    fritzbox.cfg:

    vpncfg {

    connections {

    enabled = yes;

    conn_type = conntype_lan;

    name = “xxx.xxx.xxx.102″;

    always_renew = no;

    reject_not_encrypted = no;

    dont_filter_netbios = yes;

    localip = 0.0.0.0;

    local_virtualip = 0.0.0.0;

    remoteip = xxx.xxx.xxx.102;

    remote_virtualip = 0.0.0.0;

    localid {

    fqdn = “.dnsalias.net”;

    }

    remoteid {

    ipaddr = xxx.xxx.xxx.102;

    }

    mode = phase1_mode_aggressive;

    phase1ss = “all/all/all”;

    keytype = connkeytype_pre_shared;

    key = “”;

    cert_do_server_auth = no;

    use_nat_t = yes;

    use_xauth = no;

    use_cfgmode = no;

    phase2localid {

    ipnet {

    ipaddr = 192.168.178.0;

    mask = 255.255.255.0;

    }

    }

    phase2remoteid {

    ipnet {

    ipaddr = 192.168.176.0;

    mask = 255.255.255.0;

    }

    }

    phase2ss = “esp-all-all/ah-none/comp-all/pfs”;

    accesslist = “permit ip any 192.168.176.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″;

    }

    server.cfg:

    vpncfg {

    connections {

    enabled = yes;

    conn_type = conntype_lan;

    name = “.dnsalias.net”;

    always_renew = no;

    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 = “.dnsalias.net”;

    localid {

    ipaddr = xxx.xxx.xxx.102;

    }

    remoteid {

    fqdn = “.dnsalias.net”;

    }

    mode = phase1_mode_aggressive;

    phase1ss = “all/all/all”;

    keytype = connkeytype_pre_shared;

    key = “”;

    cert_do_server_auth = no;

    use_nat_t = yes;

    use_xauth = no;

    use_cfgmode = no;

    phase2localid {

    ipnet {

    ipaddr = 192.168.176.0;

    mask = 255.255.255.0;

    }

    }

    phase2remoteid {

    ipnet {

    ipaddr = 192.168.178.0;

    mask = 255.255.255.0;

    }

    }

    phase2ss = “esp-all-all/ah-none/comp-all/pfs”;

    accesslist = “permit ip any 192.168.178.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″;

    }

  2. 2 layer9 August 30, 2010 um 4:01 nachmittags

    Die strongSwan Konfig muss unabhängig von der Distribution gleich sein. Wie sieht sie denn bei Dir aus und was sagt die Logdatei?

    Ansonsten funktioniert phase1_mode_aggressive defintiv nicht, das hatte ich ja geschrieben.

    • 3 Renne August 30, 2010 um 11:18 nachmittags

      Nach einem “apt-get purge openswan strongswan” und einem “apt-get autoremove” habe ich noch die Configs der Fritzboxen auf “mode = phase1_mode_idp;” geändert. Ohne OpenSWAN-Leichen funktionieren jetzt die Verbindungen zwischen den lokalen Netzen des Servers und der Fritzbox! :-)

      Danke! :-)

  3. 4 Michael September 6, 2010 um 8:15 nachmittags

    Hi,
    wie sieht denn die ipsec.secrets aus?

    @layer9.dyndns.org: PSK “Dh9tgxD8p5HNhQedKfiDoA93″

    Ich habe es mit der oberen Konfiguration probiert, bekomme aber immer eine Fehlermeldung das er keinen PSK findet.

    Danke,
    Michael

  4. 5 layer9 September 6, 2010 um 8:42 nachmittags

    Angenommen die strongSwan ID wäre z.B. die IP-Adresse 193.99.144.85 und die ID der FritzBox der FQDN @layer9.dyndns.org müsste der Eintrag wie folgt aussehen:

    193.99.144.85 @layer9.dyndns.org: PSK “dasistderpre-shared-key“

  5. 6 Michael September 7, 2010 um 8:20 nachmittags

    Hi,
    danke für den Tipp. Jetzt funktioniert der Verbindungsaufbau.
    Allerdings habe ich noch Probleme mit dem Routing. Ich kann von dem Netz hinter der Frit!Box in das andere Netz pingen. Der Weg anderherum funktioniert nicht. Bei einem tracert schickt er die Pakete über die Defaultroute ins Internet und nicht in den Tunnel. Ich habe aber kein ipsec0 Interface so dass ich eine Route setzen könnte.

    Gruß,
    Michael

  6. 7 layer9 September 8, 2010 um 7:20 vormittags

    In strongSwan gibt es kein ipsec0 Interface mehr und es ist normal, dass Du die unverschlüsselten Pakete auch auf dem externen Interface siehst.

    Wenn ein Ping von der anderen Seite aus funktioniert, kann es eigentlich auch kein Routingproblem sein – schließlich erhälst Du ja die Antworten aus dem anderen Netz. Für mich klingt das eher nach einer aktivierten Firewall auf dem Rechner hinter der FritzBox, den Du versucht anzupingen. Guck doch dort mal mit einem Sniffer (Wireshark/tcpdump) nach den ICMP Echo Requsts.

    • 8 Michael September 8, 2010 um 1:05 nachmittags

      Firewalls sind keine aktiviert außer in der Fritzbox und auf dem Linux System den Tunnel zur Fritzbox aufbaut und der die Pakete per NAT ins LAN weiterleitet. Es funktionieren auch andere TCP Dienste wie RDP oder SMB nur in eine Richtung. Was mich halt wundert ist, das ein tracert die Pakete die eigentlich in den Tunnel geschickt werden sollen über das Default Gateway ins Internet schickt.

  7. 9 layer9 September 8, 2010 um 2:58 nachmittags

    Wenn Du vom Netz hinter strongSwan einen Rechner hinter der FritzBox anpingst – was siehst Du dann mit tcdump auf dem externen Interface (also dem mit der Default Route)?

    Sind die Echo Requests verschlüsselt (ESP)? Haben sie als Ziel-IP die Adresse des anderen VPN Gateways (die der FritzBox)? Dann gehen sie in den Tunnel.

    Oder sind die Pakete möglicherweise unverschlüsselt und werden genattet? D.h. wenn Du 192.168.100.1 anpingst, wird die Quell-IP dann durch die IP vom Interface mit dem Default Gateway ersetzt und bleibt die Ziel-IP 192.168.100.1 unverändert?

    Vielleicht solltest Du in iptables mal testweise alles auf ACCEPT setzen, alle NAT Regeln löschen und prüfen, ob es dann funktioniert.

    • 10 Michael September 8, 2010 um 4:52 nachmittags

      Vielen Dank für den Tipp mit der Firewall. Ich habe eine zusätzlich Regel eingefügt, dass alle Pakete mit dem Zielnetz der Fritzbox nicht genattet werde.

      • 11 layer9 September 8, 2010 um 6:34 nachmittags

        Das wirft jetzt eine Frage auf: Wenn die Pakete ins Zielnetz genattet wurden und dadurch nicht in den Tunnel gegangen sind, warum haben dann Verbindungen von der Gegenseite funktioniert, also warum wurden die Antwortpakete nicht auch genattet?

        Oder hast Du nur neue Verbindungen (-m state –state NEW) natten lassen, so dass bereits hergestellte Verbindungen (-m state –state ESTABLISHED,RELATED) möglicherweise nicht davon betroffen waren? Anders könnte es mir momentan nicht erklären.

  8. 12 smart-gp November 28, 2010 um 9:26 nachmittags

    Vielen Dank für Deine Anleitung.

    Ich benutze OpenSuSE 11.2 mit StrongSwan 4.3.4 und Fritzboxen 7390, 7270v3, 7270v2 und 7240 mit dem letzten Firmware-Release, bzw. der letzten Labor von gestern.

    Damit komme ich erfolgreich bis zu IKE-Phase 1.

    Dann sagt das Log:

    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: initiating Main Mode
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: received Vendor ID payload [XAUTH]
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: received Vendor ID payload [Dead Peer Detection]
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: Peer ID is ID_FQDN: ‘@xxxxx.mine.nu’
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: ISAKMP SA established
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
    Nov 28 19:29:25 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type INVALID_ID_INFORMATION
    Nov 28 19:29:35 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type INVALID_ID_INFORMATION
    Nov 28 19:29:55 xx-yy-83-18 charon: 02[KNL] creating delete job for ESP CHILD_SA with SPI d538237a and reqid {16385}
    Nov 28 19:29:55 xx-yy-83-18 charon: 09[JOB] CHILD_SA with reqid 16385 not found for delete
    Nov 28 19:29:55 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type INVALID_ID_INFORMATION
    Nov 28 19:30:35 xx-yy-83-18 pluto[2952]: “wb” #2: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
    Nov 28 19:30:35 xx-yy-83-18 pluto[2952]: “wb” #2: starting keying attempt 2 of at most 3, but releasing whack
    Nov 28 19:30:35 xx-yy-83-18 pluto[2952]: “wb” #3: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #2 {using isakmp#1}
    Nov 28 19:30:35 xx-yy-83-18 charon: 10[CFG] received stroke: initiate ‘wb’
    Nov 28 19:30:35 xx-yy-83-18 charon: 10[CFG] ignoring initiation request for IKEv1 config
    Nov 28 19:30:35 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type INVALID_ID_INFORMATION
    Nov 28 19:30:45 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type INVALID_ID_INFORMATION
    Nov 28 19:31:05 xx-yy-83-18 charon: 02[KNL] creating delete job for ESP CHILD_SA with SPI 8b9b722b and reqid {16385}
    Nov 28 19:31:05 xx-yy-83-18 charon: 12[JOB] CHILD_SA with reqid 16385 not found for delete
    Nov 28 19:31:05 xx-yy-83-18 pluto[2952]: “wb” #1: ignoring informational payload, type INVALID_ID_INFORMATION
    Nov 28 19:31:45 xx-yy-83-18 pluto[2952]: “wb” #3: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

    Hat dazu jemand eine Idee?

  9. 13 j0k3r Februar 18, 2011 um 1:02 vormittags

    Zu smart-gp

    Vermute mal deine ipsec.secrets stimmt noch nicht ganz.

    Ansonsten lass doch mal deine config und die secrets sehen…

  10. 14 forum-merlin Dezember 17, 2011 um 11:00 nachmittags

    Hallo!
    ich bin ein Neuling in Sachen StrongSWAN.
    Und um ehrlich zu sein auch in Sachen IPsec.
    Ich sitze nun schon seit Tagen daran, einen StrongSWAN VPN Server auf einen Debian 6 ans Laufen zu bekommen. Bei mir sollen Fritzboxen als Clients arbeiten, die sich gegen diesen StrongSWAN verbinden.
    Mein Szenario schaut so aus: (privat bei mir Zuhause)

    Internet
    v
    Fritzbox 7390
    v
    Switch
    v
    ESXi Server >
    VMWare mit Debian 6
    2 NIC´s (virtuelle Netzwerkkarten)
    IP Bereich 1=10.11.12.0/24 (intern)
    IP Bereich 2=10.9.8.0/24 (VPN Netz)

    Der IP Bereich 1 soll von den VPN Clients (Fritzboxen) NICHT erreichbar sein
    Der IP Bereich 2 ist dann für die Clients (Fritzboxen) gedacht.

    Nur zwei Clients (mein Android Phone und mein PC in der Arbeit) sollen in den IP Bereich 1 verbunden werden, und müssen nicht zwingend auf den 2er Bereich gehen.

    FRAGEN:
    **************
    1) Hat jemand einen Guide für Blöde um das zu realisieren, oder könnte einen schreiben?
    >> Also wirklich unter dem Motto:
    “Melde dich als root auf dem Debian an, und tippe apt-get xxxxx…
    Öffne einen Editor Deiner wahl und editiere /etc/ipsec.conf
    Hier ein kurzer Überblick, für was welcher Parameter ist.

    Bei dem Teil mit dem Fritzbox Tool, und der daraus resultierenden CFG Datei könnte man dabei weglassen da es ja hier steht.
    Vielleicht nur noch eine Info, was in dem oben genannten Beispiel layer9.dyndns.org ist. >> Strongswan oder Fritzbox?

    2) Wie muss ich meiner Fritzbox in Sachen Portfreigaben konfigurieren?
    Muss ich die normale Config für VPN deaktivieren, und die Ports manuell an den Debian Server weitergeben? Wenn ja welche?

    3) wie sieht das Routing für die Clients aus, die als einzige in das IP Netz 1 dürfen?

    Da die Frage berechtigter Weise kommen wird…
    Ich will kein VPN zu meiner FB machen und da dan routen, da die FB ab einer gewissen Anzahl von Clients (unter 10 bereits) schlapp macht, heiss wird, und instabil.

    Ich sage Euch…
    DAS WÄRE ECHT SUPER, WENN JEMAND SOWAS MACHEN KÖNNTE.

    Vielen Dank schonmal.

    Gruß aus München.

    der Merlin.

  11. 15 Michael April 20, 2012 um 7:26 vormittags

    hallo, wirklich gutes howto, nur bei mir klappt es nicht, ich setze ein debian 6 ein und die gegenstelle ist eine fritzbox 7270 beide mit dyndns (dynamische ip) wie bekomme ich es hin?

    erstmal starte ich ipsec: /etc/init.d/ipsec start

    danach versuche ich mit: ipsec up fritz.dyndns.org die verbindung zu der fritzbox aufzubauen, leider bekomme ich nur diese fehlermeldung:

    002 “fritz.dyndns.org” #1: initiating Main Mode
    104 “fritz.dyndns.org” #1: STATE_MAIN_I1: initiate
    010 “fritz.dyndns.org” #1: STATE_MAIN_I1: retransmission; will wait 20s for response
    010 “fritz.dyndns.org” #1: STATE_MAIN_I1: retransmission; will wait 40s for response
    031 “fritz.dyndns.org” #1: max number of retransmissions (2) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message
    000 “fritz.dyndns.org” #1: starting keying attempt 2 of at most 3, but releasing whack

    wo ist mein fehler

    hier noch meine ipsec.secret:
    fritz.dyndns.org @fritz.dyndns.org: PSK “nichts für euch”

    hier noch meine ipsec.conf:

    config setup
    plutodebug=all
    # crlcheckinterval=600
    # strictcrlpolicy=yes
    # cachecrls=yes
    nat_traversal=yes
    charonstart=yes
    plutostart=yes
    interfaces=%defaultroute

    conn fritz.dyndns.org
    left=%defaultroute
    leftsubnet=192.168.3.0/24
    #
    ike=aes128-sha-modp1024
    esp=aes128-sha1
    #
    right=fritz.dyndns.org
    rightid=@fritz.dyndns.org
    rightsubnet=192.168.0.0/24
    #
    ikelifetime=4h
    keylife=1h
    #
    authby=secret
    auto=add

  12. 16 strongswan August 28, 2012 um 1:45 nachmittags

    Hallo, sehr gutes Howto!

    Ich versuche zurzeit folgende Konfiguration mit einer FritzBox 7390 und strongSwan 5.0.1 zu laufen zu bringen.

    [internet] [strongSwan gateway] IPSEC TUNNEL [Fritzbox] [local network, 192.168.177.0]

    Der Anwendungsfall ist: der gesamte Traffic aus dem lokalen FritzBox-Netzwerk soll über den IPSEC-Tunnel zu strongSwan und erst dann ins Internet gelangen.

    Das Problem dabei, links von strongSwan ist kein privates Netz, sondern das Internet.
    Somit taugt, dass AVM VPN-Einrichtungstool nur begrenzt. Sofern ich phase2remoteid und acceslist wie folgt definiere, wird der IPSEC Tunnel erfolgreich aufgebaut. Leider aber nur für Traffic zu 10.0.0.0.

    phase2remoteid {
    ipnet {
    ipaddr = 10.0.0.0;
    mask = 255.255.255.0;
    }
    }
    phase2ss = “esp-all-all/ah-none/comp-all/pfs”;
    accesslist = “permit ip any 10.0.0.0 255.255.255.0″;

    Nun meine Fragen dazu:
    - Wie definiert man für die FritzBox, dass der gesamte Traffic über IPSEC laufen soll?
    - Erstellt strongSwan zwischen 192.168.177.0 und der externen Adresse ein zusätzliches NAT? Ich brauche ja eigentlich nicht nochmals ein NAT.

    strongSwan 5.0.1 ist wie folgt konfiguriert:
    conn test
    leftid=@vpn.thegateway.net (the strongswan-gateway)
    left=%defaultroute
    leftsubnet=0.0.0.0/0
    leftfirewall=yes
    ike=aes256-sha1-modp1024
    esp=aes256-sha1-modp1024
    right=xyz.dyndns.org (the fritzbox dyndns ip)
    rightid=@yxz.dyndns.org
    rightsubnet=192.168.177.0/24
    authby=secret
    auto=add

    Bin für jeden Input dankbar!


  1. 1 Fritzbox, Fernwartung VPN und eigener DynDNS | blog.windfluechter.net Trackback zu Januar 24, 2011 um 8:15 nachmittags
  2. 2 StrongSWAN L2TP IPSec VPN with PSK and DynDNS configuration Trackback zu Oktober 14, 2012 um 5:46 nachmittags

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ photo

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s





Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

%d Bloggern gefällt das: