Ports and protocols troubleshooting practice
Five original, fictional teaching cases. These worked answers use the assumptions and approved endpoints in the activity. They are not instructions to change a production firewall.
Case 1 · DNS works for some names
Evidence: DENY TCP 192.0.2.10:53012 → 198.51.100.53:53
Best choice: Allow client → resolver on TCP/53. Keep the existing UDP/53 rule and permit TCP/53 to the same resolver. The evidence shows a TCP retry after a truncated UDP response.
Verify the result: Repeat the affected query through the approved resolver. Confirm a successful TCP/53 exchange and an allow entry for the expected endpoints; retain UDP/53 support.
Why the other choices miss the requirement
- Allow client → resolver on UDP/5353: Port 5353 is associated with multicast DNS; the denied retry is TCP/53.
- Allow resolver → client on TCP/53 as a new connection: This reverses the initiating direction. Matching return traffic is already permitted by the stated firewall model.
- Allow client → any destination on TCP/53: This would allow the resolver connection, but it also permits destinations outside the approved scope.
Remember: Traditional DNS needs both UDP and TCP support. TCP is not limited to zone transfers.
Protocol reference: RFC 9210 §3. The endpoint scope and configuration are fictional scenario facts.
Case 2 · HTTPS loads, but HTTP/3 does not
Evidence: DENY UDP 192.0.2.20:54100 → 198.51.100.20:443
Best choice: Allow client → endpoint on UDP/443. HTTP/3 uses QUIC over UDP. Permit the stated UDP/443 endpoint and preserve TCP/443 for the already approved TCP-based HTTPS service.
Verify the result: Repeat the approved test and confirm that HTTP/3 was negotiated. A page loading through HTTP/2 fallback does not verify the UDP path.
Why the other choices miss the requirement
- Allow client → endpoint on TCP/443 again: The existing TCP rule supports TCP-based HTTPS, not the denied UDP flow.
- Allow client → endpoint on UDP/80: The advertised HTTP/3 endpoint in this case is UDP/443.
- Allow client → any destination on UDP/443: This exceeds the single-endpoint test scope.
Remember: “HTTPS” does not always mean TCP. HTTP/3 can use another advertised UDP port; 443 is the configured port in this case.
Protocol reference: RFC 9114 §3.1. The endpoint scope and configuration are fictional scenario facts.
Case 3 · SFTP is mistaken for FTPS
Evidence: DENY TCP 192.0.2.30:55024 → 198.51.100.30:22
Best choice: Allow workstation → server on TCP/22. This SFTP service operates over SSH, using the configured TCP/22 listener.
Verify the result: Confirm the SSH connection and a successful authorized SFTP operation to the specified server. Check the server identity according to the approved SSH host-key policy.
Why the other choices miss the requirement
- Allow workstation → server on TCP/21: TCP/21 is normally the FTP control port, including explicit FTPS negotiation. It is not this SSH service.
- Allow workstation → server on TCP/990: Implicit FTPS is a different protocol arrangement from SFTP over SSH.
- Allow workstation → server on UDP/22: The case specifies an SSH listener using TCP.
Remember: SFTP and FTPS are not interchangeable. Confirm the actual service and its configuration before changing a firewall.
Protocol reference: OpenSSH sftp manual · RFC 4253 §4.1. The endpoint scope and configuration are fictional scenario facts.
Case 4 · FTPS logs in but cannot list files
Evidence: DENY TCP 192.0.2.40:56110 → 198.51.100.40:50004
Best choice: Allow workstation → server on TCP/50000–50009. Keep TCP/21 for control and permit the configured passive data range to this server only. Keep TLS and private data-channel protection enabled.
Verify the result: Confirm successful directory listings and approved transfers using the configured passive range, with private data-channel protection (PROT P) and certificate validation retained.
Why the other choices miss the requirement
- Allow workstation → server on TCP/20: That does not permit the passive data listener selected by this server.
- Allow server → workstation on TCP/50000–50009: In this passive-mode case, the workstation initiates the data connection to the server.
- Allow workstation → any destination on TCP/1024–65535: This opens far more destinations and ports than the configured service requires.
Remember: An allowed FTP control connection does not automatically permit a separate data connection. The passive range here is server configuration, not a universal standard range.
Protocol reference: RFC 4217 §7. The endpoint scope and configuration are fictional scenario facts.
Case 5 · The mail client uses implicit TLS
Evidence: DENY TCP 192.0.2.50:57220 → 198.51.100.50:465
Best choice: Allow workstation → server on TCP/465. Permit the configured implicit-TLS service to the approved server and retain certificate validation.
Verify the result: Verify successful TLS establishment, certificate validation and an authorized submission to the configured server. A TCP connection alone does not prove TLS was validated.
Why the other choices miss the requirement
- Allow workstation → server on UDP/465: The configured submission service uses TCP.
- Allow workstation → server on TCP/25: This does not match the approved client-submission configuration.
- Allow workstation → any destination on TCP/465: The destination scope is broader than the approved submission server.
Remember: Implicit TLS on 465 and STARTTLS on 587 are different connection setups. Properly enforced STARTTLS is not inherently insecure.
Protocol reference: RFC 8314 §3.3. The endpoint scope and configuration are fictional scenario facts.
Activity v1.0 · November 7, 2026 · Instructions