Messages

I'm running an IPSec server for road warriors. It uses public key authentication with a Let's Encrypt certificate.
Client authentication goes via EAP-RADIUS. The local FreeRADIUS uses certificate from a private CA.
Most clients here are Windows 11 built-in vpn clients.

This worked flawlessly with the LE R13 certificate. But since this was replaced by the ACME client with an YR cert, Windows fails to connect.
The reason seems to be an additional layer in the cert chain, which Windows doesn't trust:
my-cert ← R13 ← ISRG Root X1
my-cert ← YR2 ← Root YR ← ISRG Root X1

So the YR has an additional intermediate certificate: "Root YR". OPNsense shows only YR2 up in the GUI though, but if I download it, I can see both intermediate certs are stored into a single file.
So I suspect, that the vpn server only sends the first one to the client. Or Windows accepts only the first one.
The IPSec log shows

Code Select Expand

sending cert request for "C=US, O=Let's Encrypt, CN=YR2"
However, Windows fails to connect. It just stops the communication and the connection times out on the server.

Is anyone else using an LE YR or YE certificate with IPSec on OPNsense and got this working?

I assume, a workaround could be to split the intermediate cert file so that I get a unique for both and assigning them the vpn server. So that both are delivered to the client. But the intermediate cert has a limited validity. So this might be only a temporary solution.

Running the dynamic DNS client on the VPS would be the best and easiest way, however.

But yeah, if don't want this and your DDNS service just updates your entries with the source IP, which the request is coming from, you should also be able to do this from your home OPNsense and just route the requests over the VPS.

To do this, you have to find out the IP of your DDNS update service.
Then add a static route for this IP and point it to the VPN gateway.
In case, you have not allowed any IP in the VPS Wireguard settings, you will also have add this IP to the allowed ones.

And your VPS has a dynamic IP?

Dann blieben noch die Netze für LAN, DMZ und WLAN nach und es bleibt das Problem mit dem fehlenden Interface für das pfSync-Netz.

Ein gesondertes Interface für Sync ist empfohlen, aber nicht zwingend nötig.

Auch ist HA keine zwingende Voraussetzung, um die Konfiguration von einer Instanz auf eine weitere zu synchronisieren, aber es vereinfacht das ein Umschalten ungemein. Genau dafür ist es gemacht. Die Möglichkeit, die Konfig zu syncen komplettiert die Sache nur.
Wenn beide aktiv laufen, bleiben sogar die meisten Verbindungen erhalten, sofern sie synchronisiert werden.

Kann ein "üblicher" managed Switch den ganzen Verkehr von LAN, DMZ und WLAN so auseinander dröseln, dass die Daten nur an bestimmten Ports (und ohne VLAN-IDs für LAN und DMZ) des Switches herauskommen? Oder benötige ich für meine Anforderungen einen speziellen Switch?

VLAN-fähig muss der Switch sein, dann kann er das. Der Ausdruck "managed" könnte so manches Andere bedeuten, wenngleich meist das gemeint ist.

st es überhaupt "sicher" alle Netzwerk in einem Switch zusammenzuführen, um diese anschließend auf dezidierte Ports am Switch zu leiten?

Wenn er korrekt konfiguriert ist, ja.

Würde so etwas mit IPv4 und IPv6 funktionieren?

Ja, die IP-Version ist dem VLAN grundsätzlich egal und umgekehrt. Die VLAN-Segmentierung passiert am Layer 2, IP in 3.

Kann ein Switch aus einer 192.168.148.0/24 VLAN 40 eine 192.168.131.0/24  VLAN 10 machen?

Warum sollte er das tun? Ich denke, ich verstehe die Frage nicht.

Oder gehen quasi alle IP-Adressen gemeinsam auf ein Interface aus?

Es geht hier mehr um virtuelle Netzwerksegmente.
Ein Switch Port, der so konfiguriert ist, dass er an das VLAN 10 angebunden ist, ohne dass angeschlossene Geräte etwas vom VLAN merken (untagged, PVID), lässt nur Pakete vom VLAN 10  raus bzw. eingehende gehen nur ins VLAN 10.
Der Port, den du bspw. mit der OPNsense verbindest muss so konfiguriert sein, dass alle VLANs drüber gehen (Trunk). Allerdings gibt es da kein "Übersprechen", wenn ordentlich konfiguriert. In OPNsense hättest du für jedes VLAN ein Interface eingerichtet, und nur auf dieses laufen die Pakete.

Aktuell nutze ich IPv6 nicht. Muss ich bei der Anschaffung des Switches die eventuelle Nutzung von IPv6 bei der Auswahl des Switches berücksichtigen?

Nein. Bzw. nur, wenn er Layer 3 machen soll.

Könnt Ihr mir überhaupt empfehlen, an dieser Stellen weiterzudenken in Anbetracht meiner hier gestellten Fragen?

Es hätte was Gutes: Du würdest was lernen. :-)
Anfängliche Probleme musst du einkalkulieren. Ob sich der Aufwand für deinen Zweck lohnt, musst du entscheiden.

Grüße

"WAN network" is not the the internet, but it's just the Subnet defined on WAN interface. It's the equivalent to "LAN network".

To achieve internet only access, I create an alias and add all private network ranges to it, called it RFC1918.
Then I use this in the pass rule as destination with "Invert Destination" checked.
Then this rule permits access to non-RFC 1918 IPs only.

However, remember that this rule don't permit any access to local IPs. Hence you have to add additional rule to allow DNS, NTP, etc. on this interface.

If the switch doesn't nat outgoing traffic to the gateway, you have to add source NAT rules to WAN for the local networks behind it.

OPNsense creates such rules automatically, but only for subnets defined on its interfaces.

Ein ping auf die reine IP Adresse geht raus, auf die Domain aber nicht.

Den Grund dafür hast du doch eh schon erkannt. Du kannst keine Hostnamen auflösen, kein DNS.

Ich habe einen Alias über den ich einzelne Clients über den VPN schicken möchte.

Also nochmal: Je nachdem, welche Regel du sonst noch hast, schickt diese Gateway-Regel möglicherweise auch DNS Requests auf das Gateway.
Hier hast du nichts dazu erklärt.

Ich nehme aber an, dass dein Client so konfiguriert ist, dass er OPNsense als DNS verwendet. D.h. die LAN IP der Firewall.
Nun, wenn du diesen Request auf den VPN Server schickst, wird das Paket dort verworfen, weil da die Ziel-IP unbekannt ist.

Ja, man kann einen DNS Server in Wireguard in die config eintragen.

Das kenne ich nicht. Wenn dann würde so etwas dem VPN Client, also OPNsense, diesen DNS-Server zuweisen, wenn die Verbindung hergestellt wird.
Das würde aber nur funktionieren, wenn du den lokalen DNS im Forwarder-Modus betreibst. Und ggf. braucht das auch noch eine Route, kommt auf die Ziel-IP an.

Das obige ist vielleicht gar nicht das, was du möchtest. Ob du alle DNS-Anfragen auf Mullvad schicken möchtest, oder nur die im der Clients im Alias, hast du nicht verraten.
Wie auch immer, eine einfache Methode, die Request auf den gewünschten Server und auch über die VPN zu schicken, ist sie einfach mit einer NAT-Regel weiterzuleiten. Allerdings kannst du dann keine lokalen Namen mehr auflösen. Ist das gewünscht, muss du das interne DNS entsprechend konfigurieren. Was verwendest du da?

Welchen Fehler hat der Mann begangen? Wär cool wenn man sowas auflösen kann.

Die WAN-Regel, die sicherstellen soll, dass kein Traffic anderswo hingeht als auf den Mullvad Server hat er für eingehenden Traffic erstellt. Die hätte Direction out haben sollen. Erwähnt hat er es.

Überdies bin ich mir gar nicht sicher, ob dies Regel überhaupt funktionieren würde, ob diese die IP Adressen im Alias überhaupt sieht.

okay, also ich bin mir nicht ganz sicher, aber ich habe die Regeln so eingestellt wie in einem Post hier vorher.
Damit habe ich 0, aber auch wirklich 0 DNS Auflösung und das geht mir nicht so ganz in die Birne.

Eine solche Policy-Routing Regel schickt konsequent jeden Traffic, auf welchen sie zutrifft, auf das Gateway. Die könnte auch für DNS Anfragen zutreffen, während das Ziel aber eine lokale IP ist?

Wenn du interne Adressen erreichen möchtest, musst du die Regel so anlegen, dass sie diese nicht erfasst oder für interne Ziele eine eigene Pass-Regel darüber stellen.

Ich hab den VPN per Wireguard erstellt inkl DNS Eintrag

Was heißt das? Kann man in Wireguard einen DNS eintragen?

da ich den DNS von Mullvad gerne nutzen mag.

Wie soll das geschehen?
Soll das nur auf den betroffenen Geräten oder generell gelten?

Vorlage war dieses Video: https://www.youtube.com/watch?v=toB_9F-VTVo

Na hoffentlich hast du nicht dieselben Fehler gemacht wie dieser Guru. ;-)

D.h. vermeintlich alles in Ordnung.
Warum dann Traceroute als erstes eine IP im anderen Subnetz hinter dem Router ausgibt, ist mir nicht klar.

