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):
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:
/etc/sysctl.d/10-ipsec.conf:
/etc/network/interfaces (Auszug):
Danke schonmal!
Viele Grüße
Ketanest
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
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/contentid/52281016849
Ausgedruckt am: 01.11.2024 um 04:11 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
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
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
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.
Mit Quagga, FRR oder BIRD ist das ja auch unter Linux im Handumdrehen installiert. Siehe dazu auch hier.
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.
Best Practise ist das Sites mit dyn. IPs aber immer die Initiators sind.
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.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 ...