Aug 19, 2021

5930

VPN auf Dedicated Server

Hallo,

Ich habe vor ein Server im Rechenzentrum zu betreiben. Ich habe mir einige Szenarien angeschaut und habe auch die Idee wie ich das ganze realisieren kann. Nur leider spielt mein Provider nicht ganz mit, weil die keine VPN Verbindung anbieten.

Ich möchte auf ein Server im Rechenzentrum virtualisieren und habe eigentlich alles schon vorbereitet bis auf die VPN Verbindung die ich zeigend benötige um z.B. auf lokale Drucker zu drucken oder zu Scannen.

Auf dem Host, habe ich Cent OS8 mit KVM und Cockpit installiert.
Ich habe eine Netzwerkbrücke für die Kommunikation nach außen und DHCP erstellt.
Betriebssysteme installiert und Updates installiert. Alles über das Cockpit Panel
Ich habe auch Ein VPN Tunnel aufgebaut und die Verbindung zum Host aufgebaut.

Ich bekomme jedoch keine VPN Verbindung zu der Brücke und zu den Gastsystemen.

Ich möchte mein Büro Router über IPSec mit dem Server verbinden und auf die VMs uneingeschränkt zugreifen können. Die VMs sollen auch mit meinen lokalen Geräten kommunizieren, so als wäre alles im gleichen Netz.

Wie bekomme ich diese VPN Verbindung zu Stande? Mehrere IPs vom Provider würde ich bekommen aber das löst nicht mein Problem.

Das vorhandene Tunnel soll einfach nur mit mit den VMs kommunizieren, was mach ich falsch?

Please also mark the comments that contributed to the solution of the article

Content-Key: 1174573041

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

Printed on: April 23, 2024 at 15:04 o'clock

45 Comments

Latest comment

Moin,

Zitat von @bintes:

Hallo,

Ich habe vor ein Server im Rechenzentrum zu betreiben. Ich habe mir einige Szenarien angeschaut und habe auch die Idee wie ich das ganze realisieren kann. Nur leider spielt mein Provider nicht ganz mit, weil die keine VPN Verbindung anbieten.

Ich möchte auf ein Server im Rechenzentrum virtualisieren und habe eigentlich alles schon vorbereitet bis auf die VPN Verbindung die ich zeigend benötige um z.B. auf lokale Drucker zu drucken oder zu Scannen.

Auf dem Host, habe ich Cent OS8 mit KVM und Cockpit installiert.
Ich habe eine Netzwerkbrücke für die Kommunikation nach außen und DHCP erstellt.
Betriebssysteme installiert und Updates installiert. Alles über das Cockpit Panel
Ich habe auch Ein VPN Tunnel aufgebaut und die Verbindung zum Host aufgebaut.

Ich bekomme jedoch keine VPN Verbindung zu der Brücke und zu den Gastsystemen.

Ich möchte mein Büro Router über IPSec mit dem Server verbinden und auf die VMs uneingeschränkt zugreifen können. Die VMs sollen auch mit meinen lokalen Geräten kommunizieren, so als wäre alles im gleichen Netz.

Wie bekomme ich diese VPN Verbindung zu Stande? Mehrere IPs vom Provider würde ich bekommen aber das löst nicht mein Problem.

Das vorhandene Tunnel soll einfach nur mit mit den VMs kommunizieren, was mach ich falsch?

erstmal machst du das hier falsch.
Zum Anderen lieferst du ungefähr null Informationen darüber, wo du den VPN-Tunnel terminierst und wie dein Routing aufgebaut ist.
Hast du auf deinem Virtualisierungshost eine interne Netzwerkbrücke für deine VMs? Hast du eine VM die dort routet?

VG

Hallo und sorry für die falschen Angaben.

Ich habe ein Host mit einer statischen IP Netzwerkkarte eth0 dann habe ich eine Netzwerkbrücke br0 (10.0.0.0/24) aufgebaut mit einem DHCP Server. Die VMs bekommen die IP Adressen von der br0.
VM1 bekommt durch den DHCP Server die IP 10.0.0.11
VM2 bekommt durch den DHCP Server die IP 10.0.0.12
VM2 bekommt durch den DHCP Server die IP 10.0.0.13

Dazu habe ich Libreswan IPSec installiert und einen VPN Client installiert. IP 192.168.40.0/24

Ich kann meinen HomeOffice PC Windows 10 per VPN verbinden und bekomme auch eine IP zugewiesen.. in meinem Fall ist es die 192.168.40.4

Ich kann mich dann mit Putty auf meinem Server an die IP 10.0.0.1 verbinden und auch ein PING funktioniert.

Will ich mich aber an die VMs verbinden und diese ein PING Signal senden funktioniert das nicht.

Wie muss ich den VPN Adapter routen oder wie kann ich die Verbindung mit d en VMs herstellen so als wäre ich im lokalem Netz?

Kollege @BirdyB hat hier Recht. Von den Informationen ist das sehr spartantisch was eine zielführende Hilfe so gut wie unmöglich macht. Auch WAS du nach eigenen Angaben falsch machst erklärst du hier leider nicht so das keiner hier eine Chance hat deine bisherigen Schritte nachzuvollziehen und zu verstehen.

Aber versuchen wir mal einen rudimentären Ansatz...
Fakten:

1. Du hast einen Server auf CentOS Basis
2. Es ist ein VPN Router mit IPsec vorhanden
3. Es soll eine Site-to-Site Kopplung realisiert werden
4. VPN Protokoll ist IPsec

Soweit so gut...
Erste Frage die du dir beantworten musst ist ob der Server direkt mit seinem OS den VPN Tunnel realisieren soll oder ob das z.B. eine (virtualisierte) Firewall in einer VM machen sollte.
Direkt ist das problemlos möglich mit dem Strongswan Package:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi

OPNsense und pfSense wären bei der Firewall Lösung hier deine besten Freunde:
https://forum.netgate.com/topic/122148/installing-pfsense-on-kvm-with-op ...
https://kifarunix.com/install-pfsense-firewall-on-kvm/
Die Firewall Option ist so oder so die gängiste Variante, da man ja niemals einen Hypervisor so ungeschützt ins Internet exponiert. Machen nichtmal mehr Dummies heutzutage. Man kann nur hoffen das das nicht dein Plan war.
Die direkte Variante geht aber auch. Dazu musst du nur das StrongSwan VPN Image (oder auch dein LibreSwan) aus dem CentOS Repository nachinstallieren sofern noch nicht gemacht.

Wie man dann sowas löst kannst du hier nachlesen:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das hat auch eine entsprechende Anleitung zur Anbindung des StrongSwan.
Oder auch hier:
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Das wären so grob die 2 gängigsten Optionen das mit IPsec als VPN Protokoll zu lösen.
Bevor wir jetzt ins Eingemachte gehen solltest du dir also erstmal ganz grundsätzlich überlegen WIE du die VPN Anbindung an dein Büronetz realisieren willst. Machbar ist (fast) alles aber einen groben Plan sollte man schon haben.

Wenn du, wie oben geschildert, mit LibreSwan arbeitest ist das ja per se ja schonmal richtig. Aber....

WIE sollen wir dir helfen wenn du deine Setup Dateien hier nicht postest
WIE sollen wir helfen wenn wir den Gegenpart auf dem IPsec Router nicht kennen ? (Screenshots)
Es fehlen Hilfen wie der Output des LibreSwan Logs und auch des IPsec Router Logs um genau zu sehen WO der Fehler liegt

Du beschreibst nur etwas grob mit ein paar Brocken IP Adressen aber das gesamte VPN IPsec Setup fehlt und ALLE Log Outputs fehlen komplett !
Ohne in die Kristallkugel blicken zu müssen ist doch eine zielführende Hilfe so gut wie unmöglich...

Hallo @aqui und @ BirdyB

gewünscht wird vom Büro per VPN Site to Site auf den gesamten Server inkl. Gastsystem zugreifen zu können. Wenn ich unterwegs bin soll ich auch per VPN Mobile ebenfalls auf dem Server zugreifen zu können.

Im Büro soll die Verbindung konstant bleiben, weil ich ein Multifunktionsgerät habe mit dem ich Drucken und Scannen möchte. Genauso habe ich drei Telefone die ich auch über eine VMs provisionieren möchte.

Die VPN Verbindung soll von meinem Bintec Elmeg RS353jv Router direkt mit der CentOS Maschine verbunden werden. Auf beiden Seiten besteht eine feste IP.

Firewall würde ich einmal die vom Provider Hetzner nutzen und einmal die vom Cent OS 8 habe jedoch alle Regel erstmal deaktiviert, weil ich die keine Verbindung mit den VMs bekomme.

Tunnelaufbau und zwischen den Bintec Router und Cent OS 8 funktioniert. Genauso die Client Verbindung vom Windows 10 zu Cent OS 8.

Cent OS 8 minimal wurde vom Provider zur Verfügung gestellt.

Nach der Einrichtung habe ich erst alle updates durchgefürt und im Anschluss KVM und Cockpit installiert. über die Webseite xxxx.xxx.xxx.xxx:9090 konnte ich meine VMs anlegen und managen funktioniert alles wunderbar und ich komme mit den VMs über VNC ins Internet alles ok.

Nun kommen wir zum VPN

nachdem alles eingerichtet ist und die VMs arbeiten wollte ich mich per RDP auf eine VM anmelden funktioniert jedoch nicht, weil der Host nur eine IP hat und auch keine Weiterleitung an Port 3389 hat. Also um das Problem zu lösen und die VMs mit meinem lokalen Netz kommunizieren zu lassen finde ich VPN als den richtigen Weg.

Auf der Webseite: https://github.com/hwdsl2/setup-ipsec-vpn habe ich diesen Setuptool gefunden und damit mein VPN Dienst installiert. Nach dem Setup wurden schon die Zugangsdaten angezeigt und diese habe ich auch in meinem VPN Router im Büro eingetragen nach paar Sekunden später war ich per VPN mit dem Server verbunden. KEINE Fehlermeldungen und auch keine Abbrüche. Ich kann die Cockpit Seite mit 10.0.0.1:9090 abrufen und auch die VMs verwalten. Mein vorhaben ist aber damit nicht erfolgreich beendet, den ich will direkt auf die VMs zugreifen und dass klappt leider nicht.

Zur Problemlösung habe ich auch net.ipv4.ip_forward=1 im /etc/sysctl.conf eingetragen und rebootet. Es klappt einfach nicht. Was ich als Hilfe benötige ist ein HowTo um dieses Routing richtig zu konfigurieren. Ich kann euch keine Screenshots zeigen und Logs wenn ich die Konfiguration nicht gemacht habe.

Die Frage ist wie stellt man die Netzwerkadapter ein um das zu realisieren.... wenn das nicht klappt, dann kann ich euch die Logs und meine durchgeführten Schritte erläutern.

Welches Standard-Gateway haben deine VMs und wie kommen die VMs ins Internet?

Wenn ich auf die VMs mich einlogge bekomme ich den Standard Gateway von der br0 (Netzwerkbrücke) also 10.0.0.1. Die Hostmaschine hat ein statisches Gateway vom Provider.

die VMs mit meinem lokalen Netz kommunizieren zu lassen finde ich VPN als den richtigen Weg.

Das ist auch so problemlos machbar !

Es klappt einfach nicht.

Erste Anlaufstelle wäre dann doch logischerweise deine LibreSwan Log Files !!! Wo sind die ???
Zweite Anlaufstelle wäre der Bintec Log File ! Wo ist der ??

In den Log Files steht zu 98% WO der Fehler liegt oder zeigt obe der VPN Tun nel überhaupt zustande kommt ! Der Bintec zeigt den VPN Tunnelstatus auch an. Wir wäre nützlich zu wissen ob der "grün" ist.
Für uns wäre für eine zielführende Hilfe folgendes wichtig:

Inhalt der LibreSwan Konfig datei unter /etc/ipsec.conf
Was passiert (Konsol Output) wenn du mit ipsec restart die IPsec Client Verbind reinitialisierst und dann mit ipsec up <conn_name> neu startest. Der Output wäre essentiell wichtig zu wissen. "conn_name" ist dabei der Name des Tunnel in der Konf Datei zum Bintec !
Log Datei des Libre Swan
Screenshots des IPsec Setups des Bintec
Log Datei mit den Log Entries was der Bintec mitloggt wenn LibreSwan den Tunnel aufbaut

All das müssen wir KOMPLETT kennen um einen möglichen Fehler zu sehen und dir weiterhelfen zu können !
Wichtig ist doch zuallererst mal zu klären ob du überhaupt einen aktiven VPN Tunnel hast zum Server. Ist der gar nicht existent muss man sich über fehlende IP Connectivity nicht groß wundern.
Dein Szenario kannst du HIER mal am Beispiel mit einer FritzBox sehen.

Hallo,

also ich habe selber mal noch einige Möglichkeiten probiert. Mittlerweile habe ich es geschafft per VPN die Verbindung zum Server aufzubauen. Leider läuft es immer noch nicht nach meinen Vorstellungen.

Mit mobilen Geräten Laptop, iPhone usw. möchte ich die L2TP/IPSec Verbindung nutzen.

version 2.0

config setup
  virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.42.0/24,%v4:!192.168.43.0/24
  uniqueids=no

conn shared
  left=%defaultroute
  leftid=5.9.XXX.XXX
  right=%any
  encapsulation=yes
  authby=secret
  pfs=no
  rekey=no
  keyingtries=5
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  ikev2=never
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1,aes256-sha2;modp1024,aes128-sha1;modp1024
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes256-sha2_512,aes128-sha2,aes256-sha2
  ikelifetime=24h
  salifetime=24h
  sha2-truncbug=no

conn l2tp-psk
  auto=add
  leftprotoport=17/1701
  rightprotoport=17/%any
  type=transport
  also=shared

conn xauth-psk
  auto=add
  leftsubnet=0.0.0.0/0
  rightaddresspool=192.168.43.10-192.168.43.250
  modecfgdns="8.8.8.8 8.8.4.4"  
  leftxauthserver=yes
  rightxauthclient=yes
  leftmodecfgserver=yes
  rightmodecfgclient=yes
  modecfgpull=yes
  cisco-unity=yes
  also=shared

include /etc/ipsec.d/*.conf

Das nutze ich für die Mobilen Geräte.

conn ikev2-cp
  left=%defaultroute
  leftcert=5.9.XXX.XXX
  leftsendcert=always
  leftsubnet=0.0.0.0/0
  leftrsasigkey=%cert
  right=%any
  rightid=%fromcert
  rightaddresspool=192.168.43.10-192.168.43.250
  rightca=%same
  rightrsasigkey=%cert
  narrowing=yes
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  auto=add
  ikev2=insist
  rekey=no
  pfs=no
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
  ikelifetime=24h
  salifetime=24h
  encapsulation=yes
  leftid=5.9.XXX.XXX
  modecfgdns="8.8.8.8 8.8.4.4"  
  mobike=yes

Das nutze ich für die Site-to-Site Verbindung

Was meine Probleme noch sind:

a: wenn ich mich mit den mobilen Geräten verbinde, verliere ich die Lokale Internetverbindung und kann nur über den Tunnel kommunizieren.
b: ich kann von dem Router auf dem Server zugreifen aber nicht umgekehrt. Ich kann z.B. vom Server nicht auf die lokalen Geräte zugreifen.

Ich benötige eine VPN Verbindung die zwischen den IP Netz 10.0.0.0/24 wo sich mein Server und die Telefonanlage befinden und mein lokales Netz 192.168.1.0/24 eine Kommunikation als wäre das ein Netz.

Als zweites möchte ich in einem Eis Café sitzen und mit meinem Notebook mich auf dem Server verbinden können und auf dem lokalen Netz Youtube Musik hören...

Mittlerweile habe ich es geschafft per VPN die Verbindung zum Server aufzubauen.

👍

Mit mobilen Geräten Laptop, iPhone usw. möchte ich die L2TP/IPSec Verbindung nutzen.

Dann musst du natürlich zusätzlich auch eine L2TP Konfig dafür verwenden !! Deine obige Konfig ist IPsec native und KEIN L2TP und kann somit natürlich niemals mit L2TP Clients funktionieren.

Eine praxistaugliche L2TP Konfig für deinen CentOS Server findest du z.B. hier:
Ubtuntu 20.10 mit UdmPro L2tp VPN Server verbinden
Bzw. wenn du mit einem GUI arbeitest hier.

Dann musst du natürlich zusätzlich auch eine L2TP Konfig dafür verwenden !! Deine obige Konfig ist IPsec native und KEIN L2TP und kann somit natürlich niemals mit L2TP Clients funktionieren.

Also wenn ich die Configs vergleiche
Habe wohl eine L2TP Config
Ich kann mich auch vom Windows Client sauber verbinden. Kann aber nur mit dem Server kommunizieren und nebenbei nicht im Netz surfen.

Ich kann mich auch vom Windows Client sauber verbinden.

Wirklich mit L2TP Protokoll ??

wenn ich mich mit den mobilen Geräten verbinde, verliere ich die Lokale Internetverbindung und kann nur über den Tunnel kommunizieren.

Das ist eine Fehlkonfiguration deinersets des Clients bzw. Servers. Du nutzt dann hier statt des üblichen Split Tunneling eine Gateway Redirection Konfig. Dazu musst du den Client umkonfigurieren:

Haken hier entfernen bei "Standardgateway für das Remotenetzwerk..."

ich kann von dem Router auf dem Server zugreifen aber nicht umgekehrt.

Liegt vermutlich daran das du die iptables Firewall aktiv hast und am virtuellen Tunnel Interface Traffic blockst oder NAT im Tunnel machst. Blocking und/oder NAT verhindert dann den Zugriff. Dazu müsste man aber deinen iptables Ruleset kennen um das final beantworten zu können.

Wirklich mit L2TP Protokoll ??

JA wirklich

Danke für die Config ma Client es funktioniert jetzt auch das Internet.

Leider meine immer noch nicht mein Ziel.

Ich habe jetzt das ganze mal mit Debian 11 ausprobiert. und bin glaub ich zumindest etwas näher dran.

Hier ist mein HowTo:

Debian 11 minimal als nacktes Host. Ich ändere keine IPs lasse alles wie es ist.

Schritt 1: Firewall Installation

# apt update && upgrade
# apt install firewalld

Schritt 2: Cockpit Installation

# apt install -t bullseye-backports cockpit
# apt install -t bullseye-backports cockpit-machines
# apt install -t bullseye-backports cockpit-networkmanager
# apt install -t bullseye-backports cockpit-packagekit
# apt install -t bullseye-backports cockpit-pcp
# apt install -t bullseye-backports cockpit-storaged

Mehr benötige ich auch nicht

Schritt 3: Installation der Virtualisierung

#apt install --no-install-recommends qemu-system libvirt-clients libvirt-daemon-system virtinst
#apt install dnsmasq-base bridge-utils iptables qemu-utils
#adduser XXXX
#adduser XXXX libvirt

Shritt 4: Installation der VPN Verbindung

# mkdir /vpn
#wget https://git.io/vpnquickstart -O vpn.sh && sudo sh vpn.sh


#reboot

Nachdem dieser Skript durchgelaufen ist, wurden die passenden Zertifikate für ikve2 und l2tp/ipsec erstellt und ausgegeben.
Mit den Daten kann man dann die VPN Verbindungen herstellen.

Schritt 5: Firewall konfigurieren
(Achtung libvirt erstellt eine eigene Zone)

#firewall-cmd --get-default-zone
#firewall-cmd --set-default-zone=libvirt
#firewall-cmd --add-service=ipsec
#firewall-cmd --add-service=cockpit
#firewall-cmd --add-service=xl2tpd
#
Probeweise habe ich auch alle Interfaces mit reingebunden jedoch ohne Erfolg
#firewall-cmd --add-interface=enp8s0

Schritt 6: Root Account deaktivieren

#passwd -l root
#usermod -p "!" root 

Nach dieser Konfiguration habe ich über Cockpit meine Maschinen installieren können und vom libvirt wurde auch eine virbr0 erstellt mit DHCP, so das die VMs auch ins Internet kommen und unter einander Kommunizieren.

Ich schaffe es jedoch nicht per VPN auf die VMs zuzugreifen. Ich komme immer nur bis zum Host.

Wo mache ich Fehler?

Arbeiten die VMs in einem anderen IP Netz auf dem Hypervisor ?
Mit welchem VPN Client greifst du zu ? Bzw. welche IP Adresse bzw. Netzwerk bekommst du bei aktivem VPN Client auf dem Tunnel Interface ? (ipconfig -all bei Winblows)

Stimmen die mit den hier angegeben Adressen überein ?
https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/advanced-usag ...
(Zitat: "Please note, additional configuration is required if you want VPN clients to access the local subnet behind the network interface that is NOT for Internet access.")
Um also auf das gesamte lokale Subnet des Servers zugreifen zu können und damit auch auf deine VMs, sofern diese sich in dem gleichen Subnet befinden, sind laut Beschreibung ein paar zusätzliche Kommandos bei dieser Installation nötig:
https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/advanced-usag ...

Hm also…

libvirt erstellt ein 192.168.122.0/24 Subnet

VPN Script erstellt zwei verschiedene

1x 192.168.43.0/24 IPSEC (IKEv2)
1x 192.168.42.0/24 L2TP

Vom Provider habe ich für den Host ein 5.9.XXX.XXX/27 Netz

Ich habe versucht alles in das 10.0.0.0/24 zu bringen

Also mein Subnet als 10.0.0.0/24
Das IPSec 10.0.0.0/24
Und das L2TP 10.0.0.0/24

Danach ging nichts mehr 😂

Würde ja vollständig der beschriebenen IP Adressierung widersprechen sofern du L2TP nutzt !
(Zitat: "Clients are assigned internal IPs from 192.168.42.10 to 192.168.42.250" !!)
Auch mit IPsec native und Xauth wäre es dann das .43.0er Netz was deiner .122.0er Adressierung ja völlig widerspricht.
Geht man nach der Anleitung des Scripterstellers stimmt da also generell was nicht....

Ja aber bei meinen Router Konfigurationen habe ich nie das gleiche Subnetz genommen.

Z. B. Bei einem 10.0.0.0/24 Netz habe ich für VPN L2TP immer 10.0.1.0/29 genommen. Ich konnte aber über VPN auch auf das 10.0.0.0./24 zugreifen und verwalten.
Sehr häufig habe ich L2TP auf UNIQUITI Firewalls und bin immer gezwungen zwei Subnetze zu haben.

Wobei wenn ich recht überlege ist es ja mit VLANs gelöst. (Denkfehler)

Wobei wenn ich recht überlege ist es ja mit VLANs gelöst.

So ist es !

Siehe VLAN_Tutorial.

OK! Also ich habe es jetzt auch so eingestellt, dass die VPN Verbindungen im gleichen Netz landen.

Aktuelles Netz: 10.0.0.0/24
IPSec: 10.0.0.100-10.0.0.200
L2TP: 10.0.0.201-10.0.0.250

weiterhin keine PING Befehle und auch keine Kommunikation. Obwohl ich im gleichen Subnet bin.

Zitat von @bintes:
weiterhin keine PING Befehle und auch keine Kommunikation. Obwohl ich im gleichen Subnet bin.

Dafür muss der Router auf dem Interface Proxy-ARP spielen damit das funktioniert, weil die Clients ja nicht wirklich auf dem selben Interface liegen muss für die VPN Clients der Router die ARP Antworten liefern, die anderen Stationen senden dann Ihre Pakete an den Router und dieser leitet diese an die VPN-Clients auf dem VPN-Interface weiter ...

OK und wie kann ich das einstellen? Ich habe das nie gemacht.

Bei besseren Routern ist das mit dem Kommando ip proxy-arp konfigurierbar. Bei billigen Consumer Routern die L2TP support ist es meistens im Default bereits aktiviert wenn man L2TP scharf schaltet um Anfänger nicht zu verwirren.
StrongSwan nutzt das farp Plugin dafür. Sollte dann bei LibreSwan identisch sein.
https://wiki.strongswan.org/projects/strongswan/wiki/Farpplugin

Ich habe jetzt das nochmal geprüft. Leider klappt es immer noch nicht. Ich habe das mit dem ARP geprüft und es ist aktiviert.

Kann das an den IPTables liegen?

Zitat von @bintes:

Ich habe jetzt das nochmal geprüft. Leider klappt es immer noch nicht. Ich habe das mit dem ARP geprüft und es ist aktiviert.

Kann das an den IPTables liegen?

Check halt dein Regelwerk, vor allem die beteiligten Interfaces der Regeln, wenn man schon ne Firewall einsetzt dann sollte man sie auch beherrschen oder zumindest wissen wie man Ihr Logs entlockt ...

Die Verzweiflung steigt.

Ich habe die IPTables nochmals überprüft die Firewall sogar komplett gelöscht ohne Veränderungen.

Wenn ich eine IKEv2 Verbindung über den Router versuche, wird die Verbindung aufgebaut und auf beiden Seiten als verbunden angezeigt aber ich kann von beiden Seiten nicht pingen.

Wenn ich eine L2TP Verbindung über mein Windows Client erstelle, bekomme ich eine Verbindung hin und kann auch pingen und mich auf die VMs verbinden aber die VMs kommen nicht mehr ins Internet. Vermutlich, weil der gesamte Datenverkehr über das VPN geleitet wird jedoch habe ich keine Ahnung wo ich das auf dem Server deaktivieren kann.

Du armes Kerlchen. So von außen betrachtet, ist das es sehr amüsant.
Fang doch mal am Anfang an. Erstell eine vernünftige Netzwerkplanung und dann kommt der Rest von allein. In deinem Fall, könnte man sogar das Schaubild des Artikels auf Wikipedia zum Thema VPN als Grundlage nehmen.

aber die VMs kommen nicht mehr ins Internet.

Zeigt das du ein Problem mit dem Masquerading (NAT) in den iptables Settings hast. Prüfe die, denn dort stimmt irgendwas nicht. Das VM IP Netz ist bei dir vermutlich ein RFC1918 Netz was dann nicht mehr im Masquerading arbeitet wenn dein VPN aktiv ist.
Bei IKEv2 stimmen dann vermutlich deine Phase 2 Einträge nicht. Du musst dort in der Phase 2 entweder beide Netze angeben oder eine größere Subnetzmaske die beide lokalen Netze inkludiert.
Guckst du auch hier: IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik

Zitat von @148656:

Du armes Kerlchen. So von außen betrachtet, ist das es sehr amüsant.
Fang doch mal am Anfang an. Erstell eine vernünftige Netzwerkplanung und dann kommt der Rest von allein. In deinem Fall, könnte man sogar das Schaubild des Artikels auf Wikipedia zum Thema VPN als Grundlage nehmen.

Mag sein das ich nicht ein VPN Experte bin... aber dein Kommentar löst nicht mein Problem. Wenn ich den Fehler lokalisieren könnte, würde ich es beheben.

Zitat von @aqui:

aber die VMs kommen nicht mehr ins Internet.

So wie ich das sehe, liegt es allein nur an dem Libreswan.

Kennt jemand von euch ein Konfig Beispiel um folgende Funktionen zu erreichen.

Ich benötige eine Site-to-Site Verbindung und Client to Site

Seite A bintec elmeg VPN Router (für die Site to Site Verbindung)
Seite A Windows 10 VPN IPSec (für die Client to Site Verbindung)

Seite B Hetzner Dedicated Server mit Debian 11 (KVM Host) und einer statischen IP

Die VPN Verbindung soll so aufgebaut werden, dass das VPN Tunnel komplett auf dem virtuellen Switch (erstellt von KVM) zugreift.

Ich habe bereits mehrere Möglichkeiten probiert jedoch ohne Erfolg. In verschiedenen Foren wird sogar behauptet, das dies nicht möglich ist, weil Hetzner eine Sperre auf dem NIC hat. Kann mir aber sowas nicht vorstellen.

Über hilfreiche Lösungen würde ich mich freuen.

So wie ich das sehe, liegt es allein nur an dem Libreswan.

Deswegen wäre StrongSwan auch die bessere Wahl gewesen.
Mit einer FritzBox zusammen klappt damit dein gefordertes Setup problemlos. Siehe oben. Sollte also beim Bintec ähnlich klappen.

Zitat von @aqui:

So wie ich das sehe, liegt es allein nur an dem Libreswan.

Deswegen wäre StrongSwan auch die bessere Wahl gewesen.
Mit einer FritzBox zusammen klappt damit dein gefordertes Setup problemlos. Siehe oben. Sollte also beim Bintec ähnlich klappen.

Ich bekomme die Konfiguration an dem bintec Router schon hin. Hast du ein Config Beispiel mit StrongSwan ich habe keinerlei Erfahrungen mit dieser Art von VPN.

Zitat von @bintes:

Zitat von @aqui:

So wie ich das sehe, liegt es allein nur an dem Libreswan.

Deswegen wäre StrongSwan auch die bessere Wahl gewesen.
Mit einer FritzBox zusammen klappt damit dein gefordertes Setup problemlos. Siehe oben. Sollte also beim Bintec ähnlich klappen.

Ich bekomme die Konfiguration an dem bintec Router schon hin. Hast du ein Config Beispiel mit StrongSwan ich habe keinerlei Erfahrungen mit dieser Art von VPN.

Hier musst du nur dein Szenario raussuchen und nachmachen
https://wiki.strongswan.org/projects/strongswan/wiki/UserDocumentation#C ...

LibreSwan und Strongswan sind doch mehr oder minder völlig identisch.... Gleiches Ding wie mit Open Office und Libre Office. Eins ist immer etwas besser gepflegt als das andere

Zitat von @aqui:

LibreSwan und Strongswan sind doch mehr oder minder völlig identisch.... Gleiches Ding wie mit Open Office und Libre Office. Eins ist immer etwas besser gepflegt als das andere

Deshalb meine Befürchtung, dass ich am Ende vor dem gleichen Problem stehe.

Testsetup mit ner Fritze folgt... Bintec Hardware hab ich leider nicht zum testen.

Table of contents

Testsetup Design

VPN Setup FritzBox

StrongSwan Setup

Alternativ Strongswan Variante mit moderner swanctl Syntax

Tunnelaufbau zur FritzBox und Pingcheck

Einfaches Test Setup und funktioniert auf Anhieb wie erwartet...

Testsetup Design

VPN Setup FritzBox

Einfaches Default Setup über das FritzBox GUI

StrongSwan Setup

etc/ipsec.conf (Mit etwas konservativem Schlüssel Setup. Klappt wohl auch mit "aes256-sha256-modp2048")

conn fritzbox
  keyexchange=ikev1
  aggressive = yes
  authby=secret
  ike=aes256-sha1-modp1024
  esp=aes256-sha1-modp1024
  type=tunnel
  auto=add
  left=10.1.1.148
  leftsubnet=192.168.88.0/24
  right=10.99.1.146
  rightsubnet=192.168.188.0/24 

etc/ipsec.secret
: PSK "test1234"

Alternativ Strongswan Variante mit moderner swanctl Syntax

connections {

fritzbox {
        local_addrs = 10.99.1.144
        remote_addrs = 0.0.0.0/0
        aggressive = yes
        local {
            auth = psk
            id = 10.99.1.144
        }
        remote {
            auth = psk
            id = keyid:strongswan@fritz.box
        }
        children {
            net {
                local_ts = 192.168.88.0/24
                remote_ts = 192.168.188.0/24
                ipcomp = no
                esp_proposals = aes256-sha1-modp1024
                rekey_time = 60m
            }
        }
        version = 1
        fragmentation = yes
        proposals = aes256-sha-modp1024
        rekey_time = 60m
        dpd_delay=0s
        encap=no
    }
}
secrets {
   fritzbox {
      id = strongswan@fritz.box
      secret = test1234
   }
} 

Tunnelaufbau zur FritzBox und Pingcheck

root@linux:/etc# ipsec up fritzbox
initiating Aggressive Mode IKE_SA fritz[1] to 10.99.1.146
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from 10.1.1.148[500] to 10.99.1.146[500] (420 bytes)
received packet: from 10.99.1.146[500] to 10.1.1.148[500] (448 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID HASH N((24576)) V V V V V NAT-D NAT-D ]
received XAuth vendor ID
received DPD vendor ID
received NAT-T (RFC 3947) vendor ID
received draft-ietf-ipsec-nat-t-ike-03 vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
IKE_SA fritz[1] established between 10.1.1.148[10.1.1.148]...10.99.1.146[10.99.1.146]
scheduling reauthentication in 9976s
maximum IKE_SA lifetime 10516s
generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
sending packet: from 10.1.1.148[500] to 10.99.1.146[500] (108 bytes)
generating QUICK_MODE request 2632869809 [ HASH SA No KE ID ID ]
sending packet: from 10.1.1.148[500] to 10.99.1.146[500] (316 bytes)
received packet: from 10.99.1.146[500] to 10.1.1.148[500] (92 bytes)
parsed INFORMATIONAL_V1 request 2950936910 [ HASH N(INITIAL_CONTACT) ]
received packet: from 10.99.1.146[500] to 10.1.1.148[500] (300 bytes)
parsed QUICK_MODE response 2632869809 [ HASH SA No KE ID ID ]
selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
CHILD_SA fritz{1} established with SPIs c4b2e7ef_i a5db92d3_o and TS 192.168.88.0/24 === 192.168.188.0/24
connection 'fritz' established successfully

root@raspi2b:/etc# ip xfrm state list
src 10.1.1.148 dst 10.99.1.146
        proto esp spi 0xa5db92d3 reqid 1 mode tunnel
        replay-window 0 flag af-unspec
        auth-trunc hmac(sha1) 0xd639693de71851e0329768b103839b90077ff789 96
        enc cbc(aes) 0x76dedf3a8646736514a8a795ff72e1fcb64cbedb721fa2879e6b2f0aa1b1229e
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.99.1.146 dst 10.1.1.148
        proto esp spi 0xc4b2e7ef reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0x055a731541ae8dceb2c6df32c4e83d8abf71f8df 96
        enc cbc(aes) 0x2e40347c4621d2fa2fbd9700b92f48684fa7ed03a8729a5b560e249e7e8cd442
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

root@raspi2b:/etc# ping -c 3 192.168.188.1
PING 192.168.188.1 (192.168.188.1) 56(84) bytes of data.
64 bytes from 192.168.188.1: icmp_seq=1 ttl=64 time=1.44 ms
64 bytes from 192.168.188.1: icmp_seq=2 ttl=64 time=1.33 ms
64 bytes from 192.168.188.1: icmp_seq=3 ttl=64 time=1.38 ms 

Works as designed !

Zitat von @aqui:
aggressive = yes

Nur noch als Hinweis für den TO: Der "Aggressive Mode" ist normalerweise per Default aus Sicherheitsgründen in der Strongswan config deaktiviert, dieser muss dann erst noch in der /etc/strongswan.d/charon.conf freigeschaltet werden mittels setzen der Zeile

i_dont_care_about_security_and_use_aggressive_mode_psk = yes

im charon{} Abschnitt und anschließendem Service-Restart, wenn man überhaupt noch PSK via aggressive mode und IKEv1 nutzen will, ich würde es jedenfalls nicht.
Besser wäre es natürlich gleich dem Main Mode zu benutzen, bedingt aber bei Fritzbüchsen natürlich noch das manuelle Anpassen der VPN-Config.

Guter Punkt !
Oben reichte allerdings die Eingabe "aggressive = yes" in der Konfig Datei (aktuellstes Debian bzw. Ubuntu und Strongswan normal aus dem Repository) um das zu aktivieren.
Es ist auch nur eine FritzBox Besonderheit, denn die verwenden im Default immer den Agressive Mode. Kann man wie du schon richtig sagst mit einer dedizierten vpn.cfg Konfig Datei aber auch umschalten auf den Main Mode. Bintec wird vermutlich auch den Main Mode nutzen ?! Ggf. sogar IKEv2 wenn die das supporten.
Sollte hier auch nur zeigen das StrongSwan sowas immer "out of the box" wuppt...

Das ist alles super aber mein Aufbau ist etwas anders. Diese Verbindung habe ich auch in extrem kurzer Zeit hinbekommen.

Ich habe zwei Skizzen erstellt wie mein Aufbau ist, ich hoffe Ihr könnt besser meine Problematik verstehen.

Ich bekomme es nicht hin, dass mein VPN mit dem Subnet der VMs kommuniziert.

Ich komme auch mit dem PuTTY auf den Host und kann über den VPN Tunnel normal arbeiten. Ich komme nur nicht auf die einzelnen VMs

Dann poste doch bitte auch deine VPN Config. So wie das aussieht ist hier wohl das Forwarding auf dem Debian deaktiviert, prüfe das als erstes (sysctl net.ipv4.conf.all.forwarding), zusätzlich prüfen ob die Firewall des Debian in der Forwarding-Chain den Traffic in das 10.1.1.1 Netz zulässt.
Außerdem stimmt da was bei deinen Bildern nicht, einmal hat der Debian 10.1.1.1 und ein anderes mal 10.1.1.2 als IP in der virbr0.
Zusätzlich natürlich zu beachten gilt es das bspw. Windows VMs ICMP Pakete per Default nur aus ihrem eigenen Subnetz entgegen nehmen, hier muss man also die Firewall entsprechend ICMP Pakete aus anderen Subnetzen zulassen!

Ich bekomme es nicht hin, dass mein VPN mit dem Subnet der VMs kommuniziert.

Kollege @149062 hat hier absolut Recht ! WIE sieht denn deine StrongSwan (oder Libreswan) Konfig dazu aus ?? Diese wäre wichtig zu kennen. Logisch, für eine zielführende Hilfe.
Ebenso der Strongswan Output wie oben im Beispiel um zu sehen ob der Tunnel hochkommt.
Für deinen Server ist essentiell wichtig das dort IPv4 Forwarding mit net.ipv4.ip_forward=1 in der /etc/sysctl.conf (Reboot erforderlich) aktiviert ist. Ohne aktives IPv4 Forwarding (Routing) auf dem Server wird es generell nichts, das sollte dir klar sein. 2te wichtige Voraussetzung ist das du, sofern du mit einer Firewall wie iptables auf dem Server arbeitest diese VPN Pakete dort passieren lässt. Beides Punkte die oben schon richtig genannt wurden !
Ist das alles sichergestellt kommt die Server VPN Konfig.

Deine Server Konfig sollte zumindestens für die Site-to-Site Kopplung mit dem Bintec so oder so ähnlich aussehen:

conn bintec
keyexchange=ikev2
authby=secret
ike=aes256-sha1-modp1024 (Alternativ besser: ike=aes256-sha256-modp2048)
esp=aes256-sha1-modp1024 (Alternativ besser: ike=aes256-sha256-modp2048)
type=tunnel
auto=add
left=5.9.X.Y
leftsubnet=10.1.1.0/24
right=<wan_ip_bintec>
rightsubnet=10.1.2.0/24

Leider hast du es ja bis jetzt noch nicht geschafft einmal deine /etc/ipsec.conf hier zu posten die für eine zielführende Hilfe der Community hier essentiell wichtig ist.

Wichtig ist den Bintec Tunnel erstmal mit ipsec restart und dann manuell mit ipsec up bintec zu starten um die Status bzw. Log Messages zu sehen.
All das fehlt bis dato von dir. Ebenso das Bintec Log, was ein Troubleshootung ungleich schwerer macht.
Der Bintec sollte dann für die Phase 2 als remotes Netz: 10.1.1.0/24 und als lokales Netz: 10.1.2.0/24 eingetragen haben. Auch hier wären die Bintec P2 Screenshots hilfreich. (Die obigen geben fälschlicherweise noch ein 192.168.1.0er Netz an was mit deiner o.a. Skizze kollidiert !)

Wenn alle Stricke reissen setzt du halt eine VM auf mit einer pfSense Firewall drauf die zw. externer 5.9.x.y IP und dem internen 10.1.1.0er Netz liegt. Die Firewall realisiert dann das Client Dialin mit L2TP und den IPKEv2 IPsec VPN Tunnel zum Bintec.

version 2.0

config setup
  virtual-private=%v4:10.1.1.0/24,%v4:10.1.2.0/24
  uniqueids=no

conn shared
  left=%defaultroute
  leftid=5.9.x.x
  right=%any
  encapsulation=yes
  authby=secret
  pfs=no
  rekey=no
  keyingtries=5
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  ikev2=never
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1,aes256-sha2;modp1024,aes128-sha1;modp1024
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes256-sha2_512,aes128-sha2,aes256-sha2
  ikelifetime=24h
  salifetime=24h
  sha2-truncbug=no

conn l2tp-psk
  auto=add
  leftprotoport=17/1701
  rightprotoport=17/%any
  type=transport
  also=shared

conn xauth-psk
  auto=add
  leftsubnet=0.0.0.0/0
  rightaddresspool=10.1.2.201-10.1.2.250
  modecfgdns="8.8.8.8 8.8.4.4"  
  leftxauthserver=yes
  rightxauthclient=yes
  leftmodecfgserver=yes
  rightmodecfgclient=yes
  modecfgpull=yes
  cisco-unity=yes
  also=shared

include /etc/ipsec.d/*.conf

Meine ipsec.conf

conn ikev2-cp
  left=%defaultroute
  leftcert=5.9.x.x
  leftsendcert=always
  leftsubnet=0.0.0.0/0
  leftrsasigkey=%cert
  right=%any
  rightid=%fromcert
  rightaddresspool=10.1.2.201-10.1.2.250
  rightca=%same
  rightrsasigkey=%cert
  narrowing=yes
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  auto=add
  ikev2=insist
  rekey=no
  pfs=no
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
  ikelifetime=24h
  salifetime=24h
  encapsulation=yes
  leftid=5.9.x.x
  modecfgdns="8.8.8.8 8.8.4.4"  
  mobike=yes

Meine ikev2.conf

[global]                                                               
port = 1701                                                   

[lns default]                                                  
ip range = 10.1.1.201-10.1.1.250       
local ip = 10.1.1.2                           
length bit = yes                                               
require chap = yes                                     
refuse pap = yes                                           
pppoptfile = /etc/ppp/options.xl2tpd   

Meine xl2tp.conf

# Modified by hwdsl2 VPN script
# Generated by iptables-save v1.8.7 on Sun Sep  5 19:51:21 2021
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p udp -m udp --dport 1701 -m policy --dir in --pol none -j DROP
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m multiport --dports 500,4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -m policy --dir in --pol ipsec -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -j DROP
-A FORWARD -m conntrack --ctstate INVALID -j ACCEPT
-A FORWARD -i enp8s0 -o ppp+ -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp+ -o enp8s0 -j ACCEPT
-A FORWARD -i ppp+ -o ppp+ -j ACCEPT
-A FORWARD -d 10.1.1.0/24 -i enp8s0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.1.1.0/24 -o enp8s0 -j ACCEPT
-A FORWARD -s 10.1.1.0/24 -o ppp+ -j ACCEPT
-A FORWARD -j DROP
COMMIT
# Completed on Sun Sep  5 19:51:21 2021
# Generated by iptables-save v1.8.7 on Sun Sep  5 19:51:21 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.1.1.0/24 -o enp8s0 -j MASQUERADE
-A POSTROUTING -s 10.1.2.0/24 -o enp8s0 -m policy --dir out --pol none -j MASQUERADE
COMMIT
# Completed on Sun Sep  5 19:51:21 2021

Meine iptables.rules

kernel.msgmnb = 65536
kernel.msgmax = 65536

net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.enp8s0.send_redirects = 0
net.ipv4.conf.enp8s0.rp_filter = 0
net.ipv4.conf.virbr0.proxy_arp=1

net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912

Meine sysctl.conf

Ich habe Anpassungen versucht jedoch habe ich immer wieder das gleiche Problem.

Mit der IPSec / IKEv2 Verbindung will ich ein Site-to-Site mit dem Bintec Elmeg Router

Mit der XL2TP Config will ich mit den Windows Clients zugreifen.

Als Output in IPSec bekomme ich folgendes:

000 Total IPsec connections: loaded 4, active 1
000
000 State Information: DDoS cookies not required, Accepting new IKE connections
000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)
000 IPsec SAs: total(1), authenticated(1), anonymous(0)
000
000 #1: "ikev2-cp"[1] 79.140.x.x:52028 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in 63030s; newest ISAKMP; idle; 
000 #2: "ikev2-cp"[1] 79.140.x.x:52028 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); EXPIRE in 63030s; newest IPSEC; eroute owner; isakmp#1; idle; 
000 #2: "ikev2-cp"[1] 79.140.x.x esp.da4bb7c8@79.140.x.x esp.28abfb3e@5.9.x.x tun.0@79.140.x.x tun.0@5.9.x.x Traffic: ESPin=0B ESPout=0B ESPmax=0B 
000
000 Bare Shunt list:
000

Mit der IPSec / IKEv2 Verbindung will ich ein Site-to-Site mit dem Bintec Elmeg Router

Gehe doch dann erstmal immer strategisch vor !
Realisiere erstmal den Site-to-Site Tunnel das der stabil rennt, erst dann machst du dich ans Dialin. NICHT alles auf einmal !
Deine tauscend Conn sind verwirrend. Niemand weiss doch jetzt WELCHE du aktuell verwendest mit dem Bintec ?!

Sieht so aus als ob du die "conn ikev2-cp" dann verwendest. Nungut... Da ist viel überflüssiger Unsinn drin den du entweder mal auskommentieren solltest oder löschen solltest. Z.B. DNS Server auf Google DNS Dienste zu legen ist ein Unding. Das machen heutzutage nichtmal mehr Dumkies weil Google davon Profile erstellt und weltweit mit 3ten vermarktet. Datenschutz sieht anders aus. Sowas sollte also raus und noch einiges mehr. In der Regel reichen 6 oder 7 Zeilen.
Also mal verschlanken mit den Defaults arbeiten.
conn ikev2-cp
keyexchange=ikev2
left=5.9.x.x
leftcert=5.9.x.x
leftsendcert=always
leftsubnet=10.1.1.0/24
leftrsasigkey=%cert
right=any%
rightid=%fromcert
rightsubnet=10.1.2.0/24
rightca=%same
rightrsasigkey=%cert
auto=add
ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2

Das sollte reichen.
Der Bintec arbeitet doch auch mit Preshared Keys oder nutzt du dort auch Zertifikate wie auf der Server Seite ? Das ist wichtig zu klären, denn es geht nur entweder oder !
Hat der Bintec eine dynamisce WAN IP ??
Hilfreich wäre dann mal ein ipsec restart und dann der Output von ipsec up ikev2-cp und dann ein ip xfrm state list

Ich sitze auch nur an der site to site Verbindung. Ich habe hier alles reingeschrieben was ich so gemacht habe.

Ich habe das leftsubnet auch mit 10.1.1.0/ probiert ohne Erfolg.

Diese Konfiguration mit den DNS Einträgen habe ich über den Autoscript installieren lassen.

ipsec status zeigt ja eine gute Verbindung. Auf dem bintec Router ist auch eine statische IP Verbindung.

Tunnel ist aufgebaut nur kein Zugriff auf dem Subnet.

Kann jemand ein Fehler in den IPTables feststellen oder wo anders?

Zitat von @bintes:

Kann jemand ein Fehler in den IPTables feststellen oder wo anders?

Jepp, du lässt ja gar keinen Traffic zwischen den beiden Subnetzen in der Forwarding Chain des Servers zu, kann also niemals klappen.

iptables -I FORWARD -s 10.1.2.0/24 -d 10.1.1.0/24 -j ACCEPT

Ein Blick ins Firewall Log hätte man eigentlich erwarten können.

Diese Konfiguration mit den DNS Einträgen habe ich über den Autoscript installieren lassen.

Gutes Beispiel wenn man sich auf den Unsinn anderer verlässt und das nicht selber macht bzw. hinterfragt und selber anpasst.
Wie gesagt: In der Regel reichen in der Connection Definition 5-6 Zeilen weil StrongSwan alles schon im Default richtig macht.
Zur Firewall steht oben ja schon alles. Testweise kannst du die iptables Firewall ja auch mal kurz deaktivieren. In CentOS geht das mit:

# /etc/init.d/iptables save
# /etc/init.d/iptables stop 

Dann sollte pingtechnisch testweise alles ereichbar sein. Mit

# /etc/init.d/iptables start

schaltest du die Firewall wieder scharf.
Ist auch ein Test um ggf. Firewall Regelfehler wie dem obigen auf die Spur zu kommen.

Fehler scheint was ganz anderes zu sein.
Fehler kommt vom libvirt.

German solved Question LAN, WAN, Wireless Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment