19
Probleme bei IPSec im MultiWAN auf PFSense
Hallo Zusammen,
ich habe ein Problem mit einer PFSense im MultiWAN bei IPSec.
Folgender Aufbau ist gegeben:
Über die PFSense sind 2 WAN-Verbindungen per PPPoE realisiert, jeweils beide statische, öffentliche IP's. Die Clients fragen bei Aufbau der VPN-Verbindung eine Subdomain der TLD an (vpn.xyz.de), bei den DNS-Einträgen im Domainregistrar wurden jeweils ein A-Record pro öffentliche IP gesetzt, der Eintrag vpn.xyz.de hält also zwei IPv4 Adressen.
Die PFSense leitet die Anfragen dann auf einen RADIUS-Server um (Windows NPS), dieser erwartet dann zur Authentifizierung ein Zertifikat der Domänenzertifizierungsstelle für das VPN sowie das AD-Kennwort.
Dieses Wochenende habe ich die zwei WAN-Anschlüsse in eine Gateway Group gepackt, um das MultiWAN in Betrieb zu nehmen, was jedoch zu verschiedenen Problem beim VPN geführt hat:
Fragen die Clients unter vpn.xyz.de an und erhalten mittels DNS die öffentliche IP des Vodafone WAN's wird der Tunnel aufgebaut und die Verbindung ins VPN funktioniert, allerdings funktioniert beispielsweise RDP, also Remotedesktop auf einen Server nicht mehr, alle anderen Protokolle funktionieren jedoch. Fragen die Clients per DNS vpn.xyz.de an und erhalten die öffentliche IP des Telekom-WAN's wird der Tunnel mit der Fehlermeldung abgeschmettert, dass es einen Fehler in der Richtlinie gibt.
Hier einmal der aktuelle Aufbau der VPN-Config:
Hier die Gateway Group:
An den Firewallregeln kann es nicht liegen, diese sind unverändert geblieben und sollten das Problem mit dem Routing nicht auslösen können. Sind jetzt nicht mit angehangen, können aber nachgereicht werden.
Das Routing im LAN übernimmt ein Cisco C9200 im Stack, auf der PFSense sind statische Routen auf die VLAN's, die der C9200 hält konfiguriert.
Ein gescheiterter Versuch zur Authentifizierung beim VPN in den Logs auf das Telekom-WAN sieht übrigens so aus:
Es wird wohl anscheinend keine IKE config gefunden, diese existiert aber wie in den Screens zu sehen.
Ein gescheiterter RDP mit Wireshark gesnifft sagt folgendes aus:
Bevor ich am Wochenende umgestellt habe, lief das VPN super, sowohl Einwahl als auf Routing absolut fehlerfrei.
Habt ihr eine Idee?
Vorab vielen Dank für eure Hilfe.
ich habe ein Problem mit einer PFSense im MultiWAN bei IPSec.
Folgender Aufbau ist gegeben:
Über die PFSense sind 2 WAN-Verbindungen per PPPoE realisiert, jeweils beide statische, öffentliche IP's. Die Clients fragen bei Aufbau der VPN-Verbindung eine Subdomain der TLD an (vpn.xyz.de), bei den DNS-Einträgen im Domainregistrar wurden jeweils ein A-Record pro öffentliche IP gesetzt, der Eintrag vpn.xyz.de hält also zwei IPv4 Adressen.
Die PFSense leitet die Anfragen dann auf einen RADIUS-Server um (Windows NPS), dieser erwartet dann zur Authentifizierung ein Zertifikat der Domänenzertifizierungsstelle für das VPN sowie das AD-Kennwort.
Dieses Wochenende habe ich die zwei WAN-Anschlüsse in eine Gateway Group gepackt, um das MultiWAN in Betrieb zu nehmen, was jedoch zu verschiedenen Problem beim VPN geführt hat:
Fragen die Clients unter vpn.xyz.de an und erhalten mittels DNS die öffentliche IP des Vodafone WAN's wird der Tunnel aufgebaut und die Verbindung ins VPN funktioniert, allerdings funktioniert beispielsweise RDP, also Remotedesktop auf einen Server nicht mehr, alle anderen Protokolle funktionieren jedoch. Fragen die Clients per DNS vpn.xyz.de an und erhalten die öffentliche IP des Telekom-WAN's wird der Tunnel mit der Fehlermeldung abgeschmettert, dass es einen Fehler in der Richtlinie gibt.
Hier einmal der aktuelle Aufbau der VPN-Config:
Hier die Gateway Group:
An den Firewallregeln kann es nicht liegen, diese sind unverändert geblieben und sollten das Problem mit dem Routing nicht auslösen können. Sind jetzt nicht mit angehangen, können aber nachgereicht werden.
Das Routing im LAN übernimmt ein Cisco C9200 im Stack, auf der PFSense sind statische Routen auf die VLAN's, die der C9200 hält konfiguriert.
Ein gescheiterter Versuch zur Authentifizierung beim VPN in den Logs auf das Telekom-WAN sieht übrigens so aus:
Es wird wohl anscheinend keine IKE config gefunden, diese existiert aber wie in den Screens zu sehen.
Ein gescheiterter RDP mit Wireshark gesnifft sagt folgendes aus:
Bevor ich am Wochenende umgestellt habe, lief das VPN super, sowohl Einwahl als auf Routing absolut fehlerfrei.
Habt ihr eine Idee?
Vorab vielen Dank für eure Hilfe.
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: 6075943290
Url: https://administrator.de/contentid/6075943290
Ausgedruckt am: 24.11.2024 um 17:11 Uhr
19 Kommentare
Neuester Kommentar
Hallo,
warum das VPN auf der GW-Gruppe? Die GW-Gruppe unterliegt einem ein Tiering, das davon unabhängig ist, auf welchem Anschluss ein Client die Verbindung aufbaut; für den Client hingegen kann es nur einen VPN-Endpunkt pro Sitzung geben. Ich hätte in dem Fall je eine Konfiguration pro Interface verwendet.
Grüße
Richard
warum das VPN auf der GW-Gruppe? Die GW-Gruppe unterliegt einem ein Tiering, das davon unabhängig ist, auf welchem Anschluss ein Client die Verbindung aufbaut; für den Client hingegen kann es nur einen VPN-Endpunkt pro Sitzung geben. Ich hätte in dem Fall je eine Konfiguration pro Interface verwendet.
Grüße
Richard
Vorab: Bitte lese dringenst die FAQs zum Einbetten von Bildern in einem Thread!!
Leider hast du das versäumt und die Bilder erscheinen völlig zusammenhangslos und wild durcheinandergewürfelt aus dem Kontext gerissen am Ende deines Threads. Kein Helfender kann damit etwas anfangen und es ist eine Qual das lesen zu müssen. Wenn man es denn überhaupt tut..
Nutze also intelligent das "+" um die Bilder sinnvoll und Kontext bezogen an die richtige Stelle im Text zu platzieren und somit eine Struktur in deinem Thread zu schaffen. Das hilft allen hier ungemein deine Fragestellung besser zu verstehen.
Man kann das übrigens immer mit dem "Bearbeiten" Knopf zu jeder Zeit auch nachträglich korrigieren!
FAQs lesen und verstehen hilft also immer! 😉
Zurück zum Thema...
Leider machst du im Text wenig Angaben zum verwendeten Protokoll. Nutzt du hier L2TP als VPN Protokoll.
Wenn IKEv2 ist das Zertifikat rein nur bezogen auf das Server Zertifikat oder arbeitest du auch mit Client Zertifikaten.
Bei Letzterem und Radius Authentisierung gibt es einiges zu beachten auf der pfSense oder OPNsense:
Mobile Clients mit Client Certificate authentifizieren
Beachten solltest du auch das du in der Server Zertifikatsgenerierung (IKEv2) bei den SANs dann ggf. beide IP Adressen zum FQDN mit angibst. Der Windows Client kannst sonst nur über den FQDN arbeiten und nicht mit den IPs.
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Bzw. Windows Client spezifisch auch hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Auch die L2TP IKEv1 Credentials müssen entsprechend genau gesetzt sein sofern dieses VPN Protokoll verwendet wird.
Leider hast du das versäumt und die Bilder erscheinen völlig zusammenhangslos und wild durcheinandergewürfelt aus dem Kontext gerissen am Ende deines Threads. Kein Helfender kann damit etwas anfangen und es ist eine Qual das lesen zu müssen. Wenn man es denn überhaupt tut..
Nutze also intelligent das "+" um die Bilder sinnvoll und Kontext bezogen an die richtige Stelle im Text zu platzieren und somit eine Struktur in deinem Thread zu schaffen. Das hilft allen hier ungemein deine Fragestellung besser zu verstehen.
Man kann das übrigens immer mit dem "Bearbeiten" Knopf zu jeder Zeit auch nachträglich korrigieren!
FAQs lesen und verstehen hilft also immer! 😉
Zurück zum Thema...
Leider machst du im Text wenig Angaben zum verwendeten Protokoll. Nutzt du hier L2TP als VPN Protokoll.
Wenn IKEv2 ist das Zertifikat rein nur bezogen auf das Server Zertifikat oder arbeitest du auch mit Client Zertifikaten.
Bei Letzterem und Radius Authentisierung gibt es einiges zu beachten auf der pfSense oder OPNsense:
Mobile Clients mit Client Certificate authentifizieren
Beachten solltest du auch das du in der Server Zertifikatsgenerierung (IKEv2) bei den SANs dann ggf. beide IP Adressen zum FQDN mit angibst. Der Windows Client kannst sonst nur über den FQDN arbeiten und nicht mit den IPs.
Ein gescheiterter Versuch zur Authentifizierung beim VPN in den Logs auf das Telekom-WAN sieht übrigens so aus:
Auch das Problem sieht man sofort!! no proposal choosen Hier hast du falsche Crypto Credentials konfiguriert! Das o.a. Tutorial geht für IKEv2 und beide Phases genau auf diese Settings ein!IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Bzw. Windows Client spezifisch auch hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Auch die L2TP IKEv1 Credentials müssen entsprechend genau gesetzt sein sofern dieses VPN Protokoll verwendet wird.
Ich hatte auch daran gedacht, jeweils einen Tunnel pro WAN zu bauen, wurde jedoch davon abgeschreckt, da die GUI in der PFSense bei einem zweiten P1 Tunnel zum Beispiel in den Authentifizierungsmethoden kein EAP-RADIUS oder EAP-TLS anbietet.
Riecht fast nach einer Limitierung der GUI, daher habe ich die Schnittstelle auf die GW-Gruppe gelegt. Hat jemand Erfahrung damit eventuell im Config File der PFSense einen zweiten P1-Tunnel manuell einzutragen?
Dann würde ich das probieren und hätte dann mit zwei P1 Tunneln jeweils auf dem einen WAN dann festgenagelt den besten Weg?
Riecht fast nach einer Limitierung der GUI, daher habe ich die Schnittstelle auf die GW-Gruppe gelegt. Hat jemand Erfahrung damit eventuell im Config File der PFSense einen zweiten P1-Tunnel manuell einzutragen?
Dann würde ich das probieren und hätte dann mit zwei P1 Tunneln jeweils auf dem einen WAN dann festgenagelt den besten Weg?
Hallo Aqui, das stimmt natürlich, habe es bearbeitet.
Es wird IKEv2 verwendet und sowohl Client- als auch Serverzertifikate, die von einer internen Unternehmens-PKI stammen.
Das mit dem angepassten Server-Zertifikat, dem ich beide IP's angebe, kann ich auch mal testen.
Hätten mir die falschen Crypto-Credentials nicht dann schon vorher auf die Füße fallen müssen? Die Probleme tauchten ja erst auf, seit ich die GW-Gruppe als Schnittstelle in der P1 verwende. Sofern ich auf dem Windows-Client ein ipconfig /flushdns absetze, funktioniert der Verbindungsaufbau fast immer direkt.
Die Probleme tauchen also insbesondere auf, wenn der Client über DNS vpn.xyz.de auflöst und dann vom DNS-Server des Domänenregistrars als Antwort die öffentliche IP des Telekom WAN's. Setze ich dann ein ipconfig /flushdns ab, wird in der Regel vpn.xyz.de auf die Vodafone WAN-IP aufgelöst. Danach klappt der Aufbau.
Setze ich in den Schnittstellen das Telekom-WAN statt der Gateway-Group, wird auch damit die Connection aufgebaut.
Es wird IKEv2 verwendet und sowohl Client- als auch Serverzertifikate, die von einer internen Unternehmens-PKI stammen.
Das mit dem angepassten Server-Zertifikat, dem ich beide IP's angebe, kann ich auch mal testen.
Hätten mir die falschen Crypto-Credentials nicht dann schon vorher auf die Füße fallen müssen? Die Probleme tauchten ja erst auf, seit ich die GW-Gruppe als Schnittstelle in der P1 verwende. Sofern ich auf dem Windows-Client ein ipconfig /flushdns absetze, funktioniert der Verbindungsaufbau fast immer direkt.
Die Probleme tauchen also insbesondere auf, wenn der Client über DNS vpn.xyz.de auflöst und dann vom DNS-Server des Domänenregistrars als Antwort die öffentliche IP des Telekom WAN's. Setze ich dann ein ipconfig /flushdns ab, wird in der Regel vpn.xyz.de auf die Vodafone WAN-IP aufgelöst. Danach klappt der Aufbau.
Setze ich in den Schnittstellen das Telekom-WAN statt der Gateway-Group, wird auch damit die Connection aufgebaut.
Zitat von @AK-47.2:
Ich hatte auch daran gedacht, jeweils einen Tunnel pro WAN zu bauen, wurde jedoch davon abgeschreckt, da die GUI in der PFSense bei einem zweiten P1 Tunnel zum Beispiel in den Authentifizierungsmethoden kein EAP-RADIUS oder EAP-TLS anbietet.
Ich hatte auch daran gedacht, jeweils einen Tunnel pro WAN zu bauen, wurde jedoch davon abgeschreckt, da die GUI in der PFSense bei einem zweiten P1 Tunnel zum Beispiel in den Authentifizierungsmethoden kein EAP-RADIUS oder EAP-TLS anbietet.
Stimmt, es gibt immer noch nur eine P1 für Client-VPN. Hatte ich vergessen. Aufgrund des Konfliktes zwischen dem Verhalten einer GW-Gruppe und dem gewünschten Verhalten bei Client-VPN auf mehreren Interfaces, habe ich Zweifel, ob das überhaupt funktioniert.
Was ich probieren würde: A-Record für eine IP löschen, und die verbleibende IP als einzige Tier 1 in der GW-Gruppe setzen. Auf dieser IP müssten dann ein VPN auf der GW-Gruppe funktionieren bzw. andere Fehlerquellen ausgeschlossen werden können.
Als kleines Update, ich habe am Wochenende etwas probiert. Das Zertifikat im P1 Tunnel wurde geupgradet, hier sind jetzt zusätzlich zum DNS-Namen vpn.xyz.de auch die statischen IP's der ISP's hinterlegt.
Leider nach wie vor kommt hier das Problem zum tragen, dass in diesem Konstrukt, sofern vpn.xyz.de auf die IP des Telekom-WAN's zeigt, bzw vom Client aufgelöst wird, in der Systemprotokollierung von IPSec in der pfSense eine fehlende IKE-Config bemängelt wird, sofern als Schnittstelle die Gateway-Group hinterlegt wird, die beide WAN's beinhaltet.
Stelle ich um auf die WAN-Schnittstelle der Telekom, wird ohne Probleme der Tunnel gebaut. Mein nächster Ansatz wird der Tipp von C.R.S sein, allerdings habe ich die Doku der pfSense so verstanden, dass auch mein Konstrukt laufen sollte
Leider nach wie vor kommt hier das Problem zum tragen, dass in diesem Konstrukt, sofern vpn.xyz.de auf die IP des Telekom-WAN's zeigt, bzw vom Client aufgelöst wird, in der Systemprotokollierung von IPSec in der pfSense eine fehlende IKE-Config bemängelt wird, sofern als Schnittstelle die Gateway-Group hinterlegt wird, die beide WAN's beinhaltet.
Stelle ich um auf die WAN-Schnittstelle der Telekom, wird ohne Probleme der Tunnel gebaut. Mein nächster Ansatz wird der Tipp von C.R.S sein, allerdings habe ich die Doku der pfSense so verstanden, dass auch mein Konstrukt laufen sollte
in der pfSense eine fehlende IKE-Config bemängelt wird
Kann ja eigentlich nicht sein wenn der DNS auf die WAN IP dieser FW auflöst. Zeugt eher von einer fehlerhaften IPsec Konfig dort?!Wenn du mit IKEv2 arbeitest musst du aufpassen das auch der FQDN korrekt als SAN im Zertifikat angegeben ist.
Für mich erschließt sich dann aber nicht, wieso der Tunnel aufgebaut wird, wenn ich die Gateway Gruppe als Schnittstelle mit der WAN-Telekom Schnittstelle tausche. Wenn die IKE-Config fehlerhaft wäre, müsste ich hierbei doch auch eine entsprechende Fehlermeldung erhalten. Der FQDN ist als SAN im Zertifikat korrekt abgebildet.
Was ebenfalls auffällig ist: Die WAN-IP des Vodafone-Anschlusses scheint priorisiert zu sein, ich stelle mir die Frage wieso in der Gateway Group als Schnittstelle in der P1 nicht der Telekom-Anschluss priorisiert wird und dann beispielsweise bei Aufbau einer VPN-Verbindung des Clients und Auflösen des DNS vpn.xyz.de auf die Vodafone WAN-IP eine solche Fehlermeldung erscheint.
Vielleicht komme ich der Lösung näher, wenn ich dies mal zu erzwingen versuche
Was ebenfalls auffällig ist: Die WAN-IP des Vodafone-Anschlusses scheint priorisiert zu sein, ich stelle mir die Frage wieso in der Gateway Group als Schnittstelle in der P1 nicht der Telekom-Anschluss priorisiert wird und dann beispielsweise bei Aufbau einer VPN-Verbindung des Clients und Auflösen des DNS vpn.xyz.de auf die Vodafone WAN-IP eine solche Fehlermeldung erscheint.
Vielleicht komme ich der Lösung näher, wenn ich dies mal zu erzwingen versuche
Die WAN-IP des Vodafone-Anschlusses scheint priorisiert zu sein
Das kann eigentlich nicht sein. Normalerweise macht die FW ein Round Robin Balancing sofern nicht anders customized. Aber das gilt ja nur für IP Sessions die von inbound (lokales LAN) nach outbound (Internet) gehen.Von extern sprichst du aber ja immer direkt die physische WAN IP der Firewall an und damit antwortet die Firewall auch zwingend dem Client immer mit genau dieser IP. Sie darf schon vom Standard her gar nicht mit der jeweils anderen IP antworten, denn dann würde es sofort zu einem Sessionabbruch beim VPN Client kommen wenn der im Antwortpaket mit einmal eine andere IP "sieht" als die die er angesprochen hat.
In sofern kann es also niemals sowas wie eine "Priorisierung" aus Sicht des externen Clients geben.
Testhalber kannst du vom VPN Client ja einmal die dedizierte IP ansprechen ohne über den DNS zu gehen. Der VPN Test kann wegen NAT Hairpinning auch nur immer von extern gemacht werden nie aus dem lokalen LAN. Nur das du das auch auf dem Radar hast.
Zitat von @AK-47.2:
Stelle ich um auf die WAN-Schnittstelle der Telekom, wird ohne Probleme der Tunnel gebaut. Mein nächster Ansatz wird der Tipp von C.R.S sein, allerdings habe ich die Doku der pfSense so verstanden, dass auch mein Konstrukt laufen sollte
Stelle ich um auf die WAN-Schnittstelle der Telekom, wird ohne Probleme der Tunnel gebaut. Mein nächster Ansatz wird der Tipp von C.R.S sein, allerdings habe ich die Doku der pfSense so verstanden, dass auch mein Konstrukt laufen sollte
Na ja, die Doku enthielt schon immer dieses gleichgewichtete Gateway-Grouping, das aufgrund der FreeBSD-Limitation vor der kommenden CE 2.7.0 etwas fragwürdig war: https://redmine.pfsense.org/issues/9544
Die pfSense kann ausgehenden Traffic schon auf zwei Gateways verteilen. Aber zur Quell-IP eines einkommenden Requests hat sie genau eine gültige Route, die unabhängig davon ist, auf welcher Schnittstelle der Request ankommt (ausgenommen natürlich anliegende Netze).
Wenn Du deine GW-Gruppe auf ein Mitglied reduzierst und nur das übers DNS veröffentlichst, bestätigt das zumindest, ob der grundlegende Konfigurationsansatz funktioniert. Wenn ja, könnte das Vorhaben mit der 2.7.0 oder der aktuellen pfSense+ funktionieren.
Der externe Client spricht ja aber immer die physische WAN Port IP der FW an und laut TCP/IP Standard muss das Endgerät auch immer mit dieser IP antworten. Hier darf es niemals zu einem Balancing kommen. Kann es auch gar nicht.
Wenn WAN-1 die 1.1.1.1 hat und WAN-2 die 2.2.2.2 und ein externer Client spricht die 1.1.1.1 an kommt auch das Antwortpaket IMMER mit einer 1.1.1.1 Absender IP zurück bei ihm an und niemals mit der 2.2.2.2.
Wäre das der Fall bricht der Client die Session sofort ab. Insofern kann das nicht das Argument sein.
Das Verhalten lässt sich auch wasserdicht belegen wenn man es mit einem Wireshark am Client mitverfolgt.
Alles andere wäre ein Verstoß gegen den TCP/IP Standard.
Wenn WAN-1 die 1.1.1.1 hat und WAN-2 die 2.2.2.2 und ein externer Client spricht die 1.1.1.1 an kommt auch das Antwortpaket IMMER mit einer 1.1.1.1 Absender IP zurück bei ihm an und niemals mit der 2.2.2.2.
Wäre das der Fall bricht der Client die Session sofort ab. Insofern kann das nicht das Argument sein.
Das Verhalten lässt sich auch wasserdicht belegen wenn man es mit einem Wireshark am Client mitverfolgt.
Alles andere wäre ein Verstoß gegen den TCP/IP Standard.
Zitat von @aqui:
Der externe Client spricht ja aber immer die physische WAN Port IP der FW an und laut TCP/IP Standard muss das Endgerät auch immer mit dieser IP antworten. Hier darf es niemals zu einem Balancing kommen. Kann es auch gar nicht.
Der externe Client spricht ja aber immer die physische WAN Port IP der FW an und laut TCP/IP Standard muss das Endgerät auch immer mit dieser IP antworten. Hier darf es niemals zu einem Balancing kommen. Kann es auch gar nicht.
...wenn die P1en auf dem jeweiligen Interface liegen. Also redundante S2S-Verbindungen über mehrere WAN-Links funktionieren. Aber mit dem Binding auf einer GW-Gruppe sagt man der pfSense eigentlich gerade das Gegenteil.
Das spielt aber für ein Client VPN keinerlei Rolle da ja die Tunnelendpunkte immer nur die physische WAN IP und die IP des Clients sind.
Also mal ein Update:
Neues Serverzertifikat für das VPN eingebunden mit beiden Adressen -> gleicher Fehler
Zertifikat mit beiden statischen WAN-Adressen eingebunden -> gleicher Fehler
Die Schnittstelle im IPSec auf die Gateway Group in der die Telekom Tier 1 und Vodafone Tier 2 ist -> löst der Client vpn.xyc.de auf die Vodafone WAN IP auf, so wird die IKE Config nun auf der Telekom WAN-IP gefunden und die Verbindung wird aufgebaut. Trenne ich die Verbindung und sorge mit ipconfig /flushdns dafür, dass irgendwann mal auf die Vodafone WAN-IP aufgelöst passiert der gleiche Fehler nun wird jetzt für die Vodafone WAN-IP keine IKE Config mehr gefunden.
Dann habe ich mal den DNS Eintrag vpn.xyz.de, der auf die WAN-IP von Vodafone zeigt gelöscht und die Schnittstelle wieder auf die Gateway Gruppe gelegt, auf der beide Tier1 sind. Der Client löst jetzt natürlich nur noch auf die WAN-IP von Telekom auf: Jetzt wird der Client abgeschmettert mit der Fehlermeldung es würde keine IKE Config für den WAN-IP Anschluss der Telekom IP gefunden werden.
Danach habe ich die Schnittstelle mal nicht auf eine Gateway Group gelegt sondern auf das Telekom WAN. Hier dürfte jetzt ja eigentlich kein Problem mehr auftreten. Dies konnte ich auch bestätigen, es gibt keine Probleme.
Danach probiere ich testweise die Schnittstelle mit der Gateway Group, Telekom WAn ist Tier 1 und Vodafone WAn Tier 2. Hier ebenfalls keine Probleme, aus der Logik heraus überrascht dies nicht, sonst hätte ich etwas falsch konfiguriert.
Fällt euch noch etwas ein, was ich probieren könnte oder falsch gemacht haben kann?
Ansonsten muss ich mich wohl vorerst vom Redundanz Gedanken, was IPSec betrifft auf der pfSense verabschieden.
Danke euch im Voraus.
Neues Serverzertifikat für das VPN eingebunden mit beiden Adressen -> gleicher Fehler
Zertifikat mit beiden statischen WAN-Adressen eingebunden -> gleicher Fehler
Die Schnittstelle im IPSec auf die Gateway Group in der die Telekom Tier 1 und Vodafone Tier 2 ist -> löst der Client vpn.xyc.de auf die Vodafone WAN IP auf, so wird die IKE Config nun auf der Telekom WAN-IP gefunden und die Verbindung wird aufgebaut. Trenne ich die Verbindung und sorge mit ipconfig /flushdns dafür, dass irgendwann mal auf die Vodafone WAN-IP aufgelöst passiert der gleiche Fehler nun wird jetzt für die Vodafone WAN-IP keine IKE Config mehr gefunden.
Dann habe ich mal den DNS Eintrag vpn.xyz.de, der auf die WAN-IP von Vodafone zeigt gelöscht und die Schnittstelle wieder auf die Gateway Gruppe gelegt, auf der beide Tier1 sind. Der Client löst jetzt natürlich nur noch auf die WAN-IP von Telekom auf: Jetzt wird der Client abgeschmettert mit der Fehlermeldung es würde keine IKE Config für den WAN-IP Anschluss der Telekom IP gefunden werden.
Danach habe ich die Schnittstelle mal nicht auf eine Gateway Group gelegt sondern auf das Telekom WAN. Hier dürfte jetzt ja eigentlich kein Problem mehr auftreten. Dies konnte ich auch bestätigen, es gibt keine Probleme.
Danach probiere ich testweise die Schnittstelle mit der Gateway Group, Telekom WAn ist Tier 1 und Vodafone WAn Tier 2. Hier ebenfalls keine Probleme, aus der Logik heraus überrascht dies nicht, sonst hätte ich etwas falsch konfiguriert.
Fällt euch noch etwas ein, was ich probieren könnte oder falsch gemacht haben kann?
Ansonsten muss ich mich wohl vorerst vom Redundanz Gedanken, was IPSec betrifft auf der pfSense verabschieden.
Danke euch im Voraus.
Selbst in der offiziellen Netgate Doku steht das IPsec fehlerfrei mit Multi WAN Setups funktioniert:
https://docs.netgate.com/pfsense/en/latest/multiwan/ipsec.html
Irgendwas muss als an deinem Setup noch falsch sein, denn sonst würde Netgate das so ja nicht bestätigen?!
https://docs.netgate.com/pfsense/en/latest/multiwan/ipsec.html
Irgendwas muss als an deinem Setup noch falsch sein, denn sonst würde Netgate das so ja nicht bestätigen?!
Das hatte ich ja hier auch geschrieben, da ich es gelesen habe. Ich poste morgen einfach nochmal die Config mit allen wichtigen Einstellungen sauber rein. Vielleicht siehst du ja etwas, was ich übersehe. Muss doch zu schaffen sein
Erreicht nicht ganz das Ziel, aber fast: IPsec auf eine Failover-Gateway-Gruppe legen und das DNS nicht mit zwei A-Records, sondern mit Azure Traffic Manager oder AWS Route 53 mit Tiering analog zur Failover-Gruppe managen. Damit kann das DNS dem Gateway-Failover folgen.
Zitat von @aqui:
Selbst in der offiziellen Netgate Doku steht das IPsec fehlerfrei mit Multi WAN Setups funktioniert:
https://docs.netgate.com/pfsense/en/latest/multiwan/ipsec.html
Selbst in der offiziellen Netgate Doku steht das IPsec fehlerfrei mit Multi WAN Setups funktioniert:
https://docs.netgate.com/pfsense/en/latest/multiwan/ipsec.html
Das widerspricht den Beobachtungen ja nicht, insbesondere ist nur die Rede von Failover-Szenarien. Das beschriebene DynDNS über dieselbe Failover-Gruppe ist auch eleganter als das externe Probing mit Traffic Manager o.ä.
Hi,
ich würde mal probieren auf dem pfSense unter System -> Advanced -> Firewall & NAT -> IP Fragment Reassemble aktivieren.
Und ggf. Maximum MSS mit ca. 1350 bytes. Um die richtige Größe zu finden, müsste man das individuell testen.
Bei mir hat das oft geholfen, mit nicht aufbauenden RDP, TeamViewer oder SMB Verbindungen, obwohl HTTP/S und ICMP dauerhaft funktioniert haben.
Vor allem bei Verbindungen zu Lancom Geräten.
Viele Grüße
Mario
ich würde mal probieren auf dem pfSense unter System -> Advanced -> Firewall & NAT -> IP Fragment Reassemble aktivieren.
Und ggf. Maximum MSS mit ca. 1350 bytes. Um die richtige Größe zu finden, müsste man das individuell testen.
Bei mir hat das oft geholfen, mit nicht aufbauenden RDP, TeamViewer oder SMB Verbindungen, obwohl HTTP/S und ICMP dauerhaft funktioniert haben.
Vor allem bei Verbindungen zu Lancom Geräten.
Viele Grüße
Mario
1
