sperber
Goto Top

Testumgebung im VLAN, OpenVPN auf pfSense

article-picture
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:

architecture-2022-11-23 114142

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:

clientexport_psk_-192.168.1.1-2022.11.23-15_19_34

Als Ergebnis lande ich bei jedem Connect-Versuch jedoch in diesem Fehler:

error_lan_ip_psk_2022-11-23 133220

Das Log dazu sagt
log_lan_ip_psk_2022-11-23 133546

während die Konfig so aussieht
config_lan_ip_psk_2022-11-23 133357

und der Dienst für diese Verbindung aktiv ist:
services-2022-11-23 110744

Selbst wenn ich den Tunnelaufbau als ANY-ANY auf und über jedes Interface zulasse, lande ich im gleichen Fehler mit dem gleichen Logeintrag:

log-2022-11-23 130143

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-2022-11-23 111557

CA des OpenVPN-Servers:
ca-openvpn-2022-11-23 111701

CERTIFICATES:
certificates-2022-11-23 111749

FIREWALL-RULES:
fw-floating-any-2022-11-23 111149
fw-wan-2022-11-23 111114
fw-lan-2022-11-23 111301
fw-openvpn-2022-11-23 111436

OpenVPN-Server:
openvpn-servers-2022-11-23 110922

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!

Content-Key: 4732970315

Url: https://administrator.de/contentid/4732970315

Printed on: April 27, 2024 at 13:04 o'clock

Member: Visucius
Visucius Nov 23, 2022 at 14:22:55 (UTC)
Goto Top
Guck Dir evtl. mal GNS3 an. Vielleicht genügt das ja schon als "proof of concept"
Member: Sperber
Sperber Nov 23, 2022 at 14:27:20 (UTC)
Goto Top
Ich hab das schon komplett auf meinem heimischen Rechner in HyperV nachgebaut. Auch der GNS wäre natürlich zum Simulieren (für mich) völlig ausreichend gewesen, aber hier im Betrieb wird ein Test auf physischer Hardware gefordert. Ich hab mir das sicherlich nicht ausgesucht, glaub mir.
Member: C.R.S.
C.R.S. Nov 23, 2022 at 14:57:58 (UTC)
Goto Top
Hallo,

ich habe lange kein OVPN mehr konfiguriert, aber die laut Log problematische Zeile "cipher" wird sicherlich auch einen überlappenden Cipher erfordern, also z.B. "cipher AES-256-CBC" in deinem Fall.

Grüße
Richard
Member: Sperber
Sperber Nov 23, 2022 updated at 16:39:39 (UTC)
Goto Top
Dank Dir für die Antwort und das war zunächst auch meine Annahme. Daraufhin habe ich die CA und alle Zertifikate gelöscht und alles, auf der pfSense und den beiden Test-Clienten, x-mal neu aufgesetzt. Da die im OpenVPN-Server generierten und in die Clienten importierten Konfigurationsdateien aber auf genau den vom Server erzeugten und hinterlegten Server- und CA-Zertifikaten basieren, kann ich mir das als Fehlerquelle nicht vorstellen. Oder mache ich da einen Denkfehler? Ich wüßte hier nicht, wo noch eine Fehlerquelle liegen könnte. Bestenfalls, dass beim Export oder gar beim Import die .ovpn-Datei beschädigt werden würde. Aber wie könnte ich das denn prüfen? Ist das schon mal jemandem passiert oder hat da jemand eine Idee?
Member: aqui
Solution aqui Nov 24, 2022 updated at 07:41:14 (UTC)
Goto Top
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).
Member: Sperber
Sperber Nov 25, 2022 at 04:55:57 (UTC)
Goto Top
aqui, herzlichen Dank für Deinen Input. Das sind gute Denkanstösse für mich und ich bin gerade dabei, mich mit der IPsec Umsetzung zu beschäftigen. Wie das in den verkürzten Umschulungen wohl landläufig so ist, ist IPsec im einjährigen theoretischen Teil mal kurz gestreift worden - frei nach, gibt es, definiert sich durch xyz, hier sind zwei Folien -, L2TP hingegen nicht mal erwähnt worden. Dahingehend ärgere ich mich heute (über mich selbst), die Ausbildung nicht grundständig über 3 Jahre in einem Ausbildungsbetrieb angegangen zu haben. Die vollständig fehlende betriebliche Praxis fällt einem jetzt natürlich annähernd täglich auf die Füsse. "Trost" findet man da nur, weil es den anderen Umschülern scheinbar ebenso ergeht ;) . Meine Erfahrungen mit OpenVPN beschränkten sich bislang lediglich auf den Hausgebrauch als Enduser, bzw. das, was ich mir jetzt aus Tuts und Udemy zusammengeklaubt habe. Die Lernkurve hat also noch viel Luft nach oben.

