Is the Firewall Blocking the VPN? A Stage-by-Stage Check

One VPN timeout proves that no usable reply arrived, and it proves nothing about why. The profile may name the wrong port, the server may be down, or the request may arrive with no working return path. Each of those leaves a different trace, and the trace is what tells you which rule to touch. Work the four stages below in order. Stop as soon as one of them explains the symptom.

Step 1: confirm the server and the transport

Read the server name, transport and port from the operator's current profile rather than from a local edit. A port changed on your laptop cannot create a listener on a public server, and that mismatch produces a timeout identical to a block. If the profile offers a supported alternative transport, note it as a fallback rather than as a fix. Resolve the name and compare the answer with the address the operator published.

A stale DNS record sends the client to a host that never answered. That is another fault which mimics a filter, and it costs one query to rule out.

Write both values into the ticket. Every later comparison uses them, and a ticket without them restarts the investigation.

Step 2: prove the path with one controlled comparison

Keep the device and profile unchanged and try another trusted access network. If the tunnel comes up there, the original path or its policy is the difference. If a second approved device works on the original network, the first device is the difference. One of those two comparisons is almost always decisive.

Complete any legitimate network sign-in first, because a captive portal looks like a block until it is done.

Test the port you actually use, and treat a TCP result as information about TCP only.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

A successful TCP handshake on 443 says a listener answered there. It says nothing about a UDP listener on 51820, and nothing about whether the negotiation completed.

Step 3: read the security events for the moment of failure

Firewall events are the strongest evidence available, and they carry a caveat worth stating first. Logging is disabled in many default profiles, so check whether the relevant profile logs drops before reading an empty log as proof of innocence. When logging is on, the event names the rule, the direction and the addresses, which is exactly what a rule change needs. Application rules and port rules are separate objects, and managed policy can override a local setting. Confirm which client and which service a rule actually covers.

Collect the profile state and the recent events from the machine that failed, not from a neighbouring host.

Read the event time against the time of your test attempt, since a matching rule name with a different timestamp is a coincidence.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

On a server you administer, ask whether the request reached the listener at all. An arriving packet with no reply is a forwarding or return-route problem. A request that never appears is a filtering or addressing problem.

Step 4: test forwarding after the tunnel is up

A firewall can allow the session and still deny everything the session wants to reach. Forwarding sysctls, NAT rules and return routes all sit after authentication, and a broad exemption for the VPN port repairs none of them. Test one internal destination and one internet destination separately, because they usually fail for different reasons. If internal names fail but addresses work, look at pushed DNS before any rule.

Run the three checks below on the server while a client is connected and attempting the failing request.

The counters on the tunnel interface are the point, since they show whether packets entered and whether anything left.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

When packets arrive on the tunnel and nothing leaves towards the destination, forwarding or NAT is the suspect. When nothing arrives at all, the session is up but the client is not sending, and the client's route table is the place to look.

Check the fix and remove what did not help

After an approved correction, repeat the exact test that failed and record the result against the same profile and device. Then remove any temporary exception that did not change the outcome, because unused exceptions accumulate and each one is a decision nobody remembers making. Keep what remains narrow: one destination, one port, one direction, one owner.

Re-run the same three commands and compare them with the outputs you saved before the change.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

When the comparison network works, the original network still fails and the events stay empty, the remaining suspect is the path rather than the host. Hand that to the network owner as a specific statement, with both comparison results attached. That is a better place to stop than a disabled firewall profile.