As shown in the figure, a set of TCP data flows are transmitted between the Trust zone and the Untrust zone of the stateful firewall. According to the analysis of the message content in the figure…

Question

Options

• AFlow 1: TCP SYN=1, Seq=2288, ACK=0
• BFlow 2: TCP SYN=1, Seq=9955, ACK(Seq=2289)
• CFlow 3: TCP SYN=1, Seq=2289, ACK=10002
• DFlow 4: TCP SYN=1, Seq=2289, ACK=9956

• A
  5% (3)
• B
  11% (6)
• C
  4% (2)
• D
  80% (44)

Explanation

Flow 4 is blocked because, while its sequence numbers are correct (Seq=2289 equals the expected next client sequence, and ACK=9956 correctly acknowledges the server's ISN of 9955 plus one), it still carries SYN=1. After Flow 1 (initial SYN) and Flow 2 (valid SYN-ACK), the stateful firewall's session table expects the third step of the handshake to be a pure ACK with SYN=0; a packet whose flags say "new connection" but whose sequence numbers match an already half-open session is a TCP state machine violation, so the firewall drops it.

Flow 1 is not blocked because a SYN with ACK=0 is a legitimate connection initiation from the Trust zone. Flow 2 is not blocked because its ACK=2289 correctly acknowledges Flow 1's sequence number (2288+1=2289), making it a valid SYN-ACK response. Flow 3 is not blocked because its ACK value of 10002 does not match any existing session's expected acknowledgment number, so the firewall does not see it as corrupting an established state entry; it is treated as a new or unrelated connection attempt rather than a flag violation against a known session.

Memory tip: A stateful firewall trusts packets that advance the TCP state machine correctly. The danger zone is a packet that has the right sequence numbers for an existing session but the wrong flags. If you see SYN=1 paired with a non-zero ACK that perfectly matches a half-open session, the connection is being tampered with, and the firewall blocks it.

No community discussion yet for this question.