[Info] strongSwan (Linux) als VPN-Client für einen FRITZ!OS-Benutzeraccount

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,765
Punkte für Reaktionen
1,261
Punkte
113
Da ich selbst gestern ca. 1 Stunde am Zweifeln ob meiner VPN-Kenntnisse war und es wohl dazu tatsächlich noch keine passenden Infos gibt (zumindest hier im IPPF und auch im gesamten Internet ist es nicht wirklich üppig, wie ich vor dem Schreiben dieses Beitrags festgestellt habe), hier mal eine passende Beispielkonfiguration für den Anwendungsfall aus dem Thread-Titel.

Es gibt zwar mehrere Hilfen, wie man das Ganze mit einer LAN-LAN-Kopplung einrichtet oder wie man eine FRITZ!Box als (Dial-In-)Client mit einem Linux-Server verwendet, aber der Fall, daß das Linux-System als VPN-Client für die Einwahl in einer FRITZ!Box genutzt werden soll, ist bisher wohl nur wenig "besprochen" worden und es hat sich sowohl die AVM-Implementierung der VPN-Funktionen etwas verändert und gleichzeitig muß man inzwischen wohl auch festhalten, daß "strongSwan" (https://www.strongswan.org/ - was ja eine "Multi-Plattform-Solution" ist) in den allermeisten Linux-Distributionen die früheren Projekte "FreeS/WAN", "Openswan" und "Libreswan" und auch das Racoon/KAME-Gespann für den IKE-Daemon ersetzt hat und sich daraus auch (teilweise subtile) Unterschiede zu alten Anleitungen (auch zu einigen im IPPF) ergeben.

Beginnen wir mit den zwei wichtigsten Dateien - wobei ich hier der Einfachheit halber die "alten" Dateien ipsec.conf und ipsec.secrets verwende, weil die Struktur der neueren Konfigurationsmöglichkeiten (strongswan.conf und swanctl.conf) "formalere Ansprüche" erfüllen muß und da schon die geschweiften Klammern für manchen eine Herausforderung darstellen.

Zuerst also die ipsec.conf:
Rich (BBCode):
# ipsec.conf - strongSwan IPsec configuration file

config setup
        uniqueids = yes

conn    avm_conntype_user
        ikelifetime=60m
        keylife=60m
        rekeymargin=3m
        keyingtries=1
        ike=aes256-sha512-modp1024!
        esp=aes256-sha512!
        keyexchange=ikev1
        aggressive=yes
        leftauth=psk
        leftauth2=xauth
        leftsourceip=%config4
        dpdtimeout=120s
        dpdaction=restart
        dpddelay=30s
        forceencaps=yes
        modeconfig=pull
        compress=no
        rightauth=psk
        xauth=client

conn    <choose_your_own_connection_name_here>
        also=avm_conntype_user
        leftid=keyid:<IPSec-ID / Gruppenname>
        right=%<Serveradresse / Server>
        rightsubnet=<FRITZ!Box-LAN-Segment>
        xauth_identity=<Nutzername / Account >
        esp=aes256-sha1!
        auto=route
und passend zu dieser braucht es dann noch eine ipsec.secrets:
Rich (BBCode):
#
# ipsec.secrets
#
# This file holds the RSA private keys or the PSK preshared secrets for
# the IKE/IPsec authentication. See the ipsec.secrets(5) manual page.
#
keyid:<IPSec-ID / Gruppenname> : PSK "<IPSec-Schlüssel / Shared Secret>"
<Nutzername / Account > : XAUTH "<Kennwort des FRITZ!Box-Benutzers>"
(in dieser Datei sind die Leerzeichen vor und hinter den Doppelpunkten - außer nach keyid, wo keines stehen darf - wichtig!)

Kurz zu den zu ersetzenden Werten ... diese sind alle in Rot dargestellt und die spitzen Klammern gehören jeweils zum zu ersetzenden Text. Bei der Benennung habe ich - soweit das vergleichbar war/ist - die Bezeichnungen aus der AVM-Anzeige für die VPN-Einstellungen eines Benutzer-Accounts verwendet ... der einzige Wert, der sich dort nicht finden wird, ist <FRITZ!Box-LAN-Segment>, was durch das im lokalen Netz der FRITZ!Box verwendete IPv4-Segment zu ersetzen ist - bei AVM-Standardeinstellungen (mit DSL-Router) also 192.168.178.0/24 (oder 192.168.188.0/24 bei LAN1-Router). Bei <choose_your_own_connection_name_here> gibt es hoffentlich keine Fragen/Unklarheiten und wer vor dem DynDNS-Namen das Prozentzeichen auslassen will, kann dem Template (oder der Verbindung) stattdessen auch ein rightid=%any hinzufügen - aber eine der beiden Möglichkeiten sollte genutzt werden, weil man nie genau weiß, wie die FRITZ!Box die eigene localid in P1 wählt, wenn mehrere DynDNS-Konten (inkl. MyFRITZ!) aktiviert sind und strongSwan dann gerne mal mit dieser ID nichts anfangen kann.

Da alle diese "dial-in connections" mit FRITZ!Boxen als Server ein paar Einstellungen gemeinsam haben, sind diese in der "Schablone" mit dem Namen avm_conntype_user in der ipsec.conf enthalten - dieses Template kann dann mit einem also=avm_conntype_user für eine "echte" Definition einer Verbindung übernommen werden und dort definierte Werte können durch eine "konkrete" Verbindung auch wieder überschrieben werden (seit strongSwan 5.2.0 und eine noch ältere hält hoffentlich keine aktuelle Linux-Distribution bereit - die aktuelle Release-Version von strongSwan wäre 5.9.1). Da zusätzlich auch noch einige Werte durch eine %default-Verbindung "vordefiniert" sein könnten (wenn man das auf einem nicht jungfräulichen System macht, was schon ein paar andere IPSec-Verbindungen nutzt), gibt es in meinem Template auch ein paar Einstellungen, die eigentlich nicht angegeben werden müßten, weil sie ohnehin Standard sind - aber sicher ist sicher und so werden sie (u.a. compress=no oder auch xauth=client) noch einmal explizit gesetzt.

Noch ein paar Erläuterungen zu den Werten ... diejenigen, die hier in Wisteria dargestellt werden (ja, so heißt diese Farbe RGB(147, 101, 184)), sind zu den AVM-Einstellungen passende Standardannahmen meinerseits, während die in Denim für die jeweilige Verbindung bzw. die eigenen Anforderungen an Geschwindigkeit und Sicherheit passend gesetzt werden müssen.

Zu den nutzbaren Algorithmen für den Schlüsselaustausch und die Verschlüsselung der ESP-Pakete ... obwohl es in der ipsec.cfg bei AVM anders steht (hier aus der 154.07.24-84707 - das ist die IKE-Strategie, die bei conntype_user-Verbindungen in der vpn.cfg automatisch gesetzt ist):
Rich (BBCode):
                name = "LT8h/all/all/all";
                comment = "Alle Algorithmen, DH-Gruppe alternate (ausgehend) Lifetime 8h";
                dhgroup = alt;
                life_dur_sec = 8h;
                life_dur_kb = 0;
                accept_all_dh_groups = yes;
                proposals {
                        hash = ike_sha2_512;
                        enc {
                                type = ike_aes;
                                keylength = 256;
                        }
                }{
, habe ich es einfach nicht gepackt, hier mit irgendeiner anderen DH-Group als 2 (https://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites) eine Verbindung aufzubauen - die Antwort war schlicht immer "no proposal choosen". Damit kann man zwar mit dem Verschlüsselungsalgorithmus und dem HMAC-Verfahren beim IKE variieren, aber das modp1024 sollte "gesetzt" sein (nach meinen gestrigen Versuchen). Für Verschlüsselung kann man guten Gewissens eigentlich nur AES empfehlen, wobei AVM wohl die Schlüssellängen 128, 192 und 256 Bit versteht - beim HMAC-Verfahren sollte man (für den Schlüsselaustausch, also beim ike=...) aber schon auf etwas besseres als SHA1 gehen und dann läßt einem AVM mit den Vorgaben in der ipsec.cfg auch nicht mehr sooo viel Auswahl. Denn neben MD5 und SHA1 ist da für IKE nur noch ein einziges Proposal für AES256 mit SHA512 enthalten ... das sollte man dann auch verwenden. Der Datenverkehr beim IKE ist jetzt nicht so heftig (nicht mit dem über ESP zu verwechseln, wo dann die "echten Daten" übertragen werden), daß das einen spürbaren Nachteil in der Geschwindigkeit der Datenübertragung zur Folge hätte.

Die acht Stunden, die AVM da für die "lifetime" so eines ausgehandelten Schlüssels vorgeben möchte, sind (meiner Ansicht nach) eher den früheren Schwierigkeiten mit irgendwelchen Smartphones geschuldet und bei ernsthafter VPN-Verwendung auch eher nicht sinnvoll (gilt für IKE und ESP), weil das einem Angreifer schon jede Menge Zeit läßt, den Schlüssel noch innerhalb seiner Gültigkeit zu knacken. Daher habe ich in meinen Vorgaben auch nur eine Stunde vorgesehen - die ansonsten auch noch übliche Beschränkung eines Schlüssels auf ein max. damit zu verarbeitendes Datenvolumen habe ich mir aber auch geklemmt, weil üblicherweise auf diesem Weg jetzt auch nicht diiieee Datenmengen bewegt werden.

In Abhängigkeit davon, wann und wie man so eine VPN-Verbindung starten läßt (komme ich gleich noch zu), kann es sinnvoll sein, diese mittels DPD (Dead Peer Detection) zu überwachen und dann, wenn sie aus irgendeinem Grund nicht mehr funktioniert, neu aufzubauen. Die möglichen Aktionen und die Bedeutung der Zeitvorgaben findet man dann wieder im strongSwan-Wiki.

Und damit zum ESP-Protokoll (die Zeilen in Denim und das Beispiel für das "Überschreiben" einer Angabe aus dem Template in Fern) - das FRITZ!OS bietet auch in der Auswahl der Algorithmen für die ESP-Verschlüsselung nicht sooo viele Möglichkeiten, denn der entsprechende Abschnitt in der ipsec.cfg von AVM sieht so aus:
Code:
                name = "LT8h/esp-all-all/ah-none/comp-all/no-pfs";
                comment = "Alle Algorithmen, ohne AH, ohne PFS";
                pfs = no;
                life_dur_sec = 8h;
                life_dur_kb = 0;
                proposals {
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_aes;
                                enc_key_length = 256;
                                hash = hmac_sha2_512;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_aes;
                                enc_key_length = 256;
                                hash = sha;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_aes;
                                enc_key_length = 192;
                                hash = sha;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_aes;
                                enc_key_length = 0;
                                hash = sha;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_3des;
                                enc_key_length = 0;
                                hash = sha;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_des;
                                enc_key_length = 0;
                                hash = sha;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_aes;
                                enc_key_length = 256;
                                hash = md5;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_aes;
                                enc_key_length = 192;
                                hash = md5;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_aes;
                                enc_key_length = 0;
                                hash = md5;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_3des;
                                enc_key_length = 0;
                                hash = md5;
                        }
                }{
                        comp = comp_none;
                        ah = ah_none;
                        esp {
                                typ = esp_des;
                                enc_key_length = 0;
                                hash = md5;
                        }
                }
Der entscheidende Punkt ist hier - neben der, seit 07.2x und der Benutzung der Hardware-Einheiten für die Verschlüsselung, abgeschafften Verwendung (bzw. Auslassung) von compress - das Fehlen von Proposals MIT PFS. In strongSwan gibt es aber mittlerweile die Option pfs=yes gar nicht mehr - das wird jetzt implizit durch die Angabe des Algorithmus für ESP vorgegeben. Wenn dieser eine Angabe für eine DH-Gruppe enthält (also der modp1024-Teil enthalten ist), wird natürlich auch automatisch PFS gesetzt - sonst macht dabei die Angabe der DH-Group ja auch keinen Sinn.

Das ist aber die Stelle, wo ich gestern erst mal wieder eine Weile gebraucht habe ... auch weil ich vergessen hatte, die AVM-Vorgaben in der ipsec.cfg tatsächlich im Detail zu prüfen und einfach davon ausging, daß AVM PFS schon erlauben würde. Erst nach gründlicherer Überlegung und Analyse der Debug-Logs habe ich dann den Fehler gefunden ... AVM sagt da nämlich auch in der aktuellen VPN-Implementierung schlicht "Fehler 0x2026" in der eigenen Log-Datei und gut ist's - eine Anzeige, was angeboten wurde und was erlaubt wäre, fehlt in der ike.log immer noch (auch wenn's die jetzt wenigstens für den letztlich ausgewählten Vorschlag gibt).

Für diese Dial-In-Connections bei einer FRITZ!Box (zumindest für diejenigen, die mit dem automatischen Satz an Vorschlägen konfiguriert sind), MUSS man also für ESP einen Vorschlag machen, der keine Angabe einer DH-Group beinhaltet ... dann klappt's auch mit dem Nachbarn, selbst wenn der eine FRITZ!Box hat (und sich für's Geschirrspülen überhaupt nicht interessiert).

