1
23.1 Production Series / Re: New Errors in RADVD radvd can't join ipv6-allrouters on em0
« on: March 21, 2023, 08:14:15 pm »
hi,
patch works for me.
Thanks!
Markus
patch works for me.
Thanks!
Markus
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
German - Deutsch / Re: Captive Portal: Sitzung trennen
« on: April 08, 2021, 09:30:57 am »
Guten Morgen zusammen,
ich habe das gleiche Problem.
Die Sitzungen können nicht manuell getrennt werden.
Muss ein Bug-Report her?
Ist, meine ich, seit 21.1.3
Danke
Gruß
Markus
ich habe das gleiche Problem.
Die Sitzungen können nicht manuell getrennt werden.
Muss ein Bug-Report her?
Ist, meine ich, seit 21.1.3
Danke
Gruß
Markus
3
German - Deutsch / Re: Freeradius LDAP: LAN interfce anstatt WAN? (NAT?)
« on: February 06, 2020, 07:40:31 pm »
Jo, mal sehen...
Danke!
Danke!
4
German - Deutsch / Re: Freeradius LDAP: LAN interfce anstatt WAN? (NAT?)
« on: February 06, 2020, 06:20:51 pm »
Kein NAT, OK
heisst:
-das alles in den Tunnel geschoben wird?
-man noch irgendwelche FW-Regeln benötigt, die das dann erlauben?
-es mit ner dyn. IP aufwendig wird?
heisst:
-das alles in den Tunnel geschoben wird?
-man noch irgendwelche FW-Regeln benötigt, die das dann erlauben?
-es mit ner dyn. IP aufwendig wird?
5
German - Deutsch / Re: Freeradius LDAP: LAN interfce anstatt WAN? (NAT?)
« on: February 05, 2020, 07:35:23 pm »
Hallo zusammen,
darf ich hier noch mal nachhaken?
Des Rätsels Lösung war, nur die "eigene" WAN-IP mit /32 als zusätzliche IPSec SA bei der Tunneleinrichtung mit aufzunehmen?
Nur "Client-seitig"?
Oder benötigt man zusätzlich die besagten Nat-Regeln?
Sorry, aber ich konnte das hier nicht erfolgreich nachvollziehen...
(ähnliches Szenario: LDAP-Anfrage durch den Tunnel, allerdings clientseitig mit dynamischer IP)
Danke und Gruß!
Markus
darf ich hier noch mal nachhaken?
Des Rätsels Lösung war, nur die "eigene" WAN-IP mit /32 als zusätzliche IPSec SA bei der Tunneleinrichtung mit aufzunehmen?
Nur "Client-seitig"?
Oder benötigt man zusätzlich die besagten Nat-Regeln?
Sorry, aber ich konnte das hier nicht erfolgreich nachvollziehen...
(ähnliches Szenario: LDAP-Anfrage durch den Tunnel, allerdings clientseitig mit dynamischer IP)
Danke und Gruß!
Markus
6
German - Deutsch / Re: Sicherheitsniveau beim CaptivePortal mit https
« on: October 24, 2019, 04:17:46 pm »
Ok,
Ich habe nun zwischenzeitlich den schon vorhandenen Radius-Server auf meinem samba-ad-dc wieder aktiviert.
Damit funktionierte dann auch das mschap gegen das ad.
Dazu ist es aber nötig, mschapv2/also auch teilweise ntlmv1 zu aktivieren, das ist zwar gängig, behagt mir aber auch nicht so richtig.
Letztendlich habe ich reines eap-tls getestet und stelle gerade fest, dass das ja auch mit OPNsense geht!
War mir erst nicht so ersichtlich.
Prima!
Muss ich mal überlegen, wie ich am geschicktesten die Zertifikate verteile, aber so viele Clients werden es nicht werden.
Danke noch mal für die Info & den Support!
Gruß
Markus
Ich habe nun zwischenzeitlich den schon vorhandenen Radius-Server auf meinem samba-ad-dc wieder aktiviert.
Damit funktionierte dann auch das mschap gegen das ad.
Dazu ist es aber nötig, mschapv2/also auch teilweise ntlmv1 zu aktivieren, das ist zwar gängig, behagt mir aber auch nicht so richtig.
Letztendlich habe ich reines eap-tls getestet und stelle gerade fest, dass das ja auch mit OPNsense geht!
War mir erst nicht so ersichtlich.
Prima!
Muss ich mal überlegen, wie ich am geschicktesten die Zertifikate verteile, aber so viele Clients werden es nicht werden.
Danke noch mal für die Info & den Support!
Gruß
Markus
7
German - Deutsch / Re: Sicherheitsniveau beim CaptivePortal mit https
« on: October 18, 2019, 05:16:23 pm »
Nee, ich wollte eigentlich aufs LDAP zugreifen....
8
German - Deutsch / Re: Sicherheitsniveau beim CaptivePortal mit https
« on: October 18, 2019, 04:39:24 pm »
- 2 getrennte WLANs, CP für Gäste, WPA2 Enterprise für Mitarbeiter
OK!
- Anbindung an Radius (NPS) mit selbstsignierten Zertifikat und EAP-PEAP
Kein WindowsServer da, freeradius von der sense müsste auch gehen, ja?
- Keine LE Zertifikate
OK!
Danke!
Markus
OK!
- Anbindung an Radius (NPS) mit selbstsignierten Zertifikat und EAP-PEAP
Kein WindowsServer da, freeradius von der sense müsste auch gehen, ja?
- Keine LE Zertifikate
OK!
Danke!
Markus
9
German - Deutsch / Re: Sicherheitsniveau beim CaptivePortal mit https
« on: October 18, 2019, 08:55:54 am »
Guten morgen.
Ok, habs nicht genau genug erklärt.
Es handelt sich um ein Firmennetzwerk.
Dort möchte ich an mehreren Standorten bzw. in verschiedenen Abteilungen / Räumlichkeiten:
a:
Mitarbeitern u. Kunden Zugang zum Internet über W-Lan zur Verfügung stellen.
Mittels CaptivePortal, https-Verschlüsselung, Authentifizierung über Voucher oder aus dem AD /Ldap - Backend kein Problem und wohl sicher genug
b:
Einigen Mitarbeitern Zugang über W-Lan auf interne Ressourcen, z.B. smb, rdp, ...gewähren.
Ich dachte, CP wäre hier ebenfalls eine gute Idee, aber wenn dort keine Abhörsicherheit gegeben ist, dann lieber gleich das W-Lan direkt verschlüsseln.
PresharedKey finde ich ungünstig zu pflegen , also WPA-Enterprise mit Radius-Authentifizierung, backend dann wieder AD/LDAP
Ich habe mich damit noch nicht intensiv genug beschäftigt aber es scheint ja, dass man einen Weg benötigt, die Zertifikate auf unterschiedliche Clients zu bekommen und da befürchte ich etwas Aufwand.
Je nach Sicherheitsbedürfnis reicht es ja vielleicht auch aus, hier auf letsencrypt-Zertifikate zurückzugreifen.
Mache ich da einen Denkfehler?
Gruß
Markus
Ok, habs nicht genau genug erklärt.
Es handelt sich um ein Firmennetzwerk.
Dort möchte ich an mehreren Standorten bzw. in verschiedenen Abteilungen / Räumlichkeiten:
a:
Mitarbeitern u. Kunden Zugang zum Internet über W-Lan zur Verfügung stellen.
Mittels CaptivePortal, https-Verschlüsselung, Authentifizierung über Voucher oder aus dem AD /Ldap - Backend kein Problem und wohl sicher genug
b:
Einigen Mitarbeitern Zugang über W-Lan auf interne Ressourcen, z.B. smb, rdp, ...gewähren.
Ich dachte, CP wäre hier ebenfalls eine gute Idee, aber wenn dort keine Abhörsicherheit gegeben ist, dann lieber gleich das W-Lan direkt verschlüsseln.
PresharedKey finde ich ungünstig zu pflegen , also WPA-Enterprise mit Radius-Authentifizierung, backend dann wieder AD/LDAP
Ich habe mich damit noch nicht intensiv genug beschäftigt aber es scheint ja, dass man einen Weg benötigt, die Zertifikate auf unterschiedliche Clients zu bekommen und da befürchte ich etwas Aufwand.
Je nach Sicherheitsbedürfnis reicht es ja vielleicht auch aus, hier auf letsencrypt-Zertifikate zurückzugreifen.
Mache ich da einen Denkfehler?
Gruß
Markus
10
German - Deutsch / Re: Sicherheitsniveau beim CaptivePortal mit https
« on: October 17, 2019, 08:56:21 pm »
Ok, danke.!
Bedeutet: für ernsthafte "Übertragungssicherheit" bei zentraler Authentifizierung ist Radius inklusive Zertifikatsübertragung zum Client ein muss..
Fällt Dir auf Anhieb eine Alternative ein?
Danke
Gruß
Markus
Bedeutet: für ernsthafte "Übertragungssicherheit" bei zentraler Authentifizierung ist Radius inklusive Zertifikatsübertragung zum Client ein muss..
Fällt Dir auf Anhieb eine Alternative ein?
Danke
Gruß
Markus
11
German - Deutsch / [Gelöst] Sicherheitsniveau beim CaptivePortal mit https
« on: October 17, 2019, 06:13:44 pm »
Hallo zusammen,
bei der Einrichtung /Bearbeitung einer Zone des "Captive Portales" ist zum SSL-Zertifikat zu lesen:
"Wenn vorhanden, wird der gesamte Traffic über eine HTTPS-verbindung übertragen um vor Abhören zu schützen"
Meine evtl. naive Frage dazu:
Betrifft das nur den reinen Https-Verkehr, z.B. bei der Eingabe des Passwortes, oder gilt dass für den gesamten Netzwerkverkehr auf dieser Schnittstelle, also auch z.B. für smb / rdp /ftp, usw...
Ich frage, weil ich aus Bequemlichkeit gerne Zugänge für WLAN über CaptivePortale bereitstellen möchte, statt z.B. Radius für alle devices einzurichten.
Aber Sicherheit geht natürlich vor
Danke schon mal für Eure Antworten!
Gruß
Markus
bei der Einrichtung /Bearbeitung einer Zone des "Captive Portales" ist zum SSL-Zertifikat zu lesen:
"Wenn vorhanden, wird der gesamte Traffic über eine HTTPS-verbindung übertragen um vor Abhören zu schützen"
Meine evtl. naive Frage dazu:
Betrifft das nur den reinen Https-Verkehr, z.B. bei der Eingabe des Passwortes, oder gilt dass für den gesamten Netzwerkverkehr auf dieser Schnittstelle, also auch z.B. für smb / rdp /ftp, usw...
Ich frage, weil ich aus Bequemlichkeit gerne Zugänge für WLAN über CaptivePortale bereitstellen möchte, statt z.B. Radius für alle devices einzurichten.
Aber Sicherheit geht natürlich vor
Danke schon mal für Eure Antworten!
Gruß
Markus
12
German - Deutsch / Re: Nach update auf 18.1.7 funktioniert mobiler ipsec-client nicht mehr
« on: June 12, 2018, 12:17:36 pm »
Hallo Franco,
irgendwie hatte sich in letzter Zeit immer nur einer meiner Kollegen /innen zeitgleich angemeldet.
Habs jetzt noch mal selbst mit einem zweiten Laptop getestet und es funktioniert.
Also zwei parallele Verbindungen laufen definitiv über diese site2site-Leitung.
Dann wird ja auch mehr gehen!
(ich behalte das mal im Blick)
Hin und wieder sehe ich unter Statusübersicht "doppelte" Phase-2 Einträge, die als "rekeyed" markiert sind?
Ich nehme an, das hat was mit der konfigurierten lifetime zu tun?
Ansonsten ist das gelöst.
Danke
Gruß
Markus
irgendwie hatte sich in letzter Zeit immer nur einer meiner Kollegen /innen zeitgleich angemeldet.
Habs jetzt noch mal selbst mit einem zweiten Laptop getestet und es funktioniert.
Also zwei parallele Verbindungen laufen definitiv über diese site2site-Leitung.
Dann wird ja auch mehr gehen!
(ich behalte das mal im Blick)
Hin und wieder sehe ich unter Statusübersicht "doppelte" Phase-2 Einträge, die als "rekeyed" markiert sind?
Ich nehme an, das hat was mit der konfigurierten lifetime zu tun?
Ansonsten ist das gelöst.
Danke
Gruß
Markus
13
German - Deutsch / Re: Nach update auf 18.1.7 funktioniert mobiler ipsec-client nicht mehr
« on: June 08, 2018, 12:32:00 pm »
Hallo noch mal,
ich habe es jetzt so gemacht, wie bereits empfohlen.
-s2s-ipsec-Verbindung-
Das funktioniert nun auch nachdem ich
"rightid = %any"
hinzugefügt habe.
Evtl. war es ja das, was auch zuvor schon gefehlt hatte.
Ich hoffe, es lassen sich auch mehrere dieser Verbindungen parallel aufbauen.
Werd`s sehen..
Wenn`s geht, bin ich glücklich.
Danke!
Gruß
Markus
ich habe es jetzt so gemacht, wie bereits empfohlen.
-s2s-ipsec-Verbindung-
Das funktioniert nun auch nachdem ich
"rightid = %any"
hinzugefügt habe.
Evtl. war es ja das, was auch zuvor schon gefehlt hatte.
Ich hoffe, es lassen sich auch mehrere dieser Verbindungen parallel aufbauen.
Werd`s sehen..
Wenn`s geht, bin ich glücklich.
Danke!
Gruß
Markus
14
German - Deutsch / Re: Nach update auf 18.1.7 funktioniert mobiler ipsec-client nicht mehr
« on: June 04, 2018, 08:46:54 pm »
Die Nat-Regeln waren es jedenfalls nicht...
15
German - Deutsch / Re: Nach update auf 18.1.7 funktioniert mobiler ipsec-client nicht mehr
« on: May 29, 2018, 10:28:23 am »
Ok, einziger Report...dann liegt ja evtl doch eine Fehlconfig vor...
Haben (evtl. fehlerhafte) Nat-Regeln Einfluss auf den Tunnelaufbau?
Ich benutze carp und habe irgendwann mal eine Lösung gesucht, aus dem vpn-Netz auch auf den backup-node zu kommen und weitere Regeln nach dieser Anleitung erstellt:
https://doc.pfsense.org/index.php/CARP_Secondary_Unreachable_Over_VPN
Ich kann das ja ganz einfach mal raus nehmen und bei Gelegenheit testen.
Danke jedenfalls für die Mühen
Gruß
Markus
Haben (evtl. fehlerhafte) Nat-Regeln Einfluss auf den Tunnelaufbau?
Ich benutze carp und habe irgendwann mal eine Lösung gesucht, aus dem vpn-Netz auch auf den backup-node zu kommen und weitere Regeln nach dieser Anleitung erstellt:
https://doc.pfsense.org/index.php/CARP_Secondary_Unreachable_Over_VPN
Ich kann das ja ganz einfach mal raus nehmen und bei Gelegenheit testen.
Danke jedenfalls für die Mühen
Gruß
Markus
Pages: [1] 2