VPN Traffic Filter or IPsec Rule: Where Windows Enforces a Port

One Windows VPN user should reach HTTPS on a server and not SMB on the same server, and a route cannot express that. Both requests carry the same destination address, so the prefix that sends traffic into the tunnel also carries the flow you wanted to exclude. Separating them requires a rule that examines something finer than the destination.

Two different intentions get built with two different Windows mechanisms. Mixing them produces a policy that looks complete while enforcing half of what you meant.

A Route Cannot Separate Two Services at One Address

Native VPN routing is prefix-based: it decides which destinations travel through the tunnel and which stay outside. That is the right tool for keeping one subnet inside and another outside, and it is blind to ports by construction. A traffic filter on the VPN profile adds a second dimension, matching protocol, remote address and remote port for what may cross that interface. An IPsec rule works in a third place, expressing which flows require protection and with whom they authenticate. The three answer different questions and none substitutes for the others.

Start by writing the intended sentence. Allow HTTPS only is an access sentence, while require IPsec for HTTPS is a protection sentence, and the two lead to different configuration.

Access Restriction and Protection Requirement Diverge

An access restriction says what may use the interface, and it is enforced by permitting a set and refusing everything else. A protection requirement says which flows must be encrypted and authenticated, and it is enforced by negotiating security associations that match them. The first produces a blocked request when something is not on the list, while the second produces a connection that either carries the required protection or fails to establish. Treating one as the other is how a policy ends up blocking nothing or protecting nothing.

The practical consequence is that a filter list is a closed set. Once a list exists on the profile, traffic over that interface matching no entry is refused, so DNS, authentication exchanges and any dependency the application needs require their own entries. Adding one broad rule to silence the refusals reopens the whole interface and quietly cancels the restriction. The list should be as short as the requirement allows and as complete as the application demands.

Build the Filter List as a Complete Set

VPNv2 profiles carry the filter list separately from the route list, and its entries are profile properties rather than commands. For the HTTPS example the entry needs protocol 6, the remote address and the remote port, deployed through the management channel or ProfileXML for the profile type in use. Microsoft's VPNv2 traffic filter definition states that conditions inside one rule combine while separate rule identifiers act as alternatives.

TrafficFilterList/0/Protocol            = 6
TrafficFilterList/0/RemoteAddressRanges = 10.60.4.20/32
TrafficFilterList/0/RemotePortRanges    = 443
RouteList/0/Address                     = 10.60.4.0/24

Port values in that list describe the service port at the far end, and the local port should stay unconstrained so the client's ephemeral source port is not filtered out. Getting that backwards produces a rule that matches nothing and a puzzle that takes an afternoon.

Write the route and the filter as two separate decisions. The route decides that this server is reached through the tunnel, and the filter decides which services may use that path.

Prove Both Outcomes With Two Requests

Test the allowed flow and the denied flow separately, and read the failure rather than the missing page. A refusal that arrives quickly is a policy decision, while a timeout is more likely a missing route or a service that is not listening. The commands below run both requests and show the rules in force.

Test-NetConnection 10.60.4.20 -Port 443
Test-NetConnection 10.60.4.20 -Port 445
Get-NetIPsecRule -DisplayName *Vpn*
Get-VpnConnection -Name Corp

A fast rejection on the SMB test with a successful HTTPS test is the outcome the filter was supposed to produce. A refusal on both ports means the list is missing something the session needs, and a timeout on both points at routing rather than filtering. If the protected flows show no security association in the IPsec output, the protection requirement is unmet even when the connection succeeds. Read all four outputs together, because each one alone supports a different story.

Record the effective profile, the rule set and the peer's policy alongside the results. Historical compatibility notes about older Windows clients do not describe what today's managed profile features support on a particular gateway. Version-specific behaviour belongs in the record rather than in the assumption.