Sourcerouting übernimmt nicht die Routen der Main Table

[Tobias U.]

Hallo,

ich ändere gerade Einstellungen bzgl. des Routings. D. h. ich möchte schritt für Schritt ein neues Gateway für das Netzwerk konfigurieren.

Dabei setze ich z. B. für einen ersten Schritt für eine bestimmte IP-Adresse ein neues Default-GW:

Normale Route

Code: Alles auswählen

Quell-IP   : <na>
Gateway-IP : 192.168.150.10
Ziel-IP    : 0.0.0.0/0

Neue Quell-IP-spezifische Route:

Code: Alles auswählen

Quell-IP   : 172.31.30.65/32
Gateway-IP : 192.168.150.1
Ziel-IP    : 0.0.0.0/0

Das Problem dabei ist, dass mir jetzt für die Quell-IP-Adresse viele der gesetzten Routen in der Main Table fehlen. Z. B. die dynamisch generierten SSL-VPN-Routen, aber auch explizit zusätzlich gesetzte statische Routen. Wenn ich diese jetzt händisch auch als Route für diese Quell-IP setze, dann funktioniert es wieder. Aber damit verliere ich natürlich den Automatismus und muss nach jeder Änderung beim SSL-VPN auch immer händisch die Routen nachtragen.

Grundsätzlich wäre die Erwartung, dass die Clientspezifische Route einfach nur die Main-Routing-Table-ergänzt.

Als Workaround habe ich jetzt halt ein Script, dass die Routen per spcli setzt, ungefähr so:

routes.txt

Code: Alles auswählen

# 1. dst network 2. gateway
172.29.1.0/24 192.168.1.2
172.29.2.0/24 192.168.2.2
172.29.3.0/24 192.168.3.2

update-routes.sh

Code: Alles auswählen

#!/bin/sh
source=172.31.30.65
while read dst gw ; do
   spcli route new src "$source" dst "$dst" router "$gw"
done <routes.txt
spcli system update routes

Ist das gewünschte Verhalten auch anders und einfach erreichbar?

[Mario]

Die Routen haben Rangfolgen. Eine Source Route wird eine Ziel-Route immer überbieten. Bei identischen Routen ergibt sich die Rangfolge anhand der Größe der verwendeten Subnetze. Je kleiner = Mehr Priorität

Wenn Sie also per Quellroute eine Quelle über ein bestimmtes Gateway Richtung 0.0.0.0/0 schicken, wird die Default-Route, die die geringste Priorität hat, "überschrieben". Es müssen Also weitere Zielrouten definiert werden. (Für SSL S2S-Tunnel z.B.)

Linklokale Routen wiederum sind ranghöher als Quellrouten. An der UTM anliegende Netze brauchen somit keine weitere Zielroute in diesem Fall. Usw.

Grob:

"IPSEC"
Rule-Route
Linklokale Route
Quell-Route
Ziel-Route
Default-Route

Dabei sollte darauf geachtet werden, das man sich von Unten nach Oben orientiert. Man sollte nur die Art der Route verwenden, die man wirklich benötigt. Es kann (Und wahrscheinlich "wird") sich als Nachteilig herausstellen, wenn man direkt mit der Rule-Route auf Spatzen schießt.

[Tobias U.]

Ok. Ich verstehe ungefähr, was Sie schreiben, teilweise war mir das auch bereits bekannt. Insofern danke erst einmal für die Erklärung dazu.

Der Lösung meines Problems bringt micht das allerdings noch nicht näher. Mein Problem ist, dass ich ein zweites Default-Gateway habe, zu dem ich nach und nach den Traffic migrieren möchte. Nach und nach deswegen, weil in einer komplexen Konfiguration auch Dinge schief laufen können und ich deswegen die Migration schrittweise durchführen möchte. Das zweite Gateway bekommt jetzt auch nach und nach alle Public-IPs des bestehenden Internetanschlusses und hat dann auch noch ein Failover/Loadbalancing auf eine zweite Internetleitung, die transparent hinter Verbindung zur Securepoint ist.

Ansonsten komme ich mit meinem Workaround auch wie gewünscht weiter.