18
PPTP Verbindung nicht zu jedem ext. Server möglich
Moin,
ich habe ein etwas merkwürdiges Phänomen bzgl. PPTP VPN Verbindungen.
Wir nutzen eine PFSense Firewall und wollen aus unserem Netz End-To-Side VPN Verbindungen zu anderen Servern aufbauen.
Im eigenen Netz werkelt ein PPTP Server und über PFSense wird OpenVPN zur Verfügung gestellt.
Der Zugriff von extern via PPTP und OpenVPN funktioniert.
Der Zugriff von intern zu externen IPSec oder PPTP Gegenstellen funktioniert ebenfalls. - Bis auf eine Ausnahme:
Bei dem Verbindungsaufbau zu einem PPTP Server bleibt die Windows-Routine bei "Benutzername und Kennwort werden überprüft..." mit dem "Fehler 619: Es konnte keine Verbindung mit dem Remotecomputer hergestellt werden, sodass der für diese Verbindung verwendete Port geschlossen wurde." stehen.
Außerhalb des Firmennetzes und vor der Einführung der PFSense war/ist der Zugriff von Windows-Clients auf dieses VPN Netz problemlos möglich. Es muss also etwas mit der PFSense Firewall zutun haben.
Im Internet bin ich schon auf Hinweise gestoßen, dass PFSense maximal eine Verbindung pro PPTP VPN Server zulässt. Das ist in diesem Fall gegeben, und diese Restriktion sollte nicht greifen.
Auch "Any"-Regeln auf WAN und LAN Adapter der Firewall bringen nichts. Da PPTP VPNs zu anderen Servern kein Problem darstellen, denke ich, dass das Regelwerk für GRE, 1723/UDP und 500/UDP korrekt konfiguriert ist.
An der VPN Gegenstelle können wir nichts verändern.
Die IP-Netze sind unterschiedlich: Eigenes: 172.17.10.0/24; Extern: 192.168.0.0/24.
Verraten eure Glaskugeln evtl. mehr als meine? An welchen Schrauben könnte man noch drehen?
ich habe ein etwas merkwürdiges Phänomen bzgl. PPTP VPN Verbindungen.
Wir nutzen eine PFSense Firewall und wollen aus unserem Netz End-To-Side VPN Verbindungen zu anderen Servern aufbauen.
Im eigenen Netz werkelt ein PPTP Server und über PFSense wird OpenVPN zur Verfügung gestellt.
Der Zugriff von extern via PPTP und OpenVPN funktioniert.
Der Zugriff von intern zu externen IPSec oder PPTP Gegenstellen funktioniert ebenfalls. - Bis auf eine Ausnahme:
Bei dem Verbindungsaufbau zu einem PPTP Server bleibt die Windows-Routine bei "Benutzername und Kennwort werden überprüft..." mit dem "Fehler 619: Es konnte keine Verbindung mit dem Remotecomputer hergestellt werden, sodass der für diese Verbindung verwendete Port geschlossen wurde." stehen.
Außerhalb des Firmennetzes und vor der Einführung der PFSense war/ist der Zugriff von Windows-Clients auf dieses VPN Netz problemlos möglich. Es muss also etwas mit der PFSense Firewall zutun haben.
Im Internet bin ich schon auf Hinweise gestoßen, dass PFSense maximal eine Verbindung pro PPTP VPN Server zulässt. Das ist in diesem Fall gegeben, und diese Restriktion sollte nicht greifen.
Auch "Any"-Regeln auf WAN und LAN Adapter der Firewall bringen nichts. Da PPTP VPNs zu anderen Servern kein Problem darstellen, denke ich, dass das Regelwerk für GRE, 1723/UDP und 500/UDP korrekt konfiguriert ist.
An der VPN Gegenstelle können wir nichts verändern.
Die IP-Netze sind unterschiedlich: Eigenes: 172.17.10.0/24; Extern: 192.168.0.0/24.
Verraten eure Glaskugeln evtl. mehr als meine? An welchen Schrauben könnte man noch drehen?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 253668
Url: https://administrator.de/forum/pptp-verbindung-nicht-zu-jedem-ext-server-moeglich-253668.html
Ausgedruckt am: 09.04.2025 um 02:04 Uhr
18 Kommentare
Neuester Kommentar
Bei dem Verbindungsaufbau zu einem PPTP Server bleibt die Windows-Routine bei "Benutzername und Kennwort werden überprüft..." mit dem "Fehler 619: Es konnte keine Verbindung mit dem Remotecomputer hergestellt werden, sodass der für diese Verbindung verwendete Port geschlossen wurde." stehen.
Das ist ein klassisches Problem !Der Fehler liegt mit 99% Sicherheit nicht an deinem Netzwerk, denn wäre das der Fall würde PPTP gar nicht gehen. Das mit wenigen Ausnahmen alle Server erreicht werden beweist das eindeutig.
Problem ist in der Regel immer das diese Zielserver hinter einer Firewall und/oder einem NAT Router liegen und dort wie leider sehr oft vergessen wurde das GRE Protokoll zu forwarden.
PPTP besteht wie der Netzwerker weiss aus einer TCP 1723 Session und aus dem GRE Protokoll, wobei GRE keine Ports hat sondern mit der IP Protokoll Nummer 47 ein eigenständiges IP Protokoll ist (Generic Route Encapsulation)
Ohne GRE kommt die PPTP Verbindung aber nicht zustande mit exakt den gleichen Symptomen wie bei dir !
UDP 500 ist übrigens ziemlicher Blödsinn, denn das hat mit PPTP nichts zu tun. Allein IPsec VPNs verwenden UDP 500
Genauso blödsinnig ist UDP 1723. PPTP verwendet rein TCP 1723 !! Wenn du das mit UDP statt TCP gemacht hast ist klar das das in die Hose geht ?!
Ein Wireshark Trace am Zielsystem würde dir letzte Gewissheit geben.
Alle Grundlagen zu dem Thema findest du in diesem Forums Tutorial:
VPNs einrichten mit PPTP
Besonders das solltest du dazu lesen:
http://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...
Hey, vielen Dank schon einmal für deine Hinweise.
Das mit 1723/UDP ist natürlich Blödsinn und auch nur ein Verschreiber meinerseits gewesen. Es ist 1723/TCP freigegeben. Sonst würden ja die PPTP Verbindungen zu den anderen Servern nicht zu Stande gekommen.
Sollte es ein Problem auf der Ziel Seite sein, könnte man aber doch auch aus anderen Netzen keine Verbindung dahin aufbauen, was aber wunderbar funktioniert.
Das mit 1723/UDP ist natürlich Blödsinn und auch nur ein Verschreiber meinerseits gewesen. Es ist 1723/TCP freigegeben. Sonst würden ja die PPTP Verbindungen zu den anderen Servern nicht zu Stande gekommen.
Sollte es ein Problem auf der Ziel Seite sein, könnte man aber doch auch aus anderen Netzen keine Verbindung dahin aufbauen, was aber wunderbar funktioniert.
könnte man aber doch auch aus anderen Netzen keine Verbindung dahin aufbauen, was aber wunderbar funktioniert.
Das ist in der Tat sehr komisch. Legt den Verdacht nahe das diese Pakete oder Teile davon auf diesem Pfad irgendwo gefiltert werden ?!Nimm dir am besten einen Wireshark oder nimm die Capture Funktion der pfSense und sniffer den PPTP Verbindungsaufbau mit. Da wird dann recht schnell klar wo das Problem liegt...
Ich habe hier einmal einen Ausschnitt aus Wireshark.
Zu sehen ist einmal der fehlgeschlagene PPTP Aufbau (keine Antwort auf das "Configuration Request"-Paket) und kurze Zeit später ein korrekt aufgebauter Tunnel zu einem anderen Server.
Mich irritiert unter anderem, dass bei dem fehlgeschlagenen Versuch viele PPTP Pakete noch einmal bestätigt werden. Beim zweiten Versuch erhält lediglich das "Set-Link-Info"-Paket etwas später einen ACK.
Hier ein Paket, abgefangen in der PFSense. Handelt es sich hier um die Antwort auf die "Configuration Request"-Pakete? Es wird das Flag "ack present" übertragen.
Da dieses Paket nicht in Wireshark auftaucht, wird es wohl auch nicht an die 172.17.1.81 weitergeleitet.
Aber warum nicht??!
Zu sehen ist einmal der fehlgeschlagene PPTP Aufbau (keine Antwort auf das "Configuration Request"-Paket) und kurze Zeit später ein korrekt aufgebauter Tunnel zu einem anderen Server.
Mich irritiert unter anderem, dass bei dem fehlgeschlagenen Versuch viele PPTP Pakete noch einmal bestätigt werden. Beim zweiten Versuch erhält lediglich das "Set-Link-Info"-Paket etwas später einen ACK.
Hier ein Paket, abgefangen in der PFSense. Handelt es sich hier um die Antwort auf die "Configuration Request"-Pakete? Es wird das Flag "ack present" übertragen.
23:03:42.570915 AF IPv4 (2), length 61: (tos 0x0, ttl 127, id 10775, offset 0, flags [none], proto GRE (47), length 57)
172.17.1.81 > 84.128.xxx.xxx: GREv1, Flags [key present, sequence# present], call 13279, seq 7, proto PPP (0x880b), length 37
LCP (0xc021), length 25: LCP, Conf-Request (0x01), id 7, length 23
encoded length 21 (=Option(s) length 17)
0x0000: c021 0107 0015
MRU Option (0x01), length 4: 1400
0x0000: 0578
Magic-Num Option (0x05), length 6: 0x55d75c44
0x0000: 55d7 5c44
PFC Option (0x07), length 2:
ACFC Option (0x08), length 2:
Call-Back Option (0x0d), length 3: Callback Operation CBCP (6)
0x0000: 06
23:03:44.578192 AF IPv4 (2), length 69: (tos 0x0, ttl 250, id 39995, offset 0, flags [none], proto GRE (47), length 65)
84.128.xxx.yyy > 217.7.xxx.yyy: GREv1, Flags [key present, sequence# present, ack present], call 2189, seq 10, ack 0, proto PPP (0x880b), length 45
LCP (0xc021), length 29: LCP, Conf-Request (0x01), id 1, length 27
encoded length 25 (=Option(s) length 21)
0x0000: c021 0101 0019
ACCM Option (0x02), length 6: 0x00000000
0x0000: 0000 0000
Auth-Prot Option (0x03), length 5: CHAP, MS-CHAPv2
0x0000: c223 81
Magic-Num Option (0x05), length 6: 0x7e0143a9
0x0000: 7e01 43a9
PFC Option (0x07), length 2:
ACFC Option (0x08), length 2:
Da dieses Paket nicht in Wireshark auftaucht, wird es wohl auch nicht an die 172.17.1.81 weitergeleitet.
Aber warum nicht??!
Inspiriert von dem Post
habe ich in der Firewall ein Portforwarding für GRE zu der 172.17.1.81 eingerichtet und schon kommt die Verbindung zustande.
Aber das kann es doch nicht sein? Ich kann doch nicht für jeden PC, der gerne einen VPN Tunnel aufbauen möchte, temporär eine Weiterleitung einrichten.
Die andere PPTP Verbindung zeigt sich von den NAT-Klimmzügen übrigens unbeeindruckt. Der Tunnel wird aufgebaut, egal ob GRE zu diesem PC weitergeleitet wird, oder zu einem anderen.
Zitat von @aqui:
Ein lokaler VPN PPTP Client schickt einen Request los an der server und der versucht dann einen GRE tunnel aufzubauen. Du bekommst
also eine eingehenden GRE Verbindung ohne das eine interne besteht und das blockt natürlich die NAT firewall wie sie soll.
In der pfsense musst du also zuerst GRE auf die WAn IP erluaben und dann ein Port forwarding auf die lokale Client IP machen, dann
klappt das sofort.
Ein lokaler VPN PPTP Client schickt einen Request los an der server und der versucht dann einen GRE tunnel aufzubauen. Du bekommst
also eine eingehenden GRE Verbindung ohne das eine interne besteht und das blockt natürlich die NAT firewall wie sie soll.
In der pfsense musst du also zuerst GRE auf die WAn IP erluaben und dann ein Port forwarding auf die lokale Client IP machen, dann
klappt das sofort.
habe ich in der Firewall ein Portforwarding für GRE zu der 172.17.1.81 eingerichtet und schon kommt die Verbindung zustande.
Aber das kann es doch nicht sein? Ich kann doch nicht für jeden PC, der gerne einen VPN Tunnel aufbauen möchte, temporär eine Weiterleitung einrichten.
Die andere PPTP Verbindung zeigt sich von den NAT-Klimmzügen übrigens unbeeindruckt. Der Tunnel wird aufgebaut, egal ob GRE zu diesem PC weitergeleitet wird, oder zu einem anderen.
habe ich in der Firewall ein Portforwarding für GRE zu der 172.17.1.81 eingerichtet und schon kommt die Verbindung zustande.
Wie vermutet.....!! Irgendwo wurde was geblockt.Ich kann doch nicht für jeden PC, der gerne einen VPN Tunnel aufbauen möchte, temporär eine Weiterleitung einrichten.
Nein, natürlich nicht ! Das ist auch nicht der Sinn der Sache. Intelligente Firewall Firmware hat ein sog. Passthrough Feature aktiv für PPTP das alle GRE Sessions cacht und automatisch dafür ein Forwarding einrichtet wenn eine outbound Verbindung initiiert wird.Oft sieht man das an billigen Routern die diese Funktion nur sehr rudimentär implementiert haben, die machen dieses Caching für gerade mal eine einzige PPTP Session. Alle anderen gehen nicht mehr durch. Löscht man die eine kommen auch andere durch aber immer nur einer.
Eine bekannte Krankheit bei Billigprodukten im Router Umfeld. meist bei den billigen Zwangsroutern die von Providern verschenkt werden...da darfs ja nix kosten und das Gros der Anwender braucht das auch nicht.
Entweder musst du das also noch in deiner Firewall aktivieren oder einen Firmware Upgrade machen sofern sie das generell nicht supporten sollte !
Wenn es aber eine "richtige" Firewall ist wird sie das natürlich können. Es reicht in der Regel wenn man den GRE Zugang auf die öffentliche WAN IP der Firewall erlaubt. Durch das NAT was die ja in der Regel macht sieht das Ziel ja die WAN IP als Absender der PPTP Pakete.
Alles in allem also ein Bug oder Konfig Fehler deiner Firewall !
Vielen Dank für deine Unterstützung. Dieses "in die richtige Richtung stupsen" deinerseits ist genau der richtige Ansatz.
Es ist eine pfSense 2.1.5 verbaut.
Ist er richtig, dass mein Szenario ohne zweite WAN-IP gar nicht funktionieren kann?
Connect to a remote PPTP server when you have the pfSense PPTP server enabled
What are the limitations of PPTP in pfSense
Aktuell ist im PPTP-Menü der pfSense eine Umleitung auf den PPTP Server im eigenen Haus hinterlegt.
Für GRE und 1723/TCP gibt es im WAN und LAN Interface eine Firewallfreigabe.
Mit dieser Konfiguration hat es, bis auf diesen einen PPTP Ausreißer, gut funktioniert.
Seit gestern ist zusätzlich GRE als NAT-Regel zu einem PC weitergeleitet, so dass auch besagter VPN Tunnel zustande kommt.
Mit welcher Konfiguration kann man diese NAT-Regel durch etwas globales ablösen?
Zitat von @aqui:
Nein, natürlich nicht ! Das ist auch nicht der Sinn der Sache. Intelligente Firewall Firmware hat ein sog. Passthrough
Feature aktiv für PPTP das alle GRE Sessions cacht und automatisch dafür ein Forwarding einrichtet wenn eine outbound
Verbindung initiiert wird.
Nein, natürlich nicht ! Das ist auch nicht der Sinn der Sache. Intelligente Firewall Firmware hat ein sog. Passthrough
Feature aktiv für PPTP das alle GRE Sessions cacht und automatisch dafür ein Forwarding einrichtet wenn eine outbound
Verbindung initiiert wird.
Entweder musst du das also noch in deiner Firewall aktivieren oder einen Firmware Upgrade machen sofern sie das generell nicht
supporten sollte !
Wenn es aber eine "richtige" Firewall ist wird sie das natürlich können. Es reicht in der Regel wenn man den
GRE Zugang auf die öffentliche WAN IP der Firewall erlaubt. Durch das NAT was die ja in der Regel macht sieht das Ziel ja die
WAN IP als Absender der PPTP Pakete.
Alles in allem also ein Bug oder Konfig Fehler deiner Firewall !
supporten sollte !
Wenn es aber eine "richtige" Firewall ist wird sie das natürlich können. Es reicht in der Regel wenn man den
GRE Zugang auf die öffentliche WAN IP der Firewall erlaubt. Durch das NAT was die ja in der Regel macht sieht das Ziel ja die
WAN IP als Absender der PPTP Pakete.
Alles in allem also ein Bug oder Konfig Fehler deiner Firewall !
Es ist eine pfSense 2.1.5 verbaut.
Ist er richtig, dass mein Szenario ohne zweite WAN-IP gar nicht funktionieren kann?
Connect to a remote PPTP server when you have the pfSense PPTP server enabled
What are the limitations of PPTP in pfSense
Outbound PPTP with PPTP Server Enabled
Also, there is a pf limitation that stops any outbound PPTP connections from working if the PPTP Server on pfSense is enabled. This is a known issue with no simple work around. It may be possible to direct traffic bound for a specific remote PPTP server out a secondary WAN.
Also, there is a pf limitation that stops any outbound PPTP connections from working if the PPTP Server on pfSense is enabled. This is a known issue with no simple work around. It may be possible to direct traffic bound for a specific remote PPTP server out a secondary WAN.
Aktuell ist im PPTP-Menü der pfSense eine Umleitung auf den PPTP Server im eigenen Haus hinterlegt.
Für GRE und 1723/TCP gibt es im WAN und LAN Interface eine Firewallfreigabe.
Mit dieser Konfiguration hat es, bis auf diesen einen PPTP Ausreißer, gut funktioniert.
Seit gestern ist zusätzlich GRE als NAT-Regel zu einem PC weitergeleitet, so dass auch besagter VPN Tunnel zustande kommt.
Mit welcher Konfiguration kann man diese NAT-Regel durch etwas globales ablösen?
Es ist eine pfSense 2.1.5 verbaut.
Oooops ! 
Damit gibts aber in der Regel keinen Stress !! Selbst wasserdicht getestet !
Also, there is a pf limitation that stops any outbound PPTP connections from working if the PPTP Server on pfSense is enabled.
Ja das stimmt !Eine Firewall kann niemals selber PPTP Server sein und PPTP Passthrough aktiviert haben. Das kann kein Gerät der Welt !
Wie auch ?? Denn wie sollte die Firewall bzw. der aktive PPTP Server erkennen ob das PPTP Paket was reinkommt nun für ihn selber ist oder ob er das forwarden soll an ein lokales Endgerät (Client). Die Pakete sind ja nicht angemalt rot oder grün....das kann logischerweise nicht gehen, klar !
Entweder oder also...
Aber wie verhält es sich denn in meinem Fall: In der pfSense ist im PPTP Menü die Weiterleitung zum PPTP Server im eigenen Netz hinterlegt.
-> Wirkt sich das prinzipiell erstmal nicht nachteilig aus?
-> Wirkt sich das prinzipiell erstmal nicht nachteilig aus?
Das ist Unsinn, denn die Weiterleitung greift nicht bzw. ist total überflüssig.
Die pfSense antowrtet ja immer auf PPTP Pakete selber an allen ihren IP Adressen. Eine Weiterleitung ist damit dann natürlich Blödsinn wie dir sicherlich einleuchten wird.
Du musst nur in den regeln erlauben das PPTP (also TCP 1723 und GRE) Zugriff auf die WAN IP der pfSense erlaubt ist und gut iss !!
Eien Weiterleitung ist nur für Clients gedacht...in deinem Falle also überflüssig das PPTP Passthrough und PPTP Server eben NICHT koexistieren können auf einem Gerät !
Die pfSense antowrtet ja immer auf PPTP Pakete selber an allen ihren IP Adressen. Eine Weiterleitung ist damit dann natürlich Blödsinn wie dir sicherlich einleuchten wird.
Du musst nur in den regeln erlauben das PPTP (also TCP 1723 und GRE) Zugriff auf die WAN IP der pfSense erlaubt ist und gut iss !!
Eien Weiterleitung ist nur für Clients gedacht...in deinem Falle also überflüssig das PPTP Passthrough und PPTP Server eben NICHT koexistieren können auf einem Gerät !
Moin. Ich glaube, dass wir gerade aneinander vorbei reden.
Die pfSense ist kein PPTP Server. PPTP wird von einem Windows Server im eigenen Netz bereitgestellt.
Die pfSense ist so konfiguriert, dass die VPN Anfragem von extern an diesen Server durchgereicht werden.
Die pfSense ist kein PPTP Server. PPTP wird von einem Windows Server im eigenen Netz bereitgestellt.
Die pfSense ist so konfiguriert, dass die VPN Anfragem von extern an diesen Server durchgereicht werden.
Die pfSense ist so konfiguriert, dass die VPN Anfragem von extern an diesen Server durchgereicht werden.
Ahhh, ok ja dann haben wir aneinander vorbeigeredet !Wenn das der Fall ist ist das kein Thema, klar ! Dann funktioniert das fehlerfrei.
Da die pfSense NAT macht musst du 2 Schitte in den ToDos machen.
- Einmal an den WAN Port Firewall Regeln externen Zugriff von TCP 1723 und GRE auf die WAN IP Address erlauben. Die WAN IP Adresse ist ja hier quasi der "Zielhost" für die PPTP Clients
- Dann eine NAT Forwarding Regel auf die interne lokale IP Adresse für diese Ports TCP 1723 und GRE einrichten.
Sollte vor dem pfSense WAN Port noch ein weiterer NAT Router sein oder ein anderes NAT Device muss hier natürlich auch ein Passthrough der beiden Protokolle eingerichtet werden...logisch !
Bei einem reinen Modem davor (öffentliche Provider IP am WAN Port der pfSense !) ist das natürlich nicht nötig, klar !
Zitat von @aqui:
Da die pfSense NAT macht musst du 2 Schitte in den ToDos machen.
Da die pfSense NAT macht musst du 2 Schitte in den ToDos machen.
- Einmal an den WAN Port Firewall Regeln externen Zugriff von TCP 1723 und GRE auf die WAN IP Address erlauben. Die WAN IP
- Dann eine NAT Forwarding Regel auf die interne lokale IP Adresse für diese Ports TCP 1723 und GRE einrichten.
Hallo,
ich habe mich noch einmal an dem Regelwerk probiert. Die nötigen Einstellungen sind ja wirklich trivial.
Allerdings habe ich noch ein etwas merkwürdiges Problem:
Zur Veranschaulichung mal folgende Grafik:
Ich habe zwei Firewall-Regeln:
Interface: WAN1
Protocol: GRE
Source: Any
Destination: Any
Interface: WAN1
Protocol: TCP
Source: Any
Destination: Any
Destination port range: 1723
Diese beiden Regeln bleiben immer bestehen und funktionieren grundsätzlich.
Es ist ein Portforwarding von 1723 auf den internen PPTP Server eingerichtet. Auch das funktioniert prinzipiell.
Allerdings macht mir die GRE NAT-Regel sorgen.
(Regel 1): Wenn ich GRE auf den internen PPTP Client weiterleite, funktioniert "Tunnel 1".
(Regel 2): Wenn ich GRE auf den internen PPTP Server weiterleite, funktioniert "Tunnel 2".
"Tunnel 3" funktioniert bei beiden Konfigurationen.
Bei einem Wechsel der Weiterleitungsregel, greift diese für "Tunnel 2" sofort. Der "Tunnel 1" braucht beim aktivieren der Regel ca. 5 Minuten bis er aufgebaut werden kann und beim deaktivieren der Regel ca. 8 Minuten bis der Aufbau fehlschlägt ("Benutzername und Kennwort werden überprüft..." -> Abbruch).
Für 8 Minuten sind also tatsächlich alle drei Tunnel möglich.
Warum tut es das???
An welcher Stelle könnte es noch ein Problem geben?
Abgesehen von einem Loadbalancing, welches ich über eine Gateway Group realisiert habe (ist jetzt beim Testen deaktiviert) und einem OpenVPN Server ist nicht spannendes konfiguriert. Kein VLAN etc..
Hast du evtl. noch einen weiteren Hinweis für mich?
Gibt es noch etwas was ich zur Problemlösung beisteuern könnte oder habt ihr einen Tipp für mich, an welchen Ecken sich ein Fehler in der Konfiguration eingeschlichen haben könnte?
braucht beim aktivieren der Regel ca. 5 Minuten bis er aufgebaut werden kann u
Das ist normal, denn das GRE Protokoll hat keine Ports. Die FW macht ein sog. Session Caching und der Cache wird erst nach dieser Timeout Zeit gecleart und dann wird der neue Tunnel aufgebaut.Du kannst den im Setup "zwangsclearen" dann klappt es auch sofort mit der Session. Das ist eine Eigenart durch die Protokollstruktur von GRE bedingt !
Vielen Dank für den Hinweis.
Könnte es sein, dass da etwas beim Outbound-NAT dazwischen funkt?
Ich kann mir noch nicht so recht erklären, warum für eine von innen aufgebaute GRE Verbindung eine NAT Regel erstellt werden muss.
Könnte es sein, dass da etwas beim Outbound-NAT dazwischen funkt?
Ich kann mir noch nicht so recht erklären, warum für eine von innen aufgebaute GRE Verbindung eine NAT Regel erstellt werden muss.
Theoretisch ja. Das Szenario ist recht kritisch weil du einmal aktive inbound GRE Sessions hast als auch outbound. Das rührt aus der recht unglücklichen Situation her das du das VPN nicht direkt auf der FW terminierst sondern alles per Passthrough behandelst.
GRE ist da nicht unkritisch in solchen Situationen eben wegen des fehlenden Layer 4.
Steht irgendwas im Log der Firewall diesbezüglich ?
Generell wäre ein SSL basierendes VPN Verfahren für so ein Design vorteilhafter, da weniger Problem behaftet.
GRE ist da nicht unkritisch in solchen Situationen eben wegen des fehlenden Layer 4.
Steht irgendwas im Log der Firewall diesbezüglich ?
Generell wäre ein SSL basierendes VPN Verfahren für so ein Design vorteilhafter, da weniger Problem behaftet.
Das klingt alles nicht gut. Aber ich kann mich noch nicht geschlagen geben. Schließlich hat es mit nem CISCO RV042 auch funktioniert.
Im Log sieht man folgendes:
Wenn die NAT Regel auf den PPTP Server im eigenen Netz zeigt, so dass Tunnel 3 funktioniert, passiert beim Aufbau von Tunnel 1 folgendes:
Der Server von VPN Tunnel 1 will über GRE eine Verbindung mit dem PPTP Server von Tunnel 3 aufbauen. Der Datenstrom gelangt also gar nicht erst zu dem Client.
Ich habe mich mit diesem Thema aufgrund des anderen Nutzerkreises direkt an das pfSense Forum gewandt. Neue Erkenntnisse werde ich an dieser Stelle publizieren.
Im Log sieht man folgendes:
Wenn die NAT Regel auf den PPTP Server im eigenen Netz zeigt, so dass Tunnel 3 funktioniert, passiert beim Aufbau von Tunnel 1 folgendes:
Der Server von VPN Tunnel 1 will über GRE eine Verbindung mit dem PPTP Server von Tunnel 3 aufbauen. Der Datenstrom gelangt also gar nicht erst zu dem Client.
Ich habe mich mit diesem Thema aufgrund des anderen Nutzerkreises direkt an das pfSense Forum gewandt. Neue Erkenntnisse werde ich an dieser Stelle publizieren.
