Messages

You can also try to create a manual outbound NAT rule and use "Hybrid" NAT mode.

It is almost sure that you need NAT on OpnSense for this to work because your front router does not know the route to 192.168.10.1/24.

[pac]

It is the package manager for Arch Linux.

It does work. Unless you have conflicting dynamic leases because you changed the IP for a client and made it static (aka "migrating from dynamic to static"). In that case, there can still be "active" leases that prevent your clients from ever obtaining those blocked IPs.

Also, static leases need to be outside of dynamic pools. This is mandatory.

Check that first and then look at /var/db/kea/kea-leases4.csv where you may find that the IPs you reserved are still taken up by other MACs (provided that you disabled "Match client-id").

You can stop Kea, clear out the mess in the configuration and the lease file and then start Kea again and it wil magically work.

See this for a more throrough explanation.

If it is really 25.7 and not 25.7.x, then I would say yes. You can do a snapshot first if you want to switch back.

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.