Original Trifectapp practice · 5 cases · About 15 minutes
Ports and protocols troubleshooting practice
Read the evidence, select the narrowest rule that restores the approved service, then check your reasoning. Each case connects a service to its transport, destination port and permitted endpoints.
Scenario assumptions: The firewall tracks connection state and permits matching return traffic. Other new flows are denied unless allowed. Each requested flow is initiated by the client toward the named server; keep existing required rules. Routing, DNS resolution where needed, server listeners, credentials and certificates have already been checked.
These are fictional learning cases with synthetic addresses and records. The activity sends no packets and changes no firewall. It is not an official CompTIA question set. The numbers after the client addresses are example source ports, not server destination ports.
Case 1 · DNS works for some names
192.0.2.10198.51.100.53- The approved resolver already accepts this client on UDP/53.
- A UDP response has its truncation flag set. The client then retries the query over TCP.
- Goal: restore ordinary DNS resolution through this approved resolver.
SYNTHETIC FIREWALL RECORDDENY TCP 192.0.2.10:53012 → 198.51.100.53:53
Worked solution and protocol reference
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
192.0.2.20198.51.100.20- Client → approved web endpoint on TCP/443 is allowed. HTTPS over HTTP/2 works.
- The server advertises HTTP/3 on UDP/443, and this approved test requires HTTP/3.
- Goal: enable that HTTP/3 test while preserving the existing TCP-based HTTPS service.
SYNTHETIC FIREWALL RECORDDENY UDP 192.0.2.20:54100 → 198.51.100.20:443
Worked solution and protocol reference
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
192.0.2.30198.51.100.30- The approved file-transfer service is SFTP, and its SSH listener is configured on TCP/22.
- The workstation cannot establish the SSH transport used by its SFTP session.
- Goal: connect this workstation to the documented SFTP service.
SYNTHETIC FIREWALL RECORDDENY TCP 192.0.2.30:55024 → 198.51.100.30:22
Worked solution and protocol reference
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
192.0.2.40198.51.100.40- Workstation → explicit FTPS server on TCP/21 is allowed. The control connection successfully upgrades to TLS; private data protection is required.
- The server uses passive mode with a fixed TCP data-port range of 50000–50009. No FTP-aware helper dynamically opens data connections.
- The server selects port 50004 for this directory listing.
- Goal: support subsequent approved passive transfers across the configured range.
SYNTHETIC FIREWALL RECORDDENY TCP 192.0.2.40:56110 → 198.51.100.40:50004
Worked solution and protocol reference
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
192.0.2.50198.51.100.50- The approved account configuration requires implicit TLS on TCP/465 to this submission server.
- A TCP/587 firewall rule exists, but this client does not use that service.
- Goal: restore the configured mail-submission service without weakening its TLS settings.
SYNTHETIC FIREWALL RECORDDENY TCP 192.0.2.50:57220 → 198.51.100.50:465
Worked solution and protocol reference
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.
Your practice pack
Open scenario-logs.csv, complete rule-worksheet.csv, then compare with worked-solutions.html. Read README.txt for instructions.
Activity v1.0 · November 7, 2026. The linked protocol documentation supports the technical behavior; the addresses, permitted scope and FTPS port range are invented teaching inputs. Choices are kept only in this page session and are cleared when you reload. No answers are submitted by this activity.