OpenVPN hinter Router - Roadwarrior Zugriff auf WAN Port der Pfsense..?
-
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 ;)
