Testumgebung im VLAN, OpenVPN auf pfSense
Hi zusammen,
ich bin gesundheitsbedingt Umschüler in der FR Systemintegration und seit letztem Monat im Praktikumsbetrieb. Bevor die Frage wie ein rosa Elefant im Raum steht, warum ich dort nicht meine "Ausbilder" frage - weil das Praktikum alles andere als gut läuft und man offenbar jemanden erwartet hat, den man als kostenlose und fast fertige Arbeitskraft einsetzen kann. Das Umschüler/innen das nach einem Jahr Theorie nicht sind und sein können und bestenfalls im Stand eines Auszubildenden im 2. Lehrjahr sind, in die man natürlich auch entsprechend Zeit investieren muss, hatte man hier vermutlich nicht bedacht. Nicht falsch verstehen: ich hab richtig Bock auf IT-Systeme und Netzwerke und hab mir die Umschulung ausgesucht. Mir dünkt leider eher, der Betrieb - oder die IT Abteilung - hat keine Lust Leute in deren Arbeitsbereich einzuarbeiten, dort aus- oder weiter zu bilden.
Eine zur Abschlussprüfung zu erstellende Projektarbeit sollte man mit dem Praktikumsbetrieb besprechen und mit dessen Hilfestellung durchführen. Ich hatte das Vergnügen, dass es im Betrieb einen großen Ordner an seit Jahren ausstehenden und noch umzusetzenden Aufgaben gab, auf den sich meine Auswahlmöglichkeiten dann beschränkten. Das kleinste und zeitlich (bis zum Abgabetermin bei der IHK) am ehesten machbare war dabei der Aufbau einer Einwahlstruktur für Remote Access und IoT Geräte, deren Datenströme auf der öffentlichen Seite über 2 Lancoms laufen (mit gegenseitigem Failover), die Datenströme innerhalb der DMZ physisch zwingend getrennt werden müssen und dort über 2 Netgate 7100 1U mit pfSense geroutet sind. Beide pfSense müssen dann noch zusätzlich mit einem Failover auf jeweils eine VM mit einer virtuellen pfSense ausgestattet werden. Das Ganze hier kurz als Schema:
Momentan hänge ich bei der Einrichtung des OpenVPN auf der pfSense in einer Testumgebung. Testumgebung daher, da vom Betrieb ein Proof-of-concept gefordert wurde, bevor man die Hardware bestellt. Das bringt nur leider reichlich Probleme mit sich. Die pfSensen sind notgedrungen beide auf Workstations installiert und in einem VLAN eingebunden, mit dem Sie zumindest nach aussen telefonieren können. In dem mir zugewiesenen VLAN hängen noch ein paar hundert andere Geräte und eine statische Route oder Forwarding kann ich dort nicht einrichten. Ein Zugriff per DynDNS fällt damit natürlich auch aus. Die Einwahl soll grundsätzlich ausschließlich über OpenVPN und die Authentifizierung nur über einen PSK erfolgen. Ein (zusätzliches) User-Auth ist nicht gewünscht.
Ich versuche also mit einem im gleichen VLAN-Netz hängenden Clienten nun einen OpenVPN-Tunnel zur pfSense und dem dort laufenden OpenVPN-Server aufzubauen.
Da ich zum ersten Mal mit pfSense arbeite und ebenso um ersten Mal einen OpenVPN-Server einrichte, stehe ich dabei jetzt vor einem Problem, bei dem ich für ein paar erfahrene Augen echt dankbar wäre. In meinem Betrieb kann ich dazu keinen fragen, da dort offenbar keine Erfahrungswerte vorhanden sind - und noch weniger Lust, sich damit oder einem Praktikanten auseinander zu setzen.
Konfiguriert wurde der OpenVPN-Server und die Clienten mit diesem Tutorial, das - eigentlich - straight forward ist: https://technium.ch/pfsense-openvpn-server-und-user-einrichten-tutorial/ . Für die Verbindung wird clientseitig diese Konfiguration exportiert:
Als Ergebnis lande ich bei jedem Connect-Versuch jedoch in diesem Fehler:
Das Log dazu sagt
während die Konfig so aussieht
und der Dienst für diese Verbindung aktiv ist:
Selbst wenn ich den Tunnelaufbau als ANY-ANY auf und über jedes Interface zulasse, lande ich im gleichen Fehler mit dem gleichen Logeintrag:
Ich poste hier mal die Screenshots der gesamten pfSense-Konfig und es wäre wirklich eine Hilfe, wenn da mal jemand drüber schauen könnte. U.U. sehe ich einfach den Wald vor lauter Bäumen nicht mehr und mag gar nicht ausschließen, dass ich da irgendwo einen kapitalen Bock geschossen habe, den ich schlicht seit Tagen übersehe.
CA:
CA des OpenVPN-Servers:
CERTIFICATES:
FIREWALL-RULES:
OpenVPN-Server:
pfSynch läuft, Failover funktioniert, lediglich die VPN-Verbindung will ich einfach nicht zum Laufen bekommen. Bin da als immer-noch-Noob natürlich jetzt am Ende mit meinem Latein. Würde mich freuen, wenn mir da jemand ein wenig weiterhelfen und auf den Pfad der Tugend zurückhelfen könnte, sonst müssen vermutlich noch weitere Mäuse plötzlich und unerwartet an der Stirnseite meines Schreibtischs versterben (und langsam kann ich mir das, neben dem sonstigen Frust, auch finanziell einfach nicht mehr leisten).
Gruß & Dank!
ich bin gesundheitsbedingt Umschüler in der FR Systemintegration und seit letztem Monat im Praktikumsbetrieb. Bevor die Frage wie ein rosa Elefant im Raum steht, warum ich dort nicht meine "Ausbilder" frage - weil das Praktikum alles andere als gut läuft und man offenbar jemanden erwartet hat, den man als kostenlose und fast fertige Arbeitskraft einsetzen kann. Das Umschüler/innen das nach einem Jahr Theorie nicht sind und sein können und bestenfalls im Stand eines Auszubildenden im 2. Lehrjahr sind, in die man natürlich auch entsprechend Zeit investieren muss, hatte man hier vermutlich nicht bedacht. Nicht falsch verstehen: ich hab richtig Bock auf IT-Systeme und Netzwerke und hab mir die Umschulung ausgesucht. Mir dünkt leider eher, der Betrieb - oder die IT Abteilung - hat keine Lust Leute in deren Arbeitsbereich einzuarbeiten, dort aus- oder weiter zu bilden.
Eine zur Abschlussprüfung zu erstellende Projektarbeit sollte man mit dem Praktikumsbetrieb besprechen und mit dessen Hilfestellung durchführen. Ich hatte das Vergnügen, dass es im Betrieb einen großen Ordner an seit Jahren ausstehenden und noch umzusetzenden Aufgaben gab, auf den sich meine Auswahlmöglichkeiten dann beschränkten. Das kleinste und zeitlich (bis zum Abgabetermin bei der IHK) am ehesten machbare war dabei der Aufbau einer Einwahlstruktur für Remote Access und IoT Geräte, deren Datenströme auf der öffentlichen Seite über 2 Lancoms laufen (mit gegenseitigem Failover), die Datenströme innerhalb der DMZ physisch zwingend getrennt werden müssen und dort über 2 Netgate 7100 1U mit pfSense geroutet sind. Beide pfSense müssen dann noch zusätzlich mit einem Failover auf jeweils eine VM mit einer virtuellen pfSense ausgestattet werden. Das Ganze hier kurz als Schema:
Momentan hänge ich bei der Einrichtung des OpenVPN auf der pfSense in einer Testumgebung. Testumgebung daher, da vom Betrieb ein Proof-of-concept gefordert wurde, bevor man die Hardware bestellt. Das bringt nur leider reichlich Probleme mit sich. Die pfSensen sind notgedrungen beide auf Workstations installiert und in einem VLAN eingebunden, mit dem Sie zumindest nach aussen telefonieren können. In dem mir zugewiesenen VLAN hängen noch ein paar hundert andere Geräte und eine statische Route oder Forwarding kann ich dort nicht einrichten. Ein Zugriff per DynDNS fällt damit natürlich auch aus. Die Einwahl soll grundsätzlich ausschließlich über OpenVPN und die Authentifizierung nur über einen PSK erfolgen. Ein (zusätzliches) User-Auth ist nicht gewünscht.
Ich versuche also mit einem im gleichen VLAN-Netz hängenden Clienten nun einen OpenVPN-Tunnel zur pfSense und dem dort laufenden OpenVPN-Server aufzubauen.
Da ich zum ersten Mal mit pfSense arbeite und ebenso um ersten Mal einen OpenVPN-Server einrichte, stehe ich dabei jetzt vor einem Problem, bei dem ich für ein paar erfahrene Augen echt dankbar wäre. In meinem Betrieb kann ich dazu keinen fragen, da dort offenbar keine Erfahrungswerte vorhanden sind - und noch weniger Lust, sich damit oder einem Praktikanten auseinander zu setzen.
Konfiguriert wurde der OpenVPN-Server und die Clienten mit diesem Tutorial, das - eigentlich - straight forward ist: https://technium.ch/pfsense-openvpn-server-und-user-einrichten-tutorial/ . Für die Verbindung wird clientseitig diese Konfiguration exportiert:
Als Ergebnis lande ich bei jedem Connect-Versuch jedoch in diesem Fehler:
Das Log dazu sagt
während die Konfig so aussieht
und der Dienst für diese Verbindung aktiv ist:
Selbst wenn ich den Tunnelaufbau als ANY-ANY auf und über jedes Interface zulasse, lande ich im gleichen Fehler mit dem gleichen Logeintrag:
Ich poste hier mal die Screenshots der gesamten pfSense-Konfig und es wäre wirklich eine Hilfe, wenn da mal jemand drüber schauen könnte. U.U. sehe ich einfach den Wald vor lauter Bäumen nicht mehr und mag gar nicht ausschließen, dass ich da irgendwo einen kapitalen Bock geschossen habe, den ich schlicht seit Tagen übersehe.
CA:
CA des OpenVPN-Servers:
CERTIFICATES:
FIREWALL-RULES:
OpenVPN-Server:
pfSynch läuft, Failover funktioniert, lediglich die VPN-Verbindung will ich einfach nicht zum Laufen bekommen. Bin da als immer-noch-Noob natürlich jetzt am Ende mit meinem Latein. Würde mich freuen, wenn mir da jemand ein wenig weiterhelfen und auf den Pfad der Tugend zurückhelfen könnte, sonst müssen vermutlich noch weitere Mäuse plötzlich und unerwartet an der Stirnseite meines Schreibtischs versterben (und langsam kann ich mir das, neben dem sonstigen Frust, auch finanziell einfach nicht mehr leisten).
Gruß & Dank!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4732970315
Url: https://administrator.de/forum/testumgebung-im-vlan-openvpn-auf-pfsense-4732970315.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
10 Kommentare
Neuester Kommentar
Momentan hänge ich bei der Einrichtung des OpenVPN auf der pfSense
Wegen der schlechten Skalierbarkeit und der Frickelei mit externer und überflüssiger VPN Client Software keine gute und auch intelligente Wahl für ein VPN. Das Thema hatten wir gerade erst:PFSense OpenVPN Server in bestehendem LAN - FW Rules greifen nicht
Mit den überal verfügbaren onboead Clients ist sowas deutlich besser umzusetzen und auch die Managebarkeit ist erheblich besser was sicher auch bei einer Prüfung ein Pluspunkt in der Argumentation ist.
Es entfällt auch die Zertifikatsfrickelei bzw. reduziert sich nur auf das Server Zertifikat sofern du den onboard IKEv2 Client verwendest. Bei L2TP kann sie völlig entfallen wenn man mit PSK arbeitet.
Über die statische Zuordnung der IP Adressen für die Einwahlclients lässt sich damit auch sehr einfach eine Trennung erreichen die man dann mit einem einfachen FW Regelwerk separiert.
Dein Design krank daran unendlich viele OpenVPN Prozesse laufen zu lassen für unterschiedliche Clients was etwas laienhaft ist und nicht und skaliert. Schon gar nicht mit dem nicht Multithreading fähigen, antiken OpenVPN. Praxistauglich ist das eher weniger.
Wenn es denn unbedingt das antiquierte OVPN sein muss macht man das immer über den Common Name des Clients und weist ihm dann einen bestimmten IP Pool zu, den man dann wieder wie oben per FW Regelwerk separiert.
Wenn es unbedingt SSL sein muss dann wäre das modernere Wireguard die bessere Wahl aber löst auch nicht das Problem des dann wieder erforderlichen zusätzlichen und eigentlich überflüssigen VPN Clients.
Wenn das auch der IHK Prüfer erkennt bewegst du dich mit dem Konzept auf dünnem Eis. Auch weil eigentlich der Lancom ebenso ein VPN/Firewall Router ist der als Cluster alles auch ohne die pfSense Materialschlacht erledigen könnte. Die Frage des Warum wird da sicher auch kommen zumal man die pfSense andersrum auch ohne die überflüssigen Router als Doppel NAT und Doppel Firewall Durchlauferhitzer davor nutzen könnte (und auch sollte).
Wenns das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
- Beide pfSense oder OPNsense kannst du auf allen Intel/AMD Plattformen betreiben.
- So gut wie alle NIC Chispsätze werden supportet
- Multi WAN ist eine Software Funktion der Firewall und immer gegeben
- HA/Failover + Load Balancing ebenso.
Spannender ist das Thema der HW Plattform. Mit deinen Anforderungen ist das sicher eine Herausforderung.
Die Frage die sich dabei stellt: Warum 8 mal RJ-45 Kupfer wenn man 4 mal SFP+ hat? Wozu so viele Cu Ports?
Du wirst ja sicher nicht alle Netzwerk Segmente mit einem einzelnen Kabel anschliessen sondern primär LACP LAGs arbeiten.
Besser bzw. universeller ist dann eine Plattform mit z.B. ein oder zwei 4er Karten SFP+ die supporten ja dann auch Cu mit 1G oder 10G je nach Transceiver. Damit kannst du dann (fast) jede beliebige 1 HE Hardware (Supermicro usw.) verwenden.
Ggf. erweitert das deine HW Portfolio Auswahl.