Messages

I do have a running ISP connection on WAN and I have a MAC set on WAN that is different from the bridge MAC. My symptoms are:

- After a while of inactivity (300 seconds will be enough), a ping does not succeed any more, despite an ARP entry being present and non-expired.
- "arp -d <IP-OF-ONT>" makes the ping work again immediately.
- A continuous ping never stops working.

I have fiddled around with various settings on the bridge and even disabled the igc hardware mac filtering via promiscuous mode, all to no avail.

Nope. Not when the MAC on the WAN interface is manually set. Yet I fear that when I manually set the same MAC on the ONT interface, it might break my internet connection.

I hope I have found it: net.link.bridge.pfil_member=0 could do the trick.

Guess what? The ping stopped working again. It could well be something off with the MAC, because I have to set the MAC on the WAN interface manually and the bridge MAC differs.

Setting net.link.bridge.inherit_mac=1 does not change the bridge MAC immediately, BTW.

P.S.: Now it starts working again out of thin air, still with a different MAC - strange.

FWIW: I tried this approach instead of my usual (working) virtual IP setup.

However, it did not work first - I could not even ping the ONT from OpnSense itself. Only after I disabled my null route for 192.168.0.0/16 did it work - and then, to my complete disbelief, it still worked when I re-enabled the null route!

There is something fishy going on. I have read several reports of incidents where only a reboot made certain things work after settings were changed with 26.7.x.

@lmoore: Now I understand. Interesting that you can use a bridge on an otherwise configure port... the way you do it you create two interfaces, which does the trick. I stand corrected, well done.

Actually, although this is kind of complicated, it should be added to the thread where ONT/modem access for the non-VLAN DHCP case is discussed, just because the "usual" VIP way is risky in case an initial DHCP takes too long.  I cannot seem to find it just right now.

[not]

@lmoore: That will not cut it. The problem is not that the modem cannot be reached.

The problem is that the normal WAN NAT rule does not work, because the translated NAT IP is the virtual IP and not the real WAN IP.

This is, because when the DHCP client on WAN times out on the first try, the virtual IP gets to take the "primary" address slot on the WAN interface. When DHCP later succeeds, this will not change, such that the virtual IP will still be used for normal unbound NAT (not for the NAT rule that you need to reach the modem).

This problem does not manifest when the WAN is on another interface than the modem, like with PPPoE or with a VLAN or when DHCP is fast enough to succeed before the virtual IP gets initialized.

A fix for this is probably non-trivial, because you would have to delete and re-create the virtual IP when the DHCP finally succeeds and that could break other things.

The easy way out would be to skip modem access completely under these conditions. Another way would be if the modem could be configured such that the GUI can be configured on another VLAN than the internet connection. If the ISP wants a VLAN, you should tag it on OpnSense if you can and not leave that to the modem. There seems to be a community firmware for that XGS-PON:

https://pon.wiki/guides/masquerade-as-the-orange-sa-livebox-7-with-the-was-110/#from-the-web-ui

And you probably used the "fix-vlans" setting from here:

https://pon.wiki/guides/masquerade-as-the-att-inc-bgw320-500-505-with-the-was-110/#configure-ont-settings

I think (aka "IDK") that AT&T needs a VLAN. As I said, when you let OpnSense do the tagging, it could work, because you would use different interfaces for ONT and WAN, then.

You probably need the os-realtek-re plugin. Without a network connection, it is a little hard to install it, though.

Correct, I meant OpnSense "snapshots", not ZFS "snapshots" and that you cannot boot them any more, indeed making them obsolete once you upgrade the pool, even if you upgraded the boot files. While I am at it, I might as well delete my old snapshots right now...

Also, if the kernel/zfs implementation was just updated, you cannot use older snapshots if you upgrade the zpool.

Bitte die Bilder hier im Forum anhängen, nicht mit externen Links...

Ja, aber dem ursprünglichen Konzept widersprachen dann zwei Dinge (in absteigender Wichtigkeit für diejenigen, die es hätten umsetzen müssen):

1. Die ISPs möchten zur Monetarisierung von Business-Anschlüssen keine festen IPs jedweder Art beim Privatanschluss, weil damit ja Dienste bereitgestellt werden können und da möchten sie auch extra abkassieren.

2. Schmackhaft machen können sie es dem geneigten Privatkunden damit, dass wechselnde Präfixe ja die Anonymität erhöhen, damit die bösen Internet-Riesen keine Benutzerprofile anlegen können.

Ergo: Wechselnde Präfixe. Die selben Gründe sorgen übrigens auch dafür, dass CG-NAT für die ISPs gar kein echtes Problem ist, sondern eher eine brauchbare Lösung darstellt. Bei manchen ISPs bekommt man eine routebare IPv4 ja nicht mal gegen Einwurf von Scheinen.

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.