MultiWAN, Tier2 Fehler beendet Verbindungen

[MiSc]

Hallo Forum,

nachdem ich jetzt schon ein par mal versucht habe dem Phänomen auf die Spur zu kommen frage ich mal hier an was ich evtl noch übersehen habe.

Folgendes Setup:

Code: [Select]

                WAN                      WAN
                 :                        :
                 : UM Business            : T VDSL
                 :                        :
             .---+---.                 .--+--.
        WAN1 | Cable |     Modems      | DSL | WAN2
             '---+---'                 '--+--'
                 |                        |
        Ethernet |                        | PPPoE
                 |                        |
            .----+----.              .----+----.
            | Router1 |    Router    | Router2 |
            '----+----'              '----+----'
   130.x.x.49/30 |                        | 10.19.9.1/24
                 |      .----------.      |
                 +------| OPNsense |------+
          130.x.x.50/30 '----+-----' 10.19.9.2/24
                             |
                         LAN | 10.0.0.1/24
                             |
                       .-----+------.
                       | LAN-Switch |
                       '-----+------'
                             |
                     ...-----+-----...
                     (Clients/Servers)

Gateway Group WAN_LB:
Tier 1: WAN2_GW (Telekom), Monitoring-IP 8.8.4.4
Tier 2: WAN1_GW (UM), Monitoring-IP 8.8.8.8

- Firewall-Regeln für DNS und Gateway-Group laut MultiWAN-Anleitung eingerichtet.
- Allow default gateway switching: Ja
- Disable State Killing on Gateway Failure: Ja
- Skip rules when gateway is down: Nein
- Use sticky connections: Ja

Ziel ist es eigentlich das der gesamte Traffic über WAN2 (Telekom) läuft solange alles OK ist.
Diese Leitung ist auch sehr stabil.
Mit der WAN1 (Unitymedia) habe ich aktuell akute Probleme. Nach meinem Verständnis darf aber in dem Fall das WAN1 als Fehlerhaft markiert wird der Traffic über die Telekom-Leitung nicht beeinflusst werden.
Ein dauer-Ping läuft auch erfolgreich durch, aber bestehende TCP-Verbindungen werden getrennt.

Auszug aus dem Gateway-Log:

Code: [Select]

2020-02-16T17:43:03 dpinger: GATEWAY ALARM: WAN1_GWv4 (Addr: 8.8.8.8 Alarm: 1 RTT: 21678ms RTTd: 11704ms Loss: 22%)
2020-02-16T17:43:02 dpinger: WAN1_GWv4 8.8.8.8: Alarm latency 21678us stddev 11704us loss 22%
2020-02-16T17:36:16 dpinger: GATEWAY ALARM: WAN1_GWv4 (Addr: 8.8.8.8 Alarm: 0 RTT: 27106ms RTTd: 39791ms Loss: 16%)
2020-02-16T17:36:16 dpinger: WAN1_GWv4 8.8.8.8: Clear latency 27106us stddev 39791us loss 16%
2020-02-16T17:35:59 dpinger: GATEWAY ALARM: WAN1_GWv4 (Addr: 8.8.8.8 Alarm: 1 RTT: 21671ms RTTd: 9637ms Loss: 25%)
2020-02-16T17:35:59 dpinger: WAN1_GWv4 8.8.8.8: Alarm latency 21671us stddev 9637us loss 25%
2020-02-16T17:35:57 dpinger: GATEWAY ALARM: WAN1_GWv4 (Addr: 8.8.8.8 Alarm: 0 RTT: 21235ms RTTd: 9336ms Loss: 20%)
2020-02-16T17:35:57 dpinger: WAN1_GWv4 8.8.8.8: Clear latency 21235us stddev 9336us loss 20%
2020-02-16T17:35:20 dpinger: GATEWAY ALARM: WAN1_GWv4 (Addr: 8.8.8.8 Alarm: 1 RTT: 19678ms RTTd: 5922ms Loss: 22%)
2020-02-16T17:35:20 dpinger: WAN1_GWv4 8.8.8.8: Alarm latency 19678us stddev 5922us loss 22%
2020-02-16T17:35:08 dpinger: GATEWAY ALARM: WAN1_GWv4 (Addr: 8.8.8.8 Alarm: 0 RTT: 19453ms RTTd: 5945ms Loss: 18%)
2020-02-16T17:35:08 dpinger: WAN1_GWv4 8.8.8.8: Clear latency 19453us stddev 5945us loss 18%

Gateway-Log:

Code: [Select]

2020-02-16T17:43:37 kernel: pflog0: promiscuous mode enabled
2020-02-16T17:43:37 kernel: pflog0: promiscuous mode disabled
2020-02-16T17:43:35 opnsense: /usr/local/etc/rc.filter_configure: ROUTING: keeping current default gateway '10.19.9.1'
2020-02-16T17:43:24 kernel: pflog0: promiscuous mode enabled
2020-02-16T17:43:24 kernel: pflog0: promiscuous mode disabled
2020-02-16T17:43:23 opnsense: /usr/local/etc/rc.filter_configure: Ignore down inet6 gateways : WAN1_GWv4
2020-02-16T17:43:23 opnsense: /usr/local/etc/rc.filter_configure: ROUTING: keeping current default gateway '10.19.9.1'
2020-02-16T17:43:23 opnsense: /usr/local/etc/rc.filter_configure: Ignore down inet gateways : WAN1_GWv4
2020-02-16T17:43:19 kernel: pflog0: promiscuous mode enabled
2020-02-16T17:43:18 kernel: pflog0: promiscuous mode disabled
2020-02-16T17:43:17 opnsense: /usr/local/etc/rc.filter_configure: ROUTING: keeping current default gateway '10.19.9.1'
2020-02-16T17:43:04 kernel: pflog0: promiscuous mode enabled
2020-02-16T17:43:04 kernel: pflog0: promiscuous mode disabled
2020-02-16T17:43:03 opnsense: /usr/local/etc/rc.filter_configure: Ignore down inet6 gateways : WAN1_GWv4

Vielen Dank schonmal für eure Hilfe!
Michael

[geotek]

Das gleiche Phänomen haben wir hier auch. Eine stabile Verbindung als Default und eine zweite als Failover Backup. Sobald der dpinger auf der Backup-Verbindung einen Packet-Loss-Alarm gibt, gehen Verbindungen auf der Hauptleitung verloren, obwohl gar keine Gateway-Umschaltung erfolgt. Ich hatte bisher allerdings noch keine Zeit, das weiter zu analysieren.

[franco]

Bitte Firewall: Settings: Advanced: "Disable State Killing on Gateway Failure" einschalten und prüfen ob dies hilft.


Grüsse
Franco