Lesson 018 · AWS Learning Path

AWS 018: TCP, UDP, ports, stateful firewalls, and packet-path fundamentals

Anil Jalela · Published Jul 13, 2025 · 5 min read

The problem

A connection fails and the firewall is blamed. The service is actually listening on the wrong address. Another team permits a port but forgets the return path. Packet troubleshooting requires the complete path.

Learning outcomes

You will be able to distinguish TCP and UDP, explain address and port tuples, identify listening sockets, compare stateful and stateless filtering, and trace a packet through routing, filtering, process, and response.

Transport concepts

TCP provides a connection-oriented reliable byte stream with sequence, acknowledgement, retransmission, and flow behavior.

UDP sends independent datagrams without TCP's connection establishment and delivery guarantees. Applications can implement their own reliability where needed.

A port identifies an application endpoint within a host. A TCP flow is commonly identified by:

source IP, source port, destination IP, destination port, protocol

Opening TCP port 443 does not open UDP 443. Protocol matters.

TCP connection behavior

A simplified TCP opening exchanges synchronization and acknowledgement information before application data:

client -> SYN -> server
client <- SYN-ACK <- server
client -> ACK -> server

Real diagnosis should use connection-state evidence rather than assuming that every timeout occurred during this opening. TCP also manages sequence numbers, acknowledgements, retransmission, flow control, and congestion behavior.

The client commonly uses a temporary source port while the server listens on a known destination port. Return packets therefore reverse the address and port direction:

request:  client:temporary-port -> server:8080
response: server:8080 -> client:temporary-port

This is why a stateless return-path rule cannot simply allow destination port 8080 in both directions.

UDP behavior

UDP does not establish a TCP-style connection. A successful local send does not prove the destination application received or processed the datagram. Troubleshooting may require application acknowledgements, packet capture, counters, or protocol-specific health evidence.

DNS commonly uses UDP for many queries and can use TCP in defined situations. Modern protocols can also build reliability and security over UDP. Choose the transport from application protocol requirements, not from the claim that one is always faster.

Local TCP lab

Check tools:

command -v python3
command -v curl
command -v ss

If one is absent, record it rather than installing it.

Create:

mkdir -p "$HOME/nitwings-aws/evidence/aws-018/site"
printf '%s\n' 'AWS 018 local service is healthy' \
  > "$HOME/nitwings-aws/evidence/aws-018/site/index.html"

Start a loopback-only server:

python3 -m http.server 8080 \
  --bind 127.0.0.1 \
  --directory "$HOME/nitwings-aws/evidence/aws-018/site" \
  > "$HOME/nitwings-aws/evidence/aws-018/server.log" 2>&1 &
SERVER_PID=$!
printf 'server_pid=%s\n' "$SERVER_PID"

Binding to 127.0.0.1 limits the listener to local loopback.

Inspect:

ss -ltnp | sed -n '1,20p'
curl --fail --show-error http://127.0.0.1:8080/

Expected body:

AWS 018 local service is healthy

Stop and verify:

kill -TERM "$SERVER_PID"
wait "$SERVER_PID"
curl --connect-timeout 2 http://127.0.0.1:8080/
printf 'expected_failure_exit=%s\n' "$?"

The final request should fail because nothing listens. That failure proves the process matters even when the IP and port are correct.

Packet path

For a remote service, ask in order:

1. Did DNS return the intended address?
2. Does the source choose the intended route?
3. Does a local firewall allow egress?
4. Do network routes and gateways carry the packet?
5. Do stateless filters allow request and response?
6. Does a stateful control allow the initiating flow?
7. Is the destination interface/address correct?
8. Is a process listening on the destination protocol and port?
9. Does the application accept the request?
10. Can the response return?

client process
 -> source socket
 -> source route/filter
 -> network path
 -> destination filter
 -> listening process
 -> application
 -> return path

Stateful and stateless filtering

A stateful firewall tracks connection or flow state. If it permits an initiating flow, return traffic for that tracked flow can be allowed without a separate mirrored rule, subject to the product's behavior.

A stateless filter evaluates packets independently. Request and return directions need rules that match their addresses, protocols, and ports.

AWS security groups are stateful. VPC network ACLs are stateless. The detailed AWS behavior appears in the VPC lessons.

Stateful does not mean "allow everything after one packet." State tracking has protocols, timeouts, and product-specific rules.

Ports and exposure

A service listening on:

127.0.0.1:8080

is reachable only through the local loopback path.

A service listening on:

0.0.0.0:8080

accepts on all local IPv4 interfaces, but actual remote reachability still depends on routes, filters, address translation, and upstream controls.

Do not bind broadly as a generic fix.

Evidence

Create packet-path.md with:

• local source and destination;
• TCP protocol;
• port 8080;
• listener evidence;
• successful application evidence;
• stopped-process failure;
• complete ten-step remote checklist;
• stateful versus stateless explanation.

Common failure signatures

These are clues, not absolute proof.

Knowledge check

1. Does TCP guarantee application success?
2. Is a port meaningful without a protocol?
3. Why did the final local request fail?
4. What does a stateful control remember?
5. Why can a stateless return path need a separate rule?

Expected answers: no; no; listener stopped; flow state; packets are independently evaluated.

Completion gate

Pass when the local request succeeds before termination, fails afterward, packet-path.md covers all layers, and you can explain why broad firewall changes are not diagnosis.

No AWS resource was created.

Official sources

• RFC 9293, Transmission Control Protocol
• RFC 768, User Datagram Protocol
• Linux networking documentation
• Amazon VPC security groups
• Amazon VPC network ACLs