Messages

Wie kann ich diese Funktion nun umter den Instances addressieren? Ich habe bereits mit Bind address probiert, leider ist dann die Clienteinwahl nicht mehr möglich.

Weshalb ist die Einwahl dann nicht möglich? Firewall Regeln geprüft? Firewall Logs bzw. OpenVPN Logs geprüft, wohin sich der Server dann bindet?

Wenn du den Server wie vorher auf die WAN IP bindest - oder eine WAN VIP - dann sollte dieser auch genauso wie vorher dort hören und Verbindungen annehmen. Wenn das nicht (mehr) geht, klingt das eher nach einem seltsamen Routing. Wie ist denn der Netzaufbau und hat der sich verändert?

Cheers

Hi,

lass doch bitte mal für die PS jeglichen Port-Kram da raus. Das ist Unfug und muss da nicht sein. Wenn man unbedingt für irgendwas Type 1 absolute Freigabe braucht - und ich hab das noch nie - dann ist das vielleicht notwendig aber ich habs in all der Zeit noch nicht gebraucht. Type 2 reicht mir völlig.

Bitte den ganzen Quatsch mit Ports rauslassen.
Einfach nur eine NAT Outbound Regel, die für die QUELL-IP der PS sagt "du darfst ausgehend mit STATIC PORT raus" statt wie sonst mit dynamic. Fertig, speichern, testen. Sollte genügen.

Hier: kein uPNP aktiv. Outbound NAT auf manuell (ich mag die Automatik nicht, da zu viel eingetragen wird, was bei mir nichts im Netz zu suchen hat). Unter meinen Localhost NATs und VOR den normalen Outbounds für udpp/500 mit static und alles andere via random Ports eingefügt ist dann die Regel.

IF: WAN
Source: Consoles (alias)
Port: *
Dest: *
Port: *
NAT: WAN_address
Static Port: yes!

Done. Apply, ein wenig warten, Konsole ggf. neu verbinden/neustarten, damit die States Zeit haben zu expiren, dann nochmal testen.

Cheers :)

...Ich versuche immer, adressbasierte Firewall-Regeln so weit wie möglich zu vermeiden.

und

...Daher bei OVPN Regeln (oder WG etc.) immer Source mit angeben.

äääähhh, also

Ich würde mich da Patrick anschließen.

verstehe ich was falsch oder sind da deutliche UNTERSCHIEDE zwischen den Posts was FW-Regeln für VPN anbelangt?

Sorry die Antwort ging irgendwie unter und wurde mir jetzt erst als Benachrichtigung angezeigt.

Du hast da meine Posts in falscher Reihenfolge zusammengestückelt - so hab ich das ja absichtlich nicht geschrieben. Aber zugegeben, man hätte vielleicht die entsprechenden Sätze quoten sollen.

Was mit Zustimmung gemeint war: wir richten auch einzelne Server pro User(gruppe) VPN ein. Mitarbeiter VPN ist da strikt von Admin oder Dienstleister VPN getrennt.

Was die Firewall Regeln angeht: auch da stimme ich zu keine ADRESSbasierten Regeln zu machen. Also kein Schnick mit "User X bekommt bei Einwahl IP Y zugewiesen und wird damit dann gefiltert". Das geht meistens schief. Und ist unflexibel und inkompatibel wenn der User multiple Einwahlen braucht, bspw. Phone/Laptop gleichzeitig. Das müssen dann extra eigene User/Zerts sein, umständlich und fehleranfällig. Und niemand mag da wirklich gern Dutzende CSOs administrieren.

Daher meine Aussage bezüglich "kein ANY bei Source Address" in Firewallregeln vom OpenVPN Gruppeninterface. Wenn man da Any nimmt hat man schnell was freigegeben, was bei einem später hinzugefügten Server dann ins Auge geht. Daher immer das Netz vom entsprechenden Einwahlserver als Source, dann kann es auch keine versehentliche Freigabe für bspw. Dienstleister geben. Dito und noch schlimmer fürs Admin RAS Netz.

