End-to-End Packet Flow Analysis Across a Segmented Homelab

Baseline Internal Service Path

This scenario shows the normal internal path a client follows to reach a service through the reverse proxy. It establishes the expected behavior of DNS resolution, routing, access control, and proxy forwarding.

Define the expected traffic path from a client device to a backend service.

A client in VLAN 30 resolves a service hostname through AdGuard Home and receives the IP address of Nginx Proxy Manager in VLAN 10. Because the destination is not local, the client sends traffic to its default gateway. The switch forwards the frame with the correct VLAN tag, and the router performs a Layer 3 routing decision. After ACL evaluation allows the traffic, the request is forwarded to Nginx Proxy Manager, which then proxies it to the backend service in VLAN 20.

This baseline defines how the network is expected to behave. All troubleshooting, deny, and failure scenarios can be compared against this path.

Step-by-Step Packet Flow

This breakdown follows the same scenario step-by-step from DNS resolution to the final response.

1. DNS Resolution: The client queries AdGuard Home and receives the IP address of Nginx Proxy Manager.
2. Destination Check: The client determines that the destination is not on the local subnet.
3. ARP for Default Gateway: The client resolves the MAC address of the default gateway using Address Resolution Protocol (ARP).
4. Frame Creation: The client builds a frame using the gateway MAC as the Layer 2 destination and sends it to the switch.
5. Switch Forwarding: The switch tags the traffic for VLAN 30 and forwards it across the trunk toward the router.
6. Routing Decision: The router removes the Layer 2 frame, evaluates the destination IP address, and determines the correct routed path.
7. ACL Evaluation: The router checks policy and allows HTTP/HTTPS traffic from VLAN 30 to VLAN 10.
8. Forward to Proxy: The router rebuilds the Layer 2 frame for the destination VLAN and sends the traffic to Nginx Proxy Manager.
9. Proxy Forwarding: Nginx Proxy Manager forwards the request to the backend service in VLAN 20.
10. Response Path: The backend service responds, and the traffic returns through the path in reverse.

ACL Deny Scenario

This scenario shows what changes when routing still works, but policy blocks the request before it reaches the reverse proxy. It highlights the router as the enforcement point between segmented networks.

Show how a request can fail even when DNS resolution and routing logic are correct, because Access Control List (ACL) policy denies the traffic.

The client still resolves the service hostname and sends traffic toward its default gateway because the destination is remote. The switch forwards the frame normally, and the router evaluates the packet at Layer 3. Unlike the baseline scenario, the router finds a deny rule that matches the traffic. The packet is dropped at the policy layer, so it never reaches Nginx Proxy Manager or the backend service.

This scenario shows that successful DNS resolution does not guarantee successful connectivity. A request can fail after name resolution if router policy blocks traffic between VLANs. This is important during troubleshooting because an ACL deny can look like an application or proxy problem if the traffic path is not understood clearly.

Step-by-Step ACL Deny Flow

This breakdown follows the denied path from initial DNS resolution to the policy drop at the router.

1. DNS Resolution: The client queries AdGuard Home and successfully receives the IP address of Nginx Proxy Manager.
2. Destination Check: The client determines that the destination is on a remote subnet and must be reached through the default gateway.
3. ARP for Default Gateway: The client resolves the MAC address of the default gateway and prepares the frame.
4. Frame Sent to Switch: The client sends the frame to the switch, which associates it with the correct VLAN and forwards it toward the router.
5. Routing Decision: The router removes the Layer 2 framing, evaluates the destination IP, and selects the routed path.
6. ACL Evaluation: The router checks the traffic against its Access Control List (ACL) rules and finds a matching deny entry.
7. Traffic Dropped: The packet is discarded at the router and never reaches Nginx Proxy Manager.
8. Connection Fails: From the client perspective, the service does not load even though DNS resolution succeeded.

DNS Failure Scenario

This scenario shows what happens when the request fails before the application connection even begins. It highlights DNS as a dependency that must succeed before routing, policy evaluation, and reverse proxy forwarding can matter.

Show how service access can fail before any meaningful packet path to the application is established, simply because the hostname cannot be resolved.

The client attempts to access a service by hostname, but the DNS query fails or returns no usable answer. Because the client never receives a valid destination IP address, it cannot determine where to send the application traffic. That means there is no successful connection attempt to the reverse proxy or backend service. Unlike the ACL deny scenario, the failure occurs before the routed application flow even starts.

DNS failures can easily be mistaken for general connectivity or application outages. In reality, the client may never reach the network path required for the service at all. Understanding this distinction makes troubleshooting faster because it separates name resolution problems from routing, firewall, proxy, or application problems.

Step-by-Step DNS Failure Flow

This breakdown follows the failure from the initial DNS request to the point where the application connection cannot start.

