A Port in the Windows VPN Address Field Only Works for SSTP

A VPN server answers on TCP 10443, the Windows built-in client has the right credentials, and the connection still dies after a pause that looks like a DNS timeout. The cause is usually the address field: typing vpn.example.com:10443 into Server name or address makes Windows read the whole string as a hostname, because that box is not a general host:port input. Whether a port can be expressed there at all depends on the tunnel type the profile uses, and only one of the four types treats the value as something it can parse.

Why the address field is not a host:port box

The profile property behind that field is ServerAddress, and each tunnel type decides what it does with the string. Three of them have no port parameter to fill, so a colon and a number are simply characters in a name that will never resolve. The fourth runs over HTTPS, where a port is part of the URL, so the value has to be written in a form that parses as one.

That is why the failure looks like name resolution rather than like a refused connection. There is no bad port to report, only a hostname that does not exist, and the error arrives after the resolver gives up. Before you touch the server, check which tunnel type the profile claims to use.

The three types with a fixed port

PPTP connects to TCP 1723 and then carries the tunnel in GRE, IP protocol 47. L2TP/IPsec uses UDP 1701 for the tunnel and UDP 500 plus 4500 for IPsec, with 4500 being the NAT-traversal port. IKEv2 uses UDP 500 and 4500 as well. None of those profiles exposes a port field anywhere in the interface, and none will negotiate a non-standard one.

A server listening on a custom port is therefore unreachable to those profiles no matter how the address is written. The practical answers are narrow: publish the standard port on the server, or translate the standard port to the custom one on the router in front of it. Both keep the client profile untouched, which is worth a lot when the profile is deployed by policy rather than typed by hand.

SSTP needs a URL, not a name

SSTP is the exception because it runs inside a TLS session. The field must parse as a URL: the https:// scheme first, then the host, then a colon and the port. Without the scheme, Windows keeps treating the value as a plain name and the connection fails before any TLS exchange happens.

The reason this surprises people is that the default port accepts the bare hostname. A profile that never needed a custom port never teaches the rule, and the first person who adds one discovers it by failing. After saving, read the stored value back rather than trusting the dialog:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress shows exactly what was stored. If it reads as a bare hostname with a colon in it, the profile never received a URL and no amount of retrying will fix it.

Vendor syntax that gets pasted into the same box

Some gateways document extra conventions for that field, such as a realm appended after the port or query parameters that change certificate handling. They are understood by that vendor's server and, in some builds, by its own client. They are not part of the Windows profile format, and pasting them into a built-in profile usually produces the same silent name failure.

Treat a parameter that disables certificate validation as a warning rather than a fix. If a profile only connects with that parameter, the certificate does not match the name being used, and the correct repair is on the gateway, not in the client. A realm after the port has the same property: it does something only if the server on the other side expects it.

Prove the port, then read the failing stage

Confirm that something accepts TCP on that port from the client's network before blaming the profile:

Test-NetConnection vpn.example.com -Port 10443

Success proves a listener, not SSTP. A web server, a reverse proxy or a load balancer can complete the TCP handshake and still not speak SSTP, so a green test with a red VPN is a real combination. Compare the certificate subject against the name in the profile, and check the RasClient log on builds that ship it, because it records the stage that failed instead of a generic timeout.

Then consider the option that removes the problem instead of documenting it: forward TCP 443 on the outside to 10443 on the VPN server. The client then uses the default profile with no port at all, which is usually the cleanest arrangement for a managed fleet and leaves the custom port as an internal detail.