OpenVPN hinter Router - Roadwarrior Zugriff auf WAN Port der Pfsense..?
-
Genauso sehe ich das auch, mein Denkfehler war ebenfalls vorher, dass das zu wartende Gerät im Kundennetz steht und er mit der pfSense vor Ort ins Kundennetz Tunneln muss. DAS ist ein Albtraum, da man zig Adressbereichs-Überschneidungen hat. So kann er sich aber selbst ein großes Subnetz nehmen (10.x bspw.) und dann anfangen die Kundennetze nach Kunde durchzunummerieren (10.101.1.0, 10.101.2.0, 10.101.255.0, 10.102.0.0, …). Damit ist dann der Tunnel auch kein großes Problem, da das LAN des Kunden nur als ein weiteres Transfernetz mitgenutzt wird.
Zu der Aufteilung habe ich noch ne Frage. Die Hardware kommt Montag, und ich bin schon am theoretischen durchspielen.
Bei 10.101.1.0/24 habe ich pro Kunde 254 Host IP Adressen zur Wahl, was dicke ausreicht, weil es meist nur eine oder zwei sind.
Das sind ja alles verschiedene Subnetze. Lassen die sich denn alle auch von einer Service Maschine aus erreichen.?
Wo ist der Unterschied zu einem /20er Netz mit 4096 Hosts. Das würde bis zu meiner Rente und der meines AZUBI reichen… ;)
--
Rüdiger
-
Wo ist der Unterschied zu einem /20er Netz mit 4096 Hosts. Das würde bis zu meiner Rente und der meines AZUBI reichen… ;)
Du mißverstehst da etwas. Klar, dir würden 4096 Hosts ausreichen, aber du musst diese alle erreichen können. Da du aber verschiedene Standorte hast wo jeweils ein oder zwei Geräte hängen, und nicht einen, brauchst du mehrere Netze zur Unterscheidung! Jede APU vor Ort wählt sich bei dir zentral ein und macht einen Netz-zu-Netz Tunnel, gibt also bspw. das hinter ihr liegende 10.101.1.0/24 an dich zentral weiter. Die nächste APU gibt dann 10.101.2.0/24 frei. Dadurch hast du
a) ganz klar definiert wo sich bspw. dein Gerät 10.101.1.11 befindet (nämlich an Standort 1, das erste Gerät wenn du bspw. ab >10 anfängst deine Geräte zu numierieren)
b) und ganz klare Abgrenzungen, damit nicht versehentlich Geräte von Standort 1 mit Standort 2 reden könnten (auch wenn nur theoretisch möglich).Ein einziges großes Netz zu verwenden das auf allen APUs als LAN definiert wird geht nicht. Warum? Ganz klar, weil dein Rechner ja wissen muss, über WELCHE APU er denn zum Gerät 10.0.1.234/20 gehen muss. Das tut er aber nicht. Also fragt er die pfSense bei dir zentral. Die weiß es aber auch nicht, weil JEDE APU bei ihm sich mit lokalem Netz 10.0.0.0/20 anmeldet. Wohin soll er das Paket jetzt senden?
Das geht - einfach - routingtechnisch gar nicht. Sicher kannst du lokal immer hinter den APUs das gleiche Netz verwenden, das ist aber genau der Albtraum den ich anfangs schon meinte. Dann hast du nämlich den Salat und musst lokal das VPN nochmals NATten um herauszubekommen, woher die Zugriffe kommen oder wohin sie gehen.
Zusätzlich müsstest du dann (um nicht ganz in die Kacke zu kommen) aufpassen, dass du auch ja immer andere IPs aus dem /20er Netz vergibst, damit du nicht 2x ein Gerät wie 10.0.1.234 hast (was dann ja durchaus möglich wäre).Deshalb - für jede APU die sich einwählt einfach ein sinnvolles dediziertes LAN verwenden, dass via VPN gekoppelt wird. Dann kannst du dir ne große Liste machen mit Kunden <-> IP Netzen und hast das sauber getrennt. Und da es private Adressen sind, ist es völlig wurscht, ob du das halbe 10.0.0.0/8er Netz dafür verballerst solange du nicht an mehreren Enden das gleiche Netz hast. Deshalb würde ich nicht mit 10.0.0 anfangen, sondern bspw. mit 10.20/50/100.x.y oder auch 172.16/20/27.x.0/24. Also Netzen, die nicht so oft per default irgendwo auf 08/15 Routern definiert sind wie bspw. 192.168.0/1/168/178 oder auch 10.0.0
Grüße
-
Danke.
Sehr informativ.
Diese Erkenntnisse hätte ich wohl erst nach dem ersten Problem gewonnen. Und das soll ja nicht sein..
Hab die Tage schonmal nach einem Grundlagen Buch für die aktuelle pfsense gesucht. Scheint nur an Gold Member zu gehen, oder veraltet zu sein.
Und nur in English, was keine riesige, aber eine vorhandene Hürde ist.
Aber die "Grundlagen" muss ich unbedingt mal erarbeiten… Alleine wegen der Begriffe.. (Inbound...) Eingehender Traffic.? :)--
Rüdiger -
Hallo!
Die einzelnen Hosts, die du am anderen Ende der VPNs erreichen möchtest, könntest du mit aussagekräftigem Namen in ein internes DNS System aufnehmen, um sie leichter identifizieren zu können.
Eine zusätzliche akribische Dokumentation ist aber natürlich trotzdem unabdingbar.Ich denke, du bist mit der pfSense noch nicht allzu sehr vertraut, daher wäre eventuell auch das noch ein guter Tipp für dich: Die Konfigurationen der einzelnen Boxen könnten ja bis auf die WAN IP (das Kundennetz) und die VPN IP gleich sein. Es würde sich daher anbieten, eine Box ordentlich fertig zu konfigurieren, die Konfiguration dann als XML zu exportieren und in diesem die sich änderten Parameter für die nächste Box anzupassen. Nach Import der Konfig in die neue pfSense könnte sie dann gleich einsatzbereit sein.
Grüße
-
Die einzelnen Hosts, die du am anderen Ende der VPNs erreichen möchtest, könntest du mit aussagekräftigem Namen in ein internes DNS System aufnehmen, um sie leichter identifizieren zu können.
Eine zusätzliche akribische Dokumentation ist aber natürlich trotzdem unabdingbar.Dem Thema DNS muss ich mir auch noch annehmen. Ich nehme an, das die FritzBox des jetzt im lokalen Netz übernimmt. Die kann das dann ja nicht mehr… Mal schauen wie das geht.
Ich denke, du bist mit der pfSense noch nicht allzu sehr vertraut, daher wäre eventuell auch das noch ein guter Tipp für dich: Die Konfigurationen der einzelnen Boxen könnten ja bis auf die WAN IP (das Kundennetz) und die VPN IP gleich sein. Es würde sich daher anbieten, eine Box ordentlich fertig zu konfigurieren, die Konfiguration dann als XML zu exportieren und in diesem die sich änderten Parameter für die nächste Box anzupassen. Nach Import der Konfig in die neue pfSense könnte sie dann gleich einsatzbereit sein.
Ja. Fast null Erfahrungen. Hab mal eine MonoWall für ein Wlan Projekt aufgesetzt. Als Captive Portal. Läuft sehr gut…
Ich hatte auch an dieses sichern der Config gedacht. Das das mit XML Files geht, ist mit jetzt neu. Ich dachte an ein ISO mit dd erstellen tut es evtl...
--
Rüdiger
Grüße -
Ich hatte auch an dieses sichern der Config gedacht. Das das mit XML Files geht, ist mit jetzt neu. Ich dachte an ein ISO mit dd erstellen tut es evtl…
Geht auch wenn du ein vollständiges Image haben möchtest. Da du aber jede APU die beim Kunden steht noch umkonfigurieren musst, kannst du dir die einzelnen Konfigs dann nach Bedarf von diesem Image ableiten. Die VPN Config bspw. bleibt gleich (@virago: die APUs wählen sich ja zentral ein, deshalb muss sich da außer ggf. Zertifikaten nichts ändern, bei PSK bleibt alles wie es ist), lediglich WAN passt sich auf Kunden an und LAN auf die Installation (also das Netz was dann via VPN erreichbar sein soll).
Grüße
-
Hallo alle in der neuen Woche!
@virago: die APUs wählen sich ja zentral ein, deshalb muss sich da außer ggf. Zertifikaten nichts ändern, bei PSK bleibt alles wie es ist)
Ich hatte da eigentlich an die Client IP gedacht. Aber klar, auch das Zertifikat muss, falls verwendet, angepasst werden.
Ein Image bringt es meiner Ansicht nur von einer Festplatteninstallation, weil sich hier die Installationszeit und der -aufwand abkürzen lassen. Die fertigen Images einer ALIX od. APU stehen ohnehin im Netz und werden einfach auf die Karte geschrieben. Alles was angepasst werden muss, steht in der Konfig-XML.
Grüße
-
So, Hardware ist da.
Aktuelle Version auf mSata läuft.
3 VLAN dem Opt Interface zugeordnet.
Das erste ( tag 10 ) ist die DMZ für den Mailserver. Sollte kein Problem sein.
Beim zweiten ( tag 20 ) sollen ja die openvpn Verbindungen drüber laufen zum Service PC. Besondere Anforderungen.? Da ist ja ein Subnetz pro Kunde
angedacht…Das dritte vlan ist erstmal ZBV. Evtl. als Test Netz für Kunden PC in der Werkstatt...
Muss der Opt Port (Trunk) selber auch ne IP bekommen.? Wahlfrei.?
--
Rüdiger
-
Soll der Service PC in ein extra Netz bei euch lokal? Warum? (nur Frage)
Das Opt Interface selbst sollte keine IP bekommen, das würde eh nur Pakete abbekommen, die auf dem Port untagged ankommen, was nie vorkommen sollte (wenn der Switch richtig konfiguriert ist).
Das (nackte) Interface muss nicht einmal zugewiesen sein.Grüße
-
Soll der Service PC in ein extra Netz bei euch lokal? Warum? (nur Frage)
Ich hatte gedacht, das das die Sicherheit erhöht. Wenn ein Mitbewerber die Anlage mal übernimmt, würde er im Firmennetz evtl. Zugriff erlangen können…
So kann er nur auf den einen Service PC.Das Opt Interface selbst sollte keine IP bekommen, das würde eh nur Pakete abbekommen, die auf dem Port untagged ankommen, was nie vorkommen sollte (wenn der Switch richtig konfiguriert ist).
Das (nackte) Interface muss nicht einmal zugewiesen sein.Oh, ok. Habs wieder gelöscht.
Bzgl. der Konfiguration. Hab jetzt die FW im Firmennetz WAN seitig dran (DHCP von der FB ). Hab aber das LAN auf ein anderes Subnetz gelegt zwecks Konfiguration. Muss das alles nach Feierabend/ Wochenende umschwenken und wollte das alles vorbereiten. Oder kann LAN seitig auch das selbe Netz genommen werden…?
Grüße
-
Ich hatte gedacht, das das die Sicherheit erhöht. Wenn ein Mitbewerber die Anlage mal übernimmt, würde er im Firmennetz evtl. Zugriff erlangen können…
Nur, wenn du Zugriff VON den Systemen AUF deine Systeme zulässt. Auch OpenVPN bekommt ein Interface Reiter in den Firewall Regeln, so wie jedes VLAN oder normale Interface und natürlich kannst du da auch ganz einfach Regeln anlegen wie bspw. VON Systemen AUF meines geht nix und VON meinem PC-XY auf System 1 von Kunde 2 geht RDP/SSH/whatever. Damit sicherst du dich ab, dass keine Verbindung initial von dort aufgebaut werden kann. Und da "block any" eh default ist, musst du Regeln anlegen um sowas zu erlauben, ergo geht das so ohne weiteres nicht, es sei denn du willst bspw. dass dein Gerät vor Ort dir Mails sendet, dann müsstest du den Weg bspw. öffnen, da die Verbindung vom Gerät aufgebaut wird. Wenn alles was du brauchst nur Remote Access AUF die Systeme ist, müssen die bei dir gar nix dürfen :) -
Ich hatte gedacht, das das die Sicherheit erhöht. Wenn ein Mitbewerber die Anlage mal übernimmt, würde er im Firmennetz evtl. Zugriff erlangen können…
So kann er nur auf den einen Service PC.Wenn dieser Mitbewerber Zugriff auf den Service-Rechner hat, macht das natürlich schon Sinn, diesen vom übrigen LAN zu trennen.
Wie JeGr eigentlich schon geschrieben hast, kann die Firewall den Traffic nur an ihren Interfaces kontrollieren und ein VLAN schafft dir ein zusätzliches virtuelles Interface.
Hängt Service-PC gemeinsam mit dem restlichen LAN nur an Switches, kann die pfSense gegenseitige Zugriffe nicht unterbinden.Gruß
-
@virago:
Hängt Service-PC gemeinsam mit dem restlichen LAN nur an Switches, kann die pfSense gegenseitige Zugriffe nicht unterbinden.
Wie meinst du das denn? Zugriffe von den Kundensystemen ankommend sind erstmal durch die Regeln doch überhaupt nicht erlaubt. Wo soll dann der Zugriff herkommen? Ich habe natürlich nichts dagegen, wenn es einen dedizierten Service-PC gibt und der in einem extra Netz steht zur Sicherheit. Aber wenn nur Zugriffe von dieser Kiste auf die Endkunden-Systeme via VPN erlaubt sind, ist es eigentlich recht egal. Wo gibt es da aus deiner Sicht gegenseitige Zugriffe?Grüße
-
Hmm.
Ich war nur der Meinung, das es sicherer ist. Auch weil der oder die Service-PC teilweise noch auf Win2000 / XP basieren müssen. Also potentiel keine
Geräte, die man noch frei im Netz rumlaufen lassen möchte.–
Rüdiger -
@virago:
Hängt Service-PC gemeinsam mit dem restlichen LAN nur an Switches, kann die pfSense gegenseitige Zugriffe nicht unterbinden.
Wie meinst du das denn?Ich hatte diese Bemerkung
@RudiOnTheAir:Ich hatte gedacht, das das die Sicherheit erhöht. Wenn ein Mitbewerber die Anlage mal übernimmt, würde er im Firmennetz evtl. Zugriff erlangen können…
So kann er nur auf den einen Service PC.so verstanden, dass dieser Mitbewerber auch Zugriff auf den Service-PC bekommen soll. Wenn der aber lediglich die kundenseitigen Teile der Anlage übernimmt, trifft das nicht zu. Dann reicht natürlich das VPN Interface um den Zugriff auf der pfSense zu kontrollieren.
-
Geräte, die man noch frei im Netz rumlaufen lassen möchte.
Oh ja, so alten Kram sollte man wirklich einsperren.Wenn der aber lediglich die kundenseitigen Teile der Anlage übernimmt, trifft das nicht zu. Dann reicht natürlich das VPN Interface um den Zugriff auf der pfSense zu kontrollieren
Ah OK, ich hatte das andersrum verstanden :) Dann ist natürlich klar was du gemeint hast :) -
Geräte, die man noch frei im Netz rumlaufen lassen möchte.
Oh ja, so alten Kram sollte man wirklich einsperren.Ist schon ein Problem mit den "alten" Anlagen. Obwohl das jetzt erst eskaliert. XP war so lange
die Referenz. Und fast alles an Software von der Herstellern läuft noch auf XP. Aber die neuen Notebooks
mit Win 7 oder 8 machen schon Probleme. Teilweise sind Treiber für die Hardware nicht 64 Bit fähig, oder das
ganze Programm lässt sich nicht installieren.
Auf meinem Dienst Notebook ist Win7-64 und XP im Dualboot. Und nochn Linux. Das Notebook mit Win98 / DOS muss auch immer im Auto sein. Geht nicht anders. Welcher Kunde will schon seine Sicherheitstechnik nach 10 -15 Jahren wegwerfen, nur weil ein Softwarehersteller mal was abkündigt…--
Rüdiger -
Ist schon ein Problem mit den "alten" Anlagen. Obwohl das jetzt erst eskaliert. XP war so lange
die Referenz. Und fast alles an Software von der Herstellern läuft noch auf XP.Was spricht denn dagegen, eine aktuelle Win7 oder Win81 Maschine aufzusetzen und dort die Software im Komaptibilitätsmodus für XP laufen zu lassen? Oder notfalls im HyperV mit einer XP VM? Wäre zumindest sicherer als eine echte XP Kiste.
Aber die neuen Notebooks mit Win 7 oder 8 machen schon Probleme. Teilweise sind Treiber für die Hardware
nicht 64 Bit fähig, oder das ganze Programm lässt sich nicht installieren.Siehe oben
Welcher Kunde will schon seine Sicherheitstechnik nach 10 -15 Jahren wegwerfen, nur weil ein Softwarehersteller
mal was abkündigt…In dem Fall ist aber nicht der Softwarehersteller (Microsoft) schuld, sondern die Firmen der Sicherheitstechnik, die ihre Software ewig nicht auf Kette bekommen. Ich bin jetzt beileibe kein Freund von Microsoft, aber es ist wohl nicht zu viel, wenn man nach pan 10 Jahren ein OS mal wirklich sterben lässt. Vor allem wenn es danach noch 3 richtig gute und valide Optionen gab (Win2k, Win7, Win81 als akzeptabler Kompromiss). Wenn man es in der Zeit nicht schafft, sein bisschen Steuersoftware einmal in neue Entwicklungsumgebung zu hauen und endlich mal gegen ein neues aktuelles OS zu bauen oder upzudaten, ist mir ein Rätsel. Wenn das so ein Problem ist, verstehe ich den Grund nicht, warum man dann nicht gleich etwas genommen hat, was bspw. nativer Code ist und unter einem Unix oder Linux läuft.
Es sind (leider) immer wieder die Dritt-Firmen wie jetzt bei dir die Sicherheitstechnik-Hersteller (oder 1:1 anwendbar die Hersteller von Telefonanlagen, Steuersoftware von Industriehardware, etc. etc.) die "mal eben" irgendwas in klick-bunt-Compiler-Assistenten-Tools zusammenbauen, was dann Jahre später noch dazu führt, dass man sich mit altem Schrott rumschlagen muss, weil von denen keiner den Mist mehr updaten will. Und ums noch schlimmer zu machen basteln die gleichen Firmen dann Ethernet Interfaces an solche Geräte dran um die "komfortabel" übers Netzwerk/Internet steuern zu können. Die gleichen Firmen die schon für 2 Cent kaum ordentlich programmieren können. Die machen dann sowas remote erreichbar. Kühlschrank, Fernseher, Haussteueranlagen, geht inzwischen ja bis zur Medizintechnik (Herzschrittmacher etc.). Und dann wartet man ein paar Wochen bis die ersten Hacks erscheinen, weil keiner der Nasen aus der Technik mal was von sicherer Implementation von Menchanismen oder Login-Prozeduren gelesen hat.
SEUFZ
Sorry für den OT-Rant, aber ich hab da schon zu viel inzwsichen gesehen von ;)
