Inbound Alert on a VPN Server: Read the Observation Point

A server behind a VPN keeps its public service entries, and people keep finding them. What arrives in the alert queue is not one finding but three possible ones, and they mean different things. The first job is to separate an exposed service from an exposed credential.

Work through the observation points in order. Stop when the evidence changes category, because the next stage answers a different question.

Stage One: What the Capture Actually Saw

A packet capture records what was visible at its own point on the path. That point may sit before a later filtering decision. A captured packet proves the traffic arrived there. It proves nothing about what happened next.

Note the interface as well. A capture on the public adapter and a capture inside the tunnel describe different arrival points, and an alert that quotes the wrong one leads to the wrong conclusion.

Windows also filters at several layers of the stack, so the tidy model where the capture tool sits at layer two and the firewall at layer three does not survive contact with a real product. The Windows Filtering Platform overview describes filtering across stack layers, which is why observation order has to be established rather than assumed.

Stage Two: What the Drop Record Establishes

A drop record says a policy boundary rejected that packet. It is strong evidence. It is also narrow evidence, because it covers one decision at one boundary. Nothing else in the stack is described by it.

Correlate on the tuple and the timestamp. Same source, same destination, same port, within the same second. Without that match, a similar-looking event in another log is simply another event, and pairing them produces a story nobody can defend.

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

A closed port and a dropped packet look identical from outside and completely different in these two outputs. That difference is the whole reason to read the local record.

Stage Three: What the Authentication Event Proves

An authentication event says a component processed the request far enough to record a result. It is the only one of the three stages that speaks about identity, and it says nothing about how many packets arrived before it.

Read the event's actual context. A failed logon for an account that does not exist is noise from scanning. A failed logon for a real account with a plausible source is a different priority. A successful session is a different incident category altogether.

Watch the protocol names too. RPC and RDP are separate services with separate ports. A detector that watches one of them is not covering the other. Tools that summarize network activity do not always state which of the two produced the event.

One Correlated Sample Beats a Dashboard

Pick one authorized test, run it on purpose, and trace it end to end: destination address and interface, true source address, service port, effective firewall profile and rule, and the matching service result. Include any upstream mapping or cloud firewall in that chain, because a permissive rule there can override a tidy local one.

Then separate the two obligations. If administration is meant to be VPN-only, enforce it on both the public and the tunnel path while keeping an approved recovery route. Monitoring a rejected attempt is not the same task as deciding what the server should accept.

A geography rule or a blocked unrelated protocol is not a substitute for finding the observed entry and the decision it received. Neither is a VPN: routing outbound traffic through a tunnel documents nothing about inbound authorization.