Risoluzione dei problemi di asimmetria cluster FTD che causano errori di connessione TCP

Problema

Possono presentarsi uno o più dei seguenti sintomi:

• Errori di connettività intermittenti per le applicazioni che attraversano un cluster FTD

• Handshake a tre vie TCP non riuscito durante i tentativi di connessione.

• Il client invia un pacchetto SYN, ma non riceve la risposta SYN-ACK prevista.

• Il client invia un pacchetto RST dopo il SYN iniziale.

Ambiente

• Visualizzato per la prima volta in Secure Firewall Threat Defense 7.4 — il problema può riguardare anche altre versioni

• Configurazione cluster

• Bilanciamento del carico nel percorso di rete. Facoltativo

Topologia

inline_image_0.png

Risoluzione

Per risolvere la causa del problema, è necessario eseguire acquisizioni simultanee nei seguenti punti:

• Interfaccia interna FW1 (con nascondiglio a reiezione)

• Interfaccia esterna FW1 (con nascondiglio di reiezione)

• FW1 Cluster Interface (CCL)

• Interfaccia interna FW2 (con nascondiglio a reiezione)

• Interfaccia esterna FW2 (con nascondiglio a reiezione)

• FW2 Cluster Interface (CCL)

• Client (o il più vicino possibile al client)

• Server (o il più vicino possibile al server)

Per i dettagli su come configurare le acquisizioni, controllare: Come abilitare le acquisizioni del cluster.

 Le acquisizioni acquisite su entrambi i firewall insieme al client e al server rivelano questa topologia:

inline_image_0.png

1. Il client invia TCP SYN. Il pacchetto arriva al load balancer (LB) e viene inviato all'FW1.

2. FW1 riceve il pacchetto TCP SYN e diventa il proprietario del flusso.

3. FW1 informa il director (FW2) del proprietario del flusso inviando un messaggio speciale (clu add) del cluster.

4. FW1 inoltra il TCP SYN al server di destinazione.

5. Il server risponde con SYN/ACK. In questo caso, il flusso è asimmetrico in quanto SYN/ACK viene inviato verso FW2 a causa dell'algoritmo di bilanciamento del carico del canale della porta.

6. SYN/ACK arriva su FW2 prima del messaggio clu add. Si tratta di una race condition ed è puramente ambientale (come la latenza in CCL). Poiché FW2 non sa chi sia il proprietario del flusso, SYN/ACK viene scartato.

7. Viene inviato TCP RST al server.

8. Il messaggio clu add arriva su FW2.

9. Il client ritrasmette il pacchetto TCP SYN. Il pacchetto TCP SYN viene inoltrato al server di destinazione.

10. Sul bilanciamento carico si verifica il timeout della connessione TCP per il flusso specifico.

11. Il server risponde con SYN/ACK (ritrasmissione TCP). Il pacchetto SYN/ACK arriva su FW2. Questa volta, FW2 conosce il proprietario del flusso dal momento che ha ricevuto il messaggio clu add e il SYN/ACK viene inoltrato al proprietario del flusso tramite CCL. Il SYN/ACK viene inviato al client.

12. Il bilanciamento carico non è a conoscenza di questo flusso e scarta il SYN/ACK. Pertanto, il SYN/ACK non arriva mai sul client.

13. Il bilanciamento del carico è costituito da uno o più pacchetti TCP RST. 

Acquisizione del firewall con analisi della traccia

In questi output, le clip sono state raccolte dal firewall su CCL e interfacce rivolte al server:

· Su CCL, l'acquisizione avviene sulla porta UDP 4193.

· Sulle interfacce dati, l'acquisizione associa il traffico TCP tra gli endpoint utilizzando l'opzione reject-hide. Il motivo è che vogliamo vedere dove arrivano effettivamente i pacchetti.

· Indirizzo IP 192.0.2.65 = client

· Indirizzo IP 192.0.2.6 = server

Passaggio 1: utilizzare questo comando sul dispositivo firewall che ottiene il SYN/ACK per verificare quando è arrivato il messaggio clu add. Nell'output CLI il messaggio viene visualizzato come Add flow.

firepower# show capture CCL decode 
3 packets captured
   1: 08:14:20.630521       127.2.1.1.51475 > 127.2.2.1.4193:  udp 820
        Cluster ASP message: sender: 1, receiver: 0
        Add flow: owner 1, director 0, backup 0,
                  ifc_in INSIDE(7020a7), ifc_out INSIDE(7020a7)
                  TCP src 192.0.2.65/37468, dest 192.0.2.6/80

  

Passaggio 2: Tracciare il pacchetto SYN/ACK e concentrarsi sul timestamp e sul risultato della traccia:

firepower# show capture CAPI packet-number 1 trace
13 packets captured
   1: 08:14:20.628690       802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2524735158:2524735158(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611712900 970937593,nop,wscale 7> 
Phase: 1
Type: CAPTURE
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Additional Information:
MAC Access list
  
Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Elapsed time: 13664 ns
Config:
Additional Information:
Found next-hop 192.168.200.140 using egress ifc  INSIDE(vrfid:0)

Phase: 4
Type: CLUSTER-EVENT
Subtype: 
Result: ALLOW
Elapsed time: 16104 ns
Config:
Additional Information:
Input interface: 'INSIDE'
Flow type: NO FLOW
I (0) am becoming owner

Phase: 5
Type: OBJECT_GROUP_SEARCH
Subtype: 
Result: ALLOW
Elapsed time: 19520 ns
Config:
Additional Information:
 Source object-group match count:          0
 Source NSG match count:                   0
 Destination NSG match count:              0
 Classify table lookup count:              1
 Total lookup count:                       1
 Duplicate key pair count:                 0
 Classify table match count:               4

Phase: 6
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Elapsed time: 366 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268436480 
access-list CSM_FW_ACL_ remark rule-id 268436480: ACCESS POLICY: mzafeiro_empty - Default
access-list CSM_FW_ACL_ remark rule-id 268436480: L4 RULE: DEFAULT ACTION RULE
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
  
Phase: 7
Type: CONN-SETTINGS
Subtype:      
Result: ALLOW
Elapsed time: 366 ns
Config:
class-map tcp
 match access-list tcp
policy-map global_policy
 class tcp
  set connection conn-max 0 embryonic-conn-max 0 random-sequence-number disable syn-cookie-mss 1380
service-policy global_policy global
Additional Information:
  
Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 366 ns
Config:
Additional Information:
  
Phase: 9
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Elapsed time: 366 ns
Config:
Additional Information:
  
Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 54168 ns
Drop-reason: (tcp-not-syn) First TCP packet not SYN, Drop-location: frame snp_sp:7459 flow (NA)/NA

Punti chiave

· Il messaggio Add flow è arrivato alle 08:14:20.630521 mentre il SYN/ACK è arrivato circa 2 msec prima alle 08:14:20.628690. Questa è la condizione di gara.

· Il pacchetto SYN/ACK viene scartato dal firewall con il motivo ASP tcp-not-syn. Si noti che nella fase 4 il firewall ha tentato di identificare se esiste un proprietario del flusso noto ma non ne ha trovato alcuno. Pertanto, ha tentato di diventare un proprietario del flusso.

Questo output mostra una traccia del SYN/ACK quando il firewall è a conoscenza del flusso:

firepower# show capture CAPI packet-number 3 trace

13 packets captured

   3: 08:14:21.629560       802.1Q vlan#200 P0 192.0.2.6.80 > 192.0.2.65.37468: S 2540375172:2540375172(0) ack 2881263901 win 65160 <mss 1460,sackOK,timestamp 611713901 970938595,nop,wscale 7> 
Phase: 1
Type: CAPTURE
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Elapsed time: 1708 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: CLUSTER-EVENT
Subtype:      
Result: ALLOW
Elapsed time: 3416 ns
Config:
Additional Information:
Input interface: 'INSIDE'
Flow type: STUB
I (0) have flow, valid owner (1).

Phase: 4
Type: CAPTURE
Subtype: 
Result: ALLOW
Elapsed time: 7808 ns
Config:
Additional Information:
MAC Access list

Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
Action: allow
Time Taken: 14640 ns
              
1 packet shown
firepower#

Il punto chiave si trova nella Fase 3. Il firewall sa che l'unità cluster 1 è il proprietario del flusso. È possibile utilizzare il comando show cluster info per verificare quale dispositivo è l'unità 0 e quale è 1.

Domande frequenti

D. Perché vediamo problemi di connettività TCP intermittenti?

R. Poiché si tratta di una race condition, si verifica in modo casuale. La race condition può essere visualizzata di conseguenza:

inline_image_0.png

D. Quali sono le possibili soluzioni per evitare la condizione di gara?

R. 

Soluzione 1: abilitare la randomizzazione dei numeri di sequenza TCP per sfruttare il meccanismo dei cookie SYN di TCP. In tal caso, la comunicazione è strutturata in modo appropriato:

inline_image_1.png

Soluzione 2: eliminare l'asimmetria nella rete. Innanzitutto, è necessario identificare la causa dell'asimmetria. Può essere necessario regolare l'algoritmo di bilanciamento del carico del canale della porta, ricablare i cavi del canale della porta in un ordine diverso, tra le altre cose.

Causa

La causa principale è una race condition causata dall'asimmetria del cluster all'interno della distribuzione del cluster FTD. I pacchetti SYN-ACK provenienti dal server vengono elaborati da un nodo cluster FTD diverso da quello che ha gestito il pacchetto SYN iniziale, impedendo la corretta definizione della sessione TCP.

Contenuto correlato

• Supporto tecnico Cisco e download

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
3.0	23-Apr-2026	Formattazione e punteggiatura.
2.0	15-Apr-2026	Immagini aggiunte
1.0	09-Apr-2026	Versione iniziale