Securepoint Support Forum

Ich habe folgendes Szenario bei einem Kunden bei dem Fallback nicht funktioniert.
Auf dem primären Internetzugang hat der Kunde ein Subnetz mit 5 nutzbaren IPv4 Adressen.
In den ausgehenden Regeln der jeweiligen Zonen ist jeweils ein HIDENAT mit der zu nutzenden Adresse als Netzwerkobjekt hinterlegt.
Als Fallback-Interface dient ein externer LTE-Router, der selbst einen Zugang hinter einer NAT bereitstellt.
Pinge ich in den Netzwerktools der UTM meinetwegen 8.8.8.8 mit der Adresse des Interface an dem dieser Router hängt, dann bekomme ich Antworten.
Die Internetverbindung funktioniert da also.
Sobald das primäre Interface ausfällt, schaltet die UTM auch um und legt die Default-Route nun auf die Adresse des Routers (192.168.8.1).
Ich bekomme aber aus keinem der Subnetze Verbindung zum Internet. Weder auf dem Webinterface des UTM (Ping auf 8.8.8.8 mit einer der gültigen internen Adressen der UTM)
Noch von irgendeinem der Clients. Ein Traceroute endet immer am UTM, darüber hinaus gibt es nur Timeouts.
Wie bekomme ich das hin, dass alle per HIDENAT ins Netz geleiteten Verbindungen bei Ausfall der primären Verbindung und damit dieser externen Adressen, statt HIDENAT über diese Adressen einen FULLCONENAT auf den Router der Backupverbindung machen, also sich nicht als eine der festen Provideradressen ausgeben?
Ich stehe da irgendwie auf dem Schlauch...

Ein anderes Problem ist hier aufgepoppt mit dem internen LTE-Interface und dessen Treiber.
Ich setze für die Fallback-Verbindung auf eine global-SIM von simbase, da die für die aktive SIM "nur" nen Cent pro Tag berechnen, und ansonsten nur der anfallende Traffic Geld kostet (0,5ct / MB) Auch hat das den Vorteil, dass hier der immer beste verfügbare Carrier genutzt wird.
Leider sind das aber Roaming Karten, und das mit Roaming scheint egal wie der Schalter für Roaming gesetzt ist nicht zu funktionieren. Es läuft schlicht und einfach kein Traffic über die Leitung, auch wenn das WWAN0 anzeigt es wäre mit dem Anbieter verbunden, und mir auch vom Provider angezeit wird, dass das Modem verbunden wäre. Es ist dann auch kein Ping auf externe Adressen möglich.

Gruß,
Marek Tilgner

Wir haben auf der Hauptinternetleitung zB im Interface eth6 gesetzt dass es auf eth0 umspringen soll. Das passiert nach einigen pings auf 8.8.8. automatisch.
Im Paketfilter (Von einem internen LAN nach extern) haben wir dann das HIDENAT Netzwerkobjekt 0.0.0.0 über eth6 aktiv. Da dort der Fallback aktiviert ist haben wir bisher noch nie Umschwenkprobleme gehabt.
Das einzige manuelle was wir machen müssten, sollte die Hauptinternetleitung länger ausfallen, ist die VPNs anpassen durch die andere externe IP-Adresse der Backupleitung. (Kam bisher noch nicht vor)

Ich hab es ähnlich. Da läuft es halt nur so, dass die Hauptleitung auf eth0 liegt und der FALLBACK auf eth3.
In eth0 ist also eth3 als Fallback definiert.
Sobald das Internet über eth0 nicht erreichbar ist wird auch der Fallback vermeintlich aktiviert, die default-Route ändert sich auch auf den Route-hint von eth3.
Nur geht dann keine Verbindung raus, da die vermeintliche "Quelladresse" durch den Ausfall von eth0 für den Router nicht mehr existiert.
Ich kann auch hier für die diversen Subnetze nicht einfach 0.0.0.0 als HIDENAT setzen, da sie im "Normalbetrieb" mit der ihnen zugewiesenen Adresse aus dem Hauptnetz 
"nach aussen" treten müssen.
Es gibt in dem Fall ein Adresse für den normalen Internetverkehr ausgehend.
Eine Adresse über die alle VPNs laufen (also sozusagen eine DMZ für die VPNs)
Eine Adresse für diverse intern gehostete, von aussen erreichbare WEB-Dienste
Und eine Adresse für MTA / MUA (email).
Es wäre also wünschenswert, wenn beim greifen der Fallback-Route sich die Regeln dahingehend ändern würden, dass alle Subnetze dann über die Adresse der eth3 NATen.
Beim Wiederkehr der Standardverbindung sollen dann wieder die regulären HIDENATs gelten.

Man kann mit einer zweiten Regel gegen steuern. (Wird aber nicht von uns unterstützt)

Entsprechend zwei Zonen auf das Fallback Interface legen

Passende Regeln ÜBER den normalen Regeln anlegen (Bei den Objekten dann natürlich mit den Zonen des Fallback-Interfaces arbeiten)

Bei Greifen des Fallback werden somit die Regeln zuerst greifen, die ganz oben sind und passen. In dem Fall dann die, die auf die Zonen des Fallback passen.

Das ist nicht sonderlich hübsch/ wird bei daraus entstehenden Problemen nicht von uns supportet. Ich werde mir Ihren Vorschlag nächste Woche einmal anschauen Man müsste somit ein alternatives NAT-Objekt mit dazu packen können.