25.07.2024, aktualisiert um 17:39:37 Uhr

1571

Route-based Strongswan IPSec zu Fortigate: Antwort kommt nicht an

Hallöchen zusammen,

ich mal wieder. Folgendes Thema: Ich möchte Route-based IPSec einsetzen, wie wir es auch bei uns in der Arbeit machen, nur dass wir dort ausschließlich Fortigates haben. Ich möchte einen Tunnel zwischen einer Forti und einem Debian Server mit Strongswan bauen. Ich habe mir auch die entsprechenden Anleitungen schon reingezogen, komme aber irgendwie nicht weiter. Der Tunnel steht inzwischen, Routen auch. Wenn ich allerdings vom Debian-Server aus versuche, die Forti zu pingen, bekomme ich keine Antwort. Ein diag sniffer auf der Forti zeigt aber, dass die ICMP-Pakete ankommen und auch beantwortet werden. Nur kommen sie nicht wieder auf dem Debian Server an. Auch ein tcpdump aufm Debian Server zeigt, dass der Ping rausgeht aber nicht wieder zurückkommt. Ping von der Forti Richtung Debian geht auch nicht.

Config Strongswan:

conn abc
        leftsubnet=0.0.0.0/0
        left=(public IP Server)
        right=%defaultroute
        rightsubnet=0.0.0.0/0
        rightid=spoke
        ike=aes256-sha512-curve25519
        ikelifetime=7200s
        esp=aes256-sha512-curve25519
        keylife=3600s
        type=tunnel
        authby=secret
        mark=42
        auto=tunnel
        keyingtries=%forever
        keyexchange=ikev2

install_routes = no

in der /etc/strongswan.d/charon.conf ist auch schon gesetzt.

Des weitere folgende Befehle (Debian-Server):

ip tunnel add ipsec0 local x.x.x.x mode vti key 42
ip link set ipsec0 up
ip route add 10.58.0.0/24 dev ipsec0
ip address add 10.58.0.1/24 dev ipsec0

Ich hab auch schon die MTU von der ipsec interfaces mal runtergestellt (auf 1300) aber das brachte auch keine Abhilfe. Firewalls sind auf beiden seiten offen (zum testen erstmal nur).

Vielleicht habt ihr ja einen grandiosen Einfall.

Danke schonmal!
Ketanest

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

Content-ID: 6539458566

Url: https://administrator.de/forum/route-based-strongswan-ipsec-zu-fortigate-antwort-kommt-nicht-an-6539458566.html

Ausgedruckt am: 21.12.2024 um 15:12 Uhr

22 Kommentare

Neuester Kommentar

vom Debian-Server aus versuche, die Forti zu pingen, bekomme ich keine Antwort

Mit welcher Source IP pingst du denn?? Bedenke das in den IPsec Tunnel nur das geforwardet wird was in den Phase 2 SAs definiert wurde.
Realisierst du einen IKEv1 oder einen IKEv2 Tunnel mit der Fortigate?
Ist ggf. am Strongswan noch eine iptables oder nftables Firewall aktiv?

Generell:
Du solltest nicht mehr die uralte Konfig Syntax nutzen bei Strongswan sondern nur noch das neue und zielführende vici Interface mit entsprechender Syntax. Die alte Synax wird nicht mehr gepflegt und ist depricated.
Mit swanctl -T hast du z.B. deutlich bessere Debug Möglichkeiten.

Wie sowas in einer funktionalen vici Konfig aussieht kannst du an diversen Threads oder Tutorials hier im Forum nachvollziehen.
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
DynDNS mit DS-Lite für L2tp mit MikroTik
Usw...

Mit welcher Source IP pingst du denn??

Mit der 10.58.0.1 (die die auch aufm Interface konfiguriert ist) auf die 10.58.0.2 (die die auf der Forti konfiguriert ist). Die Pakete sieht man auch im Capture der Forti mit genau diesen Adressen.

Bedenke das in den IPsec Tunnel nur das geforwardet wird was in den Phase 2 SAs definiert wurde.

Jop, deswegen ja 0.0.0.0/0 auf beiden Seiten (Route-Based IPSec).

Realisierst du einen IKEv1 oder einen IKEv2 Tunnel mit der Fortigate?

IKEv2

