Messages

151

German - Deutsch / Re: Unifi AP -> VLAN -> WLAN/LAN Bridge

« on: April 17, 2018, 07:24:38 pm »

Momentan habe ich 2 SSIDs. Eine als Zugang über WPA Personal mittels PSK. Ich habe leider Geräte, die Enterprise nicht beherrschen, aber deren Abwesenheit den Hausfrieden gefährdet.

Eine zweite SSID ist für alle Geräte, die WPA Enterprise unterstützen und direkt ins LAN sollen. Dafür läuft auf meiner Sense auch der FreeRADIUS.

Die PSK SSID geht über ein VLAN das ich extra für alle "normalen" WiFi Clients angelegt habe. Da sind auch die E.T. nach haus telefonieren Features blockiert.

Die EAP SSID wird nich getagged und geht somit direkt ins LAN. Momentan sind da die Laptops und mein Handy drin.

152

German - Deutsch / Re: Unifi AP -> VLAN -> WLAN/LAN Bridge

« on: April 17, 2018, 11:55:16 am »

Kann man durchaus so machen. Ich würde jedoch eine feste Zuordnung von SSID und VLAN bevorzugen und nicht userbasierte Tags vergeben. Bei einem Multi-SSID fähigen Gerät ja auch kein Problem.

Wobei es in deinem Fall aufgrund der Fülle an VLANs dann doch Sinn machen könnte.

153

German - Deutsch / Re: Unifi AP -> VLAN -> WLAN/LAN Bridge

« on: April 16, 2018, 11:14:30 am »

Was mir nicht klar ist, ist, was passiert, wenn ich bridge. Gelesen habe ich viel, allein ist es nicht erhellend gewesen.

Stell dir vor, du hast 2 Netzwerkkarten: eth0 und eth1

Diese sind erstmal völlig unabhängig von einander und der Traffic an diesen Karten ist auch getrennt.

Es gibt nun 2 Möglichkeiten, eine Verbindung zwischen diesen Netzwerkkarten zu realisieren, beide funktionieren auf Betriebssystem (Software)-Ebene.

- Durch Forwarding:
Pakete werden von eth0 auf dem OS "zwischengespeichert" und von diesem Zwischenspeicher an eth1 weitergeleitet. Dazwischen kann auch NAT betrieben werden.

- Durch Bridging:
Bridging sorgt kurz gefasst dafür, dass eth0 und eth1 zu einer einzigen Netzwerkkarte "zusammengefasst" werden. Das heißt, dass ab dem Zeitpukt auch die komplette Bridge als "LAN-Interface" gelten muss.

Beispiel bei dir:
Bridge zwischen WLAN(Familie) und LAN: Die Bridge, die du erstellst, stellt dann dein neues LAN dar und für diesen Bridge-Adapter musst du auch alle IP Konfigurationen tätigen. Die Konfiguration von LAN wird damit obsolet. Du musst also auch deine IP und DHCP Konfiguration auf das Bridge-Interface umziehen.

Wie gesagt, das alles klappt, aber wäre nicht mein favorisierter Aufbau. Wenn der AP am Switch hängt ist er direkt mit dem "Haupt"-Netzwerk verbunden. Wenn du den Switchport nun als VLAN Trunkport konfigurierst kannst du auch die anderen VLANS über den AP benutzen.

154

German - Deutsch / Re: Unifi AP -> VLAN -> WLAN/LAN Bridge

« on: April 15, 2018, 07:42:32 pm »

Warum willst du denn bridgen? Ich würde 3 VLAN Interfaces erstellen (alle am selben realen eth device) und dort den AP anschließen. Die sense kümmert sich dann automatisch um das Routing.

Bridging brauchst du nur, wenn sich Adressbereiche überlappen. Da aber jedes VLAN ne andere Netzadresse haben sollte, sehe ich hier keine Notwendigkeit dafür.

edit:
sehe gerade eins der Drahtlos-Netze soll direkt ins LAN gehen. Dann stimmt es, brauchst du Bridging.

Andere Möglichkeit wäre, den AP direkt an den VLAN-fähigen Switch anzuschließen. Somit umgehst du die Notwendigkeit des Bridgings auf der Sense und müsstest nur 2 zusätzliche VLANs anlegen.

155

German - Deutsch / Re: [gelöst] IPsec Site2Site Verbindung aufgebaut, aber Routing falsch.

