Messages

1

German - Deutsch / Re: OPNsense VM auf Proxmox

« on: October 01, 2024, 04:28:55 pm »

> ich bin noch neu bei der Thematik OPNsense & Proxmox, ich habe einen Server mit Proxmox VE8, darauf läuft eine VM mit OPNsense ... nun würde ich gerne den Proxmox hinter der OPNsense erreichbar machen.

Hi,

das ist ein wenig unspezifisch. Kannst du da etwas Details liefern? Gibts nur ein Interface oder mehrere etc.?
Denn wenn bspw. mehrere Interfaces zur Verfügung stehen, könnte man der OPNsense Instanz einfach direkt eines durchreichen und dann die vmbr0 die Proxmox per default anlegt, einfach als zusätzliches Netz hinter der Sense einklinken. Aber da dein Setup nicht bekannt ist, kann man das "WIE" leider so nicht beantworten. Der Möglichkeiten gibt es hier viele.

Cheers

2

German - Deutsch / Re: Richtlinienbasiertes Routing

« on: October 01, 2024, 04:26:36 pm »

nun ja, ich habe Regel:

IP4/6 UDP>ports>Gateway und IP4/6 TCP>ports>Gateway, also pro udp und tcp

Summasumarum 4 Regel pro Vlan.

Bei Gateway Setting "Standard" schätze ich sind beide ip4 und 6 Gateways Drin.

Das hat aber auch den Hintergrund, weil es - auch wenn es oft so genutzt wird - nicht zwangsläufig NUR ein Gateway pro IPAF (Adressfamilie) pro Interface gibt. Es gibt bspw. keinen Grund, dass man am WAN nicht auch zwei oder drei Gateway (IPs) haben könnte. Das ist dann zwar wieder seine ganz eigene Problemstellung (Stichwort reply-to und NAT etc.) aber möglich.

Ich stimme aber zu, dass es schön wäre eine Art "Alias" zu haben, was bei "WAN" automagisch die beiden IP4/6 GWs ausliest, die auch am Interface selbst konfiguriert sind, was ein vernünftiger Default wäre. Abweichend könnte man dann ja genauer spezifizieren wie jetzt auch.

Cheers

3

German - Deutsch / Re: Probleme mit LDAP SSL an Synology

« on: October 01, 2024, 04:20:53 pm »

> mir fehlt anscheinend irgendwo ein zertifikat.

Nope, dein AD bzw. dein AD/LDAP Setup hat wahrscheinlich auf dem PDC/DC kein richtiges Zertifikat gehabt, darum läuft auch die Synology einfach mit ihrem self-signed Schlumpf Zert. OPNsense braucht aber für sinnvolles Usermanagement via LDAP (soweit mir bekannt) eine saubere sichere Verbindung - sprich das Zert muss OK sein, was bei einem self-signed nicht so ohne weiteres geht. Entweder du stellst auf dem PDC ein sauberes LDAP Cert gegen eine eigene CA aus - und die Syno macht dann auch ein Cert gegen die gleiche CA für sich als weiterer DC -> dann kannst du das CA Zert bei der Sense einspielen und die kann sich dann gegen die beiden DCs problemlos connecten, weil die Zert Kette stimmt.

Ansonsten könntest du nur versuchen, das Stammzert von der Syno direkt auf der Sense als "trusted" einzuspielen, aber das wird wahrscheinlich auch nicht so nett.