Die Angabe von forceencaps=yes entspricht dem nat-t=force - dann "betrügt" strongSwan beim Hash über die IP-Adressen, mit dem letztlich festgestellt wird/werden soll, ob ein NAT-Router zwischen den Peers sitzt und ob von UDP 500 und ESP auf UDP 4500 für NAT-T umgeschaltet werden soll. Das bringt zwar einen (kleinen) Overhead mit sich (weil die ESP-Pakete jetzt alle noch einmal in eine UDP-Hülle gesteckt werden), aber es kann hilfreich sein, wenn die automatische Detection aus irgendeinem Grunde nicht funktionieren sollte. Man kann es also auch auslassen ... sollte man das für eine Verbindung anders wünschen, als es im Template steht, kann man das bei der Verbindung ja auch wieder "überschreiben".

Bleibt noch der auto-Parameter ... mit dem kann man jetzt festlegen, was mit der VPN-Verbindung beim Start von strongSwan (entweder über ipsec start oder über irgendwelche Distro-Mechanismen zum Start aller Services) geschehen soll. Bei Angabe von route (wie in meinem Beispiel) werden nur die Vorkehrungen getroffen, daß beim ersten Versuch, ein Paket an eine Adresse aus rightsubnet zu senden, die VPN-Verbindung automatisch (on demand) aufgebaut wird. Bei auto=start wird die Verbindung gleich beim Start von strongSwan mit aufgebaut und bei auto=add wird ihre Definition zwar den verfügbaren Verbindungen hinzugefügt, aber sie wird weder automatisch, noch "on demand" aufgebaut. Dazu braucht es dann erst noch ein ipsec up <choose_your_own_connection_name_here> (was üblicherweise Superuser-Rechte benötigt) und erst dann kann die VPN-Verbindung genutzt werden. Der eigene Client kriegt dabei von der FRITZ!Box die IP-Adresse vorgegeben, die dem Benutzer im FRITZ!OS zugewiesen wurde (die wird mittlerweile im FRITZ!OS ja auch unter Netzwerkverbindungen angezeigt).
 