« on: March 07, 2018, 02:43:41 pm »

Tja, leider bietet Amazon keinen VPN Service auf Basis von OpenVPN. Und unser Admin weigert sich Netze anzubinden, die mit einem "selbst zusammengebastelten" VPN Gateway funktionieren.

Ich muss dazu sagen der wirkliche Tunnel wird später mit seiner liebsten Sophos XG aufgebaut werden. Ich habe die Sense jetzt nur mal getestet um zu gucken, dass alles funktioniert mit dem VPN.

Najo, es funzt. Nach mit die Sintflut :-D

156

German - Deutsch / Re: VPN - Anbindung an SAMBA 4 - LDAP

« on: March 07, 2018, 10:59:04 am »

Wenn die OPNsense Implementierung von LDAP OpenLDAP ist, wirst du mit deinem Plan kein Glück haben.
Die Samba 4 AD funktioniert mit einer völlig anderen LDAP Implementierung, die OpenLDAP als Backend nicht unterstützt.

157

German - Deutsch / Re: IPsec Site2Site Verbindung aufgebaut, aber Routing falsch.

« on: March 06, 2018, 09:39:46 pm »

So, habs hinbekommen.

Das Routing scheint in der Tat korrekt zu sein. Und auch, dass kein extra Interface für IPsec existiert, wie bei OpenVPN. Es hat geholfen, im WAN den Haken bei "blockiere private Netze" zu entfernen.

158

German - Deutsch / [gelöst] IPsec Site2Site Verbindung aufgebaut, aber Routing falsch.

« on: March 06, 2018, 03:50:33 pm »

Hallo!

Ich habe bei Amazon AWS ein IPsec VPN konfiguriert. Die OPNsense habe ich entsprechend Amazons Daten konfiguriert. Ich kann den Tunnel erfolgreich aufbauen, aber irgendwie erreiche ich keine Clients der Gegenseite.

Hier meine Config:

Phase 1

Code: [Select]

Anschlussart: Sofort starten
Schlüsselaustauschversion: V1
Internet Protokoll: IPv4
Schnittstelle: WAN
Ferner Gateway: x.x.x.x (Adresse des VPN Gateways auf Amazon-Seite)

Authentifizierungsmethode: Mutual PSK
Bestimmungsmodus: main
Meine Kennung: Meine-IP-Adresse
Peer-Identifizierer: Peer IP-Adresse
Pre-Shared Schlüssel: der von AWS generierte Schlüssel
Crypto-Algo: aes128
Hash-Algo: SHA1
DH Group: 2 (1024 bit)
Lebenszeit 28800
ReKey, Reauth, Tunelisolation: unchecked
NAT Traversal: Aktivieren
MOBIKE: unchecked
DPD: 10/3

Phase 2

Code: [Select]

Modus: Tunnel IPv4
Lokales Netzwerk: Typ: LAN Subnetz
Entferntes Netzwerk: Typ: Netzwerk: 10.8.0.0 / 24
Protokoll: ESP
Algos: aes128
Hash-Algos: SHA1
PFS Gruppe: 2 (1024 bit)

Ich kann den Tunnel erfolgreich aufbauen, aber micht wundert die Routigtabelle:

Code: [Select]

Protokoll   Ziel                   Gateway            Mark.      Verw.  MTU       Interface
ipv4         10.8.0.0/24       62.214.63.93      US          0        1492      pppoe0/wan

Wenn ich also das Remote-Netzwerk erreichen will, geht er direkt über mein Gateway. Da stimmt doch was nicht.

Ich habe auch kein neues Interface für IPsec. Wird dort nicht wie bei OpenVPN ein Interface erstellt?

159

German - Deutsch / Re: Layer 2 filtering

« on: March 02, 2018, 09:33:26 pm »

Schade, nicht was ich hören wollte, aber danke :-)

160

German - Deutsch / Re: OpenVPN User mit eingeschränkten Rechten (Netzwerk-Zugriff ja, surfen nein)?

« on: March 02, 2018, 09:31:41 pm »

Du musst Regeln für das OpenVPN Interface schreiben.

zB.

Code: [Select]

Aktion: Erlauben
TCP/IP Version: IPv4
Quelle: Einzelner Host/Netzwerk 10.1.2.76
Ziel: WasAuchImmer


Code: [Select]

