sleeplessnight
Goto Top

Pfsense WAN Failover LTE and dynamic DNS

Hallo,

eine Frage an euch spezis:

Ich hab mir ein WAN Failover zusammengebastelt. Das ganze funktioniert soweit auch ganz gut, bis auf ein paar DNS Server Probleme.

Was allerdings irgendwie gar nicht klappt, ist der nette Dynamic DNS Dienst. Der Updatet zwar ganz brav die IP sobald das Main WAN ausfällt, allerdings findet der irgendeine IP Adresse, die wohl irgendwo im NAT Nirvana des LTE-Providers steckt.

Das LTE Modem sagt mir die üblichen LTE Adressen: 10.xx.xx.xxx Der DynDNS Dienst löst jedoch nach 80.xx.xx.xx auf.
Das Spiel geht auch anders herum. Löse ich die FQDN von extern per trace auf (also aus einem ganz anderen Netz (LTE des Handys)), ist der letzte Point wohl auch die "übergabe" an den LTE-WAN Provider. Jedenfalls stimmt auch die von dem Trace IP nicht mit der IP des DynDNS Dienstes der pfsense überein.

Riecht das nach einem Bug oder sitzt der Bug 40cm hinter dem Bildschirm?

Ich frag mich sowieso, wie der Dienst auf die IP kommt. Das LTE Gateway der pfsense hat ja eh per DHCP vom Modem eine private Adresse bekommen. Das Modem setzt den quak ja auf die öffentliche IP um....

Content-Key: 355896

Url: https://administrator.de/contentid/355896

Ausgedruckt am: 19.03.2024 um 08:03 Uhr

Mitglied: StefanKittel
StefanKittel 24.11.2017 um 06:56:03 Uhr
Goto Top
Moin,

klingt für mich weniger nach einem Fehler als nach einer nicht öffentlichen IP die Du per LTE bekommst.
Das ist bei vielen Anbietern üblich da es zu wenige IPv4 Adressen gibt. Diese IP muss auch nicht stabil sein und im Sekundentakt wechseln.

probier mal http://ip.skittel.de aus.

Aber so eine IP bringt Dir eh nichts, da Du davon keine Weiterleitungen machen kannst.
Ist ja nicht nur Deine IP.

Stefan
Mitglied: aqui
aqui 24.11.2017 aktualisiert um 10:59:42 Uhr
Goto Top
die wohl irgendwo im NAT Nirvana
Sowas ist natürlich Unsinn und gibt es nicht.
Die 10er IP deutet darauf hin das der LTE Provider im LTE Mobilfunk Netzwerk private RFC 1918 IP Adressen nutzt und Carrier Grade NAT.
Da ist dann so oder so aus mit remotem Zugriff.
Mitglied: sleeplessnight
sleeplessnight 24.11.2017 um 23:03:23 Uhr
Goto Top
Zitat von @aqui:
Da ist dann so oder so aus mit remotem Zugriff.
Jup, das dachte ich mir schon.

Was natürlich mal richtig förderlich für einer Wartung ist.

Dann folgendes Szenario, was vielleicht abhilft:
Superman's Faust names VPN.

Ist's möglich, der pfsense folgendes Szenario beizubringen: "bei einem Failover über das LTE baue eine VPN Verbindung auf"?
Mitglied: aqui
aqui 25.11.2017 um 12:48:10 Uhr
Goto Top
Jup, das dachte ich mir schon.
Eine winzige Chance gibt es noch. Wenn dieses Gerät ein SSL basiertes VPN Nutzt wie z.B. OpenVPN und von sich aus die VPN Session irgendwohin aufbaut und den VPN Tunnel etabliert, dann kann man auch VPNs realisieren, denn so "bohrt" sich dieses Endgerät ja dann einen Tunnel durch CGN.
Andersrum wird es nicht gehen durch das CGN.
Diese Chance hast du also. Wenn sich also alle diese Geräte an einem RFC 1918 LTE aktiv irgendwo per VPN anmelden auf einem zentralen VPN Server, SIE also die Sessioninitiieren, dann geht es.
der pfsense folgendes Szenario beizubringen: "bei einem Failover über das LTE baue eine VPN Verbindung auf"?
Yepp, genau DAS ist der richtige Ansatz und das klappt natürlich fehlerlos. Die pfSense wird dann als OpenVPN Client konfiguriert und initiiert dann von sich aus das VPN im Failoverfall.
Das klappt fehlerlos auch über CGN.
Mitglied: sleeplessnight
sleeplessnight 26.11.2017 um 23:32:51 Uhr
Goto Top
Zitat von @aqui:

Yepp, genau DAS ist der richtige Ansatz und das klappt natürlich fehlerlos. Die pfSense wird dann als OpenVPN Client konfiguriert und initiiert dann von sich aus das VPN im Failoverfall.

Ja, und wie geht es, das der Tunnel nur beim Fallback auf LTE aufgebaut wird?
"immer da" Tunnel versteh ich, aber einen, der halt nur dann aufgebaut wird, nicht.
Mitglied: aqui
aqui 27.11.2017 um 10:01:54 Uhr
Goto Top
Das musst du manuell scripten mit einem der Script Tools in den Packages.
Mitglied: sleeplessnight
sleeplessnight 04.12.2017 um 21:42:54 Uhr
Goto Top
Gibt's da irgendwie weitere Infos zu?
Mitglied: sleeplessnight
sleeplessnight 11.12.2017 um 00:13:21 Uhr
Goto Top
Keine Idee, wie?
Mitglied: aqui
aqui 11.12.2017 um 10:54:40 Uhr
Goto Top
Du musst mit einem Script die Verfügbarkeit testen mit Ping und dann nach einem Timeout ein Failover anstossen. Entweder mit einem einfachen Shellscript, oder der internen Ablaufsteuerung. Dazu müsste man etwas tiefer einsteigen. Fertige Lösungen gibt es da m.W. nicht.
Die Problematik ist ja das du es nicht vom Link Status des Interfaces abhängig machen kannst was die Sache dann sehr vereinfachen würde. Man muss also aktiv mit Pings etc. die Verfügparbeite prüfen und müsste dann die Starstup Scripte für die OVPN Verbindung abhängig davon triggern. Generell nicht schwer aber es ist eben Handarbeit auf der Shell.