Da das Projektdesign weitgehend vorgegeben ist, habe ich mich bislang vollständig daran orientiert, ohne nach links oder rechts zu schauen. Dein Tutorial zur IPsec-Einrichtung hab ich jedoch regelrecht verschlungen und mein Tunnelblick lichtet sich. Ich werde das heute mal versuchen aufzusetzen und dem Betrieb vermutlich als Alternative anbieten wollen. Deine Argumentation ist da recht überzeugend und ich werde mich mit IPsec in den kommenden Tagen sicherlich in depth beschäftigen. Auch für diese Anregung ein herzliches Dankeschön. Wenn es Dir nichts ausmacht, würde ich Dich da gerne hier und da mal mit Fragen naggen und Dein Wissen anzapfen, denn wenn jemand Wissen vermitteln kann, ist das für mich wie ein Honeypot.
Member: aqui
aqui Nov 25, 2022 at 08:39:53 (UTC)
Goto Top
Immer gerne...und viel Erfolg bei der Umsetzung! 🙂
Member: aqui
aqui Dec 12, 2022 at 13:00:45 (UTC)
Goto Top
Wenns das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Member: Sperber
Sperber Dec 20, 2022 updated at 09:06:50 (UTC)
Goto Top
Zitat von @aqui:

Wenns das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!

Ich hatte ihn erst mal offen gelassen, weil ich befürchtete, das wird eine Neverending-Story, aber die - für mich -richtungsgebende Antwort hätte ich in der Tat ja mal als Lösung markieren können. Mea culpa.

Aber wenn ich Dich schon "am Rohr" hab: als Hardware wurde sich letztlich für 2x Netgate 7100 1U + 4xSFP+ Modul entschieden. Der Screenshot ist von Donnerstagabend:
screenshot-www.voleatech.de-2022.12.15-14_31_45

Nachdem am Freitagmorgen die Kosten des Gesamtprojektes bewilligt wurden, die Ziellinie in Sicht und ich bestellen wollte, war über Nacht plötzlich End of Sale der 7100er + Karten. Wäre ja schön gewesen, der Händler Voleatech hätte da irgendwo einen Hinweis auf den Ihnen seit Ewigkeiten bekannten EOS gesetzt. Bin fast vom Stuhl gefallen und der Ärger wurde beim dortigen Anruf nur noch größer, dass man nicht mal einen Weg finden willaus den Restbeständen etwas zu verkaufen, sondern einem dafür ernsthaft die 8200 als Nachfolger anpreist, die anschlusslike für uns völlig unbrauchbar und nicht erweiterbar ist - und obendrein ein alibaba-likes Plastegerät auf ner Rackmontage. Ganz großes CustomerCare-Kino und zum in die Tischkante beissen.

Jetzt suche ich seit Freitag nach einer Alternative, die

  • auf der die pfSense (nicht openSense) betrieben werden kann
  • die Multi-Wan fähig ist
  • HA/Failover + Load Balancing kann
  • ähnlichen Durchsatz (insbesondere per VPN) wie die 7100
  • 8 RJ45 und mind. 4 SFP+ Ports sein eigen nennt
  • das Ganze bis max. 5.000 € kosten darf
  • und von einem deutschen/europäischen Händler gekauft werden kann.

Ich werde nur nicht fündig. Hast Du / hat jemand von euch alten Hasen da vielleicht eine passende Alternative im Hinterkopf? So langsam fange ich hier nämlich an zu verzweifeln.
Member: aqui
aqui Dec 20, 2022 updated at 09:59:23 (UTC)
Goto Top
  • 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.
Das ist also nicht das Thema da alles Featureset der Firewalls.

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.