Messages

Das schrieb viragomann doch... es geht darum, den Rückweg, der sonst über das Default-Gateway liefe (Dein Router), zu ermöglichen, indem vorgegaukelt wird, alle Pakete von 192.168.99.0/24 kämen von 10.170.60.254, damit sie lokal beantwortet werden können und nicht über den Router laufen.

S-NAT:

Interface: LAN
TCP/IP Version: IPv4
Protocol: any
Source: WireGuard net (oder besser das spezifische WireGuard-Subnetz, z. B. 10.170.61.0/24)
Destination: LAN net (oder any)
Translation / Target: Interface address


Bei der Source kommt es darauf an, mit welcher IP die Clients oder der Host ankommen: Wenn der Host selbst ein Wireguard-Client ist, nutzt er die Tunneladresse 10.170.61.1. Geht er über ein anderes WG-Gateway, nimmt er eher 192.168.99.39/24 - die Source muss das so reflektieren.

Ich gehe oben davon aus, dass der Quell-Host ein WG-Client ist, der die Route zu 10.170.60.254 aufgrund der "AllowedIPs" kennt und dort mit der 10.170.61.1 aufschlägt. In der OpnSense würde die S-NAT-Regel dann diese Pakete aufgrund der Source auf die LAN-Interface-Adresse (10.170.60.254) umschreiben. Der Ziel-Host sieht dann diese Adresse und redet direkt im LAN damit.

Das ist richtig. Effektiv ist der Transferspeed für Daten der bestimmende Faktor dafür, wie lange man auf das Ende einer Operation wartet.

Wobei 10G Switches noch zu haben sind (wenn's auch kostet), aber alles abseits von DAC-Kabeln auch ziemlich Strom frisst. Ich nutze 10G ausschließlich mit DAC-Kabeln im Backbone, also zwischen OpnSense, Switch und Servern und nur für einen Haupt-Client per 10 GbE.

Alles andere maximal mit 2.5G, weil die Hardware günstig zu haben ist, wenig Strom verbraucht und vor allem, weil in der Realität selbst mehr großen Plattenarrays der Transferspeed meist auf ca. 300 MByte/s begrenzt ist, da zumindest beim Schreiben die Paritätsplatte(n) den maximalen Speed limitieren.

Und wenn man dann noch auf IDS verzichtet, reicht in der OpnSense ein N1x0 (allerdings mit 2x SFP+), der Switch kostet einen Tausender (z.B. USW-Pro-HD-24-PoE, weil man idealerweise 4xSFP+ braucht, denn 2 reichen nicht, wenn man noch einen Backup-Server braucht).

No, if you pass the NICs through, OpnSense has full control over the NICs.

However, there is something off with the two GUAs your WAN receives. If x:908:c21a:df00::/56 is the IA_PD prefix, as it seems, then x:908:f000:83f::9d5/128 is the IA_NA, which is not from the same range, so that's O.K.

But what is: x:8101:3ff:fc7c:2a5:69ff:fe87:c47a/64 ? It looks like the suffix ::2a5:69ff:fe87:c47a is the EUI-64 from the MAC of your WAN, but the prefix x:8101:3ff:fc7c::/64 is neither the IA_NA nor one of the IA_PD prefixes. While it is technically possible to get multiple IA_NA options, I have never seen that, so maybe it can cause problems. I would use "Request prefix only" and set a unique optional prefix ID (say, 99) to rule this out. You should see only one GUA after this, namely x:908:c21a:df99:2a5:69ff:fe87:c47a/64.

If that does not work: I know @Franco has changed some things in the IVp6 code with 26.1, but IDK exactly what.

The /128 on the WAN must be the IA_NA IPv6. But if you use a /56 prefix, there must be the least significant 8 bits that are used for any other interface - I understand the prefixes 0, 1 and 2 for your internal interfaces. But what is the /64 on the WAN made up from?

Let's leave out the fe80::/64, because those are link-local and of no special interest apart from that the WAN uses a link-local gateway as well.

I wonder what the /64 GUA on the WAN is? What is the 8-bit prefix of that? Are the first 56 bits shared with the IA_PD from your LAN interfaces?

And now I see: You are using OpnSense virtualized under some kind of KVM (i.e. TrueNAS Scale). That complicates things A LOT.

What do I mean by this? See: https://forum.opnsense.org/index.php?topic=44159.0, especially the part about "bridge-mcsnoop 0", which could well explain what you are seeing, because the known bug manifests in IPv6 connectivity breaking after a short while.

That being said, I have no experience with TrueNAS Scale at all.

That is new information. You first wrote that IPv6 initially works and it works fron OpnSense itself, now it does not. When exactly does it stop working? After initial connection or only after a while?

You can see which IPv6 you get in the interfaces overview - however, there are two sides to this even when we factor out the LAN connection first and concentrate on WAN:

1. IA_NA - which is the IPv6 your WAN interface gets via DHCPv6 as a client. That is, iff it gets one - some ISPs do not hand out an IA_NA and some even do not answer DHCPv6 requests at all if one is requested. That is the reason why the advanced setting "Request prefix only" exists. Using that is usually safe, because then:

2. IA_PD - which is the /56 prefix that can be split up and delegated to each (V)LAN and as of now, also to the WAN interface itself if "Request prefix only" is set. Note that you have to choose different 8-bit prefixes for all interfaces.

If your WAN has got an IPv6 and if the IPv6 gateway is set correctly, you should be able to ping e.g. "2600::" from OpnSense itself.

Ideally, you would then assign one of the 256 possible /64 IA_PD prefixes to your LAN interface and see that as well in the overview. This prefix will be the one that gets distributed to your LAN clients by whatever means you choose (i.e. DHCPv6 or SLAAC, but this time in the server role).

My preferred way of doing this is described here, BTW.

That does not answer how you distribute the IPv6 on your LAN. You can do that via DHCPv6 or via SLAAC, with different daemons for each.

But FWIW, if your LAN loses its IPv6, then that seems to be the problem. You should set your LAN interface to "Identity assosication" instead of "Track Interface".

Hast Du das 10er Subnetz als erlaubte Adressen für die Gegenseite eingetragen? Das erst führt bei den meisten WG-Clients dazu, dass sie eine Router dafür über das VPN eintragen. Außerdem musst Du auf der OpnSense eine Firewall-Regeln einrichten, die den Zugriff von den WG-Clients zulassen.

Look back to post #37 if you do not want to use the forum search.

You do not tell anything about your IPv6 setup:

DHCPv6 or SLAAC? Which daemon(s) for both? Do your clients still get an IPv6 assigned? What gateway do they get?

Because it is a complex timing issue that manifests itself only under specific circumstances.

Ich glaube nicht, dass das ein Problem wird - laufende TCP-Sessions werden ja nicht unterbrochen. Die temporären Adressen werden stark überlappend eingesetzt - eine neue wird nur für neue Sessions genutzt, während die alten noch zur Verfügung stehen. Würde Deine IP plötzlich wechseln, wäre die Session ja ohnehin kaputt.

Echt? Ich habe keinen Hostwatch laufen. Es reicht doch völlig, wenn ein IPv6-Paket die OpnSense erreicht oder passiert, dann wird der Neighbor Cache doch auch gefüllt? Klar, Hostwatch merkt es schneller, aber der Sinn ist ja die Verwendung in Firewall-Regeln und die können sowieso nur greifen, wenn Unicast-Traffic über die Firewall läuft.

Das schrieb ich doch - Du bringst zwei Themen zusammen, die nichts miteinander zu tun haben:

b. MAC Address - die haben nichts mit einer temporären IPv6-Adresse zu tun. In pf werden sie einfach direkt verwendet und sie sind vollkommen invariant gegen etwaige Präfixwechsel. Du kannst sie in IPv4- und in IPv6-Regeln verwenden und zwar ein- und ausgehend.

Das heißt: Wenn hMx1 ein "MAC Address" Alias ist, dann wirkt er unabhängig davon, mit welcher IPv6 oder IPv4 das Paket daherkommt. Dazu wird nicht direkt die MAC, sondern per ARP oder NDP alle zugehörigen IP-Adressen genutzt. Das klappt natürlich nur bei "lokalen" Paketen, versagt aber bei gerouteten.

Und Du hast Recht: da die NDP-Tabellen im Hintergrund gescannt werden (filterdns), kann es sein, dass sogar MAC-basierte Aliase verzögert greifen. In der Praxis ist das nicht so relevant, weil die Privacy Extensions typischerweise nur alle paar Stunden wechseln.

Und wie gesagt: Inbound ist das ziemlich irrelevant, weil man die Ziel-IP des Clients ja auch erstmal kennen müsste, weshalb man dort ja typischerweise die parallel existierende Management-IP nutzt. Das Problem entsteht also tendenziell bei ausgehenden Verbindungen, bei denen Privacy Extensions genutzt werden.

Es gibt ja zwei Typen von Firewall-Aliasen, die Du einsetzen kannst:

a. Dynamic IPv6 Host - dabei legst Du nicht wirklich die MAC-Adresse zugrunde, sondern die niedrigstwertigen 64 Bits plus den Präfix des gewählten Interfaces. Die 64 Bits können die aus der MAC gebildete EUI-64 sein, wenn SLAAC genutzt wird oder ein fixer Wert bei DHCPv6 oder auch ein zufällig gewählter, persistenter Suffix bei Windows oder auch eine wechselnde temporäre Adresse bei Privacy Extensions. Nur: Bei IPv6 gibt es jeweils beliebig viele Adressen. Normalerweise existiert die "feste" IPv6 (management address) neben den temporären. Für eingehende Regeln müsste man sowieso die "festen" IPs verwenden, weil man die temporären ja überhaupt nicht kennt. Eine Änderung bekommt die OpnSense auch nicht mit und von außen wären solche Addressen ja auch nicht per DNS bekannt. Für Regeln, die den Zugriff nach außen regeln sollen, ginge das auch überhaupt nicht.

b. MAC Address - die haben nichts mit einer temporären IPv6-Adresse zu tun. In pf werden sie einfach direkt verwendet und sie sind vollkommen invariant gegen Präfixwechsel. Du kannst sie in IPv4- und in IPv6-Regeln verwenden und zwar ein- und ausgehend. Ich verwende diese Aliase deshalb sehr gerne, wenn ich konkrete Clients mit Sonderrechten ausstatten will.

Im Grunde sind das also zwei Fragen:

1. Wie benenne ich zuverlässig Clients für Firewall-Regeln (in beiden Richtungen)?
2. Wie mache ich diese Clients "addressierbar" oder für Monitoring-Zwecke "erkennbar" (i.S.v. reverse lookups)?

Yes, it is a strange thing that opening CSV files without the specific CSV dialogue in Excel shows each row as being one text column only. To fix this, you need to import the file properly. In the English version of Excel, use the following menu path: Data > From Text/CSV (located in the Get & Transform Data group)