1. Service Request by Hostname: The client attempts to reach the service using its hostname rather than a raw IP address.
2. DNS Query Sent: The client sends a DNS query to AdGuard Home or another configured resolver.
3. DNS Fails: The resolver does not respond correctly, returns no record, or otherwise fails to provide a usable destination IP.
4. No Destination IP Learned: Because the hostname was not resolved, the client does not know where to send the application traffic.
5. No Routed Application Flow: The client cannot build a normal connection toward Nginx Proxy Manager or the backend service because it lacks a valid destination IP.
6. Service Access Fails Early: From the client perspective, the service appears unavailable, but the failure happened at name resolution rather than at routing, ACL, or proxy forwarding.

Cloudflare Public Access Scenario

This scenario shows how service access changes when the request comes from outside the home network through Cloudflare instead of from an internal client VLAN. It highlights the difference between internal access paths and public-facing access paths.

Show how an external user reaches a published service through Cloudflare and how that path differs from internal reverse proxy access.

An external client requests a service using its public hostname. Public DNS resolves that hostname through Cloudflare, and the request is sent across the internet to the Cloudflare edge. Cloudflare then forwards the request to the published homelab service path. Depending on the service design, that traffic may be sent to a reverse proxy or through a Cloudflare Tunnel before reaching the backend application. This path differs from internal access because it depends on public DNS, Cloudflare’s edge, and external connectivity rather than only internal VLAN routing and local DNS.

Public access introduces a different troubleshooting model. A failure may come from public DNS, Cloudflare configuration, external reachability, reverse proxy rules, tunnel configuration, or the backend service itself. Understanding this path helps separate internet-facing problems from internal VLAN, ACL, or local DNS issues.

Step-by-Step Cloudflare Flow

This breakdown follows the request from an external client to the published internal service.

1. Public Hostname Request: An external client attempts to reach the service using its public hostname.
2. Public DNS Resolution: The client resolves the hostname using public DNS records managed through Cloudflare.
3. Traffic Sent to Cloudflare: The request is sent across the internet to Cloudflare’s edge network.
4. Cloudflare Processes the Request: Cloudflare applies its configured proxy, DNS, and service publishing behavior before forwarding the request toward the homelab environment.
5. Traffic Reaches the Internal Publishing Path: The request is passed to the internal exposure path, such as a reverse proxy or Cloudflare Tunnel endpoint.
6. Service Selection: The reverse proxy or tunnel target forwards the request to the correct backend application.
7. Backend Response: The backend service responds, and the response is returned back through Cloudflare to the external client.

Tailscale Remote Access Scenario

This scenario shows how remote administrative access differs from both internal client access and public Cloudflare-based access. It highlights the use of an encrypted overlay path for direct remote access without exposing services publicly.

Show how remote access can reach internal systems securely through Tailscale without relying on public service exposure.

A remote device connects to the homelab through Tailscale over an encrypted WireGuard-based overlay network. Instead of reaching the service through public DNS and Cloudflare, the remote device uses the private Tailscale path to communicate directly with internal resources. This changes the troubleshooting model because the request depends on overlay connectivity, Tailscale node reachability, and access design rather than public exposure or standard local VLAN access.

Tailscale provides a separate administrative path that can remain available even when public publishing methods are not being used. It also reduces public exposure by allowing internal resources to be reached through authenticated encrypted tunnels. Understanding this path is useful because failures here usually point to overlay connectivity, node availability, routing design, or remote access configuration rather than Cloudflare or traditional internal DNS-only issues.

Step-by-Step Tailscale Flow

This breakdown follows remote traffic from an off-site device to an internal homelab resource through the Tailscale overlay.

1. Remote Access Attempt: A remote device attempts to reach an internal resource while outside the home network.
2. Tailscale Connection Established: The device connects to the Tailscale mesh using its authenticated encrypted overlay connection.
3. Private Overlay Path Selected: The remote device uses the Tailscale route to reach the target internal node or subnet.
4. Traffic Enters the Homelab Through Tailscale: The request reaches the destination system through the overlay path instead of through public internet exposure.
5. Target Resource Responds: The internal node or service responds across the same encrypted overlay connection.
6. Secure Remote Access Completed: The user reaches the service or management interface without publishing that service directly to the internet.

Key Lessons

• Understanding packet flow step-by-step makes troubleshooting significantly faster and more accurate.
• Domain Name System (DNS), routing, Access Control Lists (ACLs), and reverse proxy behavior must be viewed as one continuous system rather than separate components.
• A successful DNS response does not guarantee connectivity. Traffic can still fail at routing, policy enforcement, or proxy forwarding.
• Failures at different layers look similar from the client perspective, but occur at completely different points in the path.
• Public access through Cloudflare and remote access through Tailscale follow different paths and require different troubleshooting approaches than internal VLAN traffic.

What I Would Improve Next

• Expand the Case Studies with packet captures to show real traffic behavior alongside the diagrams.
• Add a Network Address Translation (NAT) scenario to demonstrate how internal traffic is translated when accessing external resources.
• Include additional failure paths such as reverse proxy misconfiguration or backend service downtime.
• Build a reusable troubleshooting framework based on these scenarios to standardize how issues are diagnosed across the network.
• Extend the diagrams into an interactive format to better visualize packet flow across different layers and scenarios.