Zuletzt bearbeitet:
  • Like
Reaktionen: NDiIPP

vice_pres

Mitglied
Mitglied seit
6 Apr 2008
Beiträge
474
Punkte für Reaktionen
4
Punkte
18
Hi Peter,

ich hake mich hier mal kurz ein - ein sehr interessanter Beitrag, besonders das Thema Proposals. Ich habe zwar einen leicht anderen Anwendungsfall, aber seit dem Update auf 07.25 zweifel ich ebenfalls an meinen (beschränkt vorhandenen) Kentnissen und habe ein Problem das mit alten FW Versionen nicht vorhanden war.

Mir bricht beim Rekey die Verbindung kurz ab, aber lang genug, dass es diverse Aussetzer gibt (ich arbeite per Remotedesktop auf der Gegenseite auf dem Server bei meinen Eltern zum Beispiel) oder auch eine Dateiübertragung. Ich sehe, dass bei ca. 55 Minuten (11:04/11:05) (ich hab mal kurz nicht hingeschaut, da war der Timer dann bei 18 Sekunden - ich meine vorher wären es 55 Minuten gewesen, ich hätte ja eher auf 57 Minuten getippt) der ESTABLISHED Timer im ipsec status wieder von vorne anfängt, meine Remotesitzung hatte aber keinen Aussetzer zu dem Zeitpunkt. Der kam erst ca. 6 Minuten später. (11:10 ca.) - nämlich scheinbar dann, wenn die Box die alte SA verwirft (was laut Log auch auf die Sekunde genau nach dem Verwurf der letzten SA um 10:10:44 war).

