Wireshark walkthrough: observing an Azure SQL Database TDS connection on the wire

One of the most effective ways to truly understand how Azure SQL Database connectivity works is to observe the connection at the packet level. A short Wireshark capture clearly shows the interaction between TCP, TLS, TDS, and the Azure SQL gateway / redirect flow.

This section walks through what you should expect to see in a healthy Azure SQL Database connection.

1. Capture setup (high level)

Capture traffic on the client side, while reproducing the connection attempt (for example, using sqlcmd, SSMS, or your application).

Typical display filters to start with:

tcp.port == 1433

If Redirect mode is involved, you may later see additional TCP ports (for example, 11xxx–11999 or a specific dynamic port like 6188).

2. TCP three‑way handshake (transport layer)

The first packets are standard TCP:

• SYN → client initiates connection
• SYN‑ACK → Azure SQL gateway responds
• ACK → connection established

At this point:

• The destination IP is the Azure SQL Database gateway
• The destination port is 1433

This confirms basic network reachability to the gateway.

3. TDS PRELOGIN message (application layer)

Immediately after the TCP handshake, Wireshark shows the TDS Pre‑Login packet.

Key observations:

• Protocol: TDS
• Message type: PRELOGIN
• This packet contains no credentials
• It negotiates:
  • TDS version
  • Encryption capability
  • MARS (Multiple Active Result Sets)
  • Federated authentication flags (if applicable)

In Wireshark, this often appears as:

Tabular Data Stream
  Packet Type: Pre-Login

This is the first SQL‑aware packet on the wire.

4. TLS handshake (security layer)

What happens next depends on the TDS version and encryption mode:

TDS 7.x (older behavior)

• PRELOGIN is visible in clear text
• TLS handshake occurs after PRELOGIN

TDS 8.0 / Encrypt=Strict (modern Azure SQL behavior)

• TLS handshake occurs immediately after TCP
• PRELOGIN itself is encrypted
• Wireshark shows:
  • Client Hello
  • Server Hello
  • Certificate exchange

In this case:

• You will not see readable TDS fields unless TLS decryption is configured
• This is expected and by design

5. LOGIN and authentication phase

After TLS is established:

• Client sends LOGIN7 message
• Authentication occurs (SQL auth, Azure AD token, managed identity, etc.)
• All sensitive data is encrypted

In Wireshark:

• Packets are marked as TLS Application Data
• TDS payload is no longer human‑readable

A successful login is followed by:

• ENVCHANGE tokens
• Session setup responses

6. Redirect behavior (very important in Azure SQL)

If the server is using Redirect connection policy, Wireshark shows a distinctive pattern:

1. Initial connection:
   • TCP → 1433 (gateway)
2. Server responds with routing information
3. Client opens a second TCP connection:
   • New destination IP
   • New dynamic port (for example: 6188)

In Wireshark you will see:

• A new TCP handshake
• Same SQL hostname, different port
• The original 1433 connection may close or go idle

This is the most common source of confusion:

• Firewalls allow 1433 ✅
• Dynamic redirect ports ❌ blocked
• Result: login timeout or pre‑login handshake failure

7. Query execution and result sets

Once connected to the final database endpoint:

• Client sends SQL batches or RPC calls
• Server responds with result sets
• Traffic continues over the redirected connection

In Wireshark:

• All packets appear as encrypted TLS application data
• Packet sizes correlate with query result size
• Long‑running queries show sustained data flow

8. What Wireshark helps you diagnose quickly

Using this walkthrough, Wireshark can immediately answer:

• ✅ Is the client reaching the Azure SQL gateway?
• ✅ Is TLS handshake completing?
• ✅ Is Redirect mode in effect?
• ✅ Is a second TCP connection attempted?
• ✅ Which port is failing?
• ✅ Is the failure network‑level or authentication‑level?

This makes it invaluable for troubleshooting:

• Login timeouts
• Pre‑login handshake errors
• Redirect / firewall issues
• TLS / driver encryption mismatches

Key takeaway

When troubleshooting Azure SQL connectivity:

• Always expect more than one TCP connection
• 1433 is only the entry point
• Redirect mode + TDS + TLS explains 90% of “mysterious” connection failures

Once you see the flow in Wireshark, Azure SQL connectivity stops being a black box.