[gelöst] Site-2-Site VPN mit Fritzbox und Vyatta

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
J

jpawlowski

Neuer User
Mitglied seit
10 Nov 2005
Beiträge
48
Punkte für Reaktionen
0
Punkte
0
Ahoi!

Ich möchte gerne meine Fritzbox 7390 per VPN an eine Linux Virtual Appliance anbinden (Vyatta). Dort kommt strongSwan zum Einsatz.
Leider wird der Tunnel nach der 24h Trennung nicht wieder aufgebaut, auch nicht nach mehreren Stunden. Der dyndns-Eintrag wird aber korrekt aktualisiert und auch kurze Zeit später von der Vyatta Box erkannt.
Erst wenn ich auf der Vyatta Box den Tunnel vollständig zurücksetze (mittels "clear vpn ipsec-peer myhomelocation.dyndns.org") funktioniert es wieder - bis zur nächsten DSL Unterbrechung... selbst ein Neustart der Fritzbox hilft nichts, um den Tunnel wieder ans Laufen zu bekommen.

Hat da jemand eine Idee?
Siehe auch mein Posting im Vyatta Forum (für die Engländer unter euch :))
http://www.vyatta.org/forum/viewtopic.php?p=50362

Hier mal die Configs in der Übersicht:

Vyatta Config:
Code: 
user@vyatta# show vpn 
 ipsec {
     esp-group ESP-Fritzbox {
         compression enable
         proposal 1 {
             encryption aes256
         }
     }
     ike-group IKE-Fritzbox {
         lifetime 28800
         proposal 1 {
             encryption aes256
         }
     }
     ipsec-interfaces {
         interface eth0
     }
     nat-networks {
         allowed-network 0.0.0.0/0 {
             exclude 10.2.3.4/16
         }
     }
     nat-traversal enable
     site-to-site {
         peer myhomelocation.dyndns.org {
             authentication {
                 id @vpn.domain.tld
                 pre-shared-secret PRESHAREDKEYSECRET
                 remote-id @myhomelocation.dyndns.org
             }
             ike-group IKE-Fritzbox
             local-ip 178.x.x.x
             tunnel 1 {
                 allow-nat-networks disable
                 esp-group ESP-Fritzbox
                 local-subnet 0.0.0.0/0
                 remote-subnet 192.168.x.x/24
             }
         }
     }
 }

Fritzbox Config:
Code: 
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "Connection to xxxx";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 178.x.x.x;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "myhomelocation.dyndns.org";
                }
                remoteid {
                        fqdn = "vpn.domain.tld";
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "PRESHAREDKEYSECRET";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.x.x;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 172.16.0.0 255.240.0.0",
                             "permit ip any 10.0.0.0 255.0.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

Logfile auf Vyatta wenn die DSL Trennung erfolgt:
Code: 
Jul  8 05:13:53 vyatta pluto[4881]: packet from 79.x.x.x:500: Informational Exchange is for an unknown (expired?) SA
Jul  8 05:13:53 vyatta last message repeated 4 times
Jul  8 05:13:53 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [XAUTH]
Jul  8 05:13:53 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [Dead Peer Detection]
Jul  8 05:13:53 vyatta pluto[4881]: packet from 79.x.x.x:500: initial Main Mode message received on 178.x.x.x:500 but no connection has been authorized with policy=PSK
Jul  8 05:13:55 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [XAUTH]
Jul  8 05:13:55 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [Dead Peer Detection]
Jul  8 05:13:55 vyatta pluto[4881]: packet from 79.x.x.x:500: initial Main Mode message received on 178.x.x.x:500 but no connection has been authorized with policy=PSK
Jul  8 05:13:59 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [XAUTH]
Jul  8 05:13:59 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [Dead Peer Detection]
Jul  8 05:13:59 vyatta pluto[4881]: packet from 79.x.x.x:500: initial Main Mode message received on 178.x.x.x:500 but no connection has been authorized with policy=PSK
Jul  8 05:14:07 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [XAUTH]
Jul  8 05:14:07 vyatta pluto[4881]: packet from 79.x.x.x:500: received Vendor ID payload [Dead Peer Detection]
Jul  8 05:14:07 vyatta pluto[4881]: packet from 79.x.x.x:500: initial Main Mode message received on 178.x.x.x:500 but no connection has been authorized with policy=PSK
Jul  8 05:17:48 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #389: initiating Main Mode to replace #387
Jul  8 05:18:58 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #389: max number of retransmissions (2) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
Jul  8 05:18:58 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #389: starting keying attempt 2 of at most 3
Jul  8 05:18:58 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #390: initiating Main Mode to replace #389
Jul  8 05:20:08 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #390: max number of retransmissions (2) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
Jul  8 05:20:08 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #390: starting keying attempt 3 of at most 3
Jul  8 05:20:08 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #391: initiating Main Mode to replace #390
Jul  8 05:21:18 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #391: max number of retransmissions (2) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
Jul  8 05:35:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #387: ISAKMP SA expired (LATEST!)
Jul  8 05:38:29 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #388: IPsec SA expired (LATEST!)

Logfile auf Vyatta nach dem Clearing des Tunnels mittels "clear vpn ipsec-peer"
Code: 
Jul  8 10:39:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #587: initiating Main Mode
Jul  8 10:39:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1": deleting connection
Jul  8 10:39:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #587: deleting state (STATE_MAIN_I1)
Jul  8 10:39:21 vyatta pluto[4881]: added connection description "peer-myhomelocation.dyndns.org-tunnel-1"
Jul  8 10:39:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #588: initiating Main Mode
Jul  8 10:39:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #588: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
Jul  8 10:39:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #588: received Vendor ID payload [XAUTH]
Jul  8 10:39:21 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #588: received Vendor ID payload [Dead Peer Detection]
Jul  8 10:39:22 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #588: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Jul  8 10:39:22 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #588: Peer ID is ID_FQDN: '@myhomelocation.dyndns.org'
Jul  8 10:39:22 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #588: ISAKMP SA established
Jul  8 10:39:22 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #589: initiating Quick Mode PSK+ENCRYPT+COMPRESS+TUNNEL+PFS+UP {using isakmp#588}
Jul  8 10:39:22 vyatta pluto[4881]: "peer-myhomelocation.dyndns.org-tunnel-1" #589: sent QI2, IPsec SA established {ESP=>0x348a162b <0x91b595a7 IPCOMP=>0x00009c48 <0x00002a78}
 
Zuletzt bearbeitet:
Vielleicht ein Problem ungleicher Einstellungen?
Versuche doch mal, die lifetime an die AVM-Settings anzupassen (3600 s). Hilft das was??

Jörg
 
Zuletzt bearbeitet:
Hm guter Punkt, hab jetzt mal

Code: 
ike_life: 900s; ipsec_life: 300s;

gesetzt. Konnte nach ersten Tests aber nicht wirklich beobachten, dass der Tunnel nun nach 5 oder 15min eines IP Wechsels wieder steht... :-/
 
Also inzwischen bin ich etwas weiter.
DPD war nicht auf beiden Seiten aktiviert, das sollte eigentlich den in der Luft hängenden Tunnel recht fix löschen.... Betonung auf sollte. Wie mir scheint gibts da einen Bug in strongSwan oder zumindest in der adaptierten Version von Vyatta...

Mehr dazu in meinem englischen Post, ich spare mir das Doppelposting hier mal jetzt :)
http://www.vyatta.org/forum/viewtopic.php?p=50421#50421