Das war mit alten Versionen so nicht der Fall - ich vermute, dass die im Changelog erwähnte Änderung/Verbesserung hier von AVM Seite aus den Teil dazu beiträgt, hoffe aber, dass ich es zumindest wieder besser hinbekomme. Vielleicht hast du ja eine Idee?

Code:
conn fritz-box1
        keyexchange=ikev1
        esp=aes256-sha2_512-modp1024!
        ike=aes256-sha2_512-modp1024!
        right=definition
        rightsubnet=192.168.6.0/24
        ikelifetime=60m
        keylife=60m
        rekeymargin=3m
        keyingtries=1
        dpdtimeout=300s
        dpdaction=restart
        dpddelay=180s
        inactivity=990s
        authby=secret
        auto=add
conn fritz-box1-netze
        also=fritz-box1
        [email protected]
        leftsubnet=192.168.0.0/17

Config die ich in die Box importiert habe
Code:
{
 enabled = yes;
 editable = no;
 conn_type = conntype_lan;
 name = "VPN-NETZE";
 boxuser_id = 0;
 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 = "DNSNAME";
 keepalive_ip = 192.168.127.1;
 localid {
 fqdn = "definition.netze";
 }
 remoteid {
 fqdn = "DNSNAME";
 }
 mode = phase1_mode_idp;
 phase1ss = "all/all/all";
 keytype = connkeytype_pre_shared;
 key = "<KEY>";
 cert_do_server_auth = no;
 use_nat_t = yes;
 use_xauth = no;
 use_cfgmode = no;
 phase2localid {
 ipnet {
 ipaddr = 192.168.6.0;
 mask = 255.255.255.0;
 }
 }
 phase2remoteid {
 ipnet {
 ipaddr = 192.168.0.0;
 mask = 255.255.128.0;
 }
 }
 phase2ss = "esp-all-all/ah-none/comp-all/pfs";
 accesslist = "permit ip any 192.168.0.0 255.255.128.0";
 }

