Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

VPN PPTP Clients sollen weiteres Netzwerk erreichen

Frage Netzwerke LAN, WAN, Wireless

Mitglied: anve

anve (Level 1) - Jetzt verbinden

18.05.2012, aktualisiert 30.05.2012, 6535 Aufrufe, 7 Kommentare

Ich verwende eine pfSense und die VPN Clients können das 192.168.1.0 Netzwerk nicht erreichen.

Hallo,

hier ist ein Ausschnitt des Netzwerkes:
b1ad1ec9d01c948cc68439f8afcfd75a - Klicke auf das Bild, um es zu vergrößern

Ich will den Windows 2003 Server per RDP erreichen. Momentan kann ich keinen Rechner im 192.168.1.0 Netzwerk pingen. Die VPN-Verbindung für das 192.168.10.0 Netzwerk funktionieren soweit. Die VPN-Verbindung wird direkt von der pfSense zu Verfügung gestellt.

Unter PPTP VPN im pfSense Menü habe ich folgende "pass"-Regel:
Proto: *
Source: PPTP clients
Port: *
Destination: *
Port: *
Gateway: *

Die VPN Clients bekommen eine Adresse aus dem 192.168.11.0 Netzwerk.

Aber irgendwo scheine ich noch einen Denkfehler zu haben. Könnt ihr mir hierbei bitte helfen?

LG
anve
Mitglied: Bap02-2
18.05.2012 um 23:37 Uhr
Zitat von anve:
Hallo,

hier ist ein Ausschnitt des Netzwerkes:
b1ad1ec9d01c948cc68439f8afcfd75a - Klicke auf das Bild, um es zu vergrößern
Nicht viel zu erkennen...


Ich will den Windows 2003 Server per RDP erreichen. Momentan kann ich keinen Rechner im 192.168.1.0 Netzwerk pingen. Die
Von intern oder extern? Wenn Du den Server intern nicht pingen kannst, geht es auch von extern nicht.



VPN-Verbindung für das 192.168.10.0 Netzwerk funktionieren soweit. Die VPN-Verbindung wird direkt von der pfSense zu
Verfügung gestellt.

Unter PPTP VPN im pfSense Menü habe ich folgende "pass"-Regel:
Proto: *
Source: PPTP clients
Port: *
Destination: *
Port: *
Gateway: *

Die VPN Clients bekommen eine Adresse aus dem 192.168.11.0 Netzwerk.
Das dürfte eigentlich egal sein da es sich dabei ja um das VPN Netz handelt



Aber irgendwo scheine ich noch einen Denkfehler zu haben. Könnt ihr mir hierbei bitte helfen?

LG
anve

Ich denke Du musst den beiden Routern im Netz 192.168.1.0 und im Netz 192.168.10.0 die Routen eintragen. Da die intern sind müssen die sich erstmal verständigen können. Also jetzt mal in Windows Sprache

Eingeben im Router im Netz 192.168.1.0: route add 192.168.10.0 mask 255.255.255.0 192.168.1.234 /p<- Ich hoffe dass das der Gateway ist (kann man nicht richtig erkennen) und

Eingeben im Router im Netz 192.168.10.0: route add 192.168.1.0 mask 255.255.255.0 192.168.10.234 /p<- Ich hoffe dass das der Gateway ist (kann man nicht richtig erkennen)

Ich hoffe ich hab das Problem richtig erkannt und konnte Dir weiterhelfen. Viel Spaß noch
Bitte warten ..
Mitglied: anve
19.05.2012, aktualisiert 20.05.2012
Danke für deine Antwort.

Wenn ich intern bin funktioniert alles. Von extern habe ich sowieso keinen Zugriff. Nun will ich per VPN einen internen Zugriffspunkt erstellen.