Ist ggf. am Strongswan noch eine iptables oder nftables Firewall aktiv?

Ja, nftables. Hab das ipsec0 interface aber sowohl in der INPUT als auch in der FORWARD chain mit

iifname {"andere-interfaces","ipsec0"} accept

drin.
Auf dem WAN interface vom Server ist unter anderem udp port 500 und 4500 accepted sowie ip protocol esp.

Generell:
Du solltest nicht mehr die uralte Konfig Syntax nutzen bei Strongswan sondern nur noch das neue und zielführende vici Interface mit entsprechender Syntax. Die alte Synax wird nicht mehr gepflegt und ist depricated.
Mit swanctl -T hast du z.B. deutlich bessere Debug Möglichkeiten.

Ah, das wusste ich gar nicht, danke! swanctl kann ich nicht ausführen, gibt es dazu noch irgendwelche zusätzlichen Pakete, die ich installieren muss? Vermutlich dieses charon-systemd auf der einen Anleitung oder?

Hab das ipsec0 interface aber sowohl in der INPUT als auch in der FORWARD chain mit

Hier sieht es etwas anders aus:

# Interface name
define pub_iface = "eth0"  

        table inet filter {
        chain input {
                # accepted UDP ports on public interface 
                iif $pub_iface udp dport { isakmp, ipsec-nat-t } accept 
                iif $pub_iface ip protocol esp accept 

                # allow IPsec VPN networks
                meta ipsec exists accept
                } 

Zumindestens damit rennen alle v2 Tunnel zu Cisco, Sophos, Mikrotik usw.

gibt es dazu noch irgendwelche zusätzlichen Pakete, die ich installieren muss?

apt install strongswan libstrongswan-extra-plugins charon-systemd libcharon-extra-plugins

Siehe o.a. Tutorial im Kapitel "VPN Server Konfiguration"! 😉

Moin.

Forti IPSec Tunnel wie gehabt, der läuft ja bei dir schon, dann das VTI IF auf der Fortigate setzen wie hier beschrieben
https://weberblog.net/route-based-vpn-tunnel-fortigate-cisco-asa/

config system interface
    edit "asa"  
        set vdom "root"  
        set ip 10.8.8.1 255.255.255.255
        set allowaccess ping
        set type tunnel
        set remote-ip 10.8.8.2 255.255.255.252
        set interface "wan1"  
    next
end

Auf Linux Seite:

Simple Beispiel basic VICI IPSec IKEv2 Config (PSK)

connections {
	fortigate {
		local_addrs = 3.3.3.3
		remote_addrs = 4.4.4.4

		local {
			id = 3.3.3.3
			auth = psk
		}
		remote {
			id = 4.4.4.4
			auth = psk
		}
		children {		
			net {
				local_ts = 0.0.0.0/0
				remote_ts = 0.0.0.0/0
				reqid = 42
				mark_in = 42
				mark_out = 42
				start_action = start
			}
		}
		version = 2
	}
}

secrets {
	ike-fortigate {
		id = 4.4.4.4
		secret = "Passw0rd"  
	}
}

Dann in der charon.conf folgende Dinge setzen

install_routes = no
install_virtual_ip = no

Dann noch das connmark Plugin deaktivieren (connmark.conf)

connmark {
    load = no
}

Strongswan neu laden

systemctl restart strongswan

Dann VTI Interface erstellen

ip tunnel add vt0 local 3.3.3.3 remote 4.4.4.4 type vti key 42
ip link set vt0 up
ip address add dev vt0 10.8.8.2/30

Routen für Remote-Netze über das VTI setzen

ip route add 192.168.50.0/24 dev vt0

Per sysctl policies für das VTI-IF und die WAN-NIC deaktivieren

sysctl -w net.ipv4.conf.vt0.disable_policy=1
sysctl -w net.ipv4.conf.eth0.disable_policy=1

Firewalls alle entsprechend dem gewünschten Traffic freigeben.

Fertig.

IPSEC SA

fortigate: #2, ESTABLISHED, IKEv2, 4cfe46302456aa16_i* ce6a2bfec173c32d_r
  local  '3.3.3.3' @ 3.3.3.3[4500]  
  remote '4.4.4.4' @ 4.4.4.4[4500]  
  AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  established 2359s ago, rekeying in 1016s
  net: #2, reqid 42, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA2_256_128
    installed 2359s ago, rekeying in 929s, expires in 1601s
    in  c9a6efce (0x0000002a),    504 bytes,     6 packets,   168s ago
    out c07c11b9 (0x0000002a),    756 bytes,     9 packets,   168s ago
    local  0.0.0.0/0
    remote 0.0.0.0/0

VTI Stats

10: vt0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ipip 3.3.3.3 peer 4.4.4.4
    RX:  bytes packets errors dropped  missed   mcast           
          3336      40      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
          4200      50     0       0      0       0 

Ping zur Forti selbst und in das Remote-Subnetz:

ping 10.8.8.1
PING 10.8.8.1 (10.8.8.1) 56(84) Bytes an Daten.
64 Bytes von 10.8.8.1: icmp_seq=1 ttl=64 Zeit=1.20 ms
64 Bytes von 10.8.8.1: icmp_seq=2 ttl=64 Zeit=0.837 ms
64 Bytes von 10.8.8.1: icmp_seq=3 ttl=64 Zeit=0.904 ms

ping 192.168.50.1 -I 192.168.40.1
PING 192.168.50.1 (192.168.50.1) von 192.168.40.1 : 56(84) Bytes an Daten.
64 Bytes von 192.168.50.1: icmp_seq=1 ttl=64 Zeit=0.799 ms
64 Bytes von 192.168.50.1: icmp_seq=2 ttl=64 Zeit=0.888 ms
64 Bytes von 192.168.50.1: icmp_seq=3 ttl=64 Zeit=0.886 ms

So läuft das hier auch testweise mit einer OPNSense als Gegenstelle wie Schmitz' Katz.

Mehr Details
https://docs.strongswan.org/docs/5.9/features/routeBasedVpn.html

Gruß Strods

So läuft das hier auch testweise mit einer OPNSense als Gegenstelle wie Schmitz' Katz.

Ja so läuft das jetzt auch bei mir. Ich hab keine Ahnung woran es genau lag. Entweder an reqid oder an den sysctl Dingern. Jetzt muss ich das ganze nur noch so gescripted kriegen, dass es automatisch bei jedem Neustart läuft.

Zitat von @ketanest112:
Jetzt muss ich das ganze nur noch so gescripted kriegen, dass es automatisch bei jedem Neustart läuft.

Wieso skripten? Der IPSEC Tunnel startet ja automatisch oder wenn gewünscht auch auf Anforderung. Das VTI Interface kannst du mit deinem Network-Manager oder systemd-networkd oder deinem genutzten Network-Manager anlegen lassen genauso wie die Routen und die Sysctl Optionen kannst du unter /etc/sysct.d/ in einer config ablegen. Skripten überflüssig

Wieso skripten? Der IPSEC Tunnel startet ja automatisch oder wenn gewünscht auch auf Anforderung. Das VTI Interface kannst du mit deinem Network-Manager oder systemd-networkd oder deinem genutzten Network-Manager anlegen lassen genauso wie die Routen und die Sysctl Optionen kannst du unter /etc/sysct.d/ in einer config ablegen. Skripten überflüssig face-smile

Danke, stimmt! Ich korrigiere: automatisieren

Läuft derzeit auf ner Debian-Kiste, /etc/network/interfaces und so xD

Ah und noch ne frage: Wie würde das Ganze für IPv6 aussehen? Hab das mal exakt mit der gleichen Config nachgestellt, Tunnel steht auch hier aber Ping zb geht nicht durch.

Zitat von @ketanest112:

Ah und noch ne frage: Wie würde das Ganze für IPv6 aussehen? Hab das mal exakt mit der gleichen Config nachgestellt, Tunnel steht auch hier aber Ping zb geht nicht durch.

VTI6 statt VTI nehmen, In der IPSec Config zusätzlich ::/0 in den phase2 SAs setzen und die sysctl Befehle auf die IPv6 äquivalente setzen net.ipv6. ......

Zitat von @13910172396:

Zitat von @ketanest112:

Ah und noch ne frage: Wie würde das Ganze für IPv6 aussehen? Hab das mal exakt mit der gleichen Config nachgestellt, Tunnel steht auch hier aber Ping zb geht nicht durch.

VTI6 statt VTI nehmen, In der IPSec Config zusätzlich ::/0 in den phase2 SAs setzen und die sysctl Befehle auf die IPv6 äquivalente setzen net.ipv6. ......

Jupp das meinte ich mit der gleichen Config, hab local_addrs auf die v6 Adresse angepasst sowie in Phase 2 local_ts und remote_ts.
Ich krieg jetzt nur komischerweise immer nen "no IKE config found for" Fehler im Log. IPv6-Adresse des Servers steht aber bei local_addrs drin und stimmt definitiv.

https://docs.strongswan.org/docs/5.9/config/IPv6.html

Hier eine durchgehende IPv6 Config.

VICI Config

connections {
    fortigate {
		local_addrs = 2a00:X:X:X::1
		remote_addrs = 2a00:X:X:X::2

		local {
			id = 2a00:X:X:X::1
			auth = psk
		}
		remote {
			id = 2a00:X:X:X::2
			auth = psk
		}
		children {		
			net {
				local_ts = 0.0.0.0/0,::/0
				remote_ts = 0.0.0.0/0,::/0
				reqid = 42
				mark_in = 42
				mark_out = 42
				start_action = start
			}
		}
		version = 2
	}
}

secrets {
	ike-fortigate {
		id = 2a00:X:X:X::2
		secret = "Passw0rd"  
	}
}

VTI6 Interface erstellen:

ip link add name vt0 type vti6 local 2a00:X:X:X::1 remote 2a00:X:X:X::2 key 43
ip link set vt0 up
ip -6 address add dev vt0 fd99:bade:affe::2/126

disable_policy setzen

sysctl -w net.ipv6.conf.eth0.disable_policy=1
sysctl -w net.ipv6.conf.vt0.disable_policy=1

Route zum Remote-Netz setzen (Beispiel)

ip -6 route add fd77::/64 via fd99:bade:affe::1 dev vt0

Firewall natürlich ICMP6 statt ICMP zulassen wenn du pingst ...

Rest der Charon-Config von oben bleibt gleich .

Done.

Results:

IKE SA

fortigate: #8, ESTABLISHED, IKEv2, bdc43f17a1e955b9_i* 438f18800815b15c_r
  local  ' 2a00:X:X:X::1' @ 2a00:X:X:X::1[4500]  
  remote '2a00:X:X:X::2' @ 2a00:X:X:X::2[4500]  
  AES_CBC-128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  established 784s ago, rekeying in 2738s
  net: #7, reqid 43, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA2_256_128
    installed 784s ago, rekeying in 2798s, expires in 3176s
    in  ce8577d9 (0x0000002b),   2768 bytes,    28 packets,   427s ago
    out c82e6327 (0x0000002b),   3392 bytes,    34 packets,   427s ago
    local  0.0.0.0/0 ::/0
    remote 0.0.0.0/0 ::/0

Ping Test:

ping fd99:bade:affe::1
PING fd99:bade:affe::1 (fd99:bade:affe::1) 56 Datenbytes
64 Bytes von fd99:bade:affe::1: icmp_seq=1 ttl=64 Zeit=1.44 ms
64 Bytes von fd99:bade:affe::1: icmp_seq=2 ttl=64 Zeit=0.539 ms
64 Bytes von fd99:bade:affe::1: icmp_seq=3 ttl=64 Zeit=0.618 ms

ping fd77::1 -I fd88::1
PING fd77::1 (fd77::1) von fd88::1 : 56 Datenbytes
64 Bytes von fd77::1: icmp_seq=1 ttl=64 Zeit=0.900 ms
64 Bytes von fd77::1: icmp_seq=2 ttl=64 Zeit=0.830 ms
64 Bytes von fd77::1: icmp_seq=3 ttl=64 Zeit=0.729 ms

Fazit: Lüppt wie erwartet ... 👍

Ich krieg jetzt nur komischerweise immer nen "no IKE config found for" Fehler im Log. IPv6-Adresse des Servers steht aber bei local_addrs drin und stimmt definitiv.

https://github.com/strongswan/strongswan/discussions/1939

Das wars auch bei mir.

Ein "Problem" hab ich noch: Wenn der Tunnel rum-idled und ich versuche vom strongswan in Richtung Forti zu Pingen macht er nix. Pinge ich dann einmal kurz der der Forti Richtung Strongswan gehts in beide Richtungen. "Problem" deshalb weil ich eh BGP darüber machen will (deshalb ja überhaupt das route-based) und damit kontinuierlich Daten auch von der Forti nach Stronswan fließen, was den Tunnel zurückzuholen scheint. Aber wär schon gut, wenns auch andersrum klappen würde.

Ein "Problem" hab ich noch: Wenn der Tunnel rum-idled und ich versuche vom strongswan in Richtung Forti zu Pingen macht er nix. Pinge ich dann einmal kurz der der Forti Richtung Strongswan gehts in beide Richtungen.

Stolpert man gerne mal drüber wenn man mit IPv6 hantiert. Du hast das ESP-Protokoll für IPv6 nicht in der Firewall der Forti freigeschaltet, deswegen kommt der Strongswan nicht mehr von selbst rüber wenn die States in der Firewall der Forti abgelaufen sind.
Macht die OPNSense per Default auch nur für IPv4 auf, muss man dort auch erst anpassen und IPv6 hinzufügen.

Zitat von @13910172396:

Is ja auch behindert, dass man das für v6 extra aktivieren muss. Für v4 macht sies von selbst...

IPv6 ist bei vielen halt immer noch nicht angekommen. Otto-Normalo ist froh wenn er IPv4 im Griff hat

. Jener der mit IPv6 hantiert von dem darf man erwarten das er auch die Firewall richtig konfigurieren kann

. Deswegen schalte ich jedwede Automatismen was die Firewall betrifft, immer als erstes ab, ich weiß selbst was ich freischalten will und muss, dann denkt man auch dran.

Zitat von @13910172396:

IPv6 ist halt bei vielen halt immer noch nicht angekommen. Otto-Normalo ist froh wenn er IPv4 im Griff hat

. Jener der mit IPv6 hantiert von dem darf man erwarten das er auch die Firewall richtig konfigurieren kann

. Deswegen schalte ich jedwede Automatisen was Firewall angeht, immer als erstes ab ich weiß selbst was ich freischalten will und muss.

Haha ja so scheint das wohl zu sein.

Das automatisieren bei der Forti geht nicht so einfach haha, besser gesagt gar nicht. aber ich habs mal geprüft, auch bei v4 ist ESP nicht automatisch an. Ich vermute, die Fortis sorgen über andere Wege untereinander dafür, dass das läuft und bei Tunneln zu anderen scheints halt problematisch zu werden. Ein Tunnel ohne Traffic ist eh obsolet oder so^^

ist ja auch blöd, dass man das für v6 extra aktivieren muss.

Deswegen ja oben auch die "table inet filter" address family im nftables setup. 😉
"Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support."

Zitat von @aqui:

ist ja auch blöd, dass man das für v6 extra aktivieren muss.

Deswegen ja oben auch die table inet filter address family im nftables setup. 😉
"Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support."

Es ging ja um die Firewall der Fortigate.

Aaaahhhsoo! Dann nehme ich alles zurück und behaupte das Gegenteil!

Also auch mit der ESP Regel auf der Forti geht’s nicht. Ich Probier jetzt mal noch aus, was passiert wenn ich in Strongswan als remote_addrs nicht %any sondern die IP der Forti (die leider nicht statisch ist) konfiguriere. Aber eig sollte Strongswan doch durch den Phase 1 Dialup der Forti wissen, wen er da ansprechen muss oder? Weil der Tunnel an sich steht ja und swanctl —list-sas zeigt auch die richtige Adresse…

EDIT: Wenn ich dann eben wiederum von der Forti zum Strongswan pinge, gehts ja wieder und dann sehe ich aufm WAN Interface (Forti) auch die ESP-Pakete, die kommen vorher nicht.

EDIT2: Ist ein DG-Anschluss, also CGNAT bei v4, da es aber ein v6 Tunnel ist, sollte das ja eig keine Probleme machen oder?

So und jetzt die Auflösung: Ich hab das Ganze noch nicht produktiv eingesetzt sondern erstmal hinter meiner alten OPNsense, welche das dann logischerweise geblockt hat.

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 IPSec with multiple initators on same IDketanest112 - 13 Kommentare

Fehlender Internetverbindung verlangsamt UACketanest112 - 6 Kommentare

Heiß diskutiert