I'm troubleshooting a PowerShell connectivity issue. Running Test-Connection $server succeeds, and Test-NetConnection $server -Port $Port -InformationLevel Quiet also returns a successful result. However, the normal Test-NetConnection $server -Port $Port command appears to hang instead of completing. The behavior occurs both within the local subnet and across the WAN. I'm trying to determine whether the cause is the target service, a firewall or network device, the protocol being tested, or something specific to the local PowerShell environment.
4 Answers
Some firewalls, VPNs, and security appliances intercept or delay connection probes. They may allow ICMP or even make a quiet Boolean test appear successful while the detailed command waits for additional connection information. A packet capture can show whether the TCP SYN leaves the client and whether anything comes back. Comparing a working LAN target with a WAN target is useful here.
Try running the command with -Verbose and -Debug, and note exactly which stage takes a long time. Also compare the same test from another machine and against a known-good server. That helps separate a problem on the client from a route, firewall, VPN, or remote-server issue.
Verify that the service is actually listening on the destination machine and that the port is TCP. Testing a commonly used TCP port can provide a baseline, but the important part is confirming the specific application port and its firewall rules. If every target behaves the same way locally, then investigate the PowerShell/.NET installation or endpoint security software.
Ping and a TCP port test are checking different things. ICMP can work even when the requested TCP port is filtered, unavailable, or not listening. Check the target with netstat -ano or another service-specific tool, and confirm that $Port is the correct TCP port rather than UDP. A blocked or filtered port may eventually produce a failure, but it can take a while to time out.
A failed TCP test normally should still finish and report TcpTestSucceeded as false, so a long hang points more toward filtering, an intermediary device, or a local issue than simply a closed listener.