Ich vermute dass am gate die Firewall (iptables) neu konfiguriert werden muss. Ich denke es ist dort keine entsprechende Route vom 192.168.11.0 Netzwerk eingetragen. Dazu müsste ich mit iptables beschäftigen...
Bitte warten ..
Mitglied: aqui
19.05.2012, aktualisiert um 11:48 Uhr
Nur nochmal zum Verständnis, da deine Zeichnung oben recht irreführend und unklar ist:
  • Benutzt du eine oder zwei Firewalls ?? (Cluster oder kein Cluster da 2 Symbole)
  • Einmal ist Opt1 mit 192.168.3.1 bezeichnet einmal mit .2 ! Welche IP gilt denn nun oder ist das ein Cluster ? Dieses Konstrukt wie diese ominöse "DMZ" angebunden ist und ob du 2 FW oder wie auch immer benutzt ist aus der obigen Zeichnung nicht wirklich ersichtlich. Normalerweise ist das eine FW mit 3 Interfaces wie z.B. ein ALIX_Board ! Das wäre dann eine richtige DMZ !
  • WIE hast du den PPTP Server und die PPTP Client IPs eingestellt Pool usw. ?? Separates IP Netz oder innerhalb des LAN ?
  • Hast du eine entsprechende Firewall Regel auf dem virtuellen PPTP Interface erstellt ? Ansonsten blockt die FW den PPTP Zugang !!
  • WIE sehen die Regeln auf den anderen Interfaces LAN und OPT1 aus ?? Erlauben die Pakete ins .11.0er Netz deinem VPN ??
  • WIE sieht deine Routing Tabelle aus auf dem PPTP Client bei aktivierter PPTP Verbindung ?? route print zeigt dir das !! Siehst du dort deine beiden lokalen Netze das die via VPN Tunnel geroutet werden ??? Wenn du die dort nicht siehst werden die logischerweise auch nicht in den VPN Tunnel geroutet sondern lokal wo si dann ins Nirwana gehen.
WEN du WIE pingen bzw. erreichen willst solltest du genau beschreiben z.B. VON welchem IP Netz IN welches IP Netz und ob du die dafür erforderlichen FW Rules (Regeln) auf den Interfaces eingerichtet hast !!
Bedenke immer: Bei der pfSense gelten die FW Regeln NUR eingehend und es zählt die Reihenfolge der Regeln !
Wenn das alles klar ist dann sehen wir mal weiter hier...

Und.... Bitte nicht immer alles wieder zitieren !! Wir können alle lesen hier und müssen Threads nicht sinnlos aufblähen indem man alles inklusive Zeichnung wieder und wieder zitiert...!!
Bitte warten ..
Mitglied: anve
20.05.2012, aktualisiert 21.05.2012
Benutzt du eine oder zwei Firewalls ?? (Cluster oder kein Cluster da 2 Symbole)
Zwei Firewalls: Einmal gate, einmal pfsense. Die Zeichnung ist ein bisschen komisch da es aussieht, dass gate aus zwei Komponenten besteht - was aber nicht ist. Es gibt nur mehrere Interfaces.

Einmal ist Opt1 mit 192.168.3.1 bezeichnet einmal mit .2 ! Welche IP gilt denn nun oder ist das ein Cluster ?
OPT1 am gate2 hat die IP 192.168.3.1 und auf der pfsense hat dieselbe Verbindung die IP 192.168.3.2
gate2 hat drei Interfaces mit den Netzwerken 192.168.1.0, 192.168.3.0 und einmal Anbindung an das Internet. Die pfsense hat wieder drei Interfaces mit den Netzwerken 192.168.10.0, 192.168.3.0 und wieder Anbindung an das Internet.

WIE hast du den PPTP Server und die PPTP Client IPs eingestellt Pool usw. ?? Separates IP Netz oder innerhalb des LAN ?
Die PPTP Clients bekommen eine eigene IP aus dem 192.168.11.0 Netzwerk (genauer gesagt 192.168.11.32/28). Der PPTP Server hat die IP 192.168.11.254. Also separates IP Netz.

