Advanced Topics: VPNs, Proxies, NAT & Full-PCAP Analysis

VPN Tunnels and How They Reshape Visibility

A VPN creates an encrypted tunnel between two endpoints and encapsulates the original traffic inside it. Whatever protocol the user is actually running, whether that is HTTP, DNS, or a file transfer, gets wrapped in a new outer packet before it leaves the source device. To anything watching the wire between the client and the VPN gateway, the only visible protocol is the tunnel itself.

This is the entire point of the technology: it protects traffic in transit and, as a side effect, it removes a huge amount of information from anyone monitoring the network path in between.

Three Tunnel Types You'll See Repeatedly

• IPsec: operates at the network layer. Common for site-to-site tunnels between offices, or between a corporate network and a cloud VPC.
• SSL/TLS-based VPNs: including OpenVPN and most commercial remote-access clients, wrap traffic inside a TLS session. Common for individual remote workers connecting into a corporate network.
• WireGuard: a newer, leaner protocol built on modern cryptography. Increasingly used both for legitimate remote access and, notably, by threat actors who favor its small footprint and low latency for C2 channels.

What a Monitor Actually Sees

What a monitor sees once traffic enters a tunnel depends on where it sits. A device positioned between the client and the VPN gateway sees only the encrypted tunnel: source and destination IP of the tunnel endpoints, a consistent packet size and timing pattern, and nothing about what is inside. It cannot see the destination the user is actually reaching, the DNS queries they are making, or the application protocol in use.

A device positioned inside the tunnel, such as an endpoint agent running on the client itself or a monitor placed on the network the VPN terminates into, sees the traffic in its original, unencapsulated form. This is why EDR telemetry and VPN concentrator logs become so important once traffic leaves the reach of a network tap: they are often the only place the true destination and protocol are still visible.

Consequence for the Triage Workflow

The protocol hierarchy and conversation analysis from Chapter 5 work fine against a VPN tunnel, but they only describe the tunnel, not what is inside it. If an analyst sees a host establishing a long-lived encrypted session to a single external IP and cannot explain the traffic beyond that, the next question is not "what protocol is this" but "is this a tunnel, and if so, where does it terminate and what logs exist on the other side."

Recognizing that a flow is VPN traffic, rather than trying to force it into an application-layer analysis it cannot yield, is itself a useful triage skill.

Forward and Reverse Proxies

Proxies sit between two parties and substitute their own address for one side of the connection, but forward and reverse proxies do this substitution in opposite directions and for different reasons. Confusing the two is a common source of misread traffic, because both produce the same superficial pattern on the wire: a connection that does not go directly from the true source to the true destination.

Forward Proxy: Hides the Client

A forward proxy sits in front of clients and hides the client from the destination. This is the pattern behind corporate web proxies and egress control appliances. When an employee's browser requests a website, the request goes to the proxy first, and the proxy makes the actual outbound connection on the employee's behalf.

From the perspective of the external website, every request from that organization appears to originate from the proxy's IP, not from the individual workstation. For an investigator, this means malicious traffic from a compromised host and legitimate traffic from a hundred other employees can look identical from outside the network: the same source IP. Attributing a specific external connection to a specific internal host requires the proxy's own access logs, which map each outbound request back to the originating client IP and often the authenticated user.

Reverse Proxy: Hides the Server

A reverse proxy sits in front of servers and hides backend infrastructure from the client. This is the pattern behind load balancers, CDNs, and web application firewalls. When a user connects to a public-facing web application, they are usually talking to a reverse proxy, which then forwards the request to one of potentially many backend servers, and the client never learns the real IP address or internal architecture of the backend.

For an investigator looking at inbound attack traffic against a hosted service, the reverse proxy's logs, not the backend server's logs, are usually where the true source IP and request pattern are first visible, since the backend may only see the proxy's internal address as the connecting IP.

The practical distinction to hold onto is which side of the connection is being obscured. A forward proxy protects the identity of who is asking. A reverse proxy protects the identity of who is answering. Both make a naive read of "connection from A to B" incomplete, and both require a specific additional log source before an investigator can say with confidence who actually originated or received a given piece of traffic.

NAT and Why It Complicates Attribution

How NAT Erases the Internal Source

Network Address Translation (NAT) rewrites private IP addresses into a shared public IP address as traffic crosses a network boundary, most commonly at a firewall or router sitting between an internal network and the internet. This is why an organization with hundreds of internal hosts, each using private addressing like 10.0.0.0/8 or 192.168.0.0/16, can still communicate externally through one or a small handful of public IPs.

NAT was originally a solution to IPv4 address exhaustion, but it has a lasting side effect on investigations: it deliberately erases the internal source address from anything visible outside the network.

When an investigator receives an external report of malicious activity, such as an abuse complaint or a threat intel hit tied to the organization's public IP, that IP alone does not identify which internal host generated the traffic. If fifty workstations sit behind the same NAT gateway, the public IP is identical for all fifty.

Pinpointing the actual source requires NAT translation logs from the firewall or router, which record the mapping between the internal private IP, the internal source port, and the external public IP and port for each session, along with a timestamp. Without those logs, and without them being retained long enough to cover the window in question, the internal host responsible for a piece of external traffic may be unrecoverable after the fact. This is one of the most common reasons an investigation stalls: the perimeter device did not retain NAT logs long enough, or was not logging port-level detail at all.

STUN and TURN: NAT Traversal for Real-Time Protocols

Real-time protocols such as VoIP and video conferencing face a related but distinct problem: two hosts, each behind their own NAT, need to establish a direct connection with each other despite neither having a routable public address by default.

These protocols are not primarily security tools, but analysts encounter them when investigating unusual UDP traffic to unfamiliar cloud IPs, since STUN and TURN servers are a normal and legitimate part of how many collaboration and calling applications function.

Why This Matters for PCAP Analysis

Tying this back to earlier material, NAT is exactly why the conversations and endpoints views described in Chapter 5's triage workflow can be misleading without corroborating logs. A single external IP appearing in a PCAP taken at the network perimeter may represent traffic from one host or from dozens, and the packet capture itself has no way to distinguish them.

The PCAP tells you what left the building. The firewall's NAT table tells you who inside the building sent it.

How VPNs, Proxies, and NAT Combine to Complicate Investigations

These mechanisms rarely appear alone in a real investigation. Consider a realistic scenario: a threat intel feed flags an external IP as C2 infrastructure for a known malware family, and that IP appears in a week-old PCAP captured at the organization's internet edge. The capture shows a single internal-facing NAT gateway address making periodic beacon-like connections to that IP.

On its face, this looks like it should be simple to attribute. It is not, because three separate translation layers may sit between that beacon and the actual compromised host.

Working the Chain Backward

1. NAT gateway. The PCAP shows the post-NAT public source IP, so the investigator's first move is pulling NAT translation logs for the relevant time window to recover the internal private IP that generated each beacon session. This step alone can fail silently if the firewall only retains NAT logs for 24 or 48 hours, which is common in under-resourced environments, making a week-old PCAP effectively unattributable at the network layer.
2. Forward proxy. Assume the NAT logs survive and point to an internal IP. That internal IP may itself be a corporate forward proxy rather than the compromised endpoint, if the organization routes all outbound traffic through egress filtering. In that case the beacon traffic seen externally represents dozens or hundreds of employees' aggregated outbound connections, and the proxy's own access logs, indexed by client IP or authenticated username, are the only way to separate the one malicious session from the legitimate ones sharing that same NAT'd, proxied path. This is the point where many investigations require pulling logs from two or three different infrastructure teams, firewall, proxy, and possibly VPN, each with its own retention window and its own log format.
3. VPN concentrator. Finally, consider that the compromised host itself might be a remote worker's laptop connecting through a corporate VPN before ever reaching the proxy or the internet-facing NAT gateway. In that case the internal IP recovered from the proxy log is not a fixed workstation but a VPN-assigned address that changes on every connection, and the VPN concentrator's own session logs, correlating the assigned internal IP to a specific authenticated user and physical connection window, become the final and necessary piece.

Each hop back through NAT, then proxy, then VPN requires a different log source with a different owner and a different retention policy, and a gap at any single hop can end the trail. This is why experienced investigators map out an organization's egress path, in order, before an incident happens, rather than discovering the chain of infrastructure for the first time under pressure during a live investigation.

A Full PCAP Walkthrough

Put the whole module to work on one capture. An analyst receives a PCAP covering roughly two hours of traffic from a workstation flagged for unusual outbound behavior by an EDR alert.

1. Check the protocol hierarchy. Following the Chapter 5 triage sequence, the first move is not to open individual packets but to check the protocol hierarchy statistics. The breakdown shows the expected mix of DNS, TLS, and a small amount of SMB for internal file share activity, plus one line that stands out: a modest volume of TLS traffic to a single destination that accounts for a disproportionate share of total bytes given how few packets it involved, suggesting a small number of long sessions rather than normal browsing.
2. Open the conversations view. Per the triage workflow, the analyst opens the conversations view and sorts by duration and byte count. One TCP conversation to an external IP stands out: it is long-lived, has a steady small-packet cadence consistent with a beacon rather than a bulk transfer, and the destination IP has no prior history in the organization's traffic baseline. This is exactly the "new external destination with an unusual conversation pattern" signal the Chapter 5 workflow trains analysts to flag for targeted follow-up rather than dismiss.
3. Apply targeted DNS filters. The analyst isolates DNS traffic in the minutes immediately before that conversation began. This surfaces a query for a domain that, per the organization's DNS logging, was never resolved by this workstation or any other host in the environment before that day, a classic newly-seen-domain indicator. The domain resolves to the same IP seen in the flagged conversation, connecting the DNS query directly to the outbound session. This confirms the traffic was initiated through normal name resolution rather than a hardcoded IP, which matters for scoping: DNS logs across the rest of the environment can now be searched for the same domain to check for other affected hosts.
4. Pull the JA3 fingerprint from the TLS handshake. Filtering down to the TLS handshake for that specific session, the analyst pulls the JA3 fingerprint, the technique introduced in Chapter 4 for characterizing TLS clients independent of the certificate or SNI presented. The fingerprint does not match any known legitimate browser or standard library signature in the organization's baseline, and a quick lookup shows it associated with a known malware C2 framework's default TLS stack. Combined with the newly seen domain and the beacon-like conversation pattern, this is now a high-confidence finding: the host has an active outbound connection to malicious infrastructure using a recognizable C2 toolset's default TLS fingerprint, not a coincidental resemblance.
5. Tie the finding back to attribution. The PCAP was captured at the network edge, so the source IP recorded is the workstation's real internal address in this case, no NAT hop obscures it, but the analyst still checks whether this connection passed through the corporate forward proxy per policy. It did not, which is itself a finding: the traffic bypassed the proxy entirely, either through a misconfiguration or a deliberate evasion technique on the malware's part, and that gap becomes a second, separate remediation item alongside isolating the host and blocking the domain and IP.

Where This Module Fits in H3AD-LEARN

The skills built across these eight chapters are not self-contained. They are the substrate a number of other H3AD-LEARN modules assume you already have.

Threat Hunting

The Threat Hunting module's data sources chapter takes for granted that you understand what network telemetry actually captures and where its blind spots are. Hunting hypotheses built on flow data or PCAP evidence only make sense once you know, as this chapter covered, what NAT, proxies, and encryption can hide from that evidence.

Cloud Security

The Cloud Security module's telemetry chapter builds directly on these same concepts, applied to a different environment. VPC flow logs, cloud load balancer logs, and cloud NAT gateway logs are the cloud-native equivalents of the packet captures, proxy logs, and NAT tables covered here.

The same attribution challenges reappear in that context: a flow log entry showing traffic from a NAT gateway's IP raises the identical question this chapter walked through, which backend resource actually generated it.

LOLBAS

The LOLBAS module's detection strategy chapter also leans on material from here more than it might first appear. Detecting living-off-the-land techniques often depends on network-layer signals, unusual destination patterns, beaconing intervals, or TLS fingerprints that do not match the calling process, all of which are exactly the kind of evidence this chapter's PCAP walkthrough demonstrated how to extract.

Fundamentals

Taken together with the Fundamentals module, Networking forms the baseline that nearly everything else on this platform sits on top of. Detection engineering, threat hunting, cloud security investigations, and endpoint-focused analysis all eventually touch the network.

The habits built in this module, checking protocol hierarchy before diving into packets, knowing which log source answers which attribution question, recognizing when traffic has been tunneled or translated, are the ones that keep showing up no matter which specialization comes next.