TCP-Handshake schlägt auf Cisco ASA fehl

7

Ich verwende einen Verkehrsgenerator zum Einrichten einer TCP-Verbindung, die eine Cisco ASA-Firewall passieren soll.

Meine Topologie sieht folgendermaßen aus:

                     +------------------+                      
                     |  CISCO ASA       |                      
+------------+       |                  |                      
|  Client    +-------+Outside           |                      
|  10.1.202.1|       |10.1.202.254      |                      
|            |       |                  |        +------------+
+------------+       |            Inside|        |Server      |
                     |      10.1.102.254+--------+10.1.102.19 |
                     |                  |        |            |
                     +------------------+        +------------+

Die Verbindung sollte von einem Host im externen Netzwerk (10.1.202.1/24) zu einem Server im internen Netzwerk (10.1.102.19/24) hergestellt werden.

I in Wireshark sehen , dass die SYNdie Firewall gibt (. 10.1 (1/2) 02.254), die SYN-ACK nicht passieren und fallen gelassen wird (siehe Captures: inside-Schnittstelle und die außerhalb-Schnittstelle ).

Von show asp dropIch werde informiert, dass Frames aus folgendem Grund gelöscht werden:

TCP failed 3 way handshake (tcp-3whs-failed)

Ich verwende kein ARP, sondern die MAC-Adresse der Firewall-Schnittstelle, die das Standard-Gateway ist.

Ich schaffe das SYN, SYN-ACKund ACKwie die folgenden:

SYN: (Client (außen) zum Server (innen))

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.202.1
Destination IP: 10.1.102.19
Default Gateway: 10.1.202.254

**TCP**
Source Port: 9000
Destination Port: 8000
Sequence number: 0
Acknowledgement number: 0
Synchronize: 1
Acknowledgement: 0

SYN-ACK: (Server (innen) an Client (außen)) (dies passiert die Firewall nicht)

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.102.19
Destination IP: 10.1.202.1
Default Gateway: 10.1.102.254

**TCP**
Source Port: 8000
Destination Port: 9000
Sequence number: 0
Acknowledgement number: 1
Synchronize: 1
Acknowledgement: 1

ACK: (Client (außen) zum Server (innen))

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.202.1
Destination IP: 10.1.102.19
Default Gateway: 10.1.202.254

**TCP**
Source Port: 9000
Destination Port: 8000
Sequence number: 1
Acknowledgement number: 1
Synchronize: 0
Acknowledgement: 1

Außerdem sieht meine Topologie wie folgt aus:

Der Traffic Generator Client (außerhalb des Netzwerks) ist mit einem Switch verbunden, auf dem ein VLAN hinzugefügt wird. Der Switch ist mit der externen Firewall-Schnittstelle verbunden. Im internen Netzwerk ist der Verkehrsgenerator mit dem Switch verbunden, auf dem VLAN-Tags hinzugefügt werden, und der Switch ist mit der internen Schnittstelle der Firewall verbunden.

Kann mir jemand sagen, warum die ASA die fallen lässt SYN-ACK?

Danke im Voraus!

BEARBEITEN:

Wie von Ron Trunk vorgeschlagen, habe ich die Randomisierung von Sequenznummern deaktiviert, indem ich Folgendes verwendet habe:

Zufallssequenznummer deaktivieren
Erfassung der Innenschnittstelle und der Außenschnittstelle hinzugefügt .
Die Erfassungsdateien wurden aktualisiert

cisco-asa firewall tcp

— muehsi
quelle

Was zeigt der Packet-Tracer-Befehl?

— Smithers

Was meinst du mit Packet-Tracer-Befehl? Ich arbeite an einem ASA-Servicemodul.

— Muehsi

Ah, das habe ich nie benutzt. Die ASA-Appliance verfügt über einen Befehl "packet-tracer", der ein Paket simuliert, das die Regeln durchläuft. Ich glaube, es ist hauptsächlich für den Verkehr in Schicht 3 und höher gedacht, aber vielleicht liegt das nur daran, dass ich es in keiner unteren Schicht gebraucht habe. Fragezeichen Sie Ihren Weg durch, aber die Verwendung ist im Wesentlichen "Paket-Tracer-Eingabe INCOMING-IFNAME tcp SOURCE.IP.ADDRESS.HERE SRC-PORT DST.IP.ADDRESS.HERE DST-PORT"

— Smithers

Ja, dies ist auch in ASDM verfügbar. Ich habe das überprüft und das Paket sollte weitergeleitet werden. Ich kann jedoch keine Pakete für den Verbindungsaufbau auswählen. Ich kann nur die IP und den Port überprüfen. Das Problem ist, dass der TCP-Handshake fehlschlägt.