Hast du eine entsprechende Firewall Regel auf dem virtuellen PPTP Interface erstellt ?
Im Tab "PPTP VPN" im pfSense Menü (Firewall->Rules) habe ich folgende "pass"-Regel:
Proto: *
Source: PPTP clients
Port: *
Destination: *
Port: *
Gateway: *

Damit sollten die VPN Clients überall hinkommen oder nicht?

WIE sehen die Regeln auf den anderen Interfaces LAN und OPT1 aus ?? Erlauben die Pakete ins .11.0er Netz deinem VPN ??
Unter LAN gibt es die ähnliche Regel wie zuvor geschrieben (überall Sterne) aber Source ist LAN net. Unter OPT1 gibt es nur ein paar Portkonfigurationen. Ich sehe hier keine weitere Routen.
78b63940d704fa55d818e4409053b7b3 - Klicke auf das Bild, um es zu vergrößern

>WIE sieht deine Routing Tabelle aus auf dem PPTP Client bei aktivierter PPTP Verbindung ?
IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.3 4250
0.0.0.0 0.0.0.0 Auf Verbindung 192.168.11.32 26
VPN-Server IP 255.255.255.255 192.168.0.1 192.168.0.3 4251
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 4531
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 4531
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 4531
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.3 4506
192.168.0.3 255.255.255.255 Auf Verbindung 192.168.0.3 4506
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.3 4506
192.168.11.32 255.255.255.255 Auf Verbindung 192.168.11.32 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 4531
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.3 4507
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.11.32 26
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 4531
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.3 4506
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.11.32 281

Ich sehe keine meiner beiden lokalen Netze (weder 192.168.10.0 noch 192.168.1.0). Ich kann aber alle Geräte im 192.168.10.0 Netzwerk erreichen. Jetzt will ich auch noch das 192.168.1.0 Netzwerk erreichen.

Wenn ich lokal im 192.168.10.0 Netzwerk bin (also direkt vor ort), kann ich das gesamte 192.168.10.0 Netzwerk erreichen sowie das 192.168.1.0 Netzwerk. Dasselbe sollte nun auch mittels VPN möglich sein. Anscheinend ist keine Route eingetragen ansonsten sollte es ja gehen. Also als verbundener VPN-Client bin ich im 192.168.11.0 Netzwerk unterwegs und kann nicht das 192.168.1.0 Netzwerk erreichen. Ich denke es liegt am gate da ja darauf auch eine Firewall läuft. Wenn ich dort iptables -L eingebe sehe ich einige Einträge. Am ehesten trifft dieser zu:

Tabelle filter, INPUT, gleich einer der ersten Ketten die abgearbeitet wird:
Chain eth2-DMZ (1 references)
target prot opt source destination

ACCEPT tcp -- 192.168.11.0 anywhere tcp state NEW,ESTABLISHED

eth2 hat die IP 192.168.3.1. Wenn ich als VPN Client probiere 192.168.3.1 zu pingen, dann geht das nicht (bin im 192.168.11.0 Netzwerk). Wenn ich die obige Regel richtig verstehe sollte dies zumindest möglich sein. Unter FORWARD ist keine Regel für "accept - if output is interface 192.168.1.234" (nur für input und related, established).

Was fehlt mir noch?
Bitte warten ..
Mitglied: aqui
21.05.2012, aktualisiert um 11:57 Uhr
So, um erstmal ein bischen Licht in deine kranke Zeichnung oben zu bringen sollte die aus Layer 3 Sicht so aussehen:

4a5b8766989c56c4319d0e11fab2b24c - Klicke auf das Bild, um es zu vergrößern
Ist das so richtig ???

Wenn ja, hast du in den FW Regeln einen Kardinalsfehler begangen.
Nochmals zur Erinnerung damit du die Firewallregeln generell verstehst:
1.) Die Regeln gelten nur für EINGEHENDE Pakete ins Interface !
2.) Es gilt: "First Match wins". Also die erste Regel die am Interface gültig ist bewirkt das der Rest NICHT mehr abgearbeitet wird !

