9
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....
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....
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 355896
Url: https://administrator.de/contentid/355896
Ausgedruckt am: 23.11.2024 um 02:11 Uhr
9 Kommentare
Neuester Kommentar
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
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
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.
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"?
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"?
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.
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.
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.
Das musst du manuell scripten mit einem der Script Tools in den Packages.
Gibt's da irgendwie weitere Infos zu?
Keine Idee, wie?
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.
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.
