OpenVPN hinter Router - Roadwarrior Zugriff auf WAN Port der Pfsense..?
-
Der Adressbereich des KundenNetz ist nicht zu beeinflussen und bei jedem Kunden anders. Der Bereich am Lan Port der FW ist dagegen in meinem Einfluss.
Na, dann hast du ja alle Möglichkeiten offen. Du möchtest ja nur deine Hardware bei dir ins Servicenetz einbinden.
Da sehe ich keine Probleme. -
Die "Konsole" war wohl die krude Methode wie Profis ihre sauteuren Netzwerkswitche einrichten,
Die Konsole ist DIE Methode wie (so ziemlich) alle Profis ihre Netzwerkswitche betreuen, es sei denn es sind billige Teile, die nur eine (oftmals verkrüppelte) WebUI zur Verfügung haben. Und ja das ist kniffliger, deshalb sind das auch Profis. Das hat jetzt gar nichts mit sauteuer oder nicht zu tun, sondern mit der Einfachheit. Sicher sind die Kommandos teils schwer zu begreifen, aber wenn ich mit 1-2 Kommandos schnell das erreiche, wo ich in (den meisten) WebOberflächen 20x klicken, neuladen, sonstwas muss, ist das extrem nervig und auch nicht gut orchestrierbar. In einem guten Netz sind da nämlich alle Komponenten orchestriert und deployed. Da greift man selten zum Gerät selbst, sondern passt das Deployment oder Logging an. Aber sowas braucht auch KnowHow, völlig klar. Krude ist das aber nicht im Geringstens, eher Standard. Ich finds persönlich eher schade, dass pfSense keine richtige CLI hat um bspw. schnell per SSH Regeln oder Aliase anzulegen.
@virago
Da sehe ich keine Probleme.
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.
Grüße
-
Ist mir schon klar dass der CLI Kram "besser" ist "mehr drauf hat" ;)
Alles eine Frage des Know-Hows des Betrachters.
Die Vollprofis benötigen vermutlich auch keine pfSense Firewall sondern haben richtige "Männer, höhöhö" Firewalls mit selbst selbstgeschrieben iptable (oder wie der Kram heisst)
Die pfSense ist halt irgend wie dazwischen, viel mehr als das anklicken des Firewall Kästchens im WLAN Modem-Router, aber immer noch fast Dummie-tauglich.
Gruss Auric
-
@all
Dann ist ja alles in trockenen Tüchern.
Muss schon sagen, ein super Forum. Hier trifft man auf geballte Fachkompetenz, ohne das Neulinge wie ich es bin in Sachen
Firewall und VPN mit einem RTFM abgewimmelt werden. Oder noch schlimmer, wo 50 Leute den Post gelesen haben, aber niemand was dazu sagen möchte. Das frustriert.Ich werde jetzt den Chef zwecks Bestellung der Hardware ansprechen, und dann kann es los gehen. Scheint echt ne spannende Sache zu werden.
Vielen Dank und ich melde mich wieder ;)
–
Rüdiger -
Die Vollprofis benötigen vermutlich auch keine pfSense Firewall sondern haben richtige "Männer, höhöhö" Firewalls mit selbst selbstgeschrieben iptable (oder wie der Kram heisst)
Ehrlich? Nein. Ich würde mich durchaus zu der Kategorie (semi) Profi Netzwerker zählen ;) und wir haben im Datacenter 2 große Kübel mit pfSense stehen.
Warum? Weil dat Dingens fast das gleiche kann, wie eine Juniper oder Cisco zu einem Zehntel / Fünftel des Preises (wenn man potente Hardware druntersetzt). Das ist dann wirklich ne Abschätzung: Warum soll ich 50k ausgeben für Juniper, wenn ich für 10k gute Hardware bekomme und pfSense draufschrauben kann? :)Allerdings sind wir da eben auch auf Layer 3 aufwärts. Für L2/L3 Switching etc. nimmt man dann eben Asics und spezielle Hardware und deren GUI ist mitunter eben wirklich grausam. Bestes Beispiel sind da Juniper Switche, die man über spezielle Mechanismen stacken kann (6-8 Stück). Mit jedem Switch wird die GUI langsamer und langsamer weil er von jeder Backplane alle Ports abrufen muss. CLI/SSH ist blitzschnell weil er den Kram erst dann abruft wenn er ihn braucht (wenn überhaupt). Das meinte ich mit kranken GUIs ;)
Ich habe in alten Tagen auch OpenBSD Router/Firewalls gebaut und die pf Regelsets noch per Hand getunet. War spaßig und kann extrem viel, aber bei größeren Setups ist das dann einfach zu viel und da bin ich dann über gute GUIs oder CLIs froh. Am Besten beides :)
Aber genug OT ;)
@Rüdiger:
Ein gutes Forum ist eine Sache, man sollte sich ggf. aber auch Support mit einplanen oder einkaufen. Sei es von einem kompetenten Netzwerker / Freelancer, der sein Geld wert ist und sich auskennt und ggf. auch Architektur gleich ordentlich mit aufbaut und das dann betreuen kann wenn man mal Hilfe braucht. Das haben zum Großteil nun zwar wir im Thread schon geleistet, aber so jemanden auf Standby zu haben ist nie verkehrt ;) (und ohne für böse Werbung jetzt geschlagen zu werden, ja mich kann man durchaus auch mieten :P)
Oder/Und von den pfSense Jungs & Mädels wenns eben mal wirklich hapert und man einen Bug gefunden hat.
Ich war bspw. sehr froh dass ich Live Support hatte beim Upgrade von 2.1.3->2.1.4 als alle Alias IPs weg waren. Das ging 10min und ich hatte die wieder.Grüße
Jens -
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.
