05.11.2023

2881

Site-2-Site-VPN wird nach Zwangstrennung getrennt

Hallo,
ich habe als Noob eine Site2Site-VPN zwischen einer Fritzbox 7590 (7.57) und einem StrongSwan (läuft auf einem Proxmox-Container). Alles lief monatelang reibungslos. Jetzt wurde die FritzBox auf einen DSL-Anbieter mit Zwangstrennung umgestellt. Und exakt zum Zeitpunkt der Zwangstrennung wird der Tunnel nun leider jeweils getrennt.

Bei diesem Beispiel wird die DynDNS der Fritzbox wird nach der Zwangstrennung korrekt von 93.132.121.219 auf 93.131.102.110 aktualisiert (wie ich im Log auf ddnss.de sehen kann). Allerdings erst um 7:55:08. Der Tunnel ist aber bereits um 7:55:05 beendet worden. Mit einem Restart von StrongSwan wird der Tunnel sofort korrekt wieder aufgebaut.
Meine Frage: Was läuft hier schief bzw. was kann ich tun, dass StrongSwan den IP-Wechsel besser verdaut?
Anbei die Conf von meinem StrongSwan.

Danke für Tipps

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4241015077

Url: https://administrator.de/contentid/4241015077

Ausgedruckt am: 21.11.2024 um 14:11 Uhr

36 Kommentare

Neuester Kommentar

Ich würde an deiner Stelle 2 IPSec Tunnels machen mit 2 unterschiedlichen WAN IP Adressen dann hast du bessere Redundanz und Hochverfügbarkeit.

Ansonsten wird dir vermutlich nichts anderes übrig bleiben als den Tunnel neuzustarten per Script oder so eventuell mit einem Monitoring dahinter.

DynDNS ist wirklich das letzte was man für Site-toSite VPN Verbindungen verwenden sollte. Geh zum Provider und frag dort um eine statische IPv4 oder IPv6 an.

Ein Jeder "vernünftige" Provider wird dir IPv6 gratis geben bzw. IPv4 gegen aufpreis.

Moin,

schau das DeadPeer detection aktiv ist. Das sollte dein Problem lösen. Wohl gemerkt auf beiden Seiten.

Gruß
Spirit

Es ist sinnvoller Strongswan auf das modernere swanctl (vici) Verfahren umzustellen. Das stellt dann auch eine DPD Konfig bereit so das das o.a. Verhalten nicht mehr passiert.
Guckst du hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
und in der Praxisumsetzung auch hier.

Leider fehlt hier deine Fritzbox Konfig Datei

aber auch dort kannst du ein Keepalive auf die Strongswan Loopback IP konfigurieren was dann auch ganz ohne DPD die Verbindung immer sofort wieder nach der Zwangstrennung neu aufbaut.
So oder so ist das problemlos lösbar und natürlich auch mit DynDNS.

1) Was ich gerne hätte:
- Ich möchte Main Mode Konfiguriert.
- Ich verwende auf StrongSwan-Seite den IP-Bereich 192.168.3.0/24 (wobei 192.168.3.100-192.168.3.240 durch den DHCP-Server vergeben wird).
- Auf Fritz!Box-Seite verwende ich 192.168.5.0/24
- Der Proxmox-Container, auf dem StrongSwan läuft, hat die feste IP 192.168.3.19
- Ein Dial-In für Clients ist nicht nötig, nur Site2Site zwischen StrongSwan und FritzBox (heißt das Jumphost?)
- Es soll nur eine Fritzbox eingebunden werden.

2) Ich habe Strongswanctl installiert und CA und Server Zertifikat mit StrongSwan PKI erstellt (wäre für reinen Jumphost wohl nicht nötig gewesen). Reboot.
3a) Ich habe mit nano /etc/swanctl/conf.d/vpn-server.conf folgendes angelegt:

connections {
   fritzbox {
      local_addrs = <server_ip_addresse>
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = <server_ip_addresse>
          }
      remote {
          auth = psk
          id = keyid:strongswan@fritz.box
          }
      children {
          net {
              local_ts = 192.168.3.249/32
              remote_ts = 192.168.5.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }
}
secrets {
 ike-1 {
      id = keyid:strongswan@fritz.box
      secret = "test1234"      
     }
} 

3b) 192.168.3.249/32 weil ich ja nur eine einzige IP-Adresse benötige. Korrekt?
3c) Frage: Soll für <server_ip_addresse> die Dyndns-Adresse der Fritz!Box eingesetzt werden?
4a) Fritzbox-config:

vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "StrongSwan";      
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = <server_ip_addresse>;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 192.168.2.1;
			localid {
                        key_id = "strongswan@fritz.box";      
                        }
                        remoteid {
                        ipaddr = <server_ip_addresse>;
                        }
                mode = phase1_mode_idp;
                phase1ss = "LT8h/all/all/all";      
                keytype = connkeytype_pre_shared;
                key = "test1234";      
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.3.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.3.249;
                                mask = 255.255.255.255;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";      
                accesslist = "permit ip any 192.168.3.0 255.255.255.240";      
        }
        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";      
} 

4b) <server_ip_addresse> muss durch die Dyndns-Adresse von StrongSwan-Seite gesetzt werden?
4c) Ich hoffe ich habe die IP-Adressen und Masken der Strong-Swan-Seite richtig gewählt?
5) Passwort wird auf beiden Seiten noch geändert.
6) Ich habe die /etc/network/interfaces ergänzt mit
auto lo
iface lo inet loopback
iface lo inet static
address 192.168.2.1
netmask 255.255.255.255

Ok, soweit alles richtig? Danke!

Bitte unbedingt Code Tags benutzen!! Geht immer auch noch nachträglich.
Das erleichtert allen hier das Lesen und die Übersichtlichkeit der Konfigs!

1.)

Ich möchte Main Mode Konfiguriert.

Dann brauchst du immer eine FritzBox Konfig Datei zum Einspielen, denn den Main Mode kannst du nur über die Konfig Datei setzen.
Ein paar Infos zu den Fritzbox Algorithmen findest du auch hier.

Ich verwende auf StrongSwan-Seite den IP-Bereich 192.168.3.0/24

WIE ist das gemeint? Ist das die Loopback IP oder hat der Server noch ein lokales LAN bzw. lokalen vSwitch (Proxmox) dort? Ist die Vrtualisierung hinter einem Router? Da bitte etwas genauer um Fehler zu vermeiden!
2.)

Server Zertifikat mit StrongSwan PKI erstellt (wäre für reinen Jumphost wohl nicht nötig gewesen). Reboot.

Stimmt! ist für die Fritzbox nicht erforderlich und gilt ausschliesslich nur für die IKEv2 Clients.
Fritzbox VPN Tunnel erfordert keine Zertifikate weil die FB das ja auch gar nicht kann.

3.)
Deine Server Konfig hat ein paar Fehler weil du unter local und remote ts in der Regel immer Netze angibst und keine Hosts. Es sei denn...du willst nur einem einzigen Host den Zugriff über das VPN erlauben.
OK, sehe gerade 3a!! Ja, das ist dann korrekt wenn nur eine einzige IP aus dem remoten Netz!
Mit Code Tags dann so

