Messages

Do you operate the two connections from the same location? For multi-WAN setups, you must disable "Reply-To" on WAN connections to avoid assymetric routing.

Also, to avoid your RFC1918 IPs to the main gateway(s), you should set null routes to them: https://forum.opnsense.org/index.php?msg=259031

Stable Privacy wäre für jeden Server das Aus, wenn sich der Präfix ändert.

Jein. Du könntest Dir die neigbor table ansehen, ob irgendeine IPv6 genutzt wird, die nicht der EUI-64 für die MAC entspricht.

Nur: Was macht das vor dem Hintergrund der Fragestellung für einen Sinn? Jeder Client kann verschiedene IPv6 haben, mehrere GUAs, Link-Local-Adressen und ULAs. Für den DynDNS spielt es doch nur eine Rolle, wie man den Client erreichen kann. Selbst, wenn er zusätzlich privacy-IPs nutzt, bleibt doch die aus der MAC (oder DUID) abgeleitete, "quasi-statische" GUA erhalten - und genau die will man ja erreichen, also auch per DynDNS bekannt machen bzw. mit einem Dynamic IPv6 Host Alias per Firewall-Regel freigeben.

Die privacy-IP wird ja nur ausgehend genutzt.

P.S.: Das ist ja gerade der Vorteil, dass Opnsense den DynDNS Update machen kann anstelle des Clients: der würde ja die privacy IPv6 nehmen. Bevor das in OpnSense implementiert wurde, musste der DynDNS Service die EUI-64 ,,maskieren".

Vielleicht mal hier lesen: https://forum.opnsense.org/index.php?topic=45822.0

Genau. Man kann den bekannten EUI-64 Suffix angeben und das Interface, auf dem der Client hängt, für den Präfix.

Leichenschändung - I like! Also seit 2021 haben sich da zwei Dinge geändert:

1. OpnSense kann inzwischen die GUAs von Clients per DynDNS updaten, so dass Variante 2 funktioniert.

2. Falls die bereitgestellten Services HTTP(S) sprechen, bietet sich die Möglichkeit an, einen Reverse Proxy wie Caddy, Nginx oder HAproxy zu nutzen (siehe Tutorial-Sektion des Forums). Dann braucht man nur eine DynDNS-Adresse, nämlich die der OpnSense, die kann dann auch die TLS-Terminierung machen (vorzugsweise mit Wildcard-Zertifikaten), der Rest läuft dann namensbasiert. Man benötigt dazu nur noch CNAMEs auf den DynDNS-Eintrag. Das funktioniert sogar für DS-Lite als Dual-Stack, wenn man auf einem vorgelagerten VPS einen zweiten Reverse Proxy nutzt.

This could be a case of asymmetric routing or maybe, problems because of mixing tagged and untagged VLANs on the same interface.

Since it is Proxmox, you may have also configured both subnets on that...

Bridge mode of course. I do not like double NAT. It is a Leox LXT-010H-D, BTW.

I have verified the gc time for the routes on that system to be 300s:

Code Select Expand

# cat /proc/sys/net/ipv4/route/gc_timeout
300

This would not be a problem in itself, it is just that with this configuration, an ARP request from the ONT will not work.

Thus, reducing the ARP timeout on OpnSense to 300s or below will do the trick.

Was wäre denn Deine Erwartung? Kein reines Failover, sondern Load-Balancing? Der Failover wählt doch das funktionierende Gateway anhand der Priorisierung aus, oder? Selbst wenn Du Load Balancing konfigurierst, bestimmst Du ja nicht selbst, welches Gateway genommen wird.

P.S.: Multi-WAN funktioniert nur für IPv4....

The "Default allow LAN to any rule" is an automatically created rule for your first LAN. Other than that, it is then handled like any other manual rule, i.e. it can have logging enabled or disabled.

The settings in Firewall:Settings:Advanced are for rules "behind the scenes" which are not part of your own rule set and which - apart form some checkboxes - cannot be manipulated from your own ruleset.

I cannot say why this log entry was created, however, there is a small info button on the right of each log line (at least in the live log), if you click on it, you will see the details. Within those details, you will find a link to the "rid" (aka rule id), which gives you the precise rule that led to this log entry.

Ehe Du an der Firewall herumspielst, verkleinere doch die Framed-MTU auf dem NPS, so dass es erst gar nicht zur Fragmentierung kommt - egal, woran es liegt, dass überhaupt eine auftritt (z.B. VPN o.ä.).

One of the potential problems with those 10GbE transceivers is that they get awfully hot, especially when they are in a passively cooled unit and the neigboring SFP+-slot is occupied as well. Under these conditions, higher error rates will occur. I had the same on an X540 adapter, which are made for rack servers with high airflow. Those are not suited for installation in a desktop case.

[did]

It does not matter, because OpnSense cannot reach the IP.


Wow. It seems I have found the problem. The timeout, as it turned out, was exactly 300 seconds. What happens is:

The ARP table entry on OpnSense is valid for 1200 seconds first. My ONT seems to have a timeout of 300 seconds. After 301s, OpnSense still thinks it knows the MAC of the ONT and sends the packet - which is received by the ONT.

It seems my ONT has:

a. No "passive ARP learning".
b. An ARP timeout of only 300 seconds.

Thus, there is no valid ARP entry for answering the request. Even if the ONT does ARP then (of which I am not sure), it will be sent to the WAN interface, not the ONT one. That seems to be the case for some chipsets, so it is probably dependent on the ONT brand. It could probably be circumvented if an intermediate switch was used, but I am not sure.

After reaching the ARP timeout of OpnSense or when the ARP entry is manually removed, it forces an ARP broadcast, which immediately heals the condition.

What did help is setting net.link.ether.inet.max_age=300 on OpnSense.

So, it seems this only happens with certain ONTs that have a short ARP timeout and no passive ARP learning and with this specific setup where there are ambiguities of the two network interfaces on the same physical layer. At least this did never happen with virtual IPs.

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.