29.07.2024, aktualisiert um 08:42:40 Uhr

1062

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

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

Content-ID: 52281016849

Url: https://administrator.de/forum/route-based-ipsec-with-multiple-initators-on-same-id-52281016849.html

Ausgedruckt am: 30.12.2024 um 17:12 Uhr

13 Kommentare

Neuester Kommentar

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

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

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.

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:

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.

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.

Mit Quagga, FRR oder BIRD ist das ja auch unter Linux im Handumdrehen installiert. Siehe dazu auch hier.

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?

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.

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.

Ok dann gabs da wohl n Missverständnis.

Ja, leider weil du es falsch hast gedrückt aus!

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.

Ja, leider weil du es falsch hast gedrückt aus! face-sad

Sorry, dachte das wurde klar.

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.

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

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

gelöst Frage VPN

Mehr von ketanest112

Zertifikatsvorlagen teilweise nicht sichtbarketanest112 - 20 Kommentare

Pakete gehen beim Routing von IPSec nach Wireguard verloren (Route-Based-VPNs)ketanest112 - 27 Kommentare

Route-based Strongswan IPSec zu Fortigate: Antwort kommt nicht anketanest112 - 22 Kommentare

Fehlender Internetverbindung verlangsamt UACketanest112 - 6 Kommentare

Heiß diskutiert