[ BE 23.10 ... BE 24.10_7-amd64 ] Automatic fail-over to a Fallback Gateway still fails

[Manfred-Knick]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Loosing the primary connection [ M-Net Premium IP, "Dual Stack" IPv4 + (dynamic) IPv6 ] ,
automatic fail-over to another IPv4 Fallback Gateway fails.

Hint:

Although "Loss = 100%" and "Status=Offline",
the IPv6 part of the WAN interface does not get recognized as "defunct". <----- !

To Reproduce

Simplest: by un-plugging the DSL connection / MoDem cable.

Expected behavior

The lost primary IPv6 connection should not remain "active", but result into "defunct" proper

Describe alternatives you considered

Disabling the broken IPv6 in "System: Gateways: Configuration" does not help.

Possible work-around

A) Manually delete IPv6 default gateway via "route -6 delete -net default",
afterwards re-start the Fallback IPv4 Gateway, e.g.:
-> System: Gateways: Configuration,
. . . select Fallback Gateway -> Edit, -> Save, ->Apply
to allow configuration of its alternative default route.

B) Reboot

Confirmation

Re-plugging the DSL connection / MoDem cable properly re-instantiates the primary connection without any further intervention.

Additional context

Pre-decessor: #7335

Probably related: #5630

Environment

OPNsense Business Edition 24.10_7-amd64
Processor: Intel Haswell I3-4360T
Memory: 32 GiB
Network:
. Intel I218-V
. Intel I350-T2 v2
. Intel I350-T4 v2

[Manfred-Knick]

Background

Connection: FttB ; DSL into Flat ; "M-Net Premium IP" :
"Dual Stack" IPv4 + (dynamic) IPv6 :
ISP provides IPv6 prefixes only, but no static IPv6 interface address

Connections of this type have caused problems before;
these were addressed in #5630 :
Many thanks to @meyergru, @kevinchalet and @fichtner, the situation has definitely improved a lot !

Details

1. Setup WAN interface "MNET" :
   . "IPv6 Configuration Type" = "DHCPv6"
   . "Use IPv4 connectivity"
   . "Prefix delegation size" = 56
   . "Request prefix only"
   . "Send prefix hint"
   . "Assign prefix ID" = 0x10

2. Note: no other interface is configured as
   . "IPv6 Configuration Type" = "Track Interface" yet

3. Result:

   • IPv6 Gateway is setup
   • IPv6 Monitor IP := Gateway

4. ssh into the FW

5. Result:

   • ping -6 { IPv6 Gateway IP }
   • ping -6 to Provider-internal name servers
   • . . . dns01.mnet-online.de
   • . . . dns02.mnet-online.de
   • . . . ipv6-only.m-online.net <--- AAAA Records only
   • ping -6 to external addresses
   • . . . 2a0f:fc80:: ( = dns0.eu )
   • . . . 2620:fe::fe ( = Quad9 )
   • DNS -6 host lookup
   • . . . dns01.mnet-online.de, ipv6-only.m-online.net
   • . . . dns0.eu, Quad9, heise.de,

[x] Check: All of this is working as to be expected :-)

6. Un-plug the connection cable to the upstream DSL MoDem

7. Check -> System: Gateways: Configuration:

   • The IPv6 part of the WAN interface does not get recognized as "defunct",
   • the state is still "active"
   • it's higher priority prevents the Fallback Gateway from stepping in into first row of priorities being used

[Manfred-Knick]

Additionally enabling IPv6 for LAN:

. . . "IPv6 Configuration Type" = "Track Interface"
. . . "Assign prefix ID" = 0x11

Test Site Results

German Test Site: "wieistmeineip.de"

. . . Ihre IPv4-Adresse lautet: xxx.xxx.xxx.xxx
. . . Ihre IPv6-Adresse lautet: 2001:yyy:yyyy:yyyy:yyyy:yyyy:yyyy:yyyy
 
. . . Test IPv4: "OK"
. . . Test IPv6: "OK"
. . . Test Dual Stack: "OK"

Hope
that these details help to diagnose,
and perhaps others with a similar type of ISP connection for comparison during setup.

Kind regards
Manfred

