Messages

That depends. Cliets are free to use many IPv6 at the same time: LL, ULA and GUA, and also multiple ones of the latter.
For outbound access, they have means to determine what is best (like if they use privacy extensions, they will use a random GUA preferably). For inbound access, they will react to any of them. So, if you want to have a permanent DNS handle, you would use the EUI-64 GUA (or ULA for dynamic prefixes).

As said, many clients derive that from the MAC, Windows does not, but AFAIK, the EUI-64 part still is static.

For Ubuntu and other Linuxes, I normally see MAC-derived EUI-64 parts with SLAAC, so IDK what the reason is that your see otherwise - maybe some DHCPv6 service is in play?

Now we are almost back to what I wrote in post #6:

Because you have to provide the conduit anyway (which is the hardest part), I would always prefer to do the inhouse cabling all by myself. That way, you can choose to use the original outlet in the basement if you so choose later on or extend that via a single-mode fibre cable to any location you need.

This can be done via a conduit and cable (as said, they are dirt cheap) or a system like Huawei, where you can even skip the conduit altogether and have the inhouse cabling pratically invisible glued to the wall (modulo wall breakthroughs).

It does not need to be, the gateway you are given can also further away than your counterpart. IDK how / if the Asus router shows its gateway.

If your prefix is static, you can create overrides in Unbound for any client, using its EUI-64. So you get <prefix(56 bits)>+<interface prefix (8 bits)>+<client-EUI-64> as IPv6 for usual clients.

Note that some clients (e.g. Windows) choose to use arbitrary suffixess instead of a MAC-derived EUI-64 for privacy reasons. I am not talking privacy extensions here with changing suffixes, but hiding the MAC, which could normally be derived from the suffix.

Yes, the WAN IP as well as the default gateway are on Plusnet. However, neither is reachable from here as well. This looks like a new development area where connectivity is not yet established.

On the other hand, if it works with an Asus router... I would check what WAN IP and default gateway you get with the Asus router. But heck, ask your ISP what is wrong there. Obviously, they give your the PPPoE credentials, so they must be able to deal with a different router.

Some ISPs detect a router change and give you a temporary non-routable network in which you can register your new hardware. Some do this for ONTs only, others even want to know when the router changes. Ask them, they must know.

Maybe your WAN IP is now something like 10.x.x.x, which would give an indication.

Right. SLAAC is meant to give IP adressed to clients. They can even take up random IPs (e.g. with privacy extensions). Those are for outbound access, mostly.

If you want to make your clients addressable by name, you can use these mechanisms:

1. IPv4 only (this is the simplest and my recommendation): Do not bother to make your clients addressable by IPv6 at all.
2. Via DHCPv6. While this works, the DNS entries hold as long as your DHCP lease time and thus, may be wrong with dynamic prefixes.
3. With static prefixes: Use SLAAC and hope that the client uses EUI-64 (potentially among others). Then you can statically namen your clients via PREFIX:EUI-64. In this case, you can also use DHCPv6.
4. With dynamic prefixes: ULAs may be your friend, but note that they are prioritized LOWER than even IPv4 - contrary to popular belief).

Because most people have dynamic prefixes, I prefer to use 1., but with SLAAC for outbound access only. This is all covered here: https://forum.opnsense.org/index.php?topic=45822.0

Mir stellt sich die Frage, was Du genau vorhast:

a) Dein Netzwerk aufzubauen und vorab zu spezifizieren, was Du willst und dann dokumentieren wie Du es genau gemacht hast?
b) Dich beraten zu lassen, wie der Übergang Deines Wünschens zur Realisierung geht?
c) Einen allgemeinen Leitfaden für den A-bis-Z-Aufbau zu schreiben?

Die Probleme hast Du selbst schon benannt:

a) Das wird dann sehr spezifisch für Deinen Aufbau / Deinen Provider / Dein gewünschtes Setup. Der nächste Anwender mit geringen Netzwerkkenntnissen scheitert am ersten Unterschied zu Deinem Setup - ggf. bereits beim Verbindungsaufbau zu seinem Provider.

b) Ja, das hätten alle gerne, dass sie durchgecoacht werden - allerdings: da lernst Du nichts bei (Zitat: "fällt es mir leider schwer, mich über längere Zeit in technische Dokumentationen zu vertiefen") und stehst am Ende vor der Situation, dass Du das nicht warten kannst. Das ist potentiell gefährlich. Ich sage es immer wieder: wer OpnSense mit einem Consumer-Produkt wie die Fritzbox verwechselt und glaubt, sein Netzwerk damit "irgendwie sicherer" zu machen, irrt.

c) Wie Patrick schon schrieb: Anleitungen gibt auf drei Ebenen:

1. Bücher wie "Der OpnSense-Praktiker" - als Überblick und Starthilfe.
2. Tutorials, die bestimmte Themen im Zusammenhand behandelt.
3. Die OpnSense-Dokumentation für einzelne Teile im Detail.

Ich kapiere gerade nicht, wo Du da zwischen willst.

Das ist doch eine reine Geschmacksfrage. Du kannst das auf drei Arten lösen:

1. Indem Du der Anlage beibringst, öfter Keep-Alives zu senden, um die Ports offen zu halten.
2. Global auf der Firewall alle Ports länger offen zu halten.
3. Lokal in der spezifischen Regel die spezifischen Ports länger offen zu halten.

Ich würde das Übel an der Wurzel anpacken und 1 nehmen - aber das schrieb ich ja schon. Denn: andere SIP-Geräte machen das selbst richtig.
Nummer 2 ist eine Notlösung mit offensichtlichen Drawbacks. Nummer 3 hat den Nachteil, dass Du nächstes Mal dran denken musst, dass da noch "versteckte" Optionen nötig sind.

[Ziel]

Hast Du eventuell vergessen, ein Outbound NAT auf der OpnSense zu machen? Wenn Du das nämlich nur als geroutetes Netz machst, "sieht" Eure interne IT die IPs von vmbr2 und vmbr1. Da reagieren die natürlich allergisch, wenn Quell-IPs auftauchen, die sie nicht verwalten. Da muss nur ein Client eine IP ansprechen, die nicht in ihrem Netz liegt, dann geht das über das Default-Gateway (die OpnSense) an deren Default-Gateway (interne IT) raus.

Richtest Du Outbound NAT ein, passiert das nicht. Das Maximum, was noch leakt, sind dann Ziel-IPs im RFC1918-Bereich. Das kann man durch Null-Routes verhindern: https://forum.opnsense.org/index.php?msg=258980

First, @nero355 is right, see point 8 here.

That being said, this sounds like a router-behind-router scenario where you forgot to have outbound NAT on your OpnSense such that the returning packets do not get back because the front router does not know about your LAN subnet, see point 4 here.

The problem is that you cannot use "This Firewall" as redirection target IP, regardless of IPv4 or IPv6. "This Firewall" is not a SINGLE address.

Imagine you say "192.168.10.1, 192.168.20.1" there. What does that mean? Use ONE single IP there.

Look at your WAN IPv4. Does it start with 100? Also, start this command from a CLI from your OpnSense box:

Code Select Expand

curl -4 ifconfig.me
If either your WAN IPv4 starts with 100 or the WAN IPv4 differs from what the command shows you (or both), you probably have a CG/NAT aka DS-Lite connection. With that, your ISP does not give you a routeable IPv4, but translates your WAN IPv4 via NAT to a routeable IPv4 that is used outside of the provider network.

Therefore, you share your "outside" IPv4 with many other customers. This is a case of double-NAT, where your ISP would have to create a port-forwarding rule for you, which he doesn't. So, if you find yourself in that situation, you cannot port-forward IPv4 and must find other means for outside-in access, like IPv6-only or create a tunnel connection (e.g. via Cloudflare or a VPN to a cloud instance that provides IPv4). Some ISPs also offer "real" IPv4 for a fee.

This is now also covered here, point 31.


Forget that, it does not apply to you. You cannot port-forward IPv4 and IPv6 at once, because the redirect destinations must be either IPv4 for IPv4 and IPv6 for IPv6. You cannot port-forward IPv6 to an IPv4 address, much less to a set of IP adresses for your firewall via "This Firewall". You must specify one (and just one) specific IP and you normally need two separate rules. That being said, maybe the combined rule would work with "LAN address" as the redirection target.

For IPv4, you can use 127.0.0.1 or any (V)LAN interface IP, for which there are specific aliases as well (like "LAN address"). For IPv6, you cannot use ::1, and you also cannot use the link-local IPv6s. I always use an ULA virtual IP for that or also "LAN address". Matter-of-fact, I never use IPv6 port-forwarding on OpnSense itself , but only open the ports directly with firewall rules.

For HTTPS, I use a reverse proxy, because then you can also use name-based redirection. There are guides on how to do that via Caddy or HAproxy in the tutorial section.

The only thing you cannot do is to "clone" an ONT because the ISP-provided ones are often locked. Cloning provides the benefit of having a cold standby in case the original ONT dies.

The equipment the providers usually have can do both XGS-PON and GPON or they give you a port that is suitable for you depending on what the ISP knows (or thinks) you have. Technically, they can also optically mix XGS-PON and GPON OLTs on the same customer fibres, just because of the different wavelengths.

You would be hard pressed to find an ISP that starts with XGS-PON and has only that. Although that might be true of Telekom when they now start a new "Ausbaugebiet".

XGS-PON ONT prices are a lot higher than GPON ONTs. They often draw a lot more power, as well. As long as you do not have a rate > 1 Gbps, you can use a GPON ONT, because XGS-PON is mostly downwards-compatible. In Germany, there are only a few ISPs who already offer XGS-PON - we sometimes use to call it "digital diashora".

In theory, one could have up to 2.5 Gbps downstream over plain GPON, BTW.