Ein ipsec status wirft das aus:
Code:
fritz-box1-netze[2662]: ESTABLISHED 12 minutes ago, PUBLIC.IP.SERVER[DNSNAME]...PUBLIC.IP.CLIENT[definition.netze]
fritz-box1-netze{1841}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1841}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1847}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1847}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1851}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1851}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1855}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1855}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1859}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1859}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1863}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1863}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1867}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1867}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1871}:  REKEYED, TUNNEL, reqid 183, expires in 49 days
fritz-box1-netze{1871}:   192.168.0.0/17 === 192.168.6.0/24
fritz-box1-netze{1875}:  INSTALLED, TUNNEL, reqid 183, ESP SPIs: c3add11f_i 2b0c6414_o
fritz-box1-netze{1875}:   192.168.0.0/17 === 192.168.6.0/24

Im Log der Box steht folgendes:
Code:
2021-03-17 11:04:34 avmike:wolke_neighbour_renew_sa 1 SAs
2021-03-17 11:04:34 avmike:>>> identity protection mode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 532 IC b14376bb65a2ec18 RC 00000000 0000 SA flags=
2021-03-17 11:04:34 avmike:<<<  identity protection mode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 136 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 0000 SA flags=
2021-03-17 11:04:34 avmike:identity protection mode VPN-NETZE: selected lifetime: 3600 sec(no notify)
2021-03-17 11:04:34 avmike:VPN-NETZE receive VENDOR ID Payload: XAUTH
2021-03-17 11:04:34 avmike:VPN-NETZE receive VENDOR ID Payload: DPD
2021-03-17 11:04:34 avmike:VPN-NETZE receive VENDOR ID Payload: NAT-T RFC 3947
2021-03-17 11:04:35 avmike:>>> identity protection mode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 316 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 0000 KEY flags=
2021-03-17 11:04:35 avmike:<<<  identity protection mode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 332 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 0000 KEY flags=
2021-03-17 11:04:35 avmike:VPN-NETZE: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:10
2021-03-17 11:04:35 avmike:>>> identity protection mode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 0000 IDENTIFICATION flags=e
2021-03-17 11:04:35 avmike:<<<  identity protection mode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 124 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 0000 IDENTIFICATION flags=e
2021-03-17 11:04:35 avmike:VPN-NETZE: Phase 1 ready
2021-03-17 11:04:35 avmike:VPN-NETZE: current=PUBLIC.IP.SERVER new=PUBLIC.IP.SERVER
2021-03-17 11:04:35 avmike:VPN-NETZE: start waiting connections
2021-03-17 11:04:35 avmike:VPN-NETZE: NO waiting connections
2021-03-17 11:04:45 avmike:<<<  infomode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC fdf79abf3b679c0 RC fb4ea0fc81ae0fc4 8812ba1d HASH flags=e
2021-03-17 11:04:45 avmike:VPN-NETZE: del phase 1 SA 9
2021-03-17 11:05:02 avmike:< create_sa(appl=vpnd,cname=VPN-NETZE)
2021-03-17 11:05:02 avmike:VPN-NETZE: Phase 2 starting
2021-03-17 11:05:02 avmike:>>> quickmode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 764 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 823d2968 HASH flags=e
2021-03-17 11:05:02 avmike:<<<  quickmode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 364 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 823d2968 HASH flags=e
2021-03-17 11:05:02 avmike:>>> quickmode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 108 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 823d2968 HASH flags=e
2021-03-17 11:05:02 avmike:VPN-NETZE: Phase 2 ready
2021-03-17 11:05:02 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 25942261 LT: 3600 I/O: IN
2021-03-17 11:05:02 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: C6BC9EAC LT: 3600 I/O: OUT
2021-03-17 11:05:02 avmike:< cb_sa_created(name=VPN-NETZE,id=10,...,flags=0x00002101)
2021-03-17 11:05:02 avmike:VPN-NETZE stop_vpn_keepalive to 192.168.127.1
2021-03-17 11:05:02 avmike:VPN-NETZE restart keepalive_timer timer_id 1996582992
2021-03-17 11:05:02 avmike:VPN-NETZE: start waiting connections
2021-03-17 11:05:02 avmike:VPN-NETZE: NO waiting connections
2021-03-17 11:08:07 avmike:>r> infomode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 cef2e1d4 HASH flags=e
2021-03-17 11:08:07 avmike:<<<  infomode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 717c3550 HASH flags=e
2021-03-17 11:09:07 avmike:>r> infomode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 95a545db HASH flags=e
2021-03-17 11:09:07 avmike:<<<  infomode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 23428599 HASH flags=e
2021-03-17 11:10:07 avmike:>r> infomode [PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 62de98d1 HASH flags=e
2021-03-17 11:10:07 avmike:<<<  infomode[PUBLIC.IP.SERVER] VPN-NETZE: V1.0 140 IC b14376bb65a2ec18 RC 4672f0acd5dbb03 2f0e0382 HASH flags=e
2021-03-17 11:10:44 avmike:< delete_sa(appl=vpnd,cname=VPN-NETZE,id=9,what=7,reason=Lifetime expired)
2021-03-17 11:10:44 avmike:FreeIPsecSA: spi=4B0C1314        protocol=3 iotype=1
2021-03-17 11:10:44 avmike:FreeIPsecSA: spi=C7ADD28F        protocol=3 iotype=2

Auth.log sagt
Code:
Mar 17 11:04:34 charon: 12[IKE] PUBLIC.IP.CLIENT is initiating a Main Mode IKE_SA
Mar 17 11:04:35 charon: 15[IKE] IKE_SA fritz-box1-netze[2666] established between PUBLIC.IP.SERVER[DNSNAME]...PUBLIC.IP.CLIENT[definition.netze]
Mar 17 11:04:45 charon: 11[IKE] deleting IKE_SA fritz-box1-netze[2662] between PUBLIC.IP.SERVER[DNSNAME]...PUBLIC.IP.CLIENT[definition.netze]
Mar 17 11:05:02 charon: 01[IKE] CHILD_SA fritz-box1-netze{1879} established with SPIs c6bc9eac_i 25942261_o and TS 192.168.0.0/17 === 192.168.6.0/24
 

Zurzeit aktive Besucher

Keine Mitglieder online.
3CX

Statistik des Forums

Themen
237,879
Beiträge
2,102,242
Mitglieder
360,374
Neuestes Mitglied
ffwit

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

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.
oder via

IPPF im Überblick

Neueste Beiträge

Website-Sponsoren


Kontaktieren Sie uns bei Interesse