Diese beiden Grundsätze solltest du dir immer vor Augen führen beim Definieren der FW Regeln !
Sieht man sich daraufhin einmal deine OPT1 Regeln an erlaubst du dort nur eingehend IP Pakete mit einer Absender IP Adresse (Source) aus dem OPT 1 Subnetz 192.168.3.0 und das auch nur mit den TCP Ports 5666, 12489 und 161-162.
Die nachfolgenden Blocking Regeln sind so oder so Blödsinn denn auch wenn du sie weglässt wird alles andere so oder so geblockt was nicht erlaubt ist...eine Grundregel einer Firewall im Allgemeinen !
Nun fragt man sich allen Ernstes WO bitte sehr sollen denn solche Pakete mit dieser Absender IP herkommen, denn gemäß deiner o.a. Zeichnung befinden sich ja gar keine Endgeräte im OPT1 Subnetz die IP Adressen aus diesem Netz benutzen ?? Folglich können auch niemals 192.168.3.0er IP Pakete dort auftauchen, oder ?
Irgendwie sind diese OPT1 Regeln also ziemlich sinnfrei oder du hast uns hier wieder mal was unterschlagen an Informationen ?
Wenn überhaupt, dann dürften hier nur Regeln stehen die Absender aus dem 192.168.1.0er Netz erlauben entweder auf any als Ziel oder die PPTP VPN Client IPs je nachdem was du vorhast zu steuern mit dem VPN Zugriff.
Genau die stehen da aber nicht so das Paketet aus dem .1.0er netz komplett geblockt werden !! Das kannst du auch selber sehen wenn du nur ein einziges Mal in das Firewall Logg gesehen hättest wo dir das alles angezeigt wird. So wärst du einfach von selber drauf gekommen, denn die pfSense bietet ja diese Logging Mechanismen genau deshalb !
Deine FW Regeln benötigen wenigstens auf dem OPT1 also nochmal eine grundlegende Erneuerung !
Zusätzlich kannst du sehen das das 192.168.1.0er Netzwerk gar nicht in der Client Routing Tabelle steht das es über den PPTP Tunnel geroutet werden soll.
Folglich routet der PPTP Client das dann lokal ins Internet wo es versandet. Nix geht also. Auch das bekommt man mit einem Traceroute oder Pathping ganz schnell selber raus, denn diese Tools zeigen immer den Routing Weg komplett an. Wo es kneift ist der Fehler !
Hier musst du also entweder eine Route hinzufügen oder du musst den PPTP Client so einstellen das er wenn er aktiv ist das Default Gateway ersetzt und ALLES in den Tunnel routet.
Siehe das PPTP Tutorial HIER ! "Standardgateway für das Remotenetzwerk !!"
Vielleicht solltest du uns nochmal genau mitteilen WEN die PPTP Clients aus dem .11.32 /28er Netz denn alles erreichen sollen ? Vermutlich wohl das 10er und das .1er Netz, richtig ??
Nochwas:
Bei VPNs ist es extrem kontraproduktiv diese dümmlichen 192.168.1, 10 usw. IP Netze lokal zu verwenden denn die nutzt die gesamte Welt.
Warum es da bei VPN Konstellationen erhebliche Probleme geben kann, kannst du HIER nachlesen:
http://www.administrator.de/contentid/117700#toc-61407990606-7
Auch das solltest du besser ändern für störungsfreien VPN Betrieb.
Wenn du all diese Punkte beachtest klappt es auch problemlos mit dem PPTP VPN !!
Bitte warten ..
Mitglied: anve
28.05.2012 um 17:36 Uhr
Hier habe ich mal die Zeichnung richtig gestellt:

0c7d0b60f853e3f0644f8407f4023369 - Klicke auf das Bild, um es zu vergrößern

Wo hast du die Icons her?

Zu den OPT1-Regeln:

