17
IPsec über LTE-WAN bei Failover Konfiguration (PfSense, Mikrotik)
Moin zusammen,
ich bin derzeit Zuhause auf meine Backupleitung angewiesen.
Diese hängt an meiner PfSense und ist durch ein Mikrotik Routerboard mit LTE Karte realisiert.
Interne Netze werden bis zu dem Board geroutet und nutzen das LTE Interface als outbreak.
Mein Thema besteht darin nun auch eine IPsec Strecke, mit einer festen IP als Endpunkt, über das LTE Netz laufen zu lassen.
Meines Wissens nach muss ich nur Port 500,4500 UDP und ESP am LTE Interface auf meine Sense forwarden. (dest-nat).
Allerdings führt dies noch nicht zum gewünschten Ergebnis.
Auf Seiten der Sense läuft die IPsec-Authentifizierung auf meiner dynamischen Seite mit Key-ID-Tag und zum festen Endpunkt durch IP-Indent.
Für diesen Tunnel wird IKEv2 eingesetzt. An dieser Stelle weiß ich nicht ob das mit dem CGN funktioniert.
Hier kurz das forwarding am Mikrotik:
Jeweils als Destination die IP der Sense im Trägernetz.
Firewall Regeln sind am Mikrotik nicht angepasst.
Auf Seiten der Sense dürften die Regeln im Hintergrund automatisch erstellt werden, da es sich bei IPsec um einen eigenen Service handelt. Zumindest läuft dies mit der normalen DSL Strecke einwand frei und es taucht nichts im block auf.
Hat jemand eine Idee oder ist dieses Vorhaben so nicht lösbar?
Euch ein schönes Wochenende
Spirit
ich bin derzeit Zuhause auf meine Backupleitung angewiesen.
Diese hängt an meiner PfSense und ist durch ein Mikrotik Routerboard mit LTE Karte realisiert.
Interne Netze werden bis zu dem Board geroutet und nutzen das LTE Interface als outbreak.
Mein Thema besteht darin nun auch eine IPsec Strecke, mit einer festen IP als Endpunkt, über das LTE Netz laufen zu lassen.
Meines Wissens nach muss ich nur Port 500,4500 UDP und ESP am LTE Interface auf meine Sense forwarden. (dest-nat).
Allerdings führt dies noch nicht zum gewünschten Ergebnis.
Auf Seiten der Sense läuft die IPsec-Authentifizierung auf meiner dynamischen Seite mit Key-ID-Tag und zum festen Endpunkt durch IP-Indent.
Für diesen Tunnel wird IKEv2 eingesetzt. An dieser Stelle weiß ich nicht ob das mit dem CGN funktioniert.
Hier kurz das forwarding am Mikrotik:
Firewall Regeln sind am Mikrotik nicht angepasst.
Auf Seiten der Sense dürften die Regeln im Hintergrund automatisch erstellt werden, da es sich bei IPsec um einen eigenen Service handelt. Zumindest läuft dies mit der normalen DSL Strecke einwand frei und es taucht nichts im block auf.
Hat jemand eine Idee oder ist dieses Vorhaben so nicht lösbar?
Euch ein schönes Wochenende
Spirit
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: 457478
Url: https://administrator.de/forum/ipsec-ueber-lte-wan-bei-failover-konfiguration-pfsense-mikrotik-457478.html
Ausgedruckt am: 24.12.2024 um 18:12 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
Gruß,
Peter
Zitat von @Spirit-of-Eli:
Interne Netze werden bis zu dem Board geroutet und nutzen das LTE Interface als outbreak.
Als OutBreak ?!?Interne Netze werden bis zu dem Board geroutet und nutzen das LTE Interface als outbreak.
Meines Wissens nach muss ich nur Port 500,4500 UDP und ESP am LTE Interface auf meine Sense forwarden. (dest-nat).
Wenn dein ISP dir kein CGN vorschaltet.Allerdings führt dies noch nicht zum gewünschten Ergebnis.
CGN am VPN Server Standort?Für diesen Tunnel wird IKEv2 eingesetzt. An dieser Stelle weiß ich nicht ob das mit dem CGN funktioniert.
Mit CGN nicht.Hat jemand eine Idee oder ist dieses Vorhaben so nicht lösbar?
CGN am VPN Server Standort. Ein VPN Client kann immer auch mit CGN seinen VPN Server erreichen und ein VPN aufbauen.Gruß,
Peter
Das ist normalerweise eine s2s Verbindnung.
Diese möchte ich im Failover Fall auf die LTE Verbindung legen.
Das bedeutet, dieses Vorhaben ist mit IPsec nicht möglich und ich müsste das ganze doch über OpenVPN realisieren sobald ich auf einer Seite keine öffentliche IP mehr habe?
Diese möchte ich im Failover Fall auf die LTE Verbindung legen.
Das bedeutet, dieses Vorhaben ist mit IPsec nicht möglich und ich müsste das ganze doch über OpenVPN realisieren sobald ich auf einer Seite keine öffentliche IP mehr habe?
Hallo,
Gruß,
Peter
Zitat von @Spirit-of-Eli:
Das bedeutet, dieses Vorhaben ist mit IPsec nicht möglich und ich müsste das ganze doch über OpenVPN realisieren sobald ich auf einer Seite keine öffentliche IP mehr habe?
Es kommt darauf an wo deine VPN Server sitzt. Portforwarding geht bei CGN nicht. Für ausgehenden Traffic (z.B. Aufbau eines VPN zu einen VPN Server) stört ein CGN nicht.Das bedeutet, dieses Vorhaben ist mit IPsec nicht möglich und ich müsste das ganze doch über OpenVPN realisieren sobald ich auf einer Seite keine öffentliche IP mehr habe?
Gruß,
Peter
Ich hatte die ganze Zeit einen Denkfehler.
Da es um sich um S2S IPsec handelt, muss ja auf beiden Seiten der jeweils andere Endpunkt definiert sein. Daher kann ich das in der Konstellation knicken.
WIrklich toll finde ich es nicht diese Nummer über OpenVPN realisieren zu müssen.
Alternative bleibt mir nur den Tunnel über IPv6 zu bauen. Soll ja bei IKEv2 möglich sein darüber auch eine IPv4 Phase 2 zu schieben.
Da es um sich um S2S IPsec handelt, muss ja auf beiden Seiten der jeweils andere Endpunkt definiert sein. Daher kann ich das in der Konstellation knicken.
WIrklich toll finde ich es nicht diese Nummer über OpenVPN realisieren zu müssen.
Alternative bleibt mir nur den Tunnel über IPv6 zu bauen. Soll ja bei IKEv2 möglich sein darüber auch eine IPv4 Phase 2 zu schieben.
mit einer festen IP als Endpunkt, über das LTE Netz laufen zu lassen.
Solange das LTE öffentliche IPs benutzt und kein CGN macht ist das kein Thema !muss ich nur Port 500,4500 UDP und ESP am LTE Interface auf meine Sense forwarden.
Richtig ! Wenn deine pfSense das IPsec terminiert. Der Mikrotik kann das natürlich auch 
An dieser Stelle weiß ich nicht ob das mit dem CGN funktioniert.
Nur wenn der Initiator LTE nutzt.Wenn der Initiator in einem öffentlichen IP Netz sitzt dann geht es logischerweise nicht. Klar, denn dort bleibt der Connection Request am CGN Gateway des LTE Providers hängen.
Fazit: Nur der Initiator darf an einem CGN Netz hängen, NICHT der Responder !
Firewall Regeln sind am Mikrotik nicht angepasst.
Wenn du die Default Regeln verwendest dann lassen die IPsec passieren. Siehe dazu auch:Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Daher kann ich das in der Konstellation knicken.
Nein, nicht unbedingt !Wie gesagt wenn der Initiator am CGN hängt und eine feste öffentliche IP connectet dann klappt es. Andersrum nicht.
Soll ja bei IKEv2 möglich sein darüber auch eine IPv4 Phase 2 zu schieben.
GRE Tunnel via v6 und darin dann dein privates IPv4 tunneln. Siehe MT Tutorial oben... Zitat von @aqui:
Wie gesagt wenn der Initiator am CGN hängt und eine feste öffentliche IP connectet dann klappt es. Andersrum nicht.
Daher kann ich das in der Konstellation knicken.
Nein, nicht unbedingt !Wie gesagt wenn der Initiator am CGN hängt und eine feste öffentliche IP connectet dann klappt es. Andersrum nicht.
Ich habe allerdings einen ganz normalen Tunnel (Mmn. Site to Site) laufen.
Sobald meine PfSense eine Session aufbauen will ist das allerdings ja nicht Client Basiert.
Daher wird es nicht funktionieren. Ansonsten hätte es ja klappten müssen.
Alleine daher, das ich auf beiden Seiten das Ziel definieren muss, kann es in der Konstellation nicht klappen.
Hier müsste ich eine Standortanbindung über OpenVPN realisieren. Denn meine Anforderungen kann ich nicht mit Mobile-IPsec abbilden.
Sehe ich das richtig?
// Der Endpunkt aus meiner Sicht ist fest und über öffentliche IPs erreichbar.
Du kannst aber bei der pfSense in der IPsec Phase 1 einstellen ob sie Initiator oder nur Responder ist:
Der Initiator kann auch mit wechselnden IPs arbeiten. Tut er ja sowieso, da du auf die öffentlichen CGN Gateway IPs des LTE Providers ja eh keinerlei Einfluß hast.
Der Responder muss aber auf einer festen öffentlichen IP oder Minimum DynDNS IP liegen OHNE CGN. Als Ziel nimmst du da 0.0.0.0, dann nimmt die pfSense alles an was reinkommt. Dann geht es. CNAME dürfen dann nicht die IPs sein sondern String, Email usw.
https://forum.netgate.com/topic/137452/vpn-ipsec-one-site-has-a-dynamic- ...
Der Initiator kann auch mit wechselnden IPs arbeiten. Tut er ja sowieso, da du auf die öffentlichen CGN Gateway IPs des LTE Providers ja eh keinerlei Einfluß hast.
Der Responder muss aber auf einer festen öffentlichen IP oder Minimum DynDNS IP liegen OHNE CGN. Als Ziel nimmst du da 0.0.0.0, dann nimmt die pfSense alles an was reinkommt. Dann geht es. CNAME dürfen dann nicht die IPs sein sondern String, Email usw.
https://forum.netgate.com/topic/137452/vpn-ipsec-one-site-has-a-dynamic- ...
Zitat von @aqui:
Du kannst aber bei der pfSense in der IPsec Phase 1 einstellen ob sie Initiator oder nur Responder ist:
Der Initiator kann auch mit wechselnden IPs arbeiten. Tut er ja sowieso, da du auf die öffentlichen CGN Gateway IPs des LTE Providers ja eh keinerlei Einfluß hast.
Der Responder muss aber auf einer festen öffentlichen IP oder Minimum DynDNS IP liegen OHNE CGN. Als Ziel nimmst du da 0.0.0.0, dann nimmt die pfSense alles an was reinkommt. Dann geht es. CNAME dürfen dann nicht die IPs sein sondern String, Email usw.
https://forum.netgate.com/topic/137452/vpn-ipsec-one-site-has-a-dynamic- ...
Du kannst aber bei der pfSense in der IPsec Phase 1 einstellen ob sie Initiator oder nur Responder ist:
Der Initiator kann auch mit wechselnden IPs arbeiten. Tut er ja sowieso, da du auf die öffentlichen CGN Gateway IPs des LTE Providers ja eh keinerlei Einfluß hast.
Der Responder muss aber auf einer festen öffentlichen IP oder Minimum DynDNS IP liegen OHNE CGN. Als Ziel nimmst du da 0.0.0.0, dann nimmt die pfSense alles an was reinkommt. Dann geht es. CNAME dürfen dann nicht die IPs sein sondern String, Email usw.
https://forum.netgate.com/topic/137452/vpn-ipsec-one-site-has-a-dynamic- ...
Genau das habe ich gebraucht!
Besten Danken ;) ich teste das sofort.
Ich habe es gerade getestet.
Phase 1 steht. Augenscheinlich auch Phase 2, nur ohne das Traffic drüber läuft.
Phase 1 steht. Augenscheinlich auch Phase 2, nur ohne das Traffic drüber läuft.
Es fehlte nur eine Kleinigkeit.
Für beide Seiten muss als Identifier zwingend Bsp. "Distinguished name" genutzt werden.
Wenn auf der Seite mit fester IP "My IP" eingestellt ist. wird alles aufgebaut aber Traffic ist nicht möglich.
Für beide Seiten muss als Identifier zwingend Bsp. "Distinguished name" genutzt werden.
Wenn auf der Seite mit fester IP "My IP" eingestellt ist. wird alles aufgebaut aber Traffic ist nicht möglich.
Hy Spirit,
Ich empfehle dir als Failover-Lösung ein Draytak-Router zu benutzen. Du kannst z. Bsp bei Vigor 2860 bis zu 4 ISP benutzen (1 x DSL, 1 normaler Wan, 2 x LTE). Und dahinter schaltet du dein pfsense Firewall und gut ist (:.
Ich empfehle dir als Failover-Lösung ein Draytak-Router zu benutzen. Du kannst z. Bsp bei Vigor 2860 bis zu 4 ISP benutzen (1 x DSL, 1 normaler Wan, 2 x LTE). Und dahinter schaltet du dein pfsense Firewall und gut ist (:.
Zitat von @decehakan:
Hy Spirit,
Ich empfehle dir als Failover-Lösung ein Draytak-Router zu benutzen. Du kannst z. Bsp bei Vigor 2860 bis zu 4 ISP benutzen (1 x DSL, 1 normaler Wan, 2 x LTE). Und dahinter schaltet du dein pfsense Firewall und gut ist (:.
Hy Spirit,
Ich empfehle dir als Failover-Lösung ein Draytak-Router zu benutzen. Du kannst z. Bsp bei Vigor 2860 bis zu 4 ISP benutzen (1 x DSL, 1 normaler Wan, 2 x LTE). Und dahinter schaltet du dein pfsense Firewall und gut ist (:.
Moin,
im gewerblichem Umfeld würde ich das wahrscheinlich auch machen.
Das hier war eher eine Bastelaktion. Die Routerboards von Mikrotik sind da schon schöner und freier zu konfigurieren ;)
...und haben zudem auch noch eine Menge mehr sinnvoller Features als die Drayteks !
Lesen...!!!
Dadurch das eine IP offen ist muss es Name, String oder Email usw. sein.
Aber gut wenns nun alles rennt wie es soll 👏
Works as designed...!
für beide Seiten muss als Identifier zwingend Bsp. "Distinguished name" genutzt werden.
Stand doch auch oben!! ! Lesen...!!!Dadurch das eine IP offen ist muss es Name, String oder Email usw. sein.
Aber gut wenns nun alles rennt wie es soll 👏
Works as designed...!
Noch nicht ganz.
Seid heute morgen lässt sich der Tunnel nicht mehr über die LTE Strecke aufbauen. Wohl aber über DSL.
Ich hatte jetzt noch nicht die Zeit zur Analyse.
Seid heute morgen lässt sich der Tunnel nicht mehr über die LTE Strecke aufbauen. Wohl aber über DSL.
Ich hatte jetzt noch nicht die Zeit zur Analyse.
Ich habe den Tunnel jetzt doch auf OpenVPN umgezogen, da ich es mit der 0.0.0.0 absolut nicht ans laufen gebracht habe.
Anscheind erlaubt der Sense das derzeit einfach nicht.
Wohlgemerkt steht Phase 1 anscheind, aber es geht partu kein Traffic mehr durch. Ändere ich den Remote Punkt wieder auf eine dyn-DNS Adresse läuft es sofort.
Anscheind erlaubt der Sense das derzeit einfach nicht.
Wohlgemerkt steht Phase 1 anscheind, aber es geht partu kein Traffic mehr durch. Ändere ich den Remote Punkt wieder auf eine dyn-DNS Adresse läuft es sofort.
Anscheind erlaubt der Sense das derzeit einfach nicht.
Beim Client Dialin klappt es fehlerlos, denn sonst könnten sich Clients mit wechselnder IP ja gar nicht einwählen. Bei Site to Site hab ich das noch nicht getestet. Mach ich aber die Tage nochmal. Laut Doku sollte das aber auch klappen.steht Phase 1 anscheind, aber es geht partu kein Traffic mehr durch.
Wenn die Phase 2 nicht auch durch ist kann es das logischerweise auch nicht. Phase 1 und 2 müssen negotiated werden ! Sonst kein IPsec Tunnel !!Bedenke das du hier immer den Aggressive Mode nutzen solltest !!
Aber gut, wenns nun OVPN ist ists ja eh Geschichte
Ich verstehe nur nicht, wieso es in der Konstellation erstmal über DSL läuft.
Sobald dort auf der Seite mit fester IP als Endpunkt 0.0.0.0 eingetragen ist, geht dort keine neuauthentifizierung.
Sobald ich dort wieder einen DynDNS Namen Einträge rennt der Tunnel wieder.
Allerdings habe ich das ganze mit VTI auf Phase 2 versucht. Das könnte es noch sein.
Sobald dort auf der Seite mit fester IP als Endpunkt 0.0.0.0 eingetragen ist, geht dort keine neuauthentifizierung.
Sobald ich dort wieder einen DynDNS Namen Einträge rennt der Tunnel wieder.
Allerdings habe ich das ganze mit VTI auf Phase 2 versucht. Das könnte es noch sein.