— Muehsi

Nun, das EMPFIEHLT deine Schicht 3 ist gut, was schön ist. Sie möchten den gesamten Datenverkehr an den Außen- und Innenschnittstellen des ASA erfassen, einschließlich ARP. Sie können zuerst bestätigen, ob der Datenverkehr tatsächlich die Eingangsschnittstelle erreicht, und dann bestätigen, dass er den Ausgang nicht verlässt. Wenn er Ihren Ausgang verlässt oder Ihren Eingang nicht erreicht, liegt wahrscheinlich ein Switch-Problem vor.

— Smithers

3

Standardmäßig randomisiert der ASA die Sequenznummern im Handshake (um Sitzungsentführungen zu verhindern). Ihre Sequenznummern stimmen also nicht überein. Sie können diese Funktion deaktivieren.

random-sequence-number disable

— Ron Trunk
quelle

Ich habe diesen Befehl hinzugefügt und wusste nicht, dass er existiert. Leider hat es mein Problem nicht gelöst. Wireshark sagt, mein SYN ACK hat ein 'ACK = 3200214167', was seltsam ist, da es auf der Schnittstelle erfasst wurde, bevor es die Firewall passiert. Bedeutet Win = 4096 im Syn-Paket etwas für den Verbindungsaufbau?

— Muehsi

Der Win bedeutet im Wesentlichen nur, dass 4 KB Speicherplatz im Netzwerkpuffer des Geräts verfügbar sind, das das Paket gesendet hat.

— Smithers

1

Ich stelle fest, dass der Client, bevor er eine Synchronisierung sendet, eine erste Bestätigung sendet. Ich denke, Sie müssen das zuerst herausfinden.

— Ron Trunk

Es hat nicht funktioniert, als ich dieser Erklärung gefolgt bin . Ich musste auch die Servicerichtlinie auf die Schnittstellen anwenden ( service-policy <name> interface <interface>). Danke für deinen Hinweis.

— Muehsi

3

In Ihrer internen Erfassung werden zwei Pakete vom Server (10.1.102.19) zum Client (10.1.202.1) gesendet, die jedoch von unterschiedlichen MAC-Adressen stammen.

#23 Ethernet II, Src: 00:10:94:00:00:01 (00:10:94:00:00:01), Dst: 00:19:55:07:12:ca (00:19:55:07:12:ca)
    Internet Protocol Version 4, Src: 10.1.102.19 (10.1.102.19), Dst: 10.1.202.1 (10.1.202.1)
    Transmission Control Protocol, Src Port: 8000 (8000), Dst Port: 9000 (9000), Seq: 0, Ack: 19112639, Len: 0

#25 Ethernet II, Src: 00:10:94:00:00:02 (00:10:94:00:00:02), Dst: 00:19:55:07:12:ca (00:19:55:07:12:ca)
    Internet Protocol Version 4, Src: 10.1.102.19 (10.1.102.19), Dst: 10.1.202.1 (10.1.202.1)
    Transmission Control Protocol, Src Port: 8000 (8000), Dst Port: 9000 (9000), Seq: 0, Ack: 1, Len: 0

Das scheint seltsam, ist aber wahrscheinlich nicht Ihr Problem. Soweit ich es interpretieren kann, ist Ihr Problem wie folgt:

Es scheint, als würde der Server selbst natürlich auf Ihr gestaltetes SYN-Paket mit dem RST-ACK in Paket Nr. 23 (der inneren Kappe, siehe oben) reagieren - wahrscheinlich, weil Port 8000 geschlossen ist. Dadurch wird die Firewall aufgefordert, die RST an die Außenseite weiterzuleiten (Paket Nr. 23 in der Außenkappe) und diese Verbindung aus ihrer Statustabelle zu entfernen.

Ihr gestaltetes SYN-ACK-Paket wird jedoch in # 25 (der inneren Kappe) ausgelöst und fordert eine RST von der Firewall (# 26) auf, da in der Verbindungstabelle kein Eintrag für diesen Fluss vorhanden ist.

— Eddie
quelle

Danke für deine Kommentare. Ich habe die Ethernet-Adressen überprüft und behoben. Wie Sie vermutet haben, hat dies nichts geändert. Ich habe auch das Problem mit dem RST-ACK untersucht und behoben. Auf dem Server ist eine vorübergehende Fehlkonfiguration aufgetreten. Trotzdem tritt mein Ursprungsproblem immer noch auf: Das SYN-ACKpassiert die Firewall nicht. Ich habe die Erfassungsdateien der internen / externen Schnittstellen auf den aktuellen Status aktualisiert.

