Habe eine neue Sonicwall im DC des MPLS-Anbieters installiert, sie hat durch Glück funktioniert, weiß aber nicht, WARUM sie so funktioniert

Habe eine neue Sonicwall im DC des MPLS-Anbieters installiert, sie hat durch Glück funktioniert, weiß aber nicht, WARUM sie so funktioniert

Ich bin nervös, das Gerät so zurückzulassen, weil es für mich keinen Sinn ergibt, WARUM es so funktioniert.

Wir haben die neue Sonicwall installiert, um eine ältere Cisco ASA zu ersetzen.

Habe gerade die Grundkonfiguration durchgeführt und dabei dieselben IPs wie von der ASA verwendet: (hier IPs erfinden, aber dieselben Subnetze verwenden)

X0 LAN: 172.16.5.2/30

X1 WAN: 216.40.5.100/30

Dann füge ich eine Route für eines ihrer internen Subnetze hinzu …

10.1.0.0/16 zum Gateway 172.16.5.1 am LAN-Port X0 (172.16.5.1 ist ein MPLS-Provider-Router, dessen Route zum Netzwerk 10.1.0.0 führt)

Also, ich habe das eingerichtet. Funktioniert nicht. Das Netzwerk 10.1.0.0 kann die Sonicwall nicht anpingen und kann nicht ins Internet gelangen, Sonicwall kann das Netzwerk 10.1.0.0 nicht anpingen.

JETZT habe ich, nur um etwas zu testen, den X2-Port an der Sonicwall eingeschaltet, ihn in den Layer-2-Bridge-Modus versetzt und ihn an den X0-LAN-Port gebunden. Ich verbinde nichts mit X2, sondern aktiviere nur die Bridge – X0-LAN und X1-WAN sind immer noch die einzigen verwendeten Ports. Wie durch Zauberei funktioniert alles. Ich habe zusätzliche Routen für weitere interne Netzwerke hinzugefügt, die erforderlichen Firewall-/NAT-Regeln eingerichtet, alles funktioniert zu 100 %.

Wenn ich Port X2 ausschalte und die Brücke entferne, geht alles runter.

Ich bin völlig ratlos, warum das Hinzufügen dieser scheinbar nutzlosen Brücke hier funktionieren sollte. Wohlgemerkt, auf dem Cisco war keine Überbrückungseinrichtung vorhanden. Ich habe viele Sonicwalls eingerichtet und hatte nie eine ähnliche Situation.

Hier ist ein Screenshot desSchnittstellen.

Antwort1

Sie erwähnen nicht, wie Ihre Firewall eingerichtet ist. Normalerweise ist X0 LAN und X1 WAN. Standardmäßig wird also der Verkehr von X1 nach X0 blockiert. Aber ich glaube nicht, dass das das Problem ist.

10.1.0.0/16 verfügt auf der Sonicwall nicht über eine routbare Schnittstelle zu 172.16.5.1. Die Subnetzmasken verhindern dies. Selbst wenn Sie eine statische Route hinzufügen, benötigen Sie zum Routing dennoch eine Routing-Schnittstelle im Subnetz 10.1.xx. Andernfalls leitet die SW die Pakete wahrscheinlich stattdessen an die Schnittstelle X1 weiter.

was die Überbrückung betrifft, habe ich auch keine Ahnung, warum das funktioniert. Es sieht so aus, als würde ein Fehler in der Überbrückung ausgenutzt?

Ich glaube, ich liege mit dieser Antwort völlig auf dem Holzweg. Wenn das so ist, werde ich sie löschen.

Antwort2

Laut SonicWALL-Dokumentation zur Layer 2-Überbrückung:

Layer 2 Bridge Bypass ist ein physisches X0-X1-Schnittstellen-Bypass-Relay, das derzeit auf dem SonicWALL NSA E7500 implementiert ist. Diese Funktion wird manchmal als „Fail to Wire“ bezeichnet und bedeutet, dass die LAN-WAN-Verbindung zu einer Straight-Through-Verbindung zurückkehrt, wenn auf dem SonicWALL-Gerät ein Hardware- oder Softwarefehler auftritt. Wenn das Bypass-Relay geschlossen ist, fließt der Netzwerkverkehr ungehindert zwischen den Schnittstellen X0 und X1. Wenn das Bypass-Relay geöffnet ist, wird der Netzwerkverkehr von SonicOS Enhanced abgewickelt, das auf dem SonicWALL-Gerät ausgeführt wird.

Es scheint also, dass es durch die Überbrückung der Schnittstelle und die Einbeziehung einer ausgefallenen Schnittstelle (X2 ist mit nichts verbunden) funktioniert, weil es die verbesserten Betriebssystemkontrollen von SonicOS umgeht und direkt durch die Leitung geht.

Allerdings scheint dies als aufwändiger Schritt zur Fehlerbehebung angesehen zu werden, um festzustellen, dass etwas in der Konfiguration die Verbindungen unter der regulären Konfiguration blockiert. Überprüfen Sie die Firewall-Regeln?

verwandte Informationen