Ich kann als Absender aus dem 192.168.10.0 Netzwerk sowohl auf Port 80, 21, 22 und 3389 auf das 192.168.1.0 Netzwerk zugreifen. Der Datenverkehr wird hier anscheinend über das OPT1-Netzwerk geroutet und die Regel "Default LAN -> any" lässt hier alles zu. Somit sollten mehr Daten als nur von den TCP Ports 5666, 12489 und 161-162 zurückkommen. Warum die Regeln so aufgestellt wurden kann ich nicht sagen - ich habe das Netzwerk nur übernommen. Wenn Daten über das Gate versendet werden (Absender aus 192.168.1.0 Netzwerk) greifen dann hier die OPT1 Regeln? Ich denke schon. Findet evtl. auf dem gate eine address translation statt? Oder werden Verbindungen die über das 192.168.10.1 Interface aufgebaut wurden generell zugelassen? Mir fehlt hier leider auch die Information und evtl. kannst du mir helfen sie zu erruieren. Ich kann dir nur sagen, dass am gate iptables eingerichtet sein sollte.

Wenn ich versuche auf einem Server im 192.168.1.0 Netzwerk das OPT1 Interface der pfsense (192.168.3.2) zu pingen dann wird das anscheinend geblockt. Weiter komme ich hier nicht. 192.168.3.1 kann ich aber noch pingen.

Wenn ich Packet Capture ausführe (Interface: OPT1, Host address: 192.168.11.32), dann kann er kein einziges Paket mitloggen.

Wenn ich eine Traceroute auf 192.168.3.1 mache (Absender: PPTP Client mit IP 192.168.11.32), dann ist gleich beim ersten Eintrag Schluss (192.168.11.254).

D.h. beim OPT1 Interface erlaube ich Pakete aus dem 192.168.11.32/28 auf das 192.168.1.0 Netzwerk zuzugreifen? Komischerweise steht ja bei den OPT1-Regeln keine Regel für Pakete aus dem 192.168.10.0 Netzwerk. Diese funktionieren aber ohne eine Regel?

Wenn das alles nur eingehende Regeln sind, dann müssten die VPN-Clients auch auf das 192.168.1.0 zugreifen können? Denn das wären ja ausgehende Daten.

Ich habe folgende Regeln zum OPT1 Interface hinzugefügt:
Proto: TCP
Source: PPTP clients
Port: *
Destination: *
Port: *
Gateway: *

Diese steht jetz am Ende und ich versuche als PPTP client (192.168.11.32) nun 192.168.3.1 zu pingen. Wenn ich mir die Log-Dateien ansehe (Status -> Sytem Logs -> Firewall) dann sehe ich keinen geblockten Eintrag (aber auch keinen zugelassenen).

Zu Route:

"Standardgateway für das Remotenetzwerk verwenden" ist bei mir gesetzt. Trotzdem ging es nie. Ich weiß gar nicht wie es gehen würde ohne die Verwendung dieser Option (alles ins VPN schicken). Wenn ich das in einem separaten VPN-Client benutze OK. Wie kann ich aber z.B. Remote Desktop aufbauen mit dem in Windows integrierten VPN-Client ohne diese Option?

Wo und wie würde ich alternativ eine Route hinzufügen?

Zur IP-Adresse:

Weder lokal noch remote wird das 192.168.11.0 Netzwerk verwendet. Ich habe aber nun die IP-Adressen geändert. Ich hab jetzt auch als PPTP-Client (10.6.1.68.32) "pathping 192.168.3.1" versucht, aber nach dem PPTP-Server (10.6.1.68.254) ist es vorbei. tracert liefert dasselbe Ergebnis.

Die PPTP-Clients sollen sowohl das 192.168.10.0 Netzwerk erreichen (läuft schon) als auch das 192.168.1.0 Netzwerk (geht eben noch nicht).
Bitte warten ..
Mitglied: aqui
29.05.2012 um 12:00 Uhr
.. ."anscheinend über das OPT1-Netzwerk geroutet"
Nicht nur "anscheinend" sondern es sollte ganz sicher so sein !!
Dazu solltest du aber mal in Diagnostics -->> Routes auf der pfSense deine Routing Tabelle ansehen ! Analog auf der Gate Firewall um das sicherzustellen !!
"Anscheinend" ist ein ganz schlechtes Wort in der IT !!