Für das Interface Backup gibt es eine Regel, mit Source 'Backup Network', Destination 'LAN-Network', Protocol TCP, alle Ports auf ANY.

Okay, bevor du weitersuchst, mache erst mal die Regel weiter auf. Erlaube alle Protokolle, dann versuch es mit einem Ping oder Traceroute.

Wenn nur TCP erlaubt ist, kommen Pings (ICMP) nicht drüber.
Auch würde ich Source und Destination zur Fehlersuche auf any setzen. Wenn du bspw. eine falsche Subnetzmaske gesetzt hättest, könnte Quelle oder Ziel aus dem Netzwerk fallen.

Wenn dann immer noch nichts geht, mach ein Packet Capture, erst am eingehenden Interface, wenn ok, am ausgehenden. Kommt da schon gar nichts rein oder auch das Richtige raus, kannst du OPNsense als Fehlerursache ausschließen.

Hallo,

Ausgabe eines traceroute auf dem Truenas :

traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  192.168.178.1 (192.168.178.1)  0.133 ms  0.102 ms  0.054 ms

Könnte es sein, dass du dein NAS multi-homed betreibst? Also dass es in beiden Subnetzen eine IP hat.

Eigentlich würde ich mir erwarten hier als ersten Hop die Gateway IP des NAS zu sehen, also 92.168.180.2.

Ein anderer möglicher Grund könnte ein Layer 2-Leck zwischen den beiden Netzwerksegmenten sein.
Einfach nachzuweisen, indem du am NAS die ARP-Tabelle anzeigst. 192.168.178.1 dürfte da nicht aufscheinen, wenn es in Ordnung ist.

I don't know what a "TO" is

The thread opener.

but I have not yet seen any proof that a DHCP request from a tagged ethernet frame is getting a response from the DHCP service on the base ("untagged") interface

Again, I didn't ever complain that this is possible in a correctly configured network with subnets. But we are trying to solve an issue here and I tried to give a possible explanation for it.
Man!!!

You wrote "... this goes across layer 3 boundaries.

That's correct. ff:ff:ff:ff:ff:ff, the MAC broadcard address, goes to any device in the local layer 2.
If the VLAN segmentation doesn't work, it goes to any devices in other alleged VLANs as well. And this is, what we're talking here about, the basic issue of this thread, we are trying to resolve.

What are you based that assessment on? It works for me...

The issue of the TO.
It works in my setup as well, but I don't complain.
^^

That's not really what happens. Broadcasts never "reach" between subnets. In the case of a broadcast DHCP request, there is no subnet yet. The DHCP packet gets transmitted in a broadcast ethernet frame (destination ff:ff:ff:ff:ff:ff). Any DHCP server in that layer 2 domain can reply to that request.

So what is different here to that I wrote??
ff:ff:ff:ff:ff:ff = 255.255.255.255
^^

The ethernet frame containing the request can (and should, in this case) include a VLAN tag.

And this is the part, which might not work here.

Yes, you're right, the broadcast shouldn't leave its VLAN. But the VLAN separation doesn't seam to work at layer 2.

I went back to my original configuration as posted in the beginning of this thread (listed from the SSH login to OPNSense)

So I could repeat my first post as well. ;-)

From one of my LAN devices (192.168.1.63), I attempted pings to the Guest (192.168.20.1) and IoT (192.168.40.1) vlans and there is no connectivity as expected. This means there are no leaks that could lead to bleeding FROM the LAN TO the Guest or IoT networks.

No. This just means, that there is no layer 3 leak, but VLANs must separate network segments at layer 2.

Explanation: When the (LAN) device tries to access an IP in another network segment it doesn't do ARP resolution, but sends to packets directly to the gateway, which is the firewall. If access to the other subnet isn't permitted here, the access fails of course.

Unfortunately, I still have no devices connecting on either vlan

However, to get an IP from a DHCP server, a device sends the request to the broadcast. But since it doesn't have a network setting at this point, it sends the request to the overall broadcast address,  which is 255.255.255.255, and this goes across layer 3 boundaries. So it also reaches a DHCP in the obviously other subnet.

So your network setup might leak at layer 2.

myip.dk reports the static IP as expected (84.x.x.x)
OPNsense dashboard shows WAN gateway address as (212.x.x.x)

With the old ISP both were the same.  I cannot connect to my VPN now so I suspect something is wrong.

WAN IP and gateway IP must differ at all, otherwise you would not be able to access anything on the internet.

The site displays the public IP, which you're using to access it. So it should be the same as the WAN IP OPNsense displays on the dashboard, but not the gateway.