Put the VPN gateway beside Windows XP, not inside it

Somewhere in the building sits a machine running an application nobody can replace on an operating system nobody should connect to anything. Walking outward from that host's network adapter is the quickest way to see where the tunnel belongs. In most designs it does not belong on the host at all. Move it one hop away onto a maintained gateway and the legacy problem shrinks back to the application it started as.

Start at the host adapter, not at a VPN client

Open the adapter properties and give the host a fixed address on a small dedicated segment, with the gateway as its default route. The host then needs no tunnel client, no tunnel credentials and no route table entries reaching into the wider corporate network. If the application needs one remote subnet, add exactly that one route.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

That command pins a single destination to the gateway and leaves everything else unroutable, which is the shape you want. Confirm the result with route print rather than trusting the exit code. Then check that the application still resolves its server name, because a legacy host with a broken resolver looks exactly like a network failure, and fixing the resolver is a five-minute job while rebuilding an application after a mistaken network change is not. Every destination the host cannot reach is one less thing an old network stack can be talked into attacking.

Put the tunnel on hardware you can update

The gateway wants two interfaces: one facing the host segment and one facing wherever the application lives, with the tunnel terminating on the second. That device can take firmware updates, replace its cryptographic configuration and log flows without anyone touching the old machine. Its vendor also ships fixes for the tunnel implementation, which the host will never receive. Two machines and a deadline are not a reason to copy a static-secret recipe from a forum post.

Give each gateway its own peer identity instead of cloning one client configuration across a fleet. When a unit is replaced, revoke the old identity at the same moment you bring the new one online, or you end up with two uncontrolled copies authenticating to the same endpoint. Store the keys where the gateway's management plane expects them, treat a configuration backup as a secret, and review who can push that configuration, because it now decides what the legacy host can reach.

Allow services, not networks

Write the policy in terms of protocol, port and direction between the two attachments. A single allowed port to a single application address is the usual answer, and an administrative path through a jump host covers the rest.

Remote administration of the old host should not ride the same rule as the application, and testing the refusal matters as much as writing the rule. Send one request from the host to a destination you expect to be refused and confirm that the refusal comes from the policy rather than from a missing route. Log the flows you allow while the design is new, so you can see what the application actually uses rather than what its documentation claims. Merging two subnets because a bridged tutorial looked shorter is how a legacy segment quietly becomes a pivot.

Do not expose the legacy listener directly to the internet as a shortcut around the gateway. Keep the administrative path separate from the application path so a compromise of one does not hand over the other. A rule that is never exercised is a rule nobody has verified, which is why the denied destination belongs in the acceptance run.

Recovery has to work without the tunnel

Decide who updates and recovers the gateway before the first outage, and make sure that person can reach it without the tunnel it terminates. Console access, a local management port or an out-of-band path all count as answers. A gateway that can only be configured through the tunnel it provides is a trap that waits patiently for a bad firmware push.

Write the runbook for the failure you will actually meet: tunnel down, gateway dead, host disk gone. Keep the host's recovery image under whatever support arrangement still exists for it, and remember that a restore also restores the software state and the credentials inside that image. Restore onto the isolated segment first, confirm the application starts, and only then reconnect anything; when the gateway changes, update the runbook and the inventory in the same sitting.

Certificates, clocks and signing warnings

An installer's certificate expiry does not by itself predict what a signature check will say today. Microsoft's Authenticode timestamp guidance explains that a timestamp can keep a signature verifiable after the signing certificate expires, and validation still depends on the signature, the trust chain and the verifier doing the work. Two machines with different trust stores can therefore disagree about the same file. An expired signer is not proof that a binary is malicious, and a valid signature is not proof that the software is maintained.

Do not move the system clock backwards or switch off signature checks to make an old installer run. Obtain an authorized artifact through whoever still supports the application and let them say what the platform accepts. Treat posts claiming a particular build was the last one for XP as history rather than as an installation target, since the real requirement depends on the application; if preservation work is genuinely needed, keep it on an isolated segment away from production access and document why it exists.