androxin
Goto Top

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?

Content-Key: 253668

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

Ausgedruckt am: 29.03.2024 um 01:03 Uhr

Mitglied: aqui
aqui 03.11.2014 aktualisiert um 17:02:02 Uhr
Goto Top
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 ...
Mitglied: Androxin
Androxin 03.11.2014 um 18:43:16 Uhr
Goto Top
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.
Mitglied: aqui
aqui 03.11.2014 aktualisiert um 21:01:04 Uhr
Goto Top
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...
Mitglied: Androxin
Androxin 03.11.2014, aktualisiert am 04.11.2014 um 00:27:29 Uhr
Goto Top
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.

c8ebebd3a28209013fe2e05b020654e9

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??!
Mitglied: Androxin
Androxin 04.11.2014 aktualisiert um 00:37:05 Uhr
Goto Top
Inspiriert von dem Post
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.



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.
Mitglied: aqui
aqui 04.11.2014 um 09:28:08 Uhr
Goto Top
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 !
Mitglied: Androxin
Androxin 04.11.2014 aktualisiert um 10:14:55 Uhr
Goto Top
Vielen Dank für deine Unterstützung. Dieses "in die richtige Richtung stupsen" deinerseits ist genau der richtige Ansatz.

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.

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 !



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.


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?
Mitglied: aqui
aqui 05.11.2014 um 19:37:49 Uhr
Goto Top
Es ist eine pfSense 2.1.5 verbaut.
Oooops ! face-smile
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...
Mitglied: Androxin
Androxin 05.11.2014 um 20:06:00 Uhr
Goto Top
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?
Mitglied: aqui
aqui 07.11.2014 um 09:43:29 Uhr
Goto Top
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 !
Mitglied: Androxin
Androxin 07.11.2014 um 10:04:33 Uhr
Goto Top
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.
Mitglied: aqui
aqui 07.11.2014 aktualisiert um 11:27:15 Uhr
Goto Top
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.
Das wars...!
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 !
Mitglied: Androxin
Androxin 15.12.2014 um 23:10:42 Uhr
Goto Top
Zitat von @aqui:

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.
Das wars...!


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:

0d644465bcf8b454fb4c808737e80c8f


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?
Mitglied: Androxin
Androxin 17.12.2014 um 19:10:16 Uhr
Goto Top
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?
Mitglied: aqui
aqui 19.12.2014 um 10:43:04 Uhr
Goto Top
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 !
Mitglied: Androxin
Androxin 19.12.2014 um 11:20:34 Uhr
Goto Top
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.
Mitglied: aqui
aqui 19.12.2014 aktualisiert um 18:59:45 Uhr
Goto Top
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.
Mitglied: Androxin
Androxin 19.12.2014, aktualisiert am 20.12.2014 um 10:02:58 Uhr
Goto Top
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.