"Regel "Default LAN -> any" lässt hier alles zu. " Mmmhh Ja was denn DENY oder ALLOW ?? Diese Regel ist auf dem OPT 1 Interface der pfSense totaler Unsinn und überflüssig wenn sie mit ALLOW (PASS) definiert ist.
Da sie nur eingehend wirkt und das "Default LAN" das lokale 192.168.10.0 er Netzwerk ist bewirkt diese Regel das Packete mit eingehender Absender IP 192.168.10.x auf jegliche Destination dürfen.
Diese Regel ist eigentlich unsinnig denn am OPT1 Interface (192.168.3.0) können niemals Pakete eingehen die eine IP Adsender IP von 192.168.10.x haben ! Wo sollten die denn auch herkommen ??
Einzig Pakete mit den Absender IPs 192.168.1.x und 192.168.3.x können dort eingehen, wobei letzteres unwahrscheinlich ist, da dort ja keinerlei Endgeräte vorhanden sind !
(Annahme ist hier das das OPT1 Interface die 192.168.3.0 ist !)
Diese regel greift nicht wenn Pakete aus dem 192.168.10er netz VERSENDET werden, denn dann gahen dort Pakete aus dem OPT1 Interface RAUS !
Da die Regeln amer immer nur EINGEHEND wirken greift hier erstmal gar nix !
Erst wenn ein Endgerät aus dem .1.0er Netz antwortet und es dann auch von der "Gate" FW via 3.0er Netz geroutet wird (Routetable Gate !) dann kommen am OPT1 Interface Pakete mit der Absender IP .1.x and zu einer Ziel IP .10.x EINGEHEND an !
Dort MUSS dann also eine Regel wie Erlaube/Pass "192.168.1.0 -> any oder besser 192.168.10.0" logischerweise stehen !
Diese alte Regel am OPT1 Interface eingehend ist dann irgendwie sinnfrei.
"Warum die Regeln so aufgestellt wurden kann ich nicht sagen - ich habe das Netzwerk nur übernommen"
Was soll das für eine komische Ausrede sein ?? Ist auch völlig überflüssig, denn was zählt ist doch was du JETZT machen und erreichen willst, oder ?
Dann schmeiss den alten Müll über Bord und mache es richtig !!

"Wenn ich versuche auf einem Server im 192.168.1.0 Netzwerk das OPT1 Interface der pfsense (192.168.3.2) zu pingen dann wird das anscheinend geblockt."
Ja, das ist auch logisch denn dazu fehlt dir dort die Regel:
Erlaube/Pass "192.168.1.0 -> OPT1 Interface" oder wenn du es einschränken willst als Protokoll ICMP, da Ping immer mit ICMP funktioniert !
Verhalten ist also logisch ! Siehe vermutlich auch den Eintrag dann im Firewall Logg !!

"Wenn ich Packet Capture ausführe (Interface: OPT1, Host address: 192.168.11.32), dann kann er kein einziges Paket mitloggen."
Auch klar, denn eine Regel hier die das .11.0er Netz erlaubt fehlt auch völlig !!

"Wenn ich eine Traceroute auf 192.168.3.1 mache (Absender: PPTP Client mit IP 192.168.11.32), dann ist gleich beim ersten Eintrag Schluss (192.168.11.254)."
Vermutlich auch klar wenn die Regel im PPTP Interface fehlt "Erlaube PPTP subnet --> opt 1 subnet oder any" UND am OPT1 die Regel "Erlaube OPT1 subnet --> PPTP subnet oder any"
Immer die Paketwege mit ihren Ziel- und Absender IP Adressen genau verfolgen !