Das ist BTW auch das, was im zitierten Beitrag steht. Seine Lösung (Post #3) war das Stammzert (also das der CA, die die internen Zertifikate für die LDAP Server ausgestellt hat) in die Sense einzuspielen. Da LDAPS inzwischen auch bei MS Standard ist, lohnt es sich, eine saubere interne Domain zu fahren, die nicht "irgendwas.local" ist (was bei Zertifikaten dann die Hölle lostritt), sondern eine ordentliche interne Domain (sowas wie lan/home/int.domain.tld) zu nutzen und ordentliche Zertifikate überall einzuspielen, dann gibts auch bei solchen SSL Baustellen keine größeren Probleme.

@Patrick: die Syno hat per default eigentlich ein self-signed, da gibts keine CA.

Cheers

4

General Discussion / Re: Security vulnerabilities in FreeBSD

« on: September 26, 2024, 04:43:40 pm »

@JeGr, not you personally, but:

The tickbox idi*ts are taking over. Wow...

No offense taken, I'm feeling it exactly the same way. We (Patrick and me) already talked about various cases in the usergroup meets and it really gets worse every time. And I (mostly) don't even blame our customers, because they often only have to fulfill these requirements - between a rock and a hard place - regardless of whether it makes sense or not. Just because someone higher up bought some insurance or they are even legally obligated to cater to those checklists. *sigh*

5

General Discussion / Re: Security vulnerabilities in FreeBSD

« on: September 12, 2024, 04:00:40 pm »

"that makes this one of the most dangerous vulnerabilities discovered in FreeBSD so far".

Says who? There's nothing of that alarmist kind in the security advisory.

Jumping in quickly as I also have customers that are asking the same thing. The problem is this:

https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2024-2056

As CERT Bund / BSI issued a critical warning >=9, various companies, KRITIS etc. are required(!) to act in no more then 10 days and patch that holes. So they want to know IF and if they are how fast that can be patched, workarounded, mitigated or somehow be done with.
There's also the resolution that you as vendor say "there is no danger there, move along", but they need some kind of answer on how to proceed. I've also checked the bugs and would guess that most/all of them would need local users or code to exploit, so if the firewall itself offers no service, no users to login besides admins etc. there's no imminent danger, but in that case the customers need to cover their bases for the CERT advisory or they'd be held accountable for not patching, potentially loosing their insurance cover or have to pay fines.

So even when not that dangerous for our firewall use case, an advisory is needed

Cheers
\jens

6

German - Deutsch / Re: Netzwerk, Security & Firewall Usergroup

« on: September 05, 2024, 08:05:48 am »

• Link in Startpost ergänzt
• Mini-Website mit Terminen und Links zum Pub hinzugefügt

7

German - Deutsch / Re: OpenVPN-Fragen - Migration von pfSense

« on: August 20, 2024, 12:37:38 pm »

> Noch ne Idee, weshalb DCO aus ist? Dachte, das geht jetzt mit FreeBSD 14.1?

Nein, tatsächlich nicht, da die Option aber jetzt neu dazugekommen ist, evtl. irgendwo noch ein Schalter zum explizit anschalten? Ich meinte ich habe im GIT gesehen, dass die per Schalter aktiviert werden muss, damit nirgends einfach DCO angeht.

Und ich meinte keine Client specific overrides - das ist ja im Server! Ich rede von der Client config, die du bspw. in den Tunnelblick reinkloppst. Die Client Config kannst du auch überschreiben wie du lustig bist. Bspw. bei nem Windows Client dann eben manuell noch register-dns mit reinklöppeln oder sowas. Deine Client Seiten-Konfig ist ja nicht fix - kannst du ja jederzeit umschreiben

Cheers

8

German - Deutsch / Re: VM vs Appliance - Geschmacksfrage?

« on: August 16, 2024, 03:47:24 pm »

Moin,

> Wahrscheinlich mache ich jetzt "ein Fass auf", aber ich frage trotzdem mal - und zwar im vollen Bewusstein, dass es "die" Lösung vermutlich nicht gibt:

Exakt. Die "beste" Lösung liegt immer im Auge des Betrachters bzw. in der entsprechenden Umgebung. Das kann für jeden abweichen Also Standardantwort der IT: "Es kommt drauf an"

> Wenn mein Host ein problem hat, startet auch die OPNsense nicht mehr, das ist mir klar, und deshalb schiele ich auf eine Appliance. Aber wenn ich mich "verkonfiguriere" oder (gibt es das überhaupt?) eine "kaputte Version" installiere, wie kann ich die OPNsense dann wiederbeleben? Bei der VM-Lsöung gehe ich einfach einen Snapshot zurück. geht das auf der Appliance auch? Gibt es dort so etwas wie "Timeshift"?

Aktuell meine ich - man möge mich korrigieren - dass es so einen Rollback oder Snapshot (zumindest automatisch oder via UI) (noch) nicht gibt. Bei einem Setup mit ZFS könnte man sich das aber durchaus entsprechend zusammenbauen, da ZFS genau das beherrscht via Snapshotting und Boot Environments. Da lohnt es auch mal zum Cousin pfSense zu schielen, die das seit letztem Jahr in der Plus mit drin haben und seit dem März Release diesen Jahres damit das Update Handling umgebaut haben: es wird dann nicht das Live System aktualisiert bei einem Upgrade, sondern erst ein Snapshot mit BE erstellt und dieser dann im Hintergrund aktualisiert. Ist alles fertig, wird einmalig in das neue BE reingebootet und wenn der Bootup sauber durchläuft wird der Snapshot als der neue aktive default bestätigt. Klappt was nicht oder resettet man bootet die Kiste einfach wieder ins alte BE.
Ich vermute aber, dass auf lange Sicht soetwas zumindest mit händischer Checkliste auch in OPNsense angedacht ist und vielleicht dann einen schicken Menüpunkt bekommt, der das dann automatisieren kann.

Ansonsten hast du die Hauptpunkte schon genannt. Setzt du die Firewall auf nen Hypervisor, hast du den kompletten Stack + die HV Hardware + die Netzwerk Geschichte, die potentiell schief gehen kann bis zur Firewall VM. Sprich: die Fehler die passieren können um die Firewall virtuell wegzureißen sind eben ein Vielfaches mehr als bei einer Appliance. Zusätzlich wird dann gern mal vergessen bei nem Hypervisor Update, dass dann kein Internet mehr da ist. Updates wenn Offline werden dann plötzlich schnell schwer. Und wenn man dann noch auf dem "direkte Einwahl"-Zug gesetzt hat mit Modem steht dann nicht mal ein vorgeschalteter Router zur Verfügung an den man sich mal kurz ranhängen kann, um die Sache wieder flott zu bekommen.

Wir haben da im Support schon viel gesehen, was mit HV/VMs zusammenhing. Von HV abgeschossen, Hardware Problem/Unverträglichkeit, Netzwerkkarte als VM bringt keine Performance, dediziertes Durchreichen der NIC macht Ärger, Datastore der VM bricht weg, VM/storage Migration friert die VM ein - dann läuft auch kein Traffic mehr, etc. etc.

Solange das alles im Homelab ist, muss man da einfach abwägen, ob der "alles in einer Box, spare mir Geräte" Ansatz an der Stelle mit den ganzen möglichen Problemen über dem "ich muss noch ne zweite Box bezahlen" Aspekt steht. Wie gesagt - das ist dann einfach Abwägung und ggf. auch Family/sonstige Teilnehmer mit Problem. Ich bin froh über meine TestVMs, aber würde meine HW Boxen nicht hergeben wollen

> ... und dann zur Praxis: Wenn ich umsteige, kann ich dann "einfach" meine bisherige VM-Konfiguration auf die Appliance bügeln, und es wird laufen? Oder ist die Portierung tückisch?

Prinzipiell ja. Die Konfiguration noch fix angepasst und das XML umgeschrieben von den alten HW/VM Interfaces zu den neuen der neuen Box, aber wenn man sich da einen kleinen Plan macht, geht das problemlos. Sichern, umschreiben, in neue Box reinladen, fertig.

Cheers
\jens

9

German - Deutsch / Re: OpenVPN-Fragen - Migration von pfSense

« on: August 16, 2024, 03:33:50 pm »

Hi Patrick,

die Meldung kommt auf dem Client? Was hast du denn auf dem Mac (vermute ich) als OpenVPN Version? Ist das wirklich 2.6.9?

Ansonsten würde ich auf jeden Fall bei mixed devices (aka Windows, Mac, Linux) auf dem Server das "register-dns" aus dem Push rausnehmen. Effektiv tut das ja meistens nur unter Windows etwas, das die anderen OS da nix mit anfangen können, ist also verständlich. Allerdings können das Linux, Android und Co im Normalfall entweder filtern oder ignorieren und blockieren nicht direkt den Verbindungsaufbau, das macht aus irgendeinem bescheuerten Grund nur Apple bei MacOS und iOS. Sind die einzigen Devices, die da mit unbekannten Optionen immer Terz machen.

Daher erstmal register-dns aus dem Push rausnehmen und statt dessen bei denen, die es brauchen (aka Windows) in die Client Config mit einbauen. Das geht da nämlich ganz gut auch so rum ohne dass das für alle gepusht werden muss.

Gruß Jens

10

German - Deutsch / Re: Testumgebung mit VPN Zugang konfigurieren

« on: August 15, 2024, 12:42:24 pm »

Genau das oder einfach die OPN parallel zur pf hängen, wenn das WAN im 15er Subnet ist, steht da ja offensichtlich eh noch nen anderer Router vornedran, dann kann man doch da die Separation schon machen?

11

German - Deutsch / Re: Neuling mit Multi WAN Routing fragen

« on: August 15, 2024, 08:56:16 am »

Hi!

> Wie kann ich dennoch die Fritzbox 192.168.178.1 erreichen für einstellungen sowie meine Geräte im Funknetz mit den jeweiligen Subnetzen?

Wo genau ist das Problem damit? Default GW oder nicht, deine Sense hat selbst ein Bein in dem Netz, denn wie du schreibst hat sie die .2 im FB WAN Netz. Ergo wird das nicht per Routing Table Default GW entschieden, sondern durch direkten Link, sie kann also die FB problemlos erreichen und deine Clients dahinter auch - zumindest wenn du die default Regeln hast. Wenn du Policy Regeln mit fixem GW oder GW Gruppe definiert hast, dann klappt es ohne Ausnahme nicht, sprich du brauchst eine Regel, die den Traffic erlaubt (destination 192.168.178.1) OHNE GW in der Regel (mit *) damit es über die korrekte Route raus geht. Sobald irgendwo ein PBR (policy based routing) greift, wird hart auf das angegebene IF geschoben, egal was in der Routing Table steht. Darum ist das mit Vorsicht zu nutzen, damit man nicht Traffic der woanders hin soll übers falsche GW schiebt.

Aber ohne konkretere Screens wie du was konfiguriert hast, kann ich das Problem sonst nicht eingrenzen.

Cheers
\jens

12

German - Deutsch / Re: IPSec Failover - Grundsatzfrage zum Verständnis

« on: August 15, 2024, 08:49:42 am »

Ist nicht möglich da Gegenstelle das nicht unterstützt. Wir können uns leider die Gegenseite nicht immer aussuchen und DAS ist zumindest ein Ding, das eben ohne großen Act oder zusätzliches Routing Protokoll funktioniert. Mit einer Gegenseite, die schon mit VPN Problemen hat auch noch Dinge wie OSPF oder BGP zu bauen wäre manchmal ein Albtraum. Klar geht es immer schöner, aber ich wollte das zumindest mal einwerfen, dass es technisch absolut machbar ist wie @tblum meinte und DynDNS da auch kein falscher Ansatz ist. Mind. für das remote GW der Gegenseite wirds gebraucht je nachdem was an ID unterstützt wird und was man da eingetragen bekommt. Und dann funktioniert das auch im Test recht smooth.

13

German - Deutsch / Re: Frage zu OpenVPN

« on: August 15, 2024, 08:46:13 am »

Für "normalen" Split-Tunnel Betrieb willst du gar nichts. (also literally) Denn du hast deine Netze definiert in den local subnets und das wird an den Client gepusht, damit dieser die dann als "remote subnets" bei sich in die Routing Table einträgt.

Man muss das auch nicht am Server unbedingt pushen wenn man wechseln möchte zwischen Split oder Full-Tunneling. Server auf Split einstellen (normal) und eine zweite Client Config für "Full Tunnel" machen ist überhaupt kein Problem und gern genutzt, wenn man statt dem normalen Fall (Ich muss mal kurz auf mein Homelab zugreifen) dann doch mal alles durch den Tunnel schieben will und ggf. auch DNS oder Internet darüber fahren möchte (um ggf. die IP zu Hause zu nutzen).

Die Redirect Gateway Konfigurationsvariablen kannst du auch in der Client Config setzen und dir damit 2 Stück bauen - eine ohne und eine mit "def1 autolocal" bspw. um bei Bedarf dann den Full-Tunnel zu nutzen. def1 weil es dein Default Gateway nicht anfasst am Client, was in manchen Situationen doof ist und autolocal zum Erkennen wo dein VPN peer sitzt. Meistens braucht man "local" nicht aber dafür gibts ja genau autolocal.

Beispiel:
Split: "Ich brauch nur fix ein File vom NAS zu Hause"
Full: "Ich sitz hier im Ausland und brauch meine IP zu Hause um irgendwas zu streamen"

Je nach Leitung und HW deiner Box mag man aber vllt. nicht immer Full laufen haben.

Cheers
\jens

14

German - Deutsch / Re: IPSec Failover - Grundsatzfrage zum Verständnis

« on: August 14, 2024, 03:45:04 pm »

> Danke, Patrick, das bestätigt in etwas das, was sich mir so erschließt. Schade, dass das nicht irgendwo deutlicher dokumentiert ist, das hätte mir einiges an Zeit erspart. Dann versuche ich mein Glück mal mit einem VTI-Tunnel.

Ich habe das leider noch nicht mit einer OPNsense testen können, aber mit eine pfSense funktioniert dein beschriebenes Szenario mit DynDNS und IPsec im normalen Routing Mode mit P2s genau so wie gedacht:

Aufbau:

Seite A: 3x WAN, IPsec ist konfiguriert auf einer GW Gruppe, so dass bei WAN1 Ausfall entsprechend WAN2/3 genutzt wird. OPNsense sollte das automatisch hinbekommen meine ich. Zusätzlich ein DynDNS Service eingerichtet, der prüft, welches WAN aktiv ist und die entsprechend aktive IP setzt.

IPsec IKE v2 konfiguriert mit Identifier als DNS mit DynDNS Namen als "MyID" und "RemoteID" einen Hostnamen der Remote Site. Gateway ist der Hostname der Gegenseite (fixe IP/DNS Name auf fixe IP, geht beides)

Gegenseite ist konfiguriert mit einzelnem WAN aber korrekt konfiguriertem DNS Hostnamen auf diese IP. Hier ist MyID der Hostname und RemoteID der DynDNS Name. Gateway ist hier ebenfalls der DynDNS Name.

Bei Schwenk der IP wird dann die DynDNS IP geändert via API beim Hoster, und der Tunnel versucht sich mit den neuen Daten frisch aufzubauen. Die Gegenseite braucht dann ab und an so zwischen 1-5min bis sie den DNS Namen refreshed hat, dann geht der Tunnel aber wieder up. Der Knackpunkt ist da wirklich die ID (dyndns Name) sowie das Gateway (ebenfalls der dyndns) der korrekt gesetzt sein muss, sonst meckert immer die Gegenstelle, dass es entweder einen ID oder GW Konflikt gibt.

Müsste das nochmal in OPNsense nachbauen, rein technisch kann es aber sowohl die Sense als auch der Charon/IPsec Daemon, somit ists - wenn überhaupt - noch nen UX Thema. Es könnte aber auch schlicht schon funktionieren. Eventuell klemmts aber noch am Refresh vom DynDNS beim IPsec Aufbau der Seite B (wo die statische IP klebt), denn wenn die die IP der DynDNS Adresse nicht aktualisiert, könnte sie natürlich beim GW Aufbau in ein Problem laufen. Ansonsten sollte das aber entweder mit der ID via Dyndns Name oder ID per selbst gesetzten nonsense IPs funktionieren.

Cheers
\jens

15

German - Deutsch / Re: Glückwunsch zum neuen Job, @Monviech!

« on: August 14, 2024, 10:27:12 am »

Dann lass das die "neue Frau" nicht hören

Glückwunsch auch von hier! Viel Erfolg und Spaß - trotz allem