— Muehsi

Wie haben Sie das RST-ACK "repariert"? Das ist das normale / erwartete Verhalten des Servers. Ich habe mir die neuen Aufnahmen nicht angesehen, ich werde es versuchen, wenn ich mehr Zeit finde.

— Eddie

1

@ Muehsi, sieht für mich so aus, als hättest du immer noch ein Problem. AFAIK, Cloudshark (wie die Wireshark-Standardeinstellung) passt die angezeigten Sequenznummern zur besseren Lesbarkeit relativ zu 0 an. Ihr SYN-ACK vom Server zum Client zeigt jedoch an, dass es sich um ACKing 2644561697 und nicht um 1 handelt. Da das ACK nicht mit den Erwartungen der Firewall übereinstimmt, sollte es gelöscht werden.

— YLearn

In Bezug auf "normales Verhalten" usw. Wir verwenden ein Spirent TestCenter als Verkehrsgenerator (sowohl für die Client- als auch für die Serverseite). Die Reaktion, dh in Bezug auf das Verhalten, wenn keine Anwendung einen Port abhört, kann sich daher von einem normalen Betriebssystem unterscheiden. Aber deshalb wollen wir diesen handgefertigten 3-Wege-Handshake (nur als Hintergrundinformation).

— StephenKing

1

Können Sie auf Ihrem ASA bitte Folgendes ausführen:

// Aktiviere alle Erfassungen für alle Asp-Drops

ASA# capture asp-drop type asp-drop all

// Erfassungspuffer anzeigen, der identifizieren soll, warum der Handshake fehlschlägt

ASA# sh capture asp-drop

Sollte etwas Ähnliches wie das Folgende zeigen, aber für Ihre spezielle Art von Tropfen:

   2 packets captured
   1: 15:15:00.682154 197.2.1.29.2616 > 87.200.42.101.443: S 1239395083:1239395083(0) win 65535 <mss 1260,nop,nop,sackOK> Drop-reason: (acl-drop) Flow is denied by configured rule
   4: 15:15:00.750830 10.70.0.162.3812 > 168.252.3.41.15: S 3523756300:3523756300(0) win 65535 <mss 1360,nop,nop,sackOK> Drop-reason: (rpf-violated) Reverse-path verify failed

Beachten Sie, dass eine Grundregel für den ASA lautet: Um Datenverkehr von einer Schnittstelle mit niedrigerer Sicherheit (außen) zu einer Schnittstelle mit höherer Sicherheit (innen) zu initiieren, muss ein expliziter ACL-Eintrag vorhanden sein, damit dieser Datenverkehr durchgelassen werden kann. Ohne Ihre ASA-Konfiguration zu sehen, ist es schwer zu sagen, was die Probleme verursachen könnte.

— APA
quelle

-1

Sie beschreiben den normalen / standardmäßigen Betrieb des ASA. Von OUTSIDE nach INSIDE sind nur hergestellte TCP-Verbindungen zulässig. Sie können dies deaktivieren, indem Sie den TCP-Status-Bypass konfigurieren .

Step 1 Choose Configuration > Firewall > Service Policy.

Step 2 Click Add > Add Service Policy Rule.

Alternatively, if you already have a rule for the hosts, edit the rule.

Step 3 Select whether to apply the rule to a specific interface or globally to all interfaces, and click Next.

Step 4 For Traffic Classification, select Source and Destination IP Addresses (uses ACL) and click Next.

Step 5 For the ACL rule, enter the IP addresses of the hosts on each end of the route in Source and Destination, and specify the protocol as TCP. Click Next when finished.

For example, if you want to bypass TCP state checking between 10.1.1.1 and 10.2.2.2, enter:

Source = 10.1.1.1
Destination = 10.2.2.2
Destination Protocol = tcp
Step 6 On the Rule Actions page, click the Connection Settings tab and select TCP State Bypass.

Step 7 Click Finish to save the rule, and Apply to update the device.

— Ronnie Royston
quelle

(Kollege von @muehsi spricht) Vielen Dank für Ihre Antwort. Ich denke jedoch, dass dies nicht der Grund sein kann, da anderer Verkehr (Stateful TCP), der nicht von handgefertigten TCP-Paketen vom Verkehrsgenerator erzeugt wird, den ASA von außen nach innen weiterleiten kann. Es liegt irgendwie in der Natur der Pakete, die der Trafficgen sendet.

— StephenKing