IPSec (strongswan): Wie das Routing konfigurieren?

[heisenberg]

Hi,

ich teste hier gerade ein grundsätzliches IPSec-Strongswan-Setup mit PSK.

Zum Setup:

• Site-to-Site Verbindung mit Debian Bookworm auf beiden Seiten
• IPSec-Verbindung ist erfolgreich aufgebaut

Hier ist die swanctl.conf (/etc/swanctl/conf.d/swanctl.conf): 42002

Hier ist der Verbindungsstatus (swanctl --list-sas): 42004

Jetzt stelle ich mir die Frage, wie das Routing da laufen soll?

Wenn ich mir die Beispielkonfiguration (hier: https://www.strongswan.org/testing/test ... t2net-psk/) anschaue, dann ist das Beispiel schon mal insofern anders, als dass im Beispiel beide IPSec-Stationen im gleichen IP-Netz sind. Das ist ja schon mal recht ungewöhnlich, weil verschlüsselte Verbindungen üblicherweise nicht über Gateways gehen, die direkt nebeneinander stehen.

Das Beispiel zeigt auch, dass in der Routing Table 220 bereits eine Route gesetzt wurde. Bei mir ist diese jedoch leer.

Mit welchem Befehl kann ich für die jeweils hinter den Gateways liegenden Subnetze eine Route setzen?

Viele Grüße,
h.

(Ich vermute, ich muss mich noch wesentlich tiefer einarbeiten.)

[heisenberg]

Ich habe jetzt nochmal ein anderes Tutorial verwendet, was sich sehr simpel liest. Funktionieren tut es aber nicht:

https://www.tecmint.com/setup-ipsec-vpn ... an-ubuntu/

IPSec-Verbindung ist auch hier wieder korrekt aufgebaut:

Das Setup sieht bei mir so aus:

Code: Alles auswählen

[vm-netz-a] (192.168.240.15/24)
  |
  |         (192.168.240.1/24) (=private ip)
[ipsec-server-a]
  |         (1.2.3.4/26) (=public ip)
  |
  |         (9.7.6.13/26) (=public ip)
[ipsec-server-b]
  |         (192.168.241.1/24) (=private ip)
  |
  |         
[vm-netz-b] (192.168.241.15/24)
              

Status von ipsec-server-a:

Code: Alles auswählen

# ipsec status
Security Associations (1 up, 0 connecting):
devgateway-to-prodgateway[3]: ESTABLISHED 53 minutes ago, 1.2.3.4[1.2.3.4]...9.7.6.13[9.7.6.13]
devgateway-to-prodgateway{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: ca95654e_i c8edaf02_o
devgateway-to-prodgateway{2}:   192.168.240.0/24 === 192.168.241.0/24

Status von ipsec-server-b:

Code: Alles auswählen

# ipsec status
Security Associations (1 up, 0 connecting):
prodgateway-to-devgateway[1]: ESTABLISHED 53 minutes ago, 9.7.6.13[9.7.6.13]...9.7.6.13[9.7.6.13]
prodgateway-to-devgateway{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8edaf02_i ca95654e_o
prodgateway-to-devgateway{2}:   192.168.241.0/24 === 192.168.240.0/24

Wenn ich das Tutorial befolge, dann wird mein ping on vm-netz-a zum Default-Router von ipsec-server-a geschickt und der sagt logischerweise "Destination net unreachable".

[heisenberg]

Ich bin jetzt nochmal zurück zu Beispiel 1 gegangen und habe die gleichen Konfigurationsdateien aus dem Beispiel-Setup der Strongswan-Seite genommen.

Zum einen scheint da ein Script falsch konfiguriert zu sein:

Code: Alles auswählen

Aufgerufen wird:          /usr/local/libexec/ipsec/_updown
Bei debian ist es unter:  /usr/lib/ipsec/_updown

Das musste ich nochmal in der Konfigurationsdatei ändern.

Ansonsten kann ich zumindest schon mal die internen IPs der Gateways pingen und ein zusätzliches Netzwerkgerät namens "ipsec0" gibt es jetzt auch auf beiden Seiten.

Aber die VM hinter dem ipsec-gateway kann ich nicht pingen:

Code: Alles auswählen

[ipsec-gateway-b] # ping 192.168.240.15
PING 192.168.240.15 (192.168.240.15) 56(84) bytes of data.
From 192.168.240.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.240.15)
From 192.168.240.1: icmp_seq=3 Redirect Host(New nexthop: 192.168.240.15)
...

Das Gateway auf der Zielseite sagt mir dann das:

Code: Alles auswählen

20:45:45.098742 ipsec0 In  IP 192.168.241.1 > 192.168.240.15: ICMP echo request, id 21305, seq 1, length 64
20:45:45.098849 ipsec0 Out IP 192.168.241.1 > 192.168.240.15: ICMP echo request, id 21305, seq 1, length 64
20:45:46.117585 ipsec0 In  IP 192.168.241.1 > 192.168.240.15: ICMP echo request, id 21305, seq 2, length 64
20:45:46.117652 ipsec0 Out IP 192.168.240.1 > 192.168.241.1: ICMP redirect 192.168.240.15 to host 192.168.240.15, length 92

Was widerrum klar ist. Ich habe aus Einfachheitsgründen die Public-IP und die private IP auf das gleiche Interface gelegt. Dass darf ich nicht tun, weil es dann einen ICMP redirect gibt, weil beides über das gleiche physische Interface geht.

Doch nochmal umbauen.

[heisenberg]

Ok. Umgebaut. Geht immer noch nicht.

tcpdump zeigt, dass der Ping zum lokalen Netz immer noch ins ipsec geroutet wird.

Wenn ich mir die Routing-Table vom IPSec anzeigen lasse, dann ist die auch falsch:

Code: Alles auswählen

[ipsec-server-a] # ip route list table 220
9.9.9.0/24 dev ipsec0 proto static src 9.9.9.1
192.168.184.0/24 dev ipsec0 proto static src 192.168.184.1 
192.168.240.0/24 dev ipsec0 proto static src 192.168.240.1 
192.168.241.0/24 dev ipsec0 proto static src 192.168.240.1 

Wenn ich die Route manuell lösche, dann geht das:

Code: Alles auswählen

ip route delete 192.168.240.0/24 dev ipsec0 table 220

Jetzt pingt alles hin und her.

Nur die Frage, was da falsch läuft, dass der Routing-Eintrag gesetzt wird. Das lokale Subnetz des Hosts (9.9.9.0/24) und ein anderes lokales Subnetz (192.168.184.0/24) am ipsec-server-a wird auch einfach da reingeroutet, obwohl das auch lokal ist.

[heisenberg]

Wenn ich in /etc/strongswan.d/charon.conf das folgende eintrage, dann sind die zusätzlichen Routen weg:

Code: Alles auswählen

install_routes = no

Damit sind die störenden Routen nach dem Neustarten der IPSec-Verbindung weg. Anhand der Doku kann ich das aber nicht verstehen, warum das so ist.