Messages

Mehr als ein Gateway auf WAN Seite würde ich absolut tunlichst vermeiden.

Kannst Du mir bitte helfen zu verstehen, warum asymmetrisches Routing mit zwei Gateways im selben Netzwerk (WAN) ein potentielles Problem ist, aber nicht mit den selben Gateways in 2 Netzwerken?

Es geht ja dann nicht um die SELBEN Gateways in 2 Netzen, sondern so eine Box in ein separates Netz (via VLAN, eigenes Interface, whatever) zu packen, wo nur noch die Box und die Sense drin spielen. Warum?

Die *sensen aktivieren bei WAN-style Gateways einen Zusatz im pf Filter, der Regeln auf dem WAN Interface ein "reply-to" hinzufügt, damit der Traffic der darüber reinkommt garantiert wieder dort rausgeht, wo er herkam. Gerade bei VPNs und Co kann das durchaus wichtig werden. Hast du jetzt 2 Gateways auf dem WAN und reply-to ist aktiv, dann kommt Traffic von der Box, geht zur Sense (und dem Client dahinter), kommt als Antwort zurück, geht aber NICHT wieder zur VPN Box, sondern geht zum Default-GW vom WAN -> dem Router davor. Je nachdem was das für ne Kiste ist und wie gut der Asymmetrie abkann, kann der das Paket mit Glück dann an die VPN Box weiterschicken (wenn Routen eingetragen sind), aber insgesamt ist das immer ein Konstrukt, das leicht brechen kann. Schaltet man reply-to ab, kann sein, dass vllt. andere Sachen, VPNs o.ä. nicht mehr sauber funktionieren wie gedacht.

Packt man jetzt einfach die Registerbox mit ihrem VPN in ein dediziertes VLAN/Interface an die Sense, dann wird die für das Remote Netz einfach als weiteres "WAN" an der Sense behandelt. Es gibt sauberes Routing mit einem GW pro Interface (WAN Kram bleibt WAN Kram, RemoteNetz XY wird sauber an die Registerbox geroutet) und alles läuft auf einem genau festgelegten Weg da lang, wo es soll ohne aus Versehen irgendwo anders abzubiegen.

Ich hoffe das war halbwegs verständlich ausgedrückt :)

Cheers
\jens

Zwei Tunnel mit identischer Phase 1, aber unterschiedlichem Gateway

Kurze Rückfrage: Was genau ist damit gemeint? Identische P1 aber unterschiedlichem GW? Also selbes Gerät über zwei unterschiedliche IPs?

Wäre es da statt classic P2 VPNs nicht einfacher zwei VTI (routed IPSEC) anzulegen und dann auf der Sense da nen Failover Gateway drüber zu packen? Oder kann das die Sophos nicht?

Ansonsten wir das bei IPsec ohne Hilfsmittel m.E. ziemlich bastelig. Automatisch geht da meine ich wenig - oder was stellt die Sophos da für Werkzeuge zur Verfügung, dass sie automagisch einen IPsec Tunnel auf einen anderen umschaltet? Da stecke ich in der Sophos zu wenig drin.

Cheers
 \jens

Hinweis: Je nach settings im OVPN Server und beim Export wird die OVPN Datei vllt nicht korrekt gelesen (von OpenVPN Connect auf iOS oder Android). Empfehle daher entweder einen anderen Client zu nutzen (OpenVPN von Arne Schwabe bei Android, Passpartout in iOS) oder die Serverkonfig anzupassen und entsprechende Konfigparameter statt dessen direkt am Client zu setzen. Das wird aber vom Client angemeckert wenn da was nicht klappt.

Bei iOS auch wichtig: entweder keine Domain pushen per DNS oder alle notwendigen, die via VPN aufgelöst werden sollen. iOS/Apple ist da leider zickig.

Cheers

Nur ein gewöhnliches Paket mit gesetztem ACK. Fließen die Pakete auch wirklich in beiden Richtungen durch die Firewall durch? Also hat der Ziel-Host 192.168.234.175 definitiv keine andere Route in das Netzwerk 192.168.10.0/24 an der OPNsense vorbei?

Ich mag mich täuschen, aber das Paket stimmt mich auf asymmetrischen Traffic. Da ist NUR ein Ack. Kein SYN. Die Firewall filtert aber per default nur SYNs und packt sie dann in die State Table. Wenn da Pakete abgelehnt werden, die NUR Ack sind, dann gabs entweder kein Syn oder über ein anderes Interface und der State passt nicht. Das sieht für mich nach Dreieck Routing aus. Da ich die Changelogs nicht auswendig im Kopf habe: gabs diesbezüglich eine Änderung beim State Tracking o.ä.?

Hallo OPNsense-Gemeinde,
Was für Konsequenzen kommen auf uns zu? Wird nach dem Update auf 26.1 OpenVPN nicht mehr funktionieren oder kann man dann keine Profile mehr erstellen.

Muss man alle Profile neu erstellen? Bitte um Aufklärung. Wir haben 150 OpenVPN-Profile (LEGACY) in Benutzung.

Sofern am vorhandenen OpenVPN Instance Service nicht noch Änderungen und Ergänzungen dazu kommen, wird das leider ein ziemliches Chaos werden. Da das Instanz-Zeugs leider keinerlei alte Cipher in der Liste unterstützt, sondern nur das, was OpenVPN eh schon als Standard hat (AES-GCM-256,128 und Chacha20) werden alle OpenVPN Verbindungen mit AES-CBC oder altem BF-CBC nach Abschalten des alten Legacy Pakets nicht mehr funktionieren. Ich hoffe sehr, dass der Instanz-Server bis dahin sämtliche fehlende (leider einige) Schalter und Settings bekommen wird, dann kann man ggf. auch abschätzen, was das für eine Arbeit wird das umzustellen.

Wenn sich weiterhin allerdings nichts tut, wird das auch einigen unserer Kunden extrem weh tun und das Update erstmal verhindern. Das wird sich dann sicherlich im kommenden oder nächsten Update dann zeigen, wenn wie angekündigt der Legacy Service dann zum Paket wird und danach erst verschwinden soll. Wenn der dann ausgelagert zum Paket wird, wird es wahrscheinlich dann nach Installation des Pakets noch weiterlaufen.

Wie gesagt kann man das leider erst ersehen, wenn man weiß, wie es mit dem Instanz-Server weitergeht.

Cheers

Man könnte die Registerbox auch einfach in das Netz zwischen LAN der Fritte und WAN der OPNsense legen, wenn die OPNsense sowieso NAT macht. Also, LAN der Fritte als 192.168.9.1/24 konfigurieren, DHCP dessen abschalten, die Registerbox und das WAN der OPNsense ans LAN der Fritte anschliessen. Danach auf der OPNsense das WAN als 192.168.9.2/24 (oder so) konfigurieren, die Adresse der Registerbox als Gateway definieren und die Routen eintragen. Dann spart man sich das ganze Outbound NAT.

Mit mehr als einem Gateway auf der WAN-Seite der OPNsense empfehle ich auch Firewall: Settings: Advanced: Disable force gateway zu aktivieren.

Code Select Expand

------------
| Fritzbox |
------------
        |
        | 192.168.9.0/24
        |              ---------------
        |---------------| Registerbox |
        |              ---------------
        |
------------
| OPNsense |
------------


Mehr als ein Gateway auf WAN Seite würde ich absolut tunlichst vermeiden. Ja man kann das machen. Es gibt aber jede Menge Fallstricke dafür und force Gateway ist nicht der einzige. Da spielt dann bspw. noch der reply-to von den WAN Regeln mit rein, etc. etc. und genau WENN man sowas wie ein auf-erzwungenes Gateway hat, das man integrieren muss, ist ein sauberes Transfernetz damit Gold wert und reduziert Fehlerquellen wie asymmetrisches Routing und Co auf ein Minimum. Alles andere - die Box ins LAN, WAN etc. zu packen - fördert nur Probleme.

Cheers

a) Ist das prinzipiell ähnlich oder sind das zwei paar Schuhe?

Wenn du die Einbindung meinst der Liste, dann ist das Prinzip gleich/ähnlich. Nur eben andere URI zum Abrufen. Du solltest dann aber ggf. mal nachlesen, welche firehol Liste (level 1, 2, 3...) genau WAS tut, was beinhaltet und für welchen Zweck die gedacht ist. Bspw. ist L1 eine recht generische Liste, hat aber bspw. die ganzen privaten Adressen, Multicast und Co mit drin, was man ggf. intern->extern nicht alles blocken will. Da braucht es dann ggf. eine gefilterte Liste mit negativ-Aliasen mit drin.

b) Nutzen die SPAM-Haus-Listen auch gegen SPAM-Mails? Gelistete E-Mailserver dürften doch theoretisch abgeblockt werden, oder?

Spam Blocklisten und Spam-Server Blocklisten sind zweierlei Dinge. Wenn du von der Spamhaus DROP oder EDROP Liste sprichst, dann hat die nichts oder nicht nur was mit Spam zu tun, sondern listet generell ziemlich offensive IPs, die man nicht haben will. Ransomware Crypto, Malware, Botnetze und Co können da enthalten sein. Das hat also nicht(s) nur mit Mailservern zu tun, weil die Bude Spamhaus heißt :)

Zusätzlich sind DROP und EDROP meistens in den größeren Listen schon mit enthalten. Firehol Level 1 enthält bspw. schon 100% von DROP und EDROP sowie DShield und ET_spamhaus und ET_block:



Somit kann man hier sich dann ggf. die ein oder andere Liste weil bereits enthalten einfach einsparen :)
Wichtig ist aber hier genau drauf zu achten, was man für welchen Zweck einbindet. Einfach Level 2 & 3 bspw. zu nutzen kann/wird zu false positives führen. Auf Level 2 oder 3 landen schon gerne mal CDN oder bekanntere IPs von Github, Gitlab, Discord und Co, wenn deren Dienste mal wieder zum Upload von irgendwelchem Schadcode verwendet werden. Das muss man im Auge haben und ggf. mit einer Allowliste gegensteuern, die solche IPs rauszieht.

Cheers

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