Aktion: Blockieren
TCP/IP Version: IPv4
Quelle: Einzelner Host/Netzwerk 10.1.2.76
Ziel: jeglich

Da es heißt erste Regel matcht, erstelle zuerst die Erlauben-Regeln und zum Schluss die alles Blockieren Regel. Siehe Oben.

161

German - Deutsch / Layer 2 filtering

« on: March 02, 2018, 02:51:57 pm »

Hallo,

gibt es eine Möglichkeit Firewallregeln zu erstellen, in der Quelle und/oder Ziel MAC-Adressen sind? Hintergrund wäre, dass ich einige interne Regeln (Inter-VLAN) schreiben möchte, die IP-Address-unabhängig sind.

162

German - Deutsch / Re: OpenVPN User mit eingeschränkten Rechten (Netzwerk-Zugriff ja, surfen nein)?

« on: March 02, 2018, 02:02:13 pm »

In der Regel bekommen die Clients mit dem selben CommonName immer wieder die selbe IP Adresse.

Dieses Mapping kann man auch manuell erzwingen um sicher zu gehen.
Dafür geht man unter VPN->OpenVPN->Client-spezifische Konfiguration

Dort legst du eine neue CSC (client specific config) an.
Du wählst deinen Server,
dann den CommonName des Zertifikates des Users, dem du die feste IP zuweisen willst.
Und unter erweitert trägst du dann ein:

Code: [Select]

ifconfig-push 10.3.0.44 255.255.255.0
Wobei in dem Falle 10.3.0.44 eine IP in der Range deines OpenVPN virtuellen Netzes ist und die Netzmaske muss auch mit den Servereinstellungen übereinstimmen.

Jetzt kannst du zB. allen unerwünschten Traffic über die Firewall blockieren und Ausnahmen für deine statischen Adressen anlegen.

163

German - Deutsch / Re: Nach Update-grade bootet Box nicht mehr

« on: March 01, 2018, 06:16:48 pm »

Die Trennung von Update und Upgrade hat schon lange Tradition. Sei es bei Anwendersoftware, Betriebssystemen usw.

Updates sollten "aktualisierend" sein, aber weder Kompatibilität oder Funktionalität einschränken oder ändern.
Upgrades nennt man dann meist die Major-Version "Updates" bei denen auch mal alte Zöpfe abgeschnitten oder völlig neue Programmversionen verwendet werden können.

Update bedeutet wörtlich sowas wie Aktualisierung und Upgrade eher Verbesserung, Heraufstufung.

Linguistisch sowie kontextuell also durchaus ein merklicher Unterschied.

Was in deinem Falle optimaler gewesen wäre wird dir wohl zum jetzigen Zeitpunkt keiner sagen können. Generell sollte weder beim Update, noch beim Upgrade die Kiste irreparabel abstürzen. Das nächste mal würde ich aber an deiner Stelle ein Update/Upgrade auf der Kommandozeile machen. Hat den Vorteil, dass durch Scrollback alle Meldungen nachvollziehbar bleiben.

164

German - Deutsch / Re: opnsense, pf und ein paar Anfängerfragen

« on: February 21, 2018, 01:45:57 pm »

Nein.

Ein User in der Gruppe Admins hat vollen Zugriff auf die GUI. Er kann auch im CLI Menü Einstellungen vornehmen.
Er ist aber auf FreeBSD Ebene nicht root gleichgesetzt. Das geht auch gar nicht, denn root ist root (uid 0) und kein anderer Nutzer kann die selben Rechte haben wie root. Du benötigst also immer su oder sudo, um Systemadministrationsaufgaben zu erledigen.

Wie auch immer, die Mitgliedschaft in admins sichert dem User zu, dass der su oder sudo überhaupt benutzen darf um root zu werden.

Ich habe root zB. deaktiviert und nutze einen privilegierten adminuser, der nach bedarf dann auch über sudo root-aufgaben machen kann.

165

Documentation and Translation / [SOLVED] Open up the wiki to the community

« on: February 21, 2018, 12:11:47 pm »

Hey!

It would be really nice, if the wiki was open for all people to contribute. Knowledge worked out in the forums could be added there, new articles and tutorials could be made and of course, if the core articles which are available now would be accessible, the community could also improve the docs more easily.

Closed wikis may give the project owners better controlling mechanisms but they are usually a bottleneck. Also, they may "force" people to post their knowledge somewhere else, spread across the whole internet.