> Natürlich muss man jeder weiteren OpenVPN-Instanz ein Interface zuweisen und eine Firewall Regel erstellen, sonst spielt da nicht.

Nein muss man nicht. OpenVPN Einwahlserver ziehen keinen Nutzen daraus, wenn man das Interface zuweist. Lediglich die Regelvergabe auf dem Interface mag einfacher sein, das kann man aber wie oben beschrieben problemlos mit sauberen Regeln und "Source" Angabe auf dem OpenVPN Gruppeninterface genauso machen. Zuweisung bringt nur dann was, wenn ich das Interface (gegenüber) bspw. aktiv Monitoren lassen möchte (weil ein zugewiesenes Interface im Routing/Gateway Monitoring auftaucht) oder wenn ich PBRs brauche (policy based routes) - was aber meistens auch nur bei Site2Site Tunneln der Fall ist. Hier macht das dann absolut Sinn. Bei Einwahl VPNs eher nicht.

Cheers :)

Für NAT Type 2 brauchst du keine Port Weiterleitung oder irgendeinen Käse.

Die PS bekommt problemlos NAT Typ 2 hin, wenn man sie ausgehend mit Oubound NAT mit static Ports raus schickt. Solange die OPNsense dazwischen die Ports randomisiert wird es keinen Typ kleiner 3 geben. Outbound NAT für die spezifische IP der Konsole + static Port Mapping sollte genügen.

Cheers
\jens

[acme-dns]

Aber nur wenn du es deployen kannst, Patrick :)
Geh doch nicht immer von den schönsten einfachsten Hardware Boxen aus ;) Das würde ich ja gern, aber den Luxus hat man leider nicht immer. Und wenn du in Geräte extern keine Zertifikate reinprügeln kannst/darfst, sondern die das selbst ausstellen müssen, kann(!) es eng werden - muss nicht. Ich wollte es nur mal in den Raum geworfen haben, dass es kein Panacea ist weil es Beschränkungen gibt: https://letsencrypt.org/docs/rate-limits/#new-certificates-per-exact-set-of-hostnames

Wissen nicht alle - darum der Hinweis. Gerade wenn du irgendwelche verkorkten Kisten hast die darauf bestehen, selbst Zertifikate auszustellen.

BTW: Wenn wir bei Beschränkungen sind: Der acme-dns Service hat auch eine, er kann nicht mehr als 2 SAN Einträge setzen. Also genau "domain.tld" und "www.domain.tld" oder "*.domain.tld" je nachdem was man macht. Wer damit aber bspw. ein Multi-SAN-Zert für nen Proxy o.ä. machen will, in welchem vllt. mehrere Domains drin sind (weil domain2.tld auch noch gebraucht wird) - hat da Probleme. Das ist in irgendeinem Support Ticket zu acme-dns verschüttet mal diskutiert worden, weil das hardcoded Werte sind. Klar, macht man halt die Domains einzeln, aber auch hier: weiß man vllt. nicht - sucht man stundenlang nach Nichts :)

Cheers :)

Ich habe jetzt grad nicht kurz schauen können, aber hat Monit vielleicht irgendwo ein Setting mit dem man das Binding verändert kann, also auf welche IP er gebunden wird/hört? Wenn man die aufs LAN setzt, was im P2 von IPsec mit drin ist, sollten die Abfragen von Monit eigentlich klappen können. Ansonsten wäre aber ein Monitoring außerhalb der Firewall eh sinnvoller, denn dann hat man die Daten und Infos/Notifications/Status etc. auch dann wenn die Firewall mal selbst die Grätsche macht :) Da ist jetzt weniger unbedingt ein anderes VPN benötigt, als mehr die Frage ob das Monitoring so Sinn macht ;)

Cheers :)

@JeGr nur mit DNS-01 bekommt man Wildcard-Zertifikate und hält seine konkreten FQDN aus dem transparency log raus.

Ach das ist gemeint *kopfklatsch*
OK da stand ich grad auf der Leitung ;)

Wobei das auch nur "begrenzt" funktioniert, wenn du alles auf der Subdomain Ebene abwickelst. Sobald du auf 3rd Level kommst (x.y.abc.de) ist zumindest mit der 2nd Level Domain die Katze aus dem Sack (y.abc.de ist dann bekannt). Aber klar, für die meisten privaten Sachen bekommt man das sicher so hin. Es wird nur unschön, wenn an zu vielen Stellen dann das Zert gebraucht wird, da Multi-Ausstellung bei Wildcards meine ich ab irgendeiner Zahl zu Problemen führte? Mehr als 5x? das gleiche Zert war dann - nicht so gut.

Ja acme.sh verwenden ist eine gute Lösung.

Nur zur Verifikation: also nicht mehr ACME in Caddy auswählen, sondern vorher erstmal das Zert mit dem Service ACME Client erledigen und dann hier direkt im Dropdown auswählen, statt zu sagen Caddy soll's ausstellen?

Dass der Aufwand fies ist, kann ich mir denken, das sieht man ja auch, wie oft bei acme.sh gepusht und gepullt wird bei ständigen Änderungen an APIs und Co.

Cheers

Theoretisch kann man damit mit einem Cron job einfach immer automatisch bauen, so benutze ich das. Aber ich kann es nicht ausliefern, man muss es selbst bauen wenn man es will.

Heißt im Umkehrschluß dann dass demnächst dann kein DNS mehr mit Caddy out of the box funktioniert? Oder wie verstehe ich das genau :)
Dann lieber einfach acme.sh verwenden und in Caddy einklinken (was ja jetzt auch schon geht)? Hatte ich eh schon überlegt, da der Caddy Prozess mir da aktuell zu intransparent vom Logging ist - ich bekomm einfach nie wirklich mit, ob es geht, ob es nicht geht und irgendwann ist das Zert mal da oder nicht. Neu starten - läuft dann irgendwann oder halt nicht. Das ist gefühlt aktuell oft trial & error mit DNS-01. Keine Kritik nur subjektive Benutzungsbeobachtung :)

Cheers

Ich würde mich da Patrick anschließen. Richten wir so auch nicht ein. Wir splitten das in VPN Server für bspw. Mitarbeiter, Admins und Contractor - also irgendwelche Fremdfirmen. Beim Contractor VPN werden keine Routen gepusht, kein DNS etc. und die Clients tatsächlich via CSO bzw. Radius mit fixen IPs bestückt, damit man die mit Regeln sauber "einsperren" kann. Bei Admins will man eh alles erlaubt haben auf Management und Co und Mitarbeiter bekommen nur was gehen muss und nicht mehr.

Die 3 Server (oder mehr) bekommen alle unterschiedliche IP Segmente und damit kann man die Regeln auch ordentlich auf dem OpenVPN GruppenInterface durchkonfigurieren. Wer auf dem OpenVPN bei uns ne "Any zu XY" Regel anlegt, bekommt Haue ;) Denn das geht meistens schief, sobald was dazu kommt, neuer RAS Server, neue Site2Site o.ä. - und prompt dürfen Sachen mehr als sie sollten. Daher bei OVPN Regeln (oder WG etc.) immer Source mit angeben.

Cheers :)

Das ganze ohne das ich bei den Clienten ein Zertifikat hochladen muss da dies ja mein HAproxy übernehmen soll. Dies funktioniert ja auch beim Exchangeserver schon so nur da geht alles über die ext. IP wo der hacken ist! Da ich bei den Activ Directory Domaincontroller alle verbunden Geräte ja die Einträge selbst machen und das ist die interne IP z.b für nas.meinedomain.tld = 172.20.20.23.

Mein problem ist ich verstehe nicht wie ich OPNsense(HAproxy) einstellen muss das dies von intern funktioniert ohne das ich es über die externe IP mache.
Habe unter DHCPv4 keine DNS-Server & Domainname gesetzt
hätte bei Unbound DNS die Host Überschreibeung probiert mit HOST (*) Domain (meindomain.tld) auf die DNS-Server IP leider stürtz da Unbound DNS ab und kann es nicht mehr starten.

Zwei Punkte:

1) Nur weil du intern den AD DNS hast, MUSS der nicht zwingend benutzt werden. Du kannst problemlos den Clients per DHCP den DNS der Sense geben und dort als Domain Override dein meinedomain.tld zum AD DNS verweisen lassen. Man kann da auch mehrere für Redundanz angeben. Damit würden dann alle erstmal über die Sense reden, nicht direkt mit der AD Zone.

2) In der Sense kannst du dann problemlos nas.meinedomain.tld umschreiben auf den HAProxy - entweder die Public IP oder du bindest HAproxy einfach zusätzlich noch auf die interne IP und dann kannst dus auf die interne IP umschreiben. Geht beides. Dann redet dein Client mit der Sense/Haproxy, die ruft dein NAS auf. Feddich.

Das GEHT. Ist nur nicht ganz so simpel und hängt stark von den Rahmenbedingungen ab, deshalb nutzt da kein "Howto" irgendwas, weil niemand weiß wie dein Netz intern aufgebaut und strukturiert ist.

Aber gehen tuts.

Cheers :)

Ach, ich hatte nur MySQL und PostreSQL gelesen...

Und ja: Siehe https://crt.sh, es sind einfach die Zertifikate. In Deinen DNS kann keiner reinsehen, wenn Du keinen Zonentransfer erlaubst...

Jein. Musste ich auch schon feststellen und konnte mit jemand sprechen, der sich da in Punkte Public DNS auch "etwas mehr" auskennt: Es gibt da durchaus inzwischen auch einen "grauen" Markt mit den Zone-Infos, die bspw. bei Public DNSen angefragt werden. Eine neue Domain, frisch registriert, nur einen sehr random Sub Domain Namen generiert und den einmal vom Rechner aus auf nem Public DNS angefragt -> 3 Tage später die erste Zugriffe aus Ost und Fernost. Die Subdomain war nirgendwo bekannt oder eingerichtet. Nur bei DNS queries. Das ist also durchaus wohl inzwischen ein Ding, dass auch neue Domains via DNS abgegrast oder verschachert werden. Und da war die Domain noch nichtmal irgendwo im TLS Transparency Log weil noch kein TLS ausgestellt wurde. Ab dann ist es eigentlich öffentlich, egal was du machst, weil sich genug einfach den "tail" vom SSL/TLS transparency log abgreifen um Domains zu fischen.

Wie ich neulich feststellen musste, ist eine meiner Domains inzwischen komplett verbrannt, weil ich früher einmal mit HTTP-01 Multi-Domain-Zertifikate eingerichtet hatte. Unter https://crt.sh sind die "immer noch" verfügbar.

Was meinst du mit "immer noch verfügbar"? Sind die Infos nicht aus dem transparency log? Das löscht sich ja nicht einfach, sondern protokolliert einfach nur, wann welche Domain wie mit Zertifikat ausstaffiert worden ist. Und da sind DNS Varianten auch mit drin. Nicht nur HTTP. Verstehe nicht ganz, was es bringen soll auf HTTP01 zu verzichten an der Stelle? Freu mich aber über Erklärung :)

Cheers :)

Code Select Expand

caddy build-info
Danach versionen vergleichen.

Bald sind DNS provider nicht mehr standardmäßig drin. Danach und auch schon jetzt kann man immer das aktuelle bekommen, entweder man baut es selbst mit xcaddy oder benutzt caddy add-package.

Gibt es das beim Caddy Plugin dann in der GUI? Oder muss man dann nach jedem Caddy/OS Update jedes Mal in die Konsole und das add-package wieder reinfriemeln? Ich hatte das schon bei nem Container Setup sehr nervig, dass bei jedem Container Update die installierten Packages (verständlich) weg sind, aber es wäre sinnvoll dann da auch einen Mechanismus zu haben, der das entsprechend hinterlegbar macht, was dann nach "Neubau" wieder mit rein muss/soll. Sonst knallt ja jedes Mal die Konfiguration weil Provider/Settings konfiguriert sind, die Caddy nicht kennt?

Cheers

Aber auch mit allem anderen Alternativen, kann ISC das auch. Der Punkt war nur bislang, dass das als Cluster läuft und dann auch BEIDE Nodes Adressen verteilen dürfen. Dazu muss dann aber bei Failover Peer IP auch die IP drin stehen. Wenn sonst der Standby die IP vergibt obwohl das nicht konfiguriert ist, ist was falsch. Vielleicht der Standby Node nicht sauber gesynct oder vergessen ihn manuell zu syncen? Der synchronisiert sich ja nicht mehr automatisch, also Vorsicht an der Stelle!

Cheers

1) Site-to-site VPN  - das wird wohl gehen. Im Vilfo habe ich die OPNVPN config des jeweils andren Routers als Custom VPN Provider installiert als workaround.

2) Ich möchte, wie mit Vilfo, unterschiedliche Geräte Gruppen haben, die über unterschiedliche VPN Anbieter (oder Verbindungen beim gleichen Provider) ins internet gehen oder eben eine Gruppe ohne VPN. Wenn innerhalb der Gruppe auch noch URL Ausnahmen gemacht werden können, noch besser.

Ist das möglich ohne eine Riesenaufwand, vor allem beim Maintenance?

Gerne auch andere Vorschläge außerhalb von OPNsense.

Vielen Dank!

Also gerade bei Punkt 2 würde ich mir ansehen, ob du kein Kandidat bist, für den Tailscale oder Netbird sinnvoller wäre. Gerade wegen dem Punkt "ins Internet über XY gehen".
Mit NB/TS ist es recht simpel möglich, zwei Sensen bspw. in seinem Setup miteinander zu verknüpfen. Dann können beide Seiten entweder ihre Routen pushen (also wie ein Site 2 Site VPN) oder/und man kann den Knoten als "Exit Node" pushen. Heißt: du kannst dann Internet über diesen Node nutzen. Dazu kannst du dann einfach auf dem Gerät dass woanders ins Netz soll deinen Tailscale/Netbird Client anwerfen, connecten und dann auswählen über welchen anderen Knoten er ins Netz soll. Da tauchen dann deine beiden Sensen auf bspw. oder jeder andere Host/Router/VPS/Client wo du TS/NB installiert hast und dem du gesagt hast "du darfst exit node sein".

Persönlich nutz ich da aktuell Tailscale für, in der Firma setzen wir gerade Netbird auf, beide können das. Plus du musst dazu nichts an der Firewall fummeln, sondern nur den Client auf den Geräten haben, die VPN machen sollen bzw. bei denen du nen anderen Internet-Standort nutzen willst. Das kann man dann auch simpel ergänzen indem man irgendwo nen günstigen VPS mietet, sich TS/NB draufwirft und in seinem Setup anmeldet. BAM, schon kannst du plötzlich über den Host und dessen IP ins Netz um bspw. irgendwelche Netzsperren, GeoBlocks etc. zu vermeiden - oder um bspw. die immer nervigeren Streaming Blocks zu unterlaufen. Beim Account-teilenden Kollegen einfach TS/NB installiert, exit node ausgewählt und schon siehts aus als wäre das Gerät beim Kollegen "zu Hause". Und meistens genügt das einmal alle paar Tage damit die Geoblocks wieder Ruhe geben.

https://netbird.io/
https://tailscale.com/

Einfach mal reinlesen!

Cheers :)