Zumindest ist der Fehler jetzt mal eingegrenzt!
 
Nochmals ein kurzer Nachtrag: DPD ist hier nicht dass Allheilmittel. Die Fritzbox unterstützt das offenbar nicht gescheit, nach dem DPD-Timeout bricht der Tunnel immer zusammen und muss neu aufgebaut werden, was natürlich zu Unterbrechungen führt...

Lösung war für mich dafür zu sorgen, dass der strongSwan Server auf der anderen Seite mit -"--auto-update 60" als Parameter gestartet wird. Dadurch liest dieser alle 60 Sekunden seine Konfigurationsdateien neu ein und aktualisiert dabei auch seinen DNS Cache und somit eine eventuell geänderte IP-Adresse des dynamischen Peers.
 
Da sich seit 2010 ein wenig getan hat, hier mal meine aktuelle funktionierende Konfiguration (für EdgeOS von Ubiquiti, basierend auf Vyatta).
Funktioniert auch mit dynamischen IPs auf beiden Seiten. Wenn auf dem EdgeOS-Router noch L2TP over IPSec verwendet wird, dann muss das den selben PSK verwenden (Einschränkung von strongSWAN)!

Siehe auch: https://community.ubnt.com/t5/EdgeM...-both-dynamic-IPs-between/m-p/1548055#M108614

EdgeOS:
Code: 
ubnt@router# show vpn ipsec  auto-update 60
 auto-firewall-nat-exclude enable
 esp-group espfritzbox {
     compression disable
     lifetime 3600
     mode tunnel
     pfs enable
     proposal 1 {
         encryption aes256
         hash sha1
     }
 }
 ike-group ikefritzbox {
     lifetime 3600
     proposal 1 {
         dh-group 2
         encryption aes256
         hash sha1
     }
 }
 ipsec-interfaces {
     interface eth0
 }
 nat-networks {
     allowed-network 0.0.0.0/0 {
     }
 }
 nat-traversal enable
 site-to-site {
     peer REMOTE.HOST.NAME {
         authentication {
             id @LOCAL.HOST.NAME
             mode pre-shared-secret
             pre-shared-secret VERYSECRETPSK
             remote-id @REMOTE.HOST.NAME
         }
         connection-type initiate
         dhcp-interface eth0
         ike-group ikefritzbox
         tunnel 1 {
             allow-nat-networks disable
             allow-public-networks disable
             esp-group espfritzbox
             local {
                 prefix 192.168.0.0/24
             }
             remote {
                 prefix 192.168.178.0/24
             }
         }
     }
 }

Fritz!Box:
Code: 
vpncfg {	connections {
		enabled = yes;
		conn_type = conntype_lan;
		name = "LOCAL.HOST.NAME";
		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 = "LOCAL.HOST.NAME";
		keepalive_ip = 0.0.0.0;
		localid {
			fqdn = "REMOTE.HOST.NAME";
		}
		remoteid {
			fqdn = "LOCAL.HOST.NAME";
		}
		mode = phase1_mode_idp;
		phase1ss = "all/all/all";
		keytype = connkeytype_pre_shared;
		key = "VERYSECRETPSK";
		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.0.0;
				mask = 255.255.255.0;
			}
		}
		phase2ss = "esp-all-all/ah-none/comp-all/pfs";
		accesslist = "permit ip any 192.168.0.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";
}
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 778 (Mitglieder: 52, Gäste: 726)

Neueste Beiträge

Statistik des Forums

Themen
246,308
Beiträge
2,249,843
Mitglieder
373,916
Neuestes Mitglied
torstenkietz
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück