ketanest112
Goto Top

Route-based IPSec with multiple initators on same ID

Hallöchen zusammen,

da es nicht wirklich zu meinem vorherigen Beitrag passt hoffe ich, es ist kein Problem, wenn ich hierfür einen neuen aufmache.
Folgendes Szenario würde ich gerne bauen (Hub and Spoke):
Initiator 1 (Fortigate) 10.94.255.2/24
Initiator 2 (Fortigate) 10.94.255.3/24     ===== WAN =====     10.94.255.1/24   Responder (Strongswan)
Initiator 3 (Fortigate) 10.94.255.4/24
Die Initiatoren sollen alle über das selbe Interface mit dem Responder kommunizieren können, sprich alle können die 10.94.255.1 ansprechen und erhalten auch eine Antwort. Untereinander müssen sie nicht zwingend miteinander kommunizieren. Da mit der Zeit weitere Fortis dazukommen werden und ich ungern auf dem Responder für jede einen neuen Tunnel inkl. Interface und Transfernetz bauen will wäre es schön, wenn man das so hinbekommen könnte. Wenn man es ausschließlich mit Fortis baut funktioniert das super (Responder hat nur ein Interface mit einer /24er Route). Da ich durch die Tunnel BGP-Routen austauschen will und sich die Netze auch mal ändern können hab ich das mit 0.0.0.0/0 local_ts und remote_ts gebaut und damit ein Route-Based VPN gebaut. Zwischen zwei einzelnen Endpunkten geht es auch schon, wenn ich einen zusätzlichen Endpunkt (Forti) dazunehmen wird auch eine zusätzliche SA aufgebaut, jedoch landet sämtlicher Traffic dann auf dem Tunnel der ersten SA. Ist jetzt die Frage, ob das mit Strongswan so überhaupt möglich ist?
Meine aktuelle Strongswan-Config sieht folgendermaßen aus:
connections {
        tfd-fw02 {
                version = 2
                local_addrs = x.x.x.x (Public WAN IP)
                remote_addrs = %any
                proposals = aes256-sha512-x25519
                unique = never
                keyingtries = 0
                rekey_time = 14400
                local {
                        auth = psk
                        id = this
                }
                remote {
                        auth = psk
                        id = spoke
                }
                children {
                        tfd-fw02 {
                                local_ts = 0.0.0.0/0,::/0
                                remote_ts = 0.0.0.0/0,::/0
                                esp_proposals = aes256-sha512-x25519
                                rekey_time = 7200
                                reqid = 42
                                mark_in = 42
                                mark_out = 42
                                start_action = start
                        }
                }
        }
}
secrets {
        ike-tfd-fw02 {
                id = spoke
                secret = "GEHEIM"  
        }
}

/etc/sysctl.d/10-ipsec.conf:
net.ipv4.conf.vt42.disable_policy=1
net.ipv4.conf.eth0.disable_policy=1
net.ipv6.conf.vt42.disable_policy=1
net.ipv6.conf.eth0.disable_policy=1

/etc/network/interfaces (Auszug):
auto vt42
iface vt42 inet static
    pre-up ip tunnel add vt42 local x.x.x.x remote any mode vti key 42
    post-down ip tunnel del vt42
    address 10.94.255.1/24

Danke schonmal!
Viele Grüße
Ketanest

Content-ID: 52281016849

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

Ausgedruckt am: 21.11.2024 um 11:11 Uhr

Spirit-of-Eli
Lösung Spirit-of-Eli 29.07.2024 um 09:00:25 Uhr
Goto Top
Moin,

entweder können alle mit allen oder IPsec ist für dich das falsche Protokoll.

Dein Vorhaben geht so mit IPsec nicht. Du musst jedem Teilnehmer jeden bekannt machen und Routen erstellen lassen.

Mein Tipp wäre für jede Box einen eigenen Tunnel zur Haupt FW auf zu bauen und das Routing einfach per OSPF fliegen zu lassen.
Dann kannst du das Setup weiter scalieren ohne jede Box ändern zu müssen.

Gruß
Spirit
13910172396
13910172396 29.07.2024 aktualisiert um 09:03:59 Uhr
Goto Top
Steht hier Punkt "Sharing VTI Devices" ..
VirtualIPs an die Teilnehmer vergeben, VTI Remote Endpoint auf 0.0.0.0 setzen und Route für das virtuelle Subnetz auf das VTI setzen.
https://docs.strongswan.org/docs/5.9/features/routeBasedVpn.html#_sharin ...

Gruß Strods
Spirit-of-Eli
Spirit-of-Eli 29.07.2024 um 09:31:41 Uhr
Goto Top
Zitat von @13910172396:

Steht hier Punkt "Sharing VTI Devices" ..
VirtualIPs an die Teilnehmer vergeben, VTI Remote Endpoint auf 0.0.0.0 setzen und Route für das virtuelle Subnetz auf das VTI setzen.
https://docs.strongswan.org/docs/5.9/features/routeBasedVpn.html#_sharin ...

Gruß Strods

Wäre mir neu, dass es mit einer Forti geht.
Aber ich lass mich gerne eines besseren belehren.
ketanest112
ketanest112 29.07.2024 um 09:35:56 Uhr
Goto Top
Zitat von @Spirit-of-Eli:

Moin,

entweder können alle mit allen oder IPsec ist für dich das falsche Protokoll.

Dein Vorhaben geht so mit IPsec nicht. Du musst jedem Teilnehmer jeden bekannt machen und Routen erstellen lassen.

Mein Tipp wäre für jede Box einen eigenen Tunnel zur Haupt FW auf zu bauen und das Routing einfach per OSPF fliegen zu lassen.
Dann kannst du das Setup weiter scalieren ohne jede Box ändern zu müssen.

Gruß
Spirit

Hab ich mir fast gedacht. Danke trotzdem! Dann wirds wohl ein Tunnel pro Remote-Site.

Zitat von @Spirit-of-Eli:

Zitat von @13910172396:

Steht hier Punkt "Sharing VTI Devices" ..
VirtualIPs an die Teilnehmer vergeben, VTI Remote Endpoint auf 0.0.0.0 setzen und Route für das virtuelle Subnetz auf das VTI setzen.
https://docs.strongswan.org/docs/5.9/features/routeBasedVpn.html#_sharin ...

Gruß Strods

Wäre mir neu, dass es mit einer Forti geht.
Aber ich lass mich gerne eines besseren belehren.

Jap, das funktioniert so mit der Forti tatsächlich nicht, die lässt sich keine VIPs geben, das VPN-Interface kannst du nur manuell konfigurieren. Dann scheint Forti zu Forti wohl proprietär irgendetwas anders zu machen, wodurch das dann geht.
Spirit-of-Eli
Spirit-of-Eli 29.07.2024 um 09:39:03 Uhr
Goto Top
Wenn du das Routing per OSPF laufen lässt, sind das ja auch nur drei Klicks mehr. Also eigentlich ganz entspannt und wenn du es dann doch möchtest sogar vermascht möglich.
aqui
aqui 29.07.2024 aktualisiert um 10:07:42 Uhr
Goto Top
Mit Quagga, FRR oder BIRD ist das ja auch unter Linux im Handumdrehen installiert. Siehe dazu auch hier.
ketanest112
ketanest112 29.07.2024 um 10:15:57 Uhr
Goto Top
Yep, FRR läuft eh schon für die ganzen wireguard Tunnel (das kann Forti ja leider nicht). Ab dem zweiten Tunnel hab ich dann nur das problem, dass der
ip tunnel add NAME local x.x.x.x remote 0.0.0.0 mode vti key yy
dann nicht mehr funktioniert weil es ja einen entsprechenden Tunnel schon gibt. Die Remote-IP kann ich jedoch nicht konfigurieren, die Initiatoren haben leider dynamische IPs. Ich vermute, das geht so dann auch nicht oder? Weil nen FQDN kann ich ja nur im Strongswan konfigurieren oder? Würde höchstens noch gehen, dass ich ein Updown-Script beim Verbindungsaufbau laufen lasse, das mir dann den entsprechenden Tunnel anlegt, oder?
aqui
aqui 29.07.2024 aktualisiert um 10:21:02 Uhr
Goto Top
Nein bei dyn. IPs bei den Initiators müssen logischerweise ja immer diese den Tunnel von ihrer Seite "initiieren". Wie sollte das auch andersrum gehen?! Dyn. IPs kannst du ja nicht aktiv connecten oder wenn, dann immer nur zeitlimitiert. Ausnahme du verwendest DDNS Hostnamen, dann würde es wieder klappen.
Best Practise ist das Sites mit dyn. IPs aber immer die Initiators sind.
ketanest112
ketanest112 29.07.2024 aktualisiert um 10:28:24 Uhr
Goto Top
Ok dann gabs da wohl n Missverständnis. Der Strongswan ist der Responder, die Fortis mit dyn. IPs sind die Initiatoren. Sobald die Verbindung aufgebaut wird kenne ich ja die Peer-IP und kann diese mit $PLUTO_PEER in ein
ip tunnel add $PLUTO_PPER_ID local x.x.x.x remote $PLUTO_PEER mode vti key $PLUTO_REQID
verwurschteln oder steh ich da jetzt völlig aufm Schlauch?

EDIT: Wie ich schon gesagt habe, ein zweites Mal lässt sich
ip tunnel add NAME local x.x.x.x remote 0.0.0.0 mode vti key yy
nicht ausführen, auch nicht mit einem anderen key.
aqui
aqui 29.07.2024 um 10:44:03 Uhr
Goto Top
Ok dann gabs da wohl n Missverständnis.
Ja, leider weil du es falsch hast gedrückt aus! face-sad
Standardmäßig ist ja immer die Site mit der festen IP der VPN Responder.
Sobald die Verbindung aufgebaut wird kenne ich ja die Peer-IP
Richtig, aber ja immer nur temporär für die Gültigkeit der dyn. WAN IP. Wenn der Provider auf der dyn. IP Seite eine neue IP zuweist bricht die Tunnelverbindung ab (auch allein schon durch die Zwangstrennung) und wird eben von der dyn. Seite neu initiiert. Wenn du auf so einem Tunnel mit OSPF arbeitest macht das schon der OSPF Prozess selber und seine OSPF Keepalives.
ketanest112
ketanest112 29.07.2024 um 10:59:51 Uhr
Goto Top
Ja, leider weil du es falsch hast gedrückt aus! face-sad

Sorry, dachte das wurde klar.

Richtig, aber ja immer nur temporär für die Gültigkeit der dyn. WAN IP. Wenn der Provider auf der dyn. IP Seite eine neue IP zuweist bricht die Tunnelverbindung ab (auch allein schon durch die Zwangstrennung) und wird eben von der dyn. Seite neu initiiert. Wenn du auf so einem Tunnel mit OSPF arbeitest macht das schon der OSPF Prozess selber und seine OSPF Keepalives.

Dann versteh ichs noch nicht so ganz was du genau meinst. Genau diese IP-Änderung muss ich auf dem Tunnel Interface von der Linux-Kiste ja umsetzen. Der IPSec-Daemon kriegt die Änderung ja über den Neuaufbau der Verbindung mit.

Um über den Tunnel zu routen (egal ob jetzt mit BGP oder OSPF) muss ich ihn ja mit local_ts und remote_ts 0.0.0.0/0 konfigurieren, damit auch wirklich alle Pakete da drin landen. Und um routen zu können brauch ich ja zusätzlich zum IPSec-Tunnel n verknüpftes Interface auf dem Server (ip tunnel add ...) was ich ja mit dem "key" in der Interface config und dem "reqid, mark_in und mark_out" in der strongswan config erreiche. Da aber auf dem Strongswan Server (Linux-Kiste, feste IP, Responder) mehrere IPSec-Tunnel terminieren werden funktioniert es ja mit einer statischen config in der /etc/network/interfaces nicht, weil das Anlegen des zweiten Tunnel Interfaces ja daran scheitert, dass die Tunnel nicht mehr eindeutig wären (local x.x.x.x remote 0.0.0.0, weil ich die Remote-IP nicht kenne). Und das kann ich dann, wenn ich richtig liege, nur über ein updown-Script beim Verbindungsaufbau realisieren, weil nur dann kann ich mehrere Tunnel Interfaces für die verschiedenen Tunnel anlegen, weil ich zu dem Zeitpunkt (bzw. der IPSec Daemon) die Remote IP kenne.
ketanest112
Lösung ketanest112 29.07.2024 aktualisiert um 12:17:08 Uhr
Goto Top
Also zur Auflösung: Mit folgendem script funktioniert es jetzt:

#!/bin/bash

case "$PLUTO_VERB" in  
        up-client)
                ip tunnel add "$PLUTO_PEER_ID" local x.x.x.x (WAN IP) remote "$PLUTO_PEER" mode vti key "$PLUTO_REQID"  
                ip addr add "$1" dev "$PLUTO_PEER_ID"  
                ip link set dev "$PLUTO_PEER_ID" up  
                sysctl net.ipv4.conf."$PLUTO_PEER_ID".disable_policy=1  
                sysctl net.ipv6.conf."$PLUTO_PEER_ID".disable_policy=1  
                ;;
        down-client)
                ip tunnel del "$PLUTO_PEER_ID"  
                ;;
esac

In der swanctl ist für jeden Tunnel eine connection konfiguriert, die children sind mit
updown = /usr/local/bin/ipsec-updown-custom.sh "x.x.x.x/30"  
konfiguriert, Transfernetz muss man sich halt dann aussuchen.

reqid, mark_in und mark_out muss man halt entsprechend anpassen bei den children, die müssen eindeutig sein, ich hab einfach bei 42 angefangen und hochgezählt.

Grüße
Ketanest
aqui
aqui 29.07.2024 aktualisiert um 14:38:14 Uhr
Goto Top
Transfernetz muss man sich halt dann aussuchen.
...und müsste auch keine /30er Prefixes verbraten wenn es /31 auch addressschonender tun sofern du diese IP Netze als Point to Point Netze konfigurierst?! 😉
https://packetlife.net/blog/2008/jun/18/using-31-bit-subnets-on-point-po ...