[Manfred-Knick]

Version History

OPNsense 24.10 business edition is based on the OPNsense 24.7.6 community version.

Roadmap for 24.7 contained

. </> "Interfaces"
. . . "Interfaces: allow tracking the WAN itself in DHCPv6 mode *"

(*) pointing to above named #5630

as "Completed".

[Manfred-Knick]

Completely dis-abling IPv6:

. . . WAN interface "MNET" :
. . . . . . "IPv6 Configuration Type" = "DHCPv6"

Flint_GW (active) "111 (upstream)"
MNET_PPPOE "defunct (upstream)"
MNET_DHCP6 still exists "defunct (upstream)"

BUT:
ssh -> "netstat -r" : no default route has been created at all ! <--- !

Hint:
. . . "netstat -r" quickly shows IPv4 information,
. . . but (reproducibly) takes a long time to show IPv6 information.

Re-start the Fallback IPv4 Gateway results into proper fallback default IPv4 route.

REBOOT:
. proper fallback default IPv4 route

RE-CONNECT:
. re-creates main DSL connection with correct IPv4 default route
. MNET_DHCP6 still exists as "defunct (upstream)"
. "netstat -r" still takes a long time to show IPv6 information

DIS-CONNECT:
. same failure as above:
. . . no default route created
. . . re-start the Fallback IPv4 Gateway helps again
. . . "netstat -r" takes a long time to show IPv6 information again

RE-CONNECT:
. quickly re-creates main DSL connection with correct IPv4 default route

[Manfred-Knick]

In -> System: Settings: General,
a (priority) list of DNS servers is configured:
. primary connection:
. . . MNET_PPPOE --> IPv4 (p/s)
. . . MNET_PPPOE --> IPv6 (p/s)
. fallback connection:
. . . Flint_GW --> IPv4 (p/s)

Even after re-starting the Fallback IPv4 Gateway,
the corresponding DNS servers are not being taken into service!

Even ssh -> : "host ..." delivers, but "ping ..." fails

Although -> Services: Unbound DNS: General : "Enable Unbound"

[Manfred-Knick]

Probably related:
"Topic: Multi-WAN failover not bringing link back up properly"

[Manfred-Knick]

Further observations:

. -> System: Gateways: Configuration : Disable Failover Gateway:

• only results into status "pending"
• netstat -r : corresponding entry persists

. -> Interfaces: Disable Interface:

• Gateway status changes to "Malconfigured Gateway",
• but still does not change to "defunct", keeping its Priority
• netstat -r :
• • corresponding IPv4 entry finally removed
• • corresponding IPv6 entry still persists

.-> un-plug connection:

• dpinger: only one <- fallback-GW (correct)
• netstat -r : main IPv6 default persists, all same as before

[fichtner]

@Manfred-Knick I'm sorry to say it's very hard to follow your report. Can you break this down into the initial issue and the relevant logs? Otherwise I'm unable to follow.

[Manfred-Knick]

Hallo, Franco!

Kurzfassung, aktueller Stand:

Loosing the primary connection [ Dual Stack IPv4 + dynamic IPv6 ] ,
automatic fail-over to another IPv4 Fallback Gateway fails.

System: Gateways: Configuration:
.- Primary IPv4 default gateway [Prio 101] --> "defunct" (correct)
.- Primary IPv6 default gateway [Prio 102] --> not "defunct", but should be
.- Primary IPv6 default gateway [Prio 111] --> "active" (should not be)
Routes:
.- Primary IPv6 default still persists
.- Fallback IPv4 default not created

System: Log Files: General
2024-11-22T10:26:29 Notice opnsense-business /usr/local/etc/rc.newwanip: Failed to detect IP for interface wan
2024-11-22T10:25:23 Notice kernel <6>igb0_vlan40: link state changed to DOWN
2024-11-22T10:25:23 Notice kernel <6>igb0: link state changed to DOWN
2024-11-22T10:24:55 Notice syslog-ng Configuration reload finished;
2024-11-22T10:24:55 Notice syslog-ng Configuration reload request received, reloading configuration;

Mein Eindruck:
.- surviving Primary IPv6, with it's higher priority, prevents the Fallback Gateway from stepping in

No 'automatic' work-around;
manual intervention necessary:
.- (ssh) Konsole : " 11) Reload all services "
.- (locally) reboot

System: Gateways: Configuration:
.- same as before

Routes (correct now):
.- IPv4: default created -> Fallback GW
.- IPv6: no default route

Mein Verdacht:
.- evtl. Umfeld "pppoe plus DHCPv6 ohne eigene feste IP"?

Grüße aus einem frisch verschneiten München
Manfred

[Manfred-Knick]

. # cd /var/log

. <<<<<<<<<< <<<<<<<<<< the following is as to be expected: >>>>>>>>>> >>>>>>>>>>

. # grep -s -R "MNET_"

./gateways/gateways_20241123.log:<165>1 2024-11-23T11:18:52+01:00 aaa.bbbbb.de
dpinger 76472 - [meta sequenceId="21"]
MONITOR: MNET_PPPOE (Addr: xxx.xxx.xxx.xxx
Alarm: none -> loss RTT: 4.9 ms RTTd: 1.6 ms Loss: 12.0 %)

./gateways/gateways_20241123.log:<165>1 2024-11-23T11:18:52+01:00 aaa.bbbbb.de
dpinger 76472 - [meta sequenceId="22"]
MONITOR: MNET_DHCP6 (Addr: yyyy::yyyy:yyyy:yyyy:yyyy%pppoe1
Alarm: none -> loss RTT: 4.7 ms RTTd: 1.6 ms Loss: 12.0 %)

./gateways/gateways_20241123.log:<165>1 2024-11-23T11:18:57+01:00 aaa.bbbbb.de
dpinger 76472 - [meta sequenceId="33"]
MONITOR: MNET_PPPOE (Addr: xxx.xxx.xxx.xxx
Alarm: loss -> down RTT: 4.9 ms RTTd: 1.6 ms Loss: 21.0 %)

./gateways/gateways_20241123.log:<165>1 2024-11-23T11:18:57+01:00 aaa.bbbbb.de
dpinger 76472 - [meta sequenceId="34"]
MONITOR: MNET_DHCP6 (Addr: yyyy::yyyy:yyyy:yyyy:yyyy%pppoe1
Alarm: loss -> down RTT: 4.8 ms RTTd: 1.6 ms Loss: 21.0 %)

. # cat system/latest.log

<45>1 2024-11-23T11:10:53+01:00 aaa.bbbbb.de syslog-ng 9405 - [meta sequenceId="1"]
Configuration reload request received, reloading configuration;
<45>1 2024-11-23T11:10:53+01:00 aaa.bbbbb.de syslog-ng 9405 - [meta sequenceId="2"]
Configuration reload finished;
<13>1 2024-11-23T11:18:42+01:00 aaa.bbbbb.de kernel - - [meta sequenceId="1"]
<6>igb0: link state changed to DOWN
<13>1 2024-11-23T11:18:42+01:00 aaa.bbbbb.de kernel - - [meta sequenceId="2"]
<6>igb0_vlan40: link state changed to DOWN

. <<<<<<<<<< <<<<<<<<<< not as to be expected: >>>>>>>>>> >>>>>>>>>>

<13>1 2024-11-23T11:19:49+01:00 aaa.bbbbb.de opnsense-business 47641 - [meta sequenceId="1"]
/usr/local/etc/rc.newwanip: Failed to detect IP for interface wan

<11>1 2024-11-23T11:25:10+01:00 aaa.bbbbb.de send_heartbeat.py 65880 - [meta sequenceId="1"]
connection error sending heartbeat to https://opnsense.emergingthreats.net/api/v1/telemetry

<27>1 2024-11-23T11:29:20+01:00 aaa.bbbbb.de dhcp6c 41978 - [meta sequenceId="1"]
transmit failed: Can't assign requested address

. { ... iterated ... }

[Manfred-Knick]

@fichtner : Franco, if you would like additional information, please let me know.

@meyergru : Uwe, have you ever tried Fall-Back @ your M-Net dual Stack?
For my first failover tests, the hot spot of my smartphone was sufficient.
Now it is based upon a W-LAN connection to a friend in another flat.

[meyergru]

No, I just use one connection with no fallback. M-Net is quite reliable... ;-)

[Manfred-Knick]

Allerdings!
Nebenbei: Mir werden die vertraglich vereinbarten Übertragungsraten [ M-Net Premium IP ] dauerhaft um mehr als 10% über-erfüllt; dem Privat-Anschluss der WG unter mir [ Internet 250 ] ebenso.

Mir geht es um die Validierung, ob ich OPNsense BE inklusive dieser Option ("Absicherung via Fallback") im Kunden-Umfeld anbieten und verlässlich einsetzen kann. Bisher ist die Notwendigkeit "Manual Intervention" dafür leider ein K.o.-Kriterium :-(

[Manfred-Knick]

Observation:
.-> System: Settings: General : "Allow default gateway switching":
(i) "If the link where the default gateway resides fails switch the default gateway to another available one"

• Enabling or Disabling has no effect at all, same symptoms, no different entries in the logs, whatsoever.

[fichtner]

All I can see here is that monitoring is either not set up correctly or the prerequisites for reconnect are not given.

/usr/local/etc/rc.newwanip: Failed to detect IP for interface wan

It just shows there is something else that's weird.

BTW, IPv4 and IPv6 failovers act independently of each other. In most cases the link is dead on both ends but you have to consider gateway groups can be set for IPv4 and IPv6 separately and the ordering is not strict between address families.

I'd suggest commercial support for these types of issues since it requires looking at the box as it exhibits the behaviour to find the problems with the configuration.

Cheers,
Franco

[Manfred-Knick]

Lieber Franco:

.- System: Gateways: Configuration : 2 + 1 GW, Prio 101 | 102 | 111
.- System: Settings: General : "Allow default gateway switching"
das ist alles

.- obige Fehlermeldung: ausschließlich, nachdem die DSL-MoDem-Verbindung gekappt wurde

.- reset: keine einzige Fehlermeldung, alles wie erwartet:
.- "ROUTING: ignoring down gateways: MNET_DHCP6, MNET_PPPOE"
Auf BSD-Ebene finde ich keine einzige Unstimmigkeit! Wo soll da die Fehl-Konfiguration sein?

Wieso OPNsense BE in [ System: Gateways: Configuration ] mein MNET_DHCP6 immer noch als "102 (upstream)" führt ?
Wieso OPNsense BE von 2 GW über eine gemeinsame gestörte Leitung nur eines als "defunct (upstream)" erkennt?
Dafür möchte ich keinen über BE zusätzlichen Support bezahlen müssen.

Wir hier im Office können problemlos ggfs. auf's Reboot-Knöpfchen drücken.
Bei Kunden [ "Remote" | "Fallback" ] mag ich OPNsense BE so noch nicht einsetzten.

Für beides bitte ich um Verständnis.

Meinerseits werde ich diese Nachforschung zunächst einstellen.
Dir stelle ich aber gerne zusätzliche Informationen bereit (configs / logs, ggfs. geschützt via PM)
und wäre auch bereit, Tests durchzuführen.

Was mir sehr wichtig ist:
Dir ein ganz dickes "DANKE!" für all Deine tolle Arbeit auszusprechen. Respekt! Kompliment!

Herzliche Grüße
Manfred

[fichtner]

Hallo Manfred,

Ich kenne leider das System nicht und auch nicht die Einstellungen.

Es ists darauf zu achten, dass alle Gateway Monitor IPs über separate Host Routes laufen und das DNS dazu. Diese Einstellung muss stimmig sein. Auch muss das Gateway Monitoring bei allen verwendenten Gateways aktiviert sein. Es müssen alle Gateways funktionieren mit entsprechenden Angaben über Loss usw.

Dann ist darauf zu achten, dass gegebener Paketverlust oder Latenz auf manchen Leitungen normal ist (z.B. Mobile/LTE) -- dort funktionieren die Standardeinstellungen nicht. Teilweise auch bei ISP Standleitungen bei zu viel Traffic.

Dann auch bitte das System / Log Files / General Log anhängen für rc.newwanip -- IPv6 bitte auch ausklammern. Es macht das Debugging zu wild.

Alles weitere ist wie gesagt Business Support. Da schauen wir in einer Remote Session direkt drauf. Alles viel einfacher und zielführender. Wenn es noch Bugs gibt werden diese dann auch behoben, sonst reicht ja die Rekonfiguration.

Grüsse
Franco

[fichtner]

PS: Logs an [email protected] -- danke

[Manfred-Knick]

Guten Morgen! Überraschung:

Ich habe einen alten Test aus meinem ersten OP #7335 wiederholt:

Wenn ich
. . . . . IPv6 komplett disable
( -> Interfaces -> MNet , "IPv6 Configuration Type" von "DHCPv6" auf "None"),
bleibt MNET_DHCP6 immer noch erhalten - aber nun als "defunct", immerhin.
Mir unverständlich: Selbst nach einem Kaltstart ist dies immer noch der Fall.

Jetzt zum erfreulichen Teil:

Wenn ich danach das DSL-MoDem-Kabel ziehe,
werden nun beide ( MNET_PPPOE und MNET_DHCP6 ) als "defunct (upstream)" geführt.
Weiterhin, wie erfordert:
- Es gibt keine IPv6 default route,
- die IPv4 default route wurde auf das Fallback-GW umkonfiguriert.

. . . . . Fallback erfolgreich, ohne manuellen Eingriff

Allerdings mit Fragezeichen : Wieso gibt es immer noch ein GW "MNET_DHCP6" ?

Wenn ich danach das DSL-MoDem-Kabel wieder stecke,
wird PRIMARY in sekundenschnelle wieder hergestellt:

. . . . . Retour erfolgreich, ohne manuellen Eingriff

HTH

PS: Screenshots, Logs gingen wieder direkt an [email protected]

[fichtner]

Mir unverständlich: Selbst nach einem Kaltstart ist dies immer noch der Fall.

Wenn der Gateway 1x editiert wurde bleibt er natürlich im System. Das ist allein schon deswegen nötig, weil man das Monitoring einschaltet da es im Standard aus ist. Ab dann bleibt der Gateway auch wenn er nicht benötigt wird, aber kann gelöscht werden.

Das wäre ja schon ein Anfang, wenn IPv6 hier negativ auf IPv4 einwirkt. Vielleicht reicht es schon das Monitoring abzustellen in MNET_DHCP6. Gibt es denn auf dem Failover auch ein funktionierendes IPv6?

[Manfred-Knick]

Danke für Deine Erläuterung!
Eine "Karteileiche" sollte aber nicht als "aktiv" / "upstream" anderen GW in die Quere kommen ...

weil man das Monitoring einschaltet da es im Standard aus ist

System: Gateways: Configuration: -> "Edit Gateway":
Der Eintrag lautet "Disable Gateway Monitoring", ist defaultmässig nicht aktiviert,
und muss ggfs. aktiv angewählt werten;
(i): This will consider this gateway as always being "up".

Vielleicht reicht es schon das Monitoring abzustellen in MNET_DHCP6.

widerspricht m.V.n. dem help-text (i) ; werde ich aber natürlich testen

Gibt es denn auf dem Failover auch ein funktionierendes IPv6?

Wie oben dokumentiert:
. - Fallback: Provider M-Net, Anbindung: DSLite;
. - Übertragung zur FritzBox via WLAN: ausschliesslich IPv4

[Manfred-Knick]

werde ich aber natürlich testen

as expected: does not help; default route not being switched
"Reload" or "Reboot" still needed

[fichtner]

@Manfred-Knick ping :)

[Manfred-Knick]

24.10.1 business edition released
« on: November 27, 2024, 01:46:57 pm »

. . . o system: ignore gateway monitor status on boot when setting up routes

Having upgraded to Version OPNsense 24.10.1-amd64,
running diverse tests during weekend up to today, 17:00 MEZ
with multiple cycles of Disconnect and Reconnect,
no manual intervention was necessary.

Thus I would like to confirm

. . . . . "SOLVED - WORKSFORME" .

Many thanks @franco, @meyergru, @emesterhazy