connections {
   fritzbox {
      local_addrs = <vserver_wan_ip_addresse>
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = <vserver_wan_ip_addresse>
          }
      remote {
          auth = psk
          id = keyid:strongswan@fritz.box
          }
      children {
          net {
              local_ts = 192.168.3.249/32
              remote_ts = 192.168.5.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }
}
secrets {
 ike-1 {
      id = keyid:strongswan@fritz.box
      secret = "test1234"  
     }
} 

Ansonsten aber alles korrekt!

3c)
Normal ist das die feste WAN IP Adresse eines vServers, also die feste öffentliche IP eines Hosters.
WIE ist den Proxmox bzw. die VM im Netz. Ist das ein Setup hinter einen NAT Router?
Wenn ja, dann musst du ggf. mit FQDNs arbeiten. Das hängt von deinem Proxmox Setup ab.

Die Fritzbox Konfig hat einen Fehler in der Keepalive IP, denn das .2.0er Netz gibt es bei dir in dem Design ja nicht. Ein Keeplaive dahin wäre also ohne Funktion ist aber immens wichtig für die Zwangstrennung!

vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "StrongSwan";  
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = <v_server_wan_ip_addresse>;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 192.168.3.19;
			localid {
                        key_id = "strongswan@fritz.box";  
                        }
                        remoteid {
                        ipaddr = <v_server_wan_ip_addresse>;
                        }
                mode = phase1_mode_idp;
                phase1ss = "LT8h/all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "test1234";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.5.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.3.249;
                                mask = 255.255.255.255;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = "permit ip any 192.168.3.249 255.255.255.255";  
        }
} 

Das Problem ist allerdings das dann nur der .3.249er Host in den Tunnel geroutet wird.
Die Keepalive Pings die an den .3.19er Server gehen springen damit über die Klinge!

Es wäre deutlich besser du würdest eine etwas intelligentere IP Adressvergabe im 3er Netz machen und die per VPN erreichbaren Adressen in einen CIDR Scope bringen wie z.B.
192.168.3.248 /29 (255.255.255.248) was dann z.B. den Bereich der Adressen von .3.249 bis .3.254 umfasst. oder
192.168.3.240 /29 den Bereich der Adressen von .3.241 bis .3.246.
Du bist damit auch deutlich flexibler wenn nochmal ein paar erreichbare Adressen dazukommen sollten! 😉

Generell kommt bei der Betrachtung deines Setups die Frage hoch wer VPN Initiator und wer Responder ist. Das ist aber für ein Setup sehr wichtig. Das o.a. (Jumphost) Konzept geht immer davon aus das der Strongswan Server der Responder ist und die FritzBox der Initiator.
Bei deinem Konzept könnte es andersrum gemeint sein und dann sieht die Konfig etwas anders aus.

Zitat von @aqui:

Bitte unbedingt Code Tags benutzen!! Geht immer auch noch nachträglich.
Das erleichtert allen hier das Lesen und die Übersichtlichkeit der Konfigs!

Erledigt.

Ich verwende auf StrongSwan-Seite den IP-Bereich 192.168.3.0/24

Der StrongSwan-Server hängt mit der festen IP 192.168.3.19 an einem NAT-Router. Im Router habe ich eine Static Route angelegt:

3c)
Normal ist das die feste WAN IP Adresse eines vServers, also die feste öffentliche IP eines Hosters.
WIE ist den Proxmox bzw. die VM im Netz. Ist das ein Setup hinter einen NAT Router?
Wenn ja, dann musst du ggf. mit FQDNs arbeiten. Das hängt von deinem Proxmox Setup ab.

Ja (s.o.). Und wie geht das mit FQDN? Eine Dyndns-Adresse ist doch FQDN, oder? Die also einfach einsetzen (s.u.)?

Ok, gute Idee, so mach ich das.

connections {
   fritzbox {
      local_addrs = fritzbox.ddnss.de
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = fritzbox.ddnss.de
          }
      remote {
          auth = psk
          id = keyid:strongswan@fritz.box
          }
      children {
          net {
              local_ts = 192.168.3.240/29 
              remote_ts = 192.168.5.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }
}
secrets {
 ike-1 {
      id = keyid:strongswan@fritz.box
      secret = "test1234"  
     }
}

Generell kommt bei der Betrachtung deines Setups die Frage hoch wer VPN Initiator und wer Responder ist. Das ist aber für ein Setup sehr wichtig. Das o.a. (Jumphost) Konzept geht immer davon aus das der Strongswan Server der Responder ist und die FritzBox der Initiator.
Bei deinem Konzept könnte es andersrum gemeint sein und dann sieht die Konfig etwas anders aus.

Ja, so hätte ich das auch gedacht. Ich habe mich mit meinem "Konzept" an einen Vorschlag von Dir orientiert ([S2S-Wireguard: AVM zu Mikrotik]). Wie sollte man das also ändern?
Danke!
Graefe

Der StrongSwan-Server hängt an einem NAT-Router

Das ist OK und die statische Route auch richtig!
Kardinalsfrage bleibt aber WER ist in deinem VPN Konzept der Initiator (VPN Client der aktiv den Tunnel aufbaut) und WER der Responder (VPN Ziel, Server)?
Das hast du in deiner Antwort oben leider immer noch nicht wasserdicht beantwortet.
Das von dir zitierte Konzept bzw. das Jumphost Tutorial gehen immer davon aus das der Strongswan Server der Responder (Server) ist und die remote Fritzbox der Initiator!
Das ist auch logisch da das Tutorial hier einen vServer mit einer festen öffentlichen IP annimmt. Bei einem Initiator sieht die Konfig geringfügig anders aus.

Wenn das auch deinem Design entspricht, dann fehlt in deinem derzeitigen NAT Router Setup noch ein Port Forwarding der IPsec Protokolle auf den Strongswan Server. Oder du hast vergessen das zu erwähnen?!
Die remote Fritzbox ist ja in dem Falle dann der Initiator, also baut aktiv die VPN Verbindung auf. Da sie den Server logischerweise nicht direkt hinter dem NAT Router erreichen kann spricht sie die WAN IP Adresse des NAT Routers oder seinen DDNS Hostnamen, der ja dann auf die Router WAN IP zeigt, an.
Der NAT Router forwardet dann diesen VPN Request an den internen Strongswan Server. Simples Port Forwarding am Router also!
Genau so ein Port Forwarding Szenario findest du HIER beschrieben denn es entspricht dem einer Router Kaskade.
Der NAT Router muss im Falle das der Strongswan Responder ist, dann UDP 500, UDP 4500 und das ESP Protokoll auf die lokale 192.168.3.19 IP forwarden damit die VPN Pakete auch am Strongswan ankommen.
Ist der Strongswan allerdings der Initiator, dann ist das NICHT nötig und es reicht die statische Route.
Das solltest also technisch nochmal klarstellen bevor wir hier falsche Konfigs troubleshooten!!

Da du ja schon ein laufendes Setup hattest wäre es noch einmal hilfreich die dazu korrespondierende Fritzbox Konfig zu sehen.
Du kannst die immer aus der laufenden FB sehr einfach extrahieren indem du eine Konfig Sicherung ausführst.
Die gesicherte Datei ist eine simple Textdatei die du mit einem beliebigen Editor editieren kannst wie z.B. Notepad++. Dort sucht du den Abschnitt "vpncfg {..." und cut and pastes den einfach raus.
Man müsste dann nicht groß fummeln und ggf. nur deine Strongswan Konfig etwas anpassen das die Keepalives durchkommen was sehr wahrscheinlich deine Problematik dann sofort löst.
Dazu ist es aber essentiell das du die Rolle Initiator und Responder klärst!

Zitat von @aqui:

Das von dir zitierte Konzept bzw. das Jumphost Tutorial gehen immer davon aus das der Strongswan Server der Responder (Server) ist und die remote Fritzbox der Initiator!

So soll es sein.

Das ist auch logisch da das Tutorial hier einen vServer mit einer festen öffentlichen IP annimmt. Bei einem Initiator sieht die Konfig geringfügig anders aus.

Bzw. eine DynDNS...

Wenn das auch deinem Design entspricht, dann fehlt in deinem derzeitigen NAT Router Setup noch ein Port Forwarding der IPsec Protokolle auf den Strongswan Server. Oder du hast vergessen das zu erwähnen?!

Stimmt, hatte ich vergessen zu erwähnen, ist aber eingerichtet (sonst hätte mein bisheriger Tunnel gar nicht funktioniert). Nur ESP-Forwarding... Wie geht das?

Da du ja schon ein laufendes Setup hattest wäre es noch einmal hilfreich die dazu korrespondierende Fritzbox Konfig zu sehen.

Bitteschön:

vpncfg {
	connections {
		enabled = yes;
		editable = no;
		conn_type = conntype_lan;
		name = "xxx";  
		always_renew = no;
		reject_not_encrypted = no;
		dont_filter_netbios = yes;
		localip = 0.0.0.0;
		local_virtualip = 0.0.0.0;
		remoteip 
		remote_virtualip = 0.0.0.0;
		localid {
			fqdn = "fb.ddnss.de";  
		}
		remoteid {
			fqdn = "strongswan.ddnss.de";  
		}
		mode = phase1_mode_aggressive;
		phase1ss = "all/all/all";  
		keytype = connkeytype_pre_shared;
		key = "asdfasdfasdf";  
		cert_do_server_auth = no;
		use_nat_t = yes;
		use_xauth = no;
		use_cfgmode = no;
		phase2localid {
			ipnet {
				ipaddr = 192.168.5.0;
				mask = 255.255.255.0;
				}
			}
		phase2remoteid {
			ipnet {
				ipaddr = 192.168.3.0;
				mask = 255.255.255.0;
				}
			}
		phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
		accesslist = "permit ip any 192.168.3.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";  
}
// EOF

Nur ESP-Forwarding... Wie geht das?

Du solltest auch mal die dir oben dazu geposten Links wirklich lesen!

Da sind die relevanten Ports bzw. Protokolle für IPsec doch alle aufgelistet. ESP ist ein eigenständiges IP Protokoll mit der IP Nummer 50. Der ESP Tunnel transportiert bei IPsec die Produktivdaten der SAs.

Zurück zur IPsec Konfig...
OK, Strongswan = Responder und Fritze = Initiator. 👍 Vereinfacht die Sache.... 😉
2 Dinge kannst du an deiner o.a. aktuellen Fritzbox Konfig sehen:

FB authentisiert sich lokal und remote mit einem FQDN Namen. Das muss auf beiden Seiten übereinstimmen sonst scheitert der Tunnelaufbau.
FB negotiated als Phase 2 SAs die beiden Netze .3.0 /24 und .5.0 /24. Auch das muss immer mit dem Gegenüber korrespondieren sonst scheitert der Tunnelaufbau ebenso. Nur als Erinnerung weil du den Strongswan abweichend davon mit einem Host bzw. jetzt mit einer CIDR Range .240 /29 konfiguriert hast. Entspricht dort den local_ts und remote_ts Parametern.

Die korrespondierende Strongswan Konfig sähe dann so aus:

connections {
   fritzbox {
      local_addrs = 192.168.3.19
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = fqdn:strongswan.ddnss.de
          }
      remote {
          auth = psk
          id = fqdn:fb.ddnss.de
          }
      children {
          net {
              local_ts = 192.168.3.240/29 
              remote_ts = 192.168.5.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }
}
secrets {
 ike-1 {
      id = fqdn:fb.ddnss.de
      secret = "test1234"  
     }
} 

Diese o.a. Strongswan Konfig erwartet dann eine Main Mode Connection der Fritzbox. Sprich mode = phase1_mode_idp; in der dortigen Konfig!

Deine o.a. gepostete FritzBox Konfig ist aber, wie du sicher auch selber siehst, eine die den Agressive Mode nutzt, was auch der Default bei der FritzBox ist.
Das kannst du so belassen, musst den Agressive Mode aber dann explizit im Strongswan erlauben, denn der ist im Default dort deaktiviert!!

Dazu editierst du du die /etc/strongswan.d/charon.conf Datei mit dem nano und suchst (<ctrl> w) nach dem Abschnitt:

# Allow IKEv1 Aggressive Mode with pre-shared keys as responder.
    i_dont_care_about_security_and_use_aggressive_mode_psk = yes 

und setzt den Parameter dort auf yes.
Dann ein systemctl restart strongswan und schon akzeptiert er auch die Aggressive Mode Connection einer Standard Fritzbox!

Das musst du dem Strongswan dann auch in seiner Tunnelkonfig für die Fritzbox sagen:

connections {
   fritzbox {
      local_addrs = 192.168.3.19
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = fqdn:strongswan.ddnss.de
          }
      remote {
          auth = psk
          id = fqdn:fb.ddnss.de
          }
      children {
          net {
              local_ts = 192.168.3.240/29 
              remote_ts = 192.168.5.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       aggressive = yes
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }
}
secrets {
 ike-1 {
      id = fqdn:fb.ddnss.de
      secret = "test1234"  
     }
} 

(Man achte auf das aggressive = yes)

Wenn du dann noch deine o.a. Fritzbox konfig korrekt auf die dazu korrespondierenden Phase 2 Credentials anpasst

phase2localid {
	ipnet {
	   ipaddr = 192.168.5.0;
	   mask = 255.255.255.0;
	    }
}
phase2remoteid {
	ipnet {
	   ipaddr = 192.168.3.240;
	   mask = 255.255.255.248;
	   }
} 

(Man achte auf die angepasste Phase 2!)
⚠️ ...und was bei dir leider in der o.a. FB Konfig fehlt:

Einen Keepalive in der FB Konfig setzen oder übers GUI hinzufügen keepalive_ip = 192.168.3.x; so das die FB immer aktiv ein Ziel pingt und damit den Tunnel auch aktiv hält und wieder aufbaut bei einer Trennung. Dann sollte final alles passen. 😉
Beachte das die Keepalive IP mit der o.a. Konfig immer im Address Bereich 192.168.3.240 /29 (255.255.255.248) also zw. den Adressen .3.241 bis .3.246 liegen muss, weil nur dieser Bereich über den VPN Tunnel übertragen wird! (Phase 2 SAs).

Der fehlenden Fritzbox Keepalive ist in deiner alten Konfig sehr wahrscheinlich auch der Auslöser das es nach einer Zwangstrennung zu keinem neuen Tunnelaufbau kommt was dann das fehlende DPD nicht kompensieren kann.

Nur zur Erinnerung...
Willst du mit Main Mode arbeiten musst du 2 Dinge anpassen:

mode = phase1_mode_idp; in der FB Konfig Datei setzen
aggressive = yes aus der Strongswan Konfig entfernen

Belasse die laufende FB Konfig aber erstmal so, dann musst du einzig nur die Strongswan Seite anpassen und hast dann auch die Option sowohl Aggressive als auch Main Mode flexibel bedienen zu können.

Lasse zudem immer ein swanctl -T mitlaufen auf dem Strongswan wenn die Fritzbox sich einwählt um ggf. Fehler immer mitprotokollieren zu können! (<ctrl> c stoppt den Trace wieder)

Juchu, der Tunnel baut sich auf!

)) Sogar im Main Mode.
Ich habe in der FB-Config noch remotehostname = "strong.ddnss.de" ergänzt und remoteip ganz weggelassen - korrekt?

vpncfg {
	connections {
		enabled = yes;
		editable = no;
		conn_type = conntype_lan;
		name = "xxx";  
		always_renew = no;
		reject_not_encrypted = no;
		dont_filter_netbios = yes;
		localip = 0.0.0.0;
		local_virtualip = 0.0.0.0;
		remotehostname = "swan.ddnss.de";  
		remote_virtualip = 0.0.0.0;
		keepalive_ip = 192.168.3.244;
		localid {
			fqdn = "fb.ddnss.de";  
		}
		remoteid {
			fqdn = "swan.ddnss.de";  
		}
		mode = phase1_mode_idp;
		phase1ss = "all/all/all";  
		keytype = connkeytype_pre_shared;
		key = "xxx";  
		cert_do_server_auth = no;
		use_nat_t = yes;
		use_xauth = no;
		use_cfgmode = no;
		phase2localid {
			ipnet {
				ipaddr = 192.168.5.0;
				mask = 255.255.255.0;
				}
			}
		phase2remoteid {
			ipnet {
				ipaddr = 192.168.3.240;
				mask = 255.255.255.248;
				}
			}
		phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
		accesslist = "permit ip any 192.168.3.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";  
}
// EOF

und

connections {
   fritzbox {
      local_addrs = 192.168.3.19
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = fqdn:swan.ddnss.de
          }
      remote {
          auth = psk
          id = fqdn:fb.ddnss.de
          }
      children {
          net {
              local_ts = 192.168.3.240/29
              remote_ts = 192.168.5.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }
}
secrets {
 ike-1 {
      id = fqdn:fb.ddnss.de
      secret = "xxx>  
     }
}

Mein Problem: Es wird kein Traffic zum StrongSwan geroutet. Ein Ping zu 192.168.3.1, 192.168.3.19 oder 192.168.3.241 ist erfolglos. Woran könnte das noch liegen? Ich hätte gerne, dass nur Traffic für 192.168.3.x durch den Tunnel geht.

PS: Bez. ESP-forwarding: Ich habe mir die Anleitung sehr wohl durchgelesen. Aber mein Ubiquiti-Router läßt nur UDP- und TCP-Forwarding zu.

Juchu, der Tunnel baut sich auf! Sogar im Main Mode.

Glückwunsch! 👏👍 Hättest du etwas anderes erwartet...? 😉

und remoteip ganz weggelassen

Das ist korrekt wenn man ein remotes Ziel mit wechselnder IP hat und nur mit dem (DDNS) Hostnamen arbeitet. Man kann pro Seite immer nur IP oder Hostname verwenden nicht beides.

Es wird kein Traffic zum StrongSwan geroutet. Ein Ping zu 192.168.3.1, 192.168.3.19 oder 192.168.3.241 ist erfolglos.

⚠️ Wichtige Frage vorab: IPv4 Forwarding hast du im VPN Server in der /etc/sysctl.conf aktiviert und rebootet??
Wenn ja ist zumindestens für die Adressen .3.1 und .3.19 das auch vollkommen korrekt so und von dir mit der CIDR Einschränkung im Tunnel ja auch so gewollt. Siehe Threadkommunikation oben!! 🧐

Im Eifer des (VPN) Gefechts hast du sicher die CIDR Range in den Phase 2 SAs vergessen die du dir selber für das 3er Netz mit
local_ts = 192.168.3.240/29 und auf der FB mit:
phase2remoteid {
ipnet {
ipaddr = 192.168.3.240; mask = 255.255.255.248; }
BEIDSEITIG definiert hast um nicht nur einen einzelnen Host ins VPN zu routen sondern damit einen limitierten IP Addressbereich mit Keepalive IP und dem Applikationsserver.
Zitat: "...gute Idee, so mach ich das."

Mit den P2 SAs bestimmst du immer den relevanten Traffic der in den VPN Tunnel geroutet wird!
Eine 29 Bit Maske des CIDR Netzes 192.168.3.240 inkludiert also nur die IP Adressen von .3.241 bis .3.246!
Mit anderen Worten aus dem .5.0er Netz werden im 3er Netz dann nur die Ziel IPs .3.241 bis .3.246 in den VPN Tunnel geroutet. Alle anderen landen im Nirwana!!
Sprich alle deine remote, über VPN aus dem .5.0er Netz liegenden IPs inkl. der Keepalive IP, VPN Server usw., müssen also in diesem Bereich liegen!
Und...wenn diese Geräte den lokalen Router z.B. .3.1 als Default Gateway haben muss der eine statische Route des .5.0er Netzes auf die VPN Server IP haben.
Folglich muss der VPN Server, wie gesagt, selber mit seiner lokalen IP auch in der Range liegen. VPN Server und auch Applikationsserver bzw. erreichbare 3er IPs müssen in diesem Bereich liegen.

Möchtest du lieber die .3.19er IP behalten und auch den lokalen Router dort pingbar haben musst du natürlich die CIDR Range so umkonfigurieren das es wieder passt. Dann aber auch den Applikationsserver der dann nicht die .3.24x haben kann. Andernfalls musst du alternativ das gesamte 3er Netz in den Phase 2 SAs freigeben.

Beispiel:
local_ts = 192.168.3.0/27 und auf der FB mit:
phase2remoteid {
ipnet {
ipaddr = 192.168.3.0; mask = 255.255.255.224; }
Erreicht alle Ziel IPs .3.1 bis .3.30 was dann den Server mit der .19 inkludiert.
Eine kleinere Maske geht nicht, da /28 nur .3.1 bis .3.14 abdeckt und die .19 wieder außen vor ist.
Einfache IP Subnetzrechnung... 😉

Schrotschusslösung ist mit
local_ts = 192.168.3.0/24 und auf der FB mit:
phase2remoteid {
ipnet {
ipaddr = 192.168.3.0; mask = 255.255.255.0; }
dann beide Netze vollständig per VPN erreichbar zu machen und bei Zugangsbeschränkungen mit der Firewall auf dem VPN Server (nftables) oder lokalen Firewalls auf den Endgeräten zu arbeiten.
Such dir die für dich schönste Variante aus!

Aber mein Ubiquiti-Router läßt nur UDP- und TCP-Forwarding zu.

UBQT Schrott eben... Von sowas lässt man auch die Finger als Netzwerker. ☹️
Trotzdem tut sich die Frage auf warum du das Fritzbox VPN dann nicht auf dem UBQT Router terminierst. Der kann doch auch IPsec, oder kann er das etwa auch nicht?

Zitat von @aqui:

Es wird kein Traffic zum StrongSwan geroutet. Ein Ping zu 192.168.3.1, 192.168.3.19 oder 192.168.3.241 ist erfolglos.

⚠️ Wichtige Frage vorab: IPv4 Forwarding hast du im VPN Server in der /etc/sysctl.conf aktiviert und rebootet??

Jawohl.

Ok, das ist dann ja ziemlich sinnlos, wenn ich Zugriff auf alle Geräte im 3er-Netz haben will. Dann bleibt mir ja nur Deine "Schrotschuß-Lösung" übrig.

Schrotschusslösung ist mit
local_ts = 192.168.3.0/24 und auf der FB mit:
phase2remoteid {
ipnet {
ipaddr = 192.168.3.0; mask = 255.255.255.0; }
dann beide Netze vollständig per VPN erreichbar zu machen und bei Zugangsbeschränkungen mit der Firewall auf dem VPN Server (nftables) oder lokalen Firewalls auf den Endgeräten zu arbeiten.
Such dir die für dich schönste Variante aus!

Ok, also Schrotschuss - aber damit baut sich kein Tunnel mehr auf. swanctl -T ist leer.

vpncfg {
	connections {
		enabled = yes;
		editable = no;
		conn_type = conntype_lan;
		name = "xxx";  
		always_renew = no;
		reject_not_encrypted = no;
		dont_filter_netbios = yes;
		localip = 0.0.0.0;
		local_virtualip = 0.0.0.0;
		remotehostname = "swan.ddnss.de";  
		remote_virtualip = 0.0.0.0;
		keepalive_ip = 192.168.3.244;
		localid {
			fqdn = "fb.ddnss.de";  
		}
		remoteid {
			fqdn = "swan.ddnss.de";  
		}
		mode = phase1_mode_idp;
		phase1ss = "all/all/all";  
		keytype = connkeytype_pre_shared;
		key = "asdf";  
		cert_do_server_auth = no;
		use_nat_t = yes;
		use_xauth = no;
		use_cfgmode = no;
		phase2localid {
			ipnet {
				ipaddr = 192.168.5.0;
				mask = 255.255.255.0;
				}
			}
		phase2remoteid {
			ipnet {
				ipaddr = 192.168.3.0;
				mask = 255.255.255.0;
				}
			}
		phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
		accesslist = "permit ip any 192.168.3.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";  
}

und

connections {
   fritzbox {
      local_addrs = 192.168.3.19
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = fqdn:swan.ddnss.de
          }
      remote {
          auth = psk
          id = fqdn:fb.ddnss.de
          }
      children {
          net {
              local_ts = 192.168.3.0/24
              remote_ts = 192.168.5.0/24
              esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp1024,aes256-sha1-modp1024
   }
}
secrets {
 ike-1 {
      id = fqdn:fb.ddnss.de
      secret = "asdf>  
     }
}

Was ist denn das schon wieder?

Aber mein Ubiquiti-Router läßt nur UDP- und TCP-Forwarding zu.

UBQT Schrott eben... Von sowas lässt man auch die Finger als Netzwerker. ☹️

Bin ja kein Netzwerker, sondern der DAU. ;)

Trotzdem tut sich die Frage auf warum du das Fritzbox VPN dann nicht auf dem UBQT Router terminierst. Der kann doch auch IPsec, oder kann er das etwa auch nicht?

UBQT-Router erlauben nicht die Benutzung von DynDNS-Adressen mit L2TP, sondern nur mit OpenVPN...

Dann bleibt mir ja nur Deine "Schrotschuß-Lösung" übrig.

Das ist ja auch der übliche Klassiker bei einem VPN.

Konfig oben ist korrekt so.

aber damit baut sich kein Tunnel mehr auf. swanctl -T ist leer.

Bedeutet das am Server keine IPsec Pakete ankommen. Die FB sendet also schon keinen VPN Traffic. Tippfehler beim DDNS Namen, Port Forwarding Fehler oder sowas?!?

Installiere dir mal mit tcpdump einen kleinen onboard Sniffer auf dem Server (apt install tcpdump (sudo)) dann startest du tcpdump port 500 um dir die eingehenden IKE (UDP 500) Pakete ansehen zu können die den Tunnelaufbau triggern. (Stop mit <ctrl> c)
Dann startest du die FB oder ziehst mal deren WAN Port was den VPN Tunnelaufbau neu triggert.
Jetzt solltest du in jedem Falle eingehenden IKE/ISAKMP Traffic (UDP 500) am Server sehen!!
Wenn nicht kommt am Server schon gar kein VPN Traffic von der FB an, dann stimmt irgendwas an der FB oder deinem Port Forwarding nicht.
Solltest du mehrere Interfaces am Server haben kannst du dem tcpdump dies auch mit "-i" dediziert mitgeben ala tcpdump -i eth0 port 500. Wie dein Interface heisst siehst du mit "ip a".

Ok, von der Fritzbox kommt also isakamp-Traffic über Port 500 rein und wird vom Router an den StrongSwan-Server weitergeleitet:

root@StrongSwan:~# tcpdump port 500
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
35:31.154445 IP dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp > StrongSwan.localdomain.isakmp: isakmp: phase 1 I ident
35:31.155658 IP StrongSwan.localdomain.isakmp > dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp: isakmp: phase 2/others R inf
35:36.159580 IP dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp > StrongSwan.localdomain.isakmp: isakmp: phase 1 I ident
35:36.160063 IP StrongSwan.localdomain.isakmp > dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp: isakmp: phase 2/others R inf
35:36.651277 IP scanner-02.ch1.censys-scanner.com.46693 > StrongSwan.localdomain.isakmp: isakmp: parent_sa ikev2_init[I]
35:36.651737 IP StrongSwan.localdomain.isakmp > scanner-02.ch1.censys-scanner.com.46693: isakmp: parent_sa ikev2_init[R]
35:41.156699 IP dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp > StrongSwan.localdomain.isakmp: isakmp: phase 1 I ident
35:41.157114 IP StrongSwan.localdomain.isakmp > dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp: isakmp: phase 2/others R inf
35:46.169601 IP dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp > StrongSwan.localdomain.isakmp: isakmp: phase 1 I ident
35:46.170034 IP StrongSwan.localdomain.isakmp > dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp: isakmp: phase 2/others R inf
35:49.841689 IP scanner-27.ch1.censys-scanner.com.43709 > StrongSwan.localdomain.isakmp: isakmp: phase 1 I ident
35:49.842087 IP StrongSwan.localdomain.isakmp > scanner-27.ch1.censys-scanner.com.43709: isakmp: phase 2/others R inf
35:49.985412 IP scanner-27.ch1.censys-scanner.com.56733 > StrongSwan.localdomain.isakmp: isakmp: parent_sa ikev2_init[I]
35:49.985797 IP StrongSwan.localdomain.isakmp > scanner-27.ch1.censys-scanner.com.56733: isakmp: parent_sa ikev2_init[R]
35:51.164816 IP dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp > StrongSwan.localdomain.isakmp: isakmp: phase 1 I ident
35:51.165248 IP StrongSwan.localdomain.isakmp > dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp: isakmp: phase 2/others R inf
35:56.177366 IP dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp > StrongSwan.localdomain.isakmp: isakmp: phase 1 I ident
35:56.177780 IP StrongSwan.localdomain.isakmp > dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp: isakmp: phase 2/others R inf
36:01.170461 IP dynamic-078-048-089-082.78.48.pool.telefonica.de.isakmp

Aber swanctl -T ist immer noch leer, Strongswan scheint auf den Traffic nicht zu reagieren.
Habe den StrongSwan auch mehrmals rebootet.

root@StrongSwan:/etc/swanctl/conf.d# swanctl -L
fritzbox: IKEv1, reauthentication every 14400s
  local:  192.168.3.19
  remote: 0.0.0.0/0
  local pre-shared key authentication:
    id: swan.ddnss.de
  remote pre-shared key authentication:
    id: fb.ddnss.de
  net: TUNNEL, rekeying every 3600s
    local:  192.168.3.0/24
    remote: 192.168.5.0/24

Der Schrottschuss ist hier echt der Standard da es ums Routing geht. Granularer definiert man die Kommunikation per Firewall.

Aus Verzweiflung habe ich jetzt die Fritzbox auf ein altes Backup wiederhergestellt und die neue VPN-Config aufgespielt. Es scheint jetzt zu laufen - mal abwarten...!

Edit: ...und die Zwangstrennung heute morgen hat der Tunnel auch überlebt...

Kann auch mal sein das sich die FB verschluckt hat. Zur Sicherheit filft dann ein Reboot oder wie du es gemacht hast die VPN Datei neu einzuspielen, was den VPN Daemon auf der FB auch neu startet.
Wenn du einen Tippfehler im klassischen Setup mit den /24er Netzwerkmasken in der P2 gemacht hättest würde die FB auch meckern.

und die Zwangstrennung heute morgen hat der Tunnel auch überlebt...

Klingt ja fürs erste positiv!

👍 Aber das Setup muss natürlich auch so mit der P2 Freigabe der ganzen Netze laufen.
Kann es ggf. auch sein das du nach der Änderung der Konfig auf dem Server ein systemctl restart strongswan vergessen hast? Das stellt sicher das die Konfig Änderung mit dem Daemon Neustart wirklich ausgeführt wird. swanctl -q kann in seltenen Fällen auch mal haken.

Tip:
Wenn du ein -n beim tcpdump Kommando einsetzt also tcpdump -n port 500 macht der Sniffer keinen DNS Lookup und du siehst die nackten IPs was manchmal übersichtlicher ist.

Die Fritzbox hat bekannte Probleme mit dem Importieren von VPN-Konfigurationen.
Wie auch immer, es läuft (auch ohne ESP-Forwarding) und ich bin total happy! Dir herzlichen Dank für die super Hilfestellung!

Immer gerne! 😊

Wie kann ich einen Beitrag als gelöst markieren?

Das Site-2-Site-VPN funktioniert weiterhin zuverlässig. Das einzige was mich stört: Das VPN baut sich erst ca. 30min. nach der Zwangstrennung wieder auf. Kann man die Down-Zeit irgendwie beschleunigen?
Am DynDNS-Service scheint es zumindest nicht zu liegen, der wird sofort aktualisiert.
Danke

Die DPD (Dead Peer Detection) Timer sind im Default auf 0 gesetzt. https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html
Ggf. macht es Sinn diese auf einen sinnvollen Wert zu setzen.

Noch einfacher wäre es allerdings wenn du schlicht und einfach auf der Fritzbox eine Keepalive IP konfigurierst. Bleibt der Ping Response aus triggert die FB den Peer neu. Das klappt aber nur wenn die Fritzbox VPN Initiator ist, NICHT wenn sie Responder ist.
Wenn du einen standalone vServer mit Strongswan hast machst du das idealerweise über eine 2te Loopback Adresse die das Keepalive Ziel ist.
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi

keepalive = lokale Adresse des Routers der Gegenseite?
Ich hatte irgendwo gelesen, dass keepalive nur dazu dient, Traffic zu erzeugen und das Response gar nicht ausgewertet wird.
Danke

Das ist ja gerade der Schlüssel, denn die Erzeugung des Phase 2 relevanten Traffics triggert sofort den Aufbau des Peers. Ob dabei eine Antwort kommt ist dabei völlig Wumpe da nur der Traffic zählt. Normal bleibt ein VPN passiv solange kein relevanter Traffic kommt der in der Phase 2 SA definiert ist. Einfache Logik...

Ok, gerade überprüft, aber die keepalive_ip ist in der Config gesetzt, aber im entfernten Netzwerk keinem Gerät zugewiesen.
Sollte das alway_renew ggf. auf yes jetzt werden?

Zitat von @Graefe:

vpncfg {
	connections {
		enabled = yes;
		editable = no;
		conn_type = conntype_lan;
		name = "xxx";  
		always_renew = no;
		reject_not_encrypted = no;
		dont_filter_netbios = yes;
		localip = 0.0.0.0;
		local_virtualip = 0.0.0.0;
		remotehostname = "swan.ddnss.de";  
		remote_virtualip = 0.0.0.0;
		keepalive_ip = 192.168.3.244;
		localid {
			fqdn = "fb.ddnss.de";  
		}
		remoteid {
			fqdn = "swan.ddnss.de";  
		}
		mode = phase1_mode_idp;
		phase1ss = "all/all/all";  
		keytype = connkeytype_pre_shared;
		key = "asdf";  
		cert_do_server_auth = no;
		use_nat_t = yes;
		use_xauth = no;
		use_cfgmode = no;
		phase2localid {
			ipnet {
				ipaddr = 192.168.5.0;
				mask = 255.255.255.0;
				}
			}
		phase2remoteid {
			ipnet {
				ipaddr = 192.168.3.0;
				mask = 255.255.255.0;
				}
			}
		phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
		accesslist = "permit ip any 192.168.3.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";  
}

Ok, gerade überprüft, aber die keepalive_ip ist in der FB-Config gesetzt (s.o.).
StrongSwan läuft auf einem separaten Rechner hinter einem Router. Dort ist allerdings noch nicht mit ip addr add eine Loopback-IP ergänzt worden.
Warum ist die Einrichtung einer expliziten Loopback-IP eigentlich notwendig bzw. warum darf es auf keinen Fall eine bereits benutzte IP sein bzw. muss sogar zu einem sonst unbenutzten Subnet gehören? Wenn eine Antwort zwar nicht benötigt wird, dann ist sie doch nicht per se nachteilig, oder? Warum kann man nicht einfach irgendeine IP nehmen?

Sollte das always_renew ggf. auf yes jetzt werden?

Ja, unbedingt wenn deine FB der VPN Initiator ist!!

Ok, gerade überprüft, aber die keepalive_ip ist in der FB-Config gesetzt (s.o.).

Gut aber wenn du oben schreibst (Zitat): "aber im entfernten Netzwerk keinem Gerät zugewiesen." dann ist das Setzen dieser IP natürlich sinnfrei. Dort sollte schon ein aktives Gerät (IP) hinterlegt sein. Idealerweise die Loopback IP des Servers, es geht aber natürlich auch jede andere.

Warum ist die Einrichtung einer expliziten Loopback-IP eigentlich notwendig

Sie ist nicht "notwendig" im Sinne eines Zwangs. Vorteil ist aber das der Server als VPN Responder immer erreichbar ist bzw. sein sollte!! Bei IPs im lokalen LAN ist das ja ggf. nicht immer der Fall sollte z.B. der Switch mal ausfallen usw. Ein Einrichtezwang in dem Sinne besteht selbstverständlich nicht du kannst natürlich jede beliebige (erreichbare) IP im remoten Netz nehmen.

Ok, ich habe jetzt eine Loopback-Adresse eingerichtet. Die Adresse ist vom Client anpingbar. Die Fritzbox-Config wurde mit der erweiterten Netzmaske aktualisiert.

vpncfg {
	connections {
		enabled = yes;
		editable = no;
		conn_type = conntype_lan;
		name = "name";  
		always_renew = yes;
		reject_not_encrypted = no;
		dont_filter_netbios = yes;
		localip = 0.0.0.0;
		local_virtualip = 0.0.0.0;
		remotehostname = "strongswan.ddnss.de";  
		remote_virtualip = 0.0.0.0;
		keepalive_ip = 192.168.2.1;
		localid {
			fqdn = "client.ddnss.de";  
		}
		remoteid {
			fqdn = "strongswan.ddnss.de";  
		}
		mode = phase1_mode_idp;
		phase1ss = "all/all/all";  
		keytype = connkeytype_pre_shared;
		key = "geheim";  
		cert_do_server_auth = no;
		use_nat_t = yes;
		use_xauth = no;
		use_cfgmode = no;
		phase2localid {
			ipnet {
				ipaddr = 192.168.5.0;
				mask = 255.255.255.0;
				}
			}
		phase2remoteid {
			ipnet {
				ipaddr = 192.168.2.0;
				mask = 255.255.254.0;
				}
			}
		phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
		accesslist = "permit ip any 192.168.2.0 255.255.254.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

root@StrongSwan:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 192.168.2.1/32 brd 192.168.2.1 scope global lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if105: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a6:5c:90:28:53:54 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.3.19/24 brd 192.168.3.255 scope global dynamic eth0
       valid_lft 66369sec preferred_lft 66369sec
    inet6 2a01:c23:6c87:1500:a45c:90ff:fe28:5354/64 scope global dynamic mngtmpaddr 
       valid_lft 86219sec preferred_lft 86219sec
    inet6 fe80::a45c:90ff:fe28:5354/64 scope link 
       valid_lft forever preferred_lft forever

Auf StrongSwan-Seite beobachte ich den VPN-Tunnel, indem ich die Gegenseite mit einem Skript regelmäßig anpinge. Nach der Zwangstrennung ist der Client für 20-30min. nicht anpingbar. Allerdings sehe ich in dem Fritzbox-Log (Ereignisse) keinen Eintrag, dass der VPN-Tunnel zu diesem Zeitpunkt verloren ginge oder wieder aufgebaut worden wäre.
Gibts da eine Erklärung für?

Gibts da eine Erklärung für?

Das wäre sehr ungewöhnlich. In der Regel dokumentiert die Fritzbox in den "Ereignissen" immer wenn es eine Link Loss oder einen Aufbau der Tunnelverbindung gibt. Zumindestens macht es hier eine 7490 mit latest 7.4er Image wenn man einen VPN Link loss manuell initiiert. Strongswan dokumentiert das ebenfalls. (swanctl -l und ip xfrm state)

Meine FB protokolliert keinen Verlust des VPN-Tunnels, aber dokumentiert den Aufbau des Tunnels nach Zwangstrennung des StrongSwan-Servers.
So, Netzmaske in der StrongSwan-Config war falsch. Jetzt läßt sich die Gegenseite nach ca. 10min nach Zwangstrennung wieder anpingen. Ich denke das ist ganz gut bzw. geht nicht besser?!

Ist hier nicht nachvollziehbar aber wenn 10Min für dich tolerierbar ist who cares?!
Kannst ja alternativ auf der FB mit phase1ss = "LT8h/all/all/all"; mal testweise den klassischen 8 Stunden Keychange aktivieren ob das noch was bringt.

Heute nach Zwangstrennung plötzlich gar kein VPN-Aufbau mehr. Hatte nichts verändert (™).
Fritzbox meldet in Schleife "time out".
StrongSwan für -l bzw. für -T (in Schleife):

root@StrongSwan:~# swanctl -l
(unnamed): #20, CONNECTING, IKEv1, fdd004c0bb2d64ef_i 736e518d9acd61a6_r*
  local  '%any' @ 192.168.3.19[500]  
  remote '%any' @ 93.132.67.142[500]  
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
  passive: ISAKMP_VENDOR MAIN_MODE
(unnamed): #19, CONNECTING, IKEv1, f583ed383b7f9d36_i 08c61e07c433b6fa_r*
  local  '%any' @ 192.168.3.19[500]  
  remote '%any' @ 93.132.67.142[500]  
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
  passive: ISAKMP_VENDOR MAIN_MODE
root@StrongSwan:~# swanctl -l
(unnamed): #20, CONNECTING, IKEv1, fdd004c0bb2d64ef_i 736e518d9acd61a6_r*
  local  '%any' @ 192.168.3.19[500]  
  remote '%any' @ 93.132.67.142[500]  
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
  passive: ISAKMP_VENDOR MAIN_MODE
(unnamed): #19, CONNECTING, IKEv1, f583ed383b7f9d36_i 08c61e07c433b6fa_r*
  local  '%any' @ 192.168.3.19[500]  
  remote '%any' @ 93.132.67.142[500]  
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
  passive: ISAKMP_VENDOR MAIN_MODE
root@StrongSwan:~# swanctl -T
14[JOB] deleting half open IKE_SA with 93.132.67.142 after timeout
16[NET] received packet: from 93.132.67.142[500] to 192.168.3.19[500] (532 bytes)
16[ENC] parsed ID_PROT request 0 [ SA V V V V V V ]
16[IKE] received XAuth vendor ID
16[IKE] received DPD vendor ID
16[IKE] received NAT-T (RFC 3947) vendor ID
16[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
16[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
16[ENC] received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
16[IKE] 93.132.67.142 is initiating a Main Mode IKE_SA
16[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
16[ENC] generating ID_PROT response 0 [ SA V V V ]
16[NET] sending packet: from 192.168.3.19[500] to 93.132.67.142[500] (136 bytes)
13[NET] received packet: from 93.132.67.142[500] to 192.168.3.19[500] (316 bytes)
13[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
13[IKE] local host is behind NAT, sending keep alives
13[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
13[NET] sending packet: from 192.168.3.19[500] to 93.132.67.142[500] (332 bytes)
05[IKE] sending keep alive to 93.132.67.142[500]
09[JOB] deleting half open IKE_SA with 93.132.67.142 after timeout

Kannst Du damit etwas anfangen?

strongswan -q bzw Neustart der Fritzbox helfen nicht. Löschen des VPN-Config-Files der Fritz!Box und Wiedereinspielen hilft auch nicht.

PS: Ich habe Deinen o.g. Vorschlag noch nicht umgesetzt.

PPS: Nachdem ich am Ende aufgegeben habe und ins Bett gegangen bin, sehe ich heute morgen, dass die VPN-Verbindung irgendwann in der Nacht wieder erfolgreich aufgebaut werden konnte. Wie kann das sein??

Wie kann das sein??

Gute Frage... Hört sich so an als ob der Provider auf einer Seite Wartungsarbeiten oder sowas gemacht hat oder es eine DoS Attacke gab. Mehrere hiesige Strongswan Server rennen seit 2 Jahren ohne jegliche Ausfälle oder Hänger (Debian 12).
Hast du den Server zusätzlich mit einer Firewall gesichert (nftables)? Desweiteren ist natürlich fail2ban Pflicht und... das du in jedem Falle und auch den SSH Zugang auf einen Key umstellst und NICHT mehr Username/Passwort nutzt!
Diese 3 Dinge sind für einen stabilen Betrieb eines solchen Servers Pflicht.

Eine grundlegende /etc/nftables.conf Datei findest du im Tutorial.
Grundlagen zu fail2ban u.a. hier.

Hm, mein StrongSwan-Server hängt aber hinter dem Router und nur Port 500 und 4500 werden an StrongSwan durchgereicht, alles andere dürfte also durch die Router-Firewall geschützt sein. Das müsste doch genügen, oder?

OK, dann kannst du das als Fehler natürlich ausschliessen, keine Frage.
Bleibt dann nur noch die wackelige Leitungsqualität des Providers.
https://www.heise.de/select/ct/2024/5/2329915072010250772

Zitat von @aqui:

Ist hier nicht nachvollziehbar aber wenn 10Min für dich tolerierbar ist who cares?!
Kannst ja alternativ auf der FB mit phase1ss = "LT8h/all/all/all"; mal testweise den klassischen 8 Stunden Keychange aktivieren ob das noch was bringt.

Auch nach dieser Modifikation bleibt es dabei, dass der Tunnel ca. 30min. nach Zwangstrennung nicht funktioniert. Die FRITZ!Box zeigt im Log weder die Trennung noch später den Wiederaufbau des Tunnels an.
Auch StrongSwan scheint keine Probleme zu erkennen:

 root@StrongSwan:/etc/ssh# swanctl -l
fritzbox: #699, ESTABLISHED, IKEv1, e58dd5a41d4590a0_i* 5a2c7d278b9e08b9_r
  local  'swan.ddnss.de' @ 192.168.3.19[4500]  
  remote 'fb.ddnss.de' @ 93.132.34.195[4500]  
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
  established 8335s ago, rekeying in 4773s
  net: #117, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_512_256/MODP_1024
    installed 2365s ago, rekeying in 1047s, expires in 1596s
    in  c9f733b8,  24636 bytes,   247 packets,  1473s ago
    out cdbebbf2, 141005 bytes,  1237 packets,     0s ago
    local  192.168.2.0/23
    remote 192.168.5.0/24 

Und es scheint sogar irgendein Traffic über den Tunnel zu laufen:

 root@StrongSwan:/etc/ssh# swanctl -T
16[NET] received packet: from 93.132.34.195[4500] to 192.168.3.19[4500] (140 bytes)
16[ENC] parsed INFORMATIONAL_V1 request 985327319 [ HASH N(DPD) ]
16[ENC] generating INFORMATIONAL_V1 request 2885234460 [ HASH N(DPD_ACK) ]
16[NET] sending packet: from 192.168.3.19[4500] to 93.132.34.195[4500] (140 bytes)
07[NET] received packet: from 93.132.34.195[4500] to 192.168.3.19[4500] (140 bytes)
07[ENC] parsed INFORMATIONAL_V1 request 708828516 [ HASH N(DPD) ]
07[ENC] generating INFORMATIONAL_V1 request 1702527046 [ HASH N(DPD_ACK) ]
07[NET] sending packet: from 192.168.3.19[4500] to 93.132.34.195[4500] (140 bytes)

Aber Pingen geht in beide Richtungen nicht.
Kurz vor Wiederaufbau des Tunnels sagt StrongSwan:

 root@StrongSwan:/etc/ssh# swanctl -l
fritzbox: #703, ESTABLISHED, IKEv1, c322f47523792645_i c49c0a557111551f_r*
  local  'swan.ddnss.de' @ 192.168.3.19[4500]  
  remote 'fb.ddnss.de' @ 93.132.34.195[4500]  
  AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
  established 77s ago, rekeying in 13536s
  net: #117, reqid 1, REKEYED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_512_256/MODP_1024
    installed 3318s ago, rekeying in 94s, expires in 643s
    in  c9f733b8,  24636 bytes,   247 packets,  2426s ago
    out cdbebbf2, 193066 bytes,  1935 packets,     5s ago
    local  192.168.2.0/23
    remote 192.168.5.0/24
  net: #118, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_512_256/MODP_1024
    installed 77s ago, rekeying in 3232s, expires in 3884s
    in  cad17a6d,    672 bytes,     8 packets,     5s ago
    out d5ed12d4,    672 bytes,     8 packets,     5s ago
    local  192.168.2.0/23
    remote 192.168.5.0/24 

Es scheint also ein neuer Tunnel aufgebaut worden zu sein.
Kann man hieraus auf irgendetwas schließen, was das Problem ist?
Danke!

Was ggf. noch einen Versuch wert ist, ist der Fakt das PFS laut AVM nicht supportet ist im Fritzbox IPsec VPN:
https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-5490/3331_FRITZ-Bo ...
"Authentication Header (AH) und Perfect Forward Security (PFS) werden nicht unterstützt."
Die Strongswan Doku sagt dazu im Kapitel IPsec SAs:
https://docs.strongswan.org/docs/5.9/config/rekeying.html
"To make PFS optional (i.e. let the peer choose whether PFS is used or not) add proposals with and without DH groups e.g"

Sinnvollerweise sollte man dann die Fritzbox Peer Definition in der Strongswan Konfig darauf anpassen:

esp_proposals = aes256-sha512,aes256-sha512-modp1024,aes256-sha1,aes256-sha1-modp1024

So ist PFS optional. Oder, da es eh nicht supportet ist, im Fritzbox Peer gleich ganz weglassen mit "esp_proposals = aes256-sha512,aes256-sha1"
Ein Fehler den das Tutorial leider nicht beachtet hat aber korrigiert wird!

Das SHA512 Hashing in der Phase 2 sollte man bei einem Fritzbox Tunnel ggf. auch besser entfernen sofern eine größere Bandbreite im VPN das Ziel ist. Siehe dazu HIER.

Hattest du das Verhalten in beiden Modi, also Main Mode und Agressive Mode, getestet??
Gab es einen Unterschied in beiden Modi mit dem "always_renew = yes/no;" Kommando ob yes oder no?
Der Strongswan ist ja Responder so das ein Rekeying einzig nur vom Initiator also der Fritzbox ausgehen kann. Es ist vollkommen unverständlich warum diese nach der Zwangstrennung nicht sofort den Tunnel wieder aufbaut. Die Keepalives sorgen ja zusätzlich auch dafür das Tunnel relevanter Traffic gesendet wird.
Wie gesagt, an einer hiesigen 7490 mit aktueller Firmware 7.5.7 lässt sich das so nicht reproduzieren.

gelöst Frage Netzwerke VPN

Heiß diskutiert