"D.h. beim OPT1 Interface erlaube ich Pakete aus dem 192.168.11.32/28 auf das 192.168.1.0 Netzwerk zuzugreifen? "
Nein, das wäre völliger Blödsinn, denn die FW Regeln greifen nur eingehend also auf Pakete die IN das Interface reingehen.
Am OPT1 Interface können niemals Pakete ankommen die vom .11.0er Interface kommen. Dort kann nur was von .1.0 und von .3.0 kommen.
Es kann nur was zum .11.0 und .10.0 hingehen also entsprechende Ziel IPs in der Regel haben !
Beachte das Source und Destination IP ist hier schon wichtig ! Mache dir immer den kompletten weg mit den entsprechenden Sender- und Empfänger IPs bewusst !!

"Ich habe folgende Regeln zum OPT1 Interface hinzugefügt:..."
Falsch !!
"Source: PPTP clients" Solche Absender können niemals am OPT1 ankommen wie oben beschrieben ! Wie denn auch ? .1.0 und .3.0 ist das immer, siehe oben !!
Destination: PPTP clients ...das würde stimmen, denn die Antwortpakete von einem PPTP Client der mit einem Host im .1.0er Netz kommuniziert haben ja logischerweise einen .11.0er IP als Zieladresse (Destination) !!

"...dann sehe ich keinen geblockten Eintrag (aber auch keinen zugelassenen)."
Klar, wo sollte der denn auch herkommen ?? Socle Pakete kommen niemals an das Interface, siehe Beschreibung oben ! (Regel NUR eingehend, Source und Destination IP zählt !)

""Standardgateway für das Remotenetzwerk verwenden" ist bei mir gesetzt."
Das ist korrekt und muss so sein wenn du mehrere IP Netze hinter dem VPN Client erreichen willst !
Ohne das müsstest du eine Route Table via PPTP an den VPN Client schicken !
Eine alternative Route würdes du dann mit dem "route add 192.168.1.0..." Komamndo lokal am Client definieren.
Vergiss das aber erstmal das sind Speilereien die du machen kannst wenn dein ganzes Konstrukt sauber rennt und du ertsmal die FW Regeln auf die Rehe bekommen hast !!

Was die Änderung auf dei 10er IPs betrifft ist dein Problem wieder die vollkommen falschen FW Regeln oben. Das bricht dir dann wieder das Genick !
Wenn du die endlich richtig setzt, dann funktioniert das ganze auch absolut sauber und problemlos !!
Deshalb können die das 192.168.1.0er Netz nicht erreichen.
Versuche erstmal eine "Schrottschuss Regel" auf dem Interface die du später dichtziehst:
  • OPT1 = Erlaube dort 192.168.1.0 --> any (Achtung: Gate FW darf kein NAT am .3.0er Netz machen !!)
  • PPTP = Erlaube dort PPTP Clients --> any
  • Zusätzlich musst du sicherstellen das die Gate FW .10.0er und auch .11.0er (jetzt 10er) Pakete auf dem .3.0er Interface erlaubt als Ziel IP Adressen !
Testweise kannst du auch mal alles aufmachen mit "any zu any" damit sollte es dann in jedem Fall klappen !
Logisch das du danch dann mit entsprechenden regeln alles wieder entsprechend deinen Vorgaben dichtmachen solltest !!
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
LAN, WAN, Wireless
Drucker aus anderem Netzwerk erreichen (13)

Frage von heisenberg4 zum Thema LAN, WAN, Wireless ...

Router & Routing
VPN für LAN-Clients über Asus RT-AC51-U hinter Fritz 7490 (3)

Frage von Samuel113 zum Thema Router & Routing ...

Windows Netzwerk
PPTP-VPN Abbruch nach 20 Sekunden (13)

Frage von Otomombe zum Thema Windows Netzwerk ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (21)

Frage von Xaero1982 zum Thema Microsoft ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Windows Update
Treiberinstallation durch Windows Update läßt sich nicht verhindern (17)

Frage von liquidbase zum Thema Windows Update ...