5
OPNsense test
Moin Moin,
ich habe vor einiger Zeit versucht OPNsense zum laufen zu bringen.. war aber nicht erfolgreich und wollte jetzt noch mal von vorne beginnen. Aber ich habe das beklemmende Gefühl, ich brauche Hilfe.
Da ich aber letztes mal im Labyrinth der Einstellungen versunken bin, wollte ich dieses mal mir die Hilfe gleich holen bevor es für alles zu spät ist =) villeicht mag ein Mentor mich auf meiner Reise unterstützen. ^^
Mein Ziel: Ein Captive Portal zwischen MANAGEMENT und dem Internet zu errichten damit sich die leute via Voucher Zugriff verschaffen können.
OPNsense und linux lasse ich über virtual box laufen.
Zu OPNsense
3 Schnittstellen:
- LAN (192.168.1.0/24) [VB: em0 hostonly]
- MANAGEMENT (192.168.200.0/24)[VB: em2 Internes Netzwerk "intern-0009" promiscuous mode deny]
- WAN (home netzwerk 192.168.5.0/24)[VB:em0 netzwerkbrücke]
DHCP:
- pool: 192.168.200.150 - 200
- dns server : 192.168.5.13
zu Linux:
- puppi linux [VB: Internes Netzwerk "intern-0009" promiscuous mode deny]
- auto dhcp (ifconfig: 192.168.200.150/24 , dns 192.168.5.13 , gateway 192.168.200.1)
mein Ansatz so weit wäre:
das ich von dem rechner, (auf dem VirtualBox läuft), mit den Host-Only adapter über 192.168.1.1 auf die OPNsense GUI zugreifen kann. (klappt auch)
Die Linux-VM sich via DHCP eine adresse beschafft. (geht auch)
SO WEIT SO GUT =)
jetzt sind für mich aber einige Ungereimtheiten aufgetaucht, die ich einfach mal versuche zu schildern.
- wenn ich jetzt über das Terminal versuche die MANAGEMENT schnittstelle zu pingen funktioniert es nicht ... dhcp schon !??!
PS: danke, für das investieren deiner Zeit für mein Problem, im vorraus. fals Du noch irgend welche Infos über OPN brauchst, zu meinen aktuellen Einstellungen, werde ich versuche diese so schell wie möglich zu dokumentieren. =)
(zum Abschluss noch ein paar Bilder bei den ich nicht wusste wohin damit [deaktiviertes captive portal, routen, management schnittstelle] =)
Edit: ich hoffe ich habe das richtige Thema erwischt *~*
ich habe vor einiger Zeit versucht OPNsense zum laufen zu bringen.. war aber nicht erfolgreich und wollte jetzt noch mal von vorne beginnen. Aber ich habe das beklemmende Gefühl, ich brauche Hilfe.
Da ich aber letztes mal im Labyrinth der Einstellungen versunken bin, wollte ich dieses mal mir die Hilfe gleich holen bevor es für alles zu spät ist =) villeicht mag ein Mentor mich auf meiner Reise unterstützen. ^^
Mein Ziel: Ein Captive Portal zwischen MANAGEMENT und dem Internet zu errichten damit sich die leute via Voucher Zugriff verschaffen können.
OPNsense und linux lasse ich über virtual box laufen.
Zu OPNsense
3 Schnittstellen:
- LAN (192.168.1.0/24) [VB: em0 hostonly]
- MANAGEMENT (192.168.200.0/24)[VB: em2 Internes Netzwerk "intern-0009" promiscuous mode deny]
- WAN (home netzwerk 192.168.5.0/24)[VB:em0 netzwerkbrücke]
DHCP:
- pool: 192.168.200.150 - 200
- dns server : 192.168.5.13
zu Linux:
- puppi linux [VB: Internes Netzwerk "intern-0009" promiscuous mode deny]
- auto dhcp (ifconfig: 192.168.200.150/24 , dns 192.168.5.13 , gateway 192.168.200.1)
mein Ansatz so weit wäre:
das ich von dem rechner, (auf dem VirtualBox läuft), mit den Host-Only adapter über 192.168.1.1 auf die OPNsense GUI zugreifen kann. (klappt auch)
Die Linux-VM sich via DHCP eine adresse beschafft. (geht auch)
SO WEIT SO GUT =)
jetzt sind für mich aber einige Ungereimtheiten aufgetaucht, die ich einfach mal versuche zu schildern.
- wenn ich jetzt über das Terminal versuche die MANAGEMENT schnittstelle zu pingen funktioniert es nicht ... dhcp schon !??!
PS: danke, für das investieren deiner Zeit für mein Problem, im vorraus. fals Du noch irgend welche Infos über OPN brauchst, zu meinen aktuellen Einstellungen, werde ich versuche diese so schell wie möglich zu dokumentieren. =)
(zum Abschluss noch ein paar Bilder bei den ich nicht wusste wohin damit [deaktiviertes captive portal, routen, management schnittstelle] =)
Edit: ich hoffe ich habe das richtige Thema erwischt *~*
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 352706
Url: https://administrator.de/contentid/352706
Ausgedruckt am: 19.11.2024 um 20:11 Uhr
5 Kommentare
Neuester Kommentar
Wenn du den hiesigen Tutorials dazu folgst sollte das Setup ein Kinderspiel sein:
Für die Firewall an sich:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
und für das Captive Portal:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Da Opensense ein 100%iger Fork zur pfSense ist sind die gesamten ToDos vollkommen identisch.
Was die Zuordnung der VM Schnittstellen anbetrifft in einer VM hast du ja folgende Voraussetzungen:
2 NICs solltest du also mindestens im Hypervisor Rechner dafür haben.
Wenn das nur ein Test sein soll, dann kann man das interne LAN Interface der FW natürlich auch auf ein internes Netzwerk isolieren. Hier musst du dann noch eine VM mit einem Client PC einhängen.
In dem Falle würde dann auch eine einzelne NIC reiche an die müsste man dann den WAN/Internet Port mit einer Bridge anhängen.
Ist der WAN Port dann als DHCP Client konfiguriert zieht er sich vom lokalen Router eine IP, Default Gateway und DNS Server.
Dann sähe das So aus:
VM WAN Port = Bridge auf Hypervisor NIC = Port zieht sich aus dem lokalen LAN auch eine .5.x IP
VM LAN Port = Isoliertes LAN in der VM = Simuliert das lokale LAN an der Firewall
VM Management = Host Adapter = Isolierte Verbindung Hypervisor VM = nur Konfig Zugriff.
Nur nebenbei: Eine Firewall gehört eigentlich niemals in eine VM aus Sicherheitsgründen. Zum testen im Labor ist das natürlich OK.
Für die Firewall an sich:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
und für das Captive Portal:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Da Opensense ein 100%iger Fork zur pfSense ist sind die gesamten ToDos vollkommen identisch.
Was die Zuordnung der VM Schnittstellen anbetrifft in einer VM hast du ja folgende Voraussetzungen:
- Der Hostadapter ist vollkommen isoliert nach außen, geht also nur vom Hypervisor (Linux) zur VM. Vermutlich soll der Management Port dann auch nur für den Konfig Zugriff da sein, richtig ?
- Deine beiden anderen Schnittstellen an der Firewall VM wie Lokales LAN und Internet Port (WAN) musst du ja irgendwie isoliert auf externe NICs am Hypervisor mappen.
2 NICs solltest du also mindestens im Hypervisor Rechner dafür haben.
Wenn das nur ein Test sein soll, dann kann man das interne LAN Interface der FW natürlich auch auf ein internes Netzwerk isolieren. Hier musst du dann noch eine VM mit einem Client PC einhängen.
In dem Falle würde dann auch eine einzelne NIC reiche an die müsste man dann den WAN/Internet Port mit einer Bridge anhängen.
Ist der WAN Port dann als DHCP Client konfiguriert zieht er sich vom lokalen Router eine IP, Default Gateway und DNS Server.
Dann sähe das So aus:
VM WAN Port = Bridge auf Hypervisor NIC = Port zieht sich aus dem lokalen LAN auch eine .5.x IP
VM LAN Port = Isoliertes LAN in der VM = Simuliert das lokale LAN an der Firewall
VM Management = Host Adapter = Isolierte Verbindung Hypervisor VM = nur Konfig Zugriff.
Nur nebenbei: Eine Firewall gehört eigentlich niemals in eine VM aus Sicherheitsgründen. Zum testen im Labor ist das natürlich OK.
Hi,
Wenn MANAGEMENT ursprünglich OPT1 war, hat sie bei default keine Regel (-> deny all).
Erstelle mal eine allow all Regel und aktiviere Logging.
CH
- wenn ich jetzt über das Terminal versuche die MANAGEMENT schnittstelle zu pingen funktioniert es nicht
Welche Firewall Regeln hast du auf der MANAGEMENT Schnittstelle ?Wenn MANAGEMENT ursprünglich OPT1 war, hat sie bei default keine Regel (-> deny all).
Erstelle mal eine allow all Regel und aktiviere Logging.
CH
Welche Firewall Regeln hast du auf der MANAGEMENT Schnittstelle ?
Guter Punkt !Oft vergisst man das alle NICHT LAN Ports allen Traffic blockieren wie es ja bei Firewalls immer üblich ist.
In der Default Konfiguration ist bei Opensense und auch pfSense nur der LAN Port mit einer Default any zu any Regel versehen die Traffic passieren lässt.
Alle anderen Ports blockiewren per Dewfault jeglichen Traffic und lassen ihn erst passieren wenn eine entsprechende Regel dort konfiguriert ist !
Oh ja .. hab jetzt auf dem MANAGEMENT die Firewall überarbeitet mit einer any - any Regel .. jetzt funktioniert es auch (blutige Anfänger mal wieder =)
da ich von der linux maschiene auch ins Internet gehen würde, habe ich ja die Routen angelegt(0.0.0.0/0 konte man nicht eintragen da bin ich auf folgendes ausgewichen =):
da das auch nicht funktioniert, frag ich mich: ob das überhaupt richtig ist bzw. brauch ich überhaupt eine Route? da es für die eigene Schnittstelle des selben Gerätes ist ...
WAN:
Danke ! =)
Edit: (an euch beide =)
da ich von der linux maschiene auch ins Internet gehen würde, habe ich ja die Routen angelegt(0.0.0.0/0 konte man nicht eintragen da bin ich auf folgendes ausgewichen =):
da das auch nicht funktioniert, frag ich mich: ob das überhaupt richtig ist bzw. brauch ich überhaupt eine Route? da es für die eigene Schnittstelle des selben Gerätes ist ...
Welche Firewall Regeln hast du auf der MANAGEMENT Schnittstelle ?
Danke ! =)
Edit: (an euch beide =)
da ich von der linux maschiene auch ins Internet gehen würde
Mit "Linux Maschine meinst du den Hypervisor also da wo die Virtual Box rennt ??Da wären dann Routen völliger Quatsch weil diese >Maschine ihre IP und default Route ja vom Internet Router bekommt.
Wenn nicht hast du ja eine statische IP mit default Gateway konfiguriert. Zusätzliche Routen braucht der Hypervisor logischerweise nicht.
Analog die Firewall am WAN Port die sich entweder alles per DHCP zeiht vom Internet Router oder du es statisch konfigurierst.
brauch ich überhaupt eine Route?
Nein !Im Gegenteil: Das ist kontraproduktiv !
Deine Firewall Regeln haben noch ein paar Fehler....
1.) LAN Port
Es ist Quatsch das Management LAN nochmal separat anzugeben wenn du davor eine Scheunentor Regel hast * die alle Netze erlaubt.
Da immer die Grundregel gilt: First match wins wird die überflüssige Extra Regel mit dem dedizierten Management Netz nie greifen.
Den Unsinn kannst du also besser löschen.
2.) WAN Port
Da du die Firewall ja in einer NAT Router Kaskade mit dem Internet Router betreibst solltest du hier dein internes Netzwerk immer erlauben mit der ersten Regel !
Die pfSense hat dafür einen Haken "Allow private RFC 1918 IP networks" was das erledigt am Interface.
Keine Aknung oder der Opensense Fork das auch hat.
Ansonsten solltest du in deiner Testkonfig eine ALLOW Regel erstellen die das lokale Netz am WAN Port (Source) auf die WAN Port IP (Destination) mit Protocoll ANY erlaubt.
