Packet Flow • VLANs • Routing • ACLs • Troubleshooting

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

I created this project to explain how traffic actually moves through my segmented homelab instead of treating networking as a set of isolated features. Using a client on one VLAN accessing a service on another, I traced the path step by step through DNS resolution, Layer 2 framing, inter-VLAN routing, Access Control List (ACL) evaluation, and return traffic.

Packet Flow VLANs Routing ACLs Troubleshooting

Environment

Client VLAN

A client device on VLAN 30 initiates traffic toward an internal service using a hostname instead of a raw IP address.

Services VLAN

The destination service lives on VLAN 20, requiring inter-VLAN routing to move traffic between networks.

Router and Policy Layer

The router provides Layer 3 forwarding between VLANs and enforces Access Control Lists (ACLs) to determine what traffic is allowed.

Name Resolution

Domain Name System (DNS) is part of the workflow because the client resolves the service name before it can begin the actual connection.

Problem

It is easy to configure VLANs, routes, and ACLs as separate features without fully understanding how they interact during real traffic flow. I wanted a project that explains what actually happens from the moment a client requests a service to the moment the response comes back, because troubleshooting depends on understanding that full path.

Why This Matters

  • Traffic problems are easier to solve when the full packet path is understood instead of guessed.
  • Segmentation, routing, and policy controls only make sense when viewed as one system.
  • Understanding packet flow is foundational for networking, security, and troubleshooting work.

Scenario

The scenario used in this project is a client on VLAN 30 accessing an internal service on VLAN 20 by hostname through Nginx Proxy Manager. That makes the path useful because it includes DNS resolution, inter-VLAN routing, Access Control List (ACL) evaluation, and reverse proxy forwarding.

Packet Flow Diagram
Packet flow from a VLAN 30 client to a VLAN 20 backend service through DNS resolution, inter-VLAN routing, Access Control List (ACL) evaluation, and reverse proxy forwarding.

Step-by-Step Packet Flow

1. The client resolves the service name

The client first uses DNS to resolve the hostname into an IP address. In my environment, AdGuard Home uses a DNS rewrite so the requested hostname resolves to the IP address of Nginx Proxy Manager (NPM). At this stage, DNS only returns the IP address. It does not forward the actual application traffic.

2. The client checks whether the destination is local

The client compares its own subnet to the destination IP. Because Nginx Proxy Manager is on a different VLAN and subnet, the client determines that the traffic must be sent to its default gateway.

3. The client uses Address Resolution Protocol (ARP) for the default gateway

If the client does not already know the Media Access Control (MAC) address of the default gateway, it uses Address Resolution Protocol (ARP) to learn it. The client does not ARP for Nginx Proxy Manager directly because that destination is remote.

4. The client builds the frame and sends it to the switch

The client creates a Layer 3 packet with the destination IP of Nginx Proxy Manager and a Layer 2 frame addressed to the default gateway MAC. The client sends an untagged frame into its access port, and the switch associates it with the correct VLAN.

5. The switch forwards the traffic toward the router

As traffic moves across a trunk, the switch adds the appropriate Institute of Electrical and Electronics Engineers (IEEE) 802.1Q VLAN tag so the router knows which VLAN the frame came from.

6. The router processes the packet at Layer 3

The router removes the incoming Layer 2 framing, examines the destination IP address, determines that the packet should be forwarded toward VLAN 20, and evaluates any Access Control List (ACL) policy applied to that traffic path.

7. The Access Control List (ACL) is evaluated

The router checks the packet against the configured policy in top-down order. In my network, VLAN 30 is allowed to reach Nginx Proxy Manager on ports 80 and 443, while other unauthorized traffic from VLAN 30 to VLAN 20 is denied. If the traffic matches an allow rule, it continues. If it matches a deny rule, the flow stops at this point.

8. The router rebuilds the Layer 2 frame for the destination VLAN

After making the forwarding decision, the router creates a new Layer 2 frame for VLAN 20. The source and destination MAC addresses are different from the original frame, but the Layer 3 destination IP remains the same.

9. Nginx Proxy Manager receives the request

Nginx Proxy Manager receives the HTTP or HTTPS request because the hostname resolved to its IP address. Nginx Proxy Manager then uses the requested hostname to determine which backend service should receive the traffic.

10. Nginx Proxy Manager forwards the request to the backend service

After matching the hostname to the correct proxy host configuration, Nginx Proxy Manager forwards the request to the intended internal application. At this point, the full path succeeded because DNS, switching, routing, ACL policy, and reverse proxying all worked together correctly.

11. Return traffic follows the reverse path

The backend service returns the response to Nginx Proxy Manager, which then sends the response back to the client. If the response crosses VLAN boundaries, the router again evaluates policy, rebuilds Layer 2 framing for the destination VLAN, and forwards the traffic back toward the client.

Key Technical Points

  • The client only uses Address Resolution Protocol (ARP) for local neighbors, such as the default gateway, not for remote destinations.
  • The Layer 2 frame changes at each routed hop, but the destination IP address remains the same end to end.
  • VLAN separation at Layer 2 does not prevent Layer 3 communication unless routing policy also controls it.
  • Access Control Lists (ACLs) matter because the router is the decision point between segmented networks.
  • Domain Name System (DNS) problems can look like connectivity problems, and reverse proxy misconfiguration can look like routing or service failure even when the packet path is working correctly.

Validation

  • Tested name resolution separately from application connectivity.
  • Verified that the client used the default gateway for remote traffic.
  • Confirmed expected flows were allowed and blocked flows were denied by policy.
  • Used troubleshooting tools to separate Domain Name System (DNS), switching, routing, and Access Control List (ACL) issues.

Outcome

This project gave me a clearer mental model for how segmented networking actually behaves under normal operation and during troubleshooting. Instead of viewing VLANs, routing, and ACLs as separate topics, I learned to see them as one continuous traffic path.

Key Lesson

One of the biggest lessons from this project was that strong troubleshooting depends on understanding packet flow step by step. When I know where a frame is built, where a packet is routed, where policy is evaluated, and where name resolution fits in, I can diagnose problems much more accurately.

What I'd Improve Next

  • Add a failure-path version showing what changes when an ACL blocks the request.
  • Expand the project with a second example that includes internet-bound traffic and Network Address Translation (NAT).
  • Include packet capture examples to show what the path looks like during real troubleshooting.
  • Add a second diagram showing how the reverse path differs once Nginx Proxy Manager creates a new session to the backend.
← Back to Projects