Snort at the VPN Edge: Where the Packets Are Visible

Follow one request from a remote laptop and it crosses several boundaries before anything can inspect it. The outer tunnel ends at the VPN process, the inner packet appears on an interface, and the HTTPS session inside continues to the application. An inspection tool only sees what is visible at the point where packets reach it. Install one without deciding that point, and the logs describe the wrong layer.

One packet crosses several boundaries

Before VPN termination the observer sees one outer connection, typically to the VPN port, with addresses and sizes but no inner structure. After termination the inner addresses, ports and protocols are available at whatever processing point hands them over. The application's own TLS remains encrypted unless a separate design terminates it. Those are three visibility levels, and a package name does not tell you which one you bought.

Draw the path with the boundaries marked, then place the sensor on the line where the question can be answered, because the location is part of the answer. A boundary you cannot name is a boundary you cannot test.

See what is readable at each point

Check the interface and a short capture before trusting any description of the architecture.

ip -br link
tcpdump -ni tun0 -c 10 'tcp port 443'

The link list shows which tunnel and physical interfaces exist, and the capture shows exactly what a sensor attached there would receive. If it shows inner addresses but no HTTP request lines, you are after VPN termination and still outside the application's TLS. That is the normal place for network detection and the wrong place for body inspection. Repeat the capture on the outer interface to compare what the other boundary exposes.

Passive detection cannot block on its own

Snort's inspection documentation separates passive observation from inline operation. Passive mode can alert on traffic without stopping it on that path.

snort -T -c /etc/snort/snort.lua

Test mode validates the configuration without running the sensor, which is the right first step before any deployment. Inline operation needs a compatible packet-acquisition arrangement and matching enforcement configuration, not just an extra flag. A log entry is therefore not evidence that a request was prevented, and a process started with an inline-looking option does not prove the real forwarded flow passes through it. Confirm where the implementation actually hands packets over.

Choose the enforcement mode before deploying

Decide whether the requirement is visibility or prevention, because the two carry different failure behaviour. A passive sensor that dies leaves traffic flowing and produces a monitoring gap; an inline device that dies can either pass traffic or stop it, and that choice must be deliberate. Agree on one allowed flow, one flow that must be denied, and the behaviour you want when the sensor fails. Keep management recovery separate from the inspected path, so a mistake in the sensor does not also remove your access.

Then record the visible traffic, the processing point and the enforcement behaviour. Those three facts, not the installed package, describe what the deployment actually does.