Multiwan Failover auf Tier2 funktioniert nicht

[wurmloch]

Moin,

heute habe ich mich das erste Mal an dem Multiwan failover versucht (v16.7.1). Leider noch ohne Erfolg. Ich vermute, dass jemand mir schlicht auf die Sprünge helfen muss, dafür bin ich sehr dankbar. Leider hat mich die Suche im Forum nicht weitergebracht.

Mein Setup:

Code: [Select]

Notebook (192.168.1.60)
  |
  v
LAN 192.168.1.1 /24
  |
[opnsense16.7.1]
  |    |
  |  WAN1QSC aa.bb.13.104 /24 --> WAN1GW aa.bb.13.1  --|
  |                                                    |-- WANGWGROUP
WAN2DTAG cc.dd.1.114 /24 --> WAN2GW cc.dd.1.1  --------|
Ich richte mich strikt nach der Anleitung https://docs.opnsense.org/manual/how-tos/multiwan.html?highlight=multi%20wan. Parallel habe ich zwei Fenster auf mit "ping 192.168.1.1" und "ping 8.8.8.8". Beide pings werden kontinuierlich beantwortet.

Nun ziehe ich den Stecker von WAN2DTAG (Tier 2). Beide pings laufen weiter, sollte auch so sein.
Nun stecke ich das Kabel WAN2DTAG wieder und trenne WAN1QSC. Beide pings werden nicht mehr beantwortet und im Browser kann ich www.heise.de nicht mehr aufrufen.

Jetzt wird es merkwürdig: Ich stecke WAN1QSC wieder und nach einiger Zeit wird der ping auf 8.8.8.8 beantwortet, der ping auf die opnsense (192.168.1.1) wird wie folgt beantwortet:

Code: [Select]

C:\Users\wurmloch>ping 192.168.1.1 -t
Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:
Antwort von aa.bb.13.2: Zielnetz nicht erreichbar.
Antwort von aa.bb.13.2: Zielnetz nicht erreichbar.
Antwort von aa.bb.13.2: Zielnetz nicht erreichbar.
Antwort von 192.168.1.1: Zielnetz nicht erreichbar.
Antwort von aa.bb.13.2: Zielnetz nicht erreichbar.
Antwort von aa.bb.13.2: Zielnetz nicht erreichbar.
Antwort von 192.168.1.1: Zielnetz nicht erreichbar.
Antwort von aa.bb.13.2: Zielnetz nicht erreichbar.
Ping-Statistik für 192.168.1.1:
    Pakete: Gesendet = 8, Empfangen = 8, Verloren = 0
    (0% Verlust),
Vorher mit beiden GWs erreichbar, funktionierte der Ping, das Failover auf Tier2 funktioniert überhaupt nicht und am Ende (mit beiden GWs wieder erreichbar) ist der ursprüngliche Zustand nicht wieder herzustellen. Zu jeder Zeit kann ich aus dem LAN per https:8443 und ssh:8022 auf die opnsense zugreifen.

Was mache ich falsch? Anbei noch ein paar screen shots von meiner Konfig.

Danke und Gruß, Wurmloch

[wurmloch]

Noch ein screen shot vom Dashboard.

Danke!
Wurmloch

[wurmloch]

Moin,

heute habe ich eine zweite opnsense frisch installiert und mich am Multi WAN failover Setup versucht. Und es hat sofort funktioniert! :-)

Nun habe ich zwei Maschinen:
1) zu Hause 2x WAN (private IPs per DHCP vom jeweiligen Internet Router) - funktioniert
2) auf der Arbeit 2x WAN (feste öffentliche IPs von zwei verschiedenen Carriern) - funktioniert nicht.

Also werde ich rausbekommen, warum 2) sich noch wehrt! :-)

[franco]

Moin Uwe,

Freut mich zu hören. Bin gespannt auf die Rückmeldung. 


Grüße
Franco

[wurmloch]

Moin,

nach ein paar Tests schreibe ich einen kurzen Statusbericht. Ich bin immer noch bei einem reinen Multi WAN Failover setup.



Ansicht Gateways:








Einstellungen Firewall Regeln:








Nach vielen Tests mit Unterbrechungen der einen oder anderen Leitung bin ich zu folgender Erkenntnis gelandet:

Es scheint nicht egal zu sein, wie ich die Leitung unterbreche, also entweder Kabel aus der Box ziehen, so dass die NIC den Link verliert, oder den Zugang über den vorliegenden Router sperre, die NIC aber den Link behält (und damit in meinem Testszenario die DHCP Lease gültig bleibt?).

Das Failover funktioniert immer, solange die entsprechende NIC einen Link hat. Wenn ich aber das Kabel aus der Box ziehe, dann ist der Status nach dem Reinstecken "unknown". Das kann ich relativ gut reproduzieren. Hier drei Bilder zu "unknown":







In einer Produktivumgebung wird die opnsense die WAN IPs vermutlich nicht über DHCP bekommen und auch nicht direkt mit den Routern verbunden sein.

Bei meinem zweiten Multiwan Testszenario (wie eingangs beschrieben) mit festen public IPs auf den WANs werde ich das Failover vermutlich nur durch Stecker ziehen bzw. Port down schalten auf den vorgelagerten Switches provozieren können. Wie gesagt, da werde ich noch berichten.

LG
Wurmloch