Messages

Lies mal den Artikel.

Link-Local kannst Du vergessen, weil Du dazu sogar das Interface angeben musst (z.B. ping "fe80::xxxxx%eth0", etwas anderes funktioniert nicht), außerdem: die können nicht geroutet werden, funktionieren also nicht über VLAN-Grenzen hinweg.

Mit ULA hast Du lokal das IPv6-Äquivalent für RFC1918 bei IPv4 - allerdings nur, wenn es NUR IPv6 im lokalen DNS gibt. Außerdem: Wie regelst Du Verkehr zu IPv4-only Clients (ich habe noch einige)? An Dualstack führt also wenig vorbei.

Es kommt sehr darauf an, wozu Du IPv6 tatsächlich nutzen willst. Sicher, man kann sich als Ziel setzen "IPv6-only" (oder -mostly) - nur: warum?

Das erste Problem bei den meisten Providern ist, dass die zugewiesenen GUAs einen dynamischen Präfix haben. Man kann natürlich für einzelne Clients DynDNS machen, das kann sogar die OpnSense stellvertretend tun. Nur: Willst Du das für alle Clients pflegen, nur damit sie im LAN adressierbar sind? Wohl eher nicht.

Ein oft vorgeschlagener Ausweg ist, dass man für die interne Adressierung ULAs zusätzlich verwendet. Das wirft aber das Problem auf, dass diese bei DNS-Auflösung niedriger priorisiert werden als IPv4-Adressen, also gar nicht wirklich genutzt werden, solange man DualStack verwendet, was oft notwendig ist.

Wenn Du die Clients in Logs anhand ihrer IPv6 identifizieren willst, gibt es auch diverse Probleme, denn die niedrigen 64 Bits können zwar, müssen aber nicht aus der MAC abgeleitet werden - es kann auch eine zufällige DUID sein (z.B. Windows) und die kann auch wechseln (mal ganz abgesehen davon, dass manche Clients sogar die MAC anonymisieren (z.B. iOS). Außerdem gibt es noch IPv6 privacy extensions.

DHCPv6 hilft gegen all das nur sehr bedingt - zudem Android es beispielsweise gar nicht unterstützt.

Ich verwende für interne Adressierung IPv4 und sorge dafür, dass IPv6-fähige Clients ausgehende Verbindungen auch per IPv6 nutzen können. Für den Zugriff von außen nach innen kann man mit Dynamischen Host-Aliasen und DynDNS den Zugriff erlauben oder einen Reverse Proxy einsetzen. Ist alles hier beschrieben.

See, https://forum.opnsense.org/index.php?topic=9245.0 - especially see to it that you do not create a loop to itself.

The script is quite clever. I tested it on all my different installations, SATA, NVME and virtio, but all UEFI and it worked flawlessly.

Besides: loaders-update is neither installed nor available on OpnSense, is it?

I hardly ever use the source port field in a source NAT rule - after all, that usually is on Outbound NAT rule that applies to an interface and most probably to all addresses that can originate from it. Thus, I do not find it unusual to hide that setting under "advanced".

The only thing I find strange with the blocks is that "Destination (advanced)" seems reverted wrt all other settings: Wenn the arrow points down, the subordinate settings should be visible, like with all other items. If it bothers you, you should open a bug on Github.

You did use multiple threads if you tried this via iperf?

Also look at:

https://forum.opnsense.org/index.php?topic=52420.0

And be sure to use "host" CPU type and disable Spectre and Meltdown mitigations.

Port 113 is often blocked by ISPs - there is good reason to do that. Try if you see any packets on that port by creating a logging rule for the port and see if it fires at all.

You can check by creating rules as well for the "open" ports in order to see if something in front of your connection catches these packets, be it the ISP or the bridge modem.

Other than that, you may have a PNP daemon installed which allows LAN devices to dynamically open ports to the outside and some VoIP or other device does this (And yes, port 5060 is for SIP).

See this for a start. Use RSS under OpnSense (it's documented) and set the VM NICs to multiqueue.

A few observations:

1. The new late loading scheme does not leave any traces in dmesg, even if it did update the CPU microcode. You can check with cpucontrol instead.
2. dmesg can show multiple boot logs, so if you only grep in its output, you cannot be sure which previous boot it was in. You would need something like this to grep only the last boot:

Code Select Expand

dmesg | awk '/---<<BOOT>>---/{boot=""} {boot=boot $0 "\n"} END{print boot}' | fgrep microcode

3. After having upgraded your boot files, you may use early loading again by adding these tuneables via System:Settings:Tunables (for Intel CPUs):

Code Select Expand

cpu_microcode_load = YES
cpu_microcode_name = /boot/firmware/intel-ucode.bin


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.