Introduction

Important: This guide applies to version 4.0.0 and later. If you use an earlier version, update to the latest release before continuing and uninstall OpenVPN TUN/TAP.

Microsoft Windows does not natively support Generic Routing Encapsulation (GRE) or IP-in-IP (IPIP) tunnels. The X4B tunnel client, available to all X4B customers, provides this functionality and fully encapsulates traffic to preserve your backend IP address.

You can download the client from your X4B Dashboard by choosing Action > Setup Tunnel for the relevant tunnel. It automatically configures your GRE or IPIP tunnel.

This guide is current for software version v4.0.x.

Notes

  • Allow the required traffic for your services through Windows Firewall.
  • The client has been tested primarily on Windows Server 2025, 2022 & 2019, and also on Windows 11.
  • Both IP-in-IP and GRE tunnels are supported.
  • An Ethernet (802.1 or 802.1Q) network connection is required.
  • One client instance can manage multiple tunnels. Running multiple client instances is not supported. If you are running other applications using GRE or IP-in-IP on the system the argument --shared should be provided (but no staff support will be provided for this setup)

Steps

Please follow the steps below carefully.

Step 1: Download the tunnel client

In the Tunnels page of your X4B Dashboard, locate the tunnel and select Action > Setup Tunnel. Download the customized tunnel client to your Windows server.

The download is a ZIP archive containing the .exe and its supporting files. Extract it and keep all of these files together in the same directory as the executable.

Step 2 (optional): Install a capture driver

From version 4.0.3alpha2 onward, Npcap is optional. The tunnel ZIP includes WinDivert, an alternative that provides comparable performance for most workloads. Keep the supporting files in the executable directory and Npcap should not be necessary.

Version 4.0.3alpha2 supports these adapters:

  • Npcap — used by default when installed; requires the driver to be installed.
  • WinDivert — bundled fallback adapter.
  • WinPkFilter — requires the driver to be installed and is enabled only with --encap.
Using & Installing Npcap

If you choose to use Npcap, download and install it from the Npcap downloads page. Npcap captures packets from the network adapter before the Windows networking stack processes them. WinPcap can also be used, but it offers lower performance. Install Npcap in WinPcap compatibility mode.Note: If the application cannot detect an adapter after installing Npcap, restart the server. A restart is required on some systems and is recommended after installation.

Using & Installing WinPkFilter

WinPkFilter is required only when you run the tunnel client with --encap. Download the latest driver installer from the official WinPkFilter download page, then right-click the installer and select Run as administrator. Complete the installer and accept any Windows driver prompts. Restart the server before starting the tunnel client with --encap.

License requirement: WinPkFilter is free only for personal, educational, and non-profit use. You must obtain an appropriate commercial license from NT Kernel before using it for a commercial service. Do not bundle or redistribute the driver unless your license expressly permits redistribution.

WinPkFilter can be incredibly fast on the right hardware, however hardware performance does seem to vary. Running WinPkFilter on a virtualised server is not recomm

Step 3: Run the tunnel client

Run the application as an administrator. On Windows 7 and later, right-click the executable and select Run as administrator if you are not already signed in as an administrator.

To start the client automatically at boot, add it to startup and enable Run this program as an administrator in its compatibility properties.

Conclusion & Testing

Your tunnel should now be online. From the Windows server, verify connectivity by pinging the EncapsulatedRemote address.

Running your web server, game server, or other service

Ensure that your service is bound to the 10.x.x.x tunnel interface on the server. You can find the backend tunnel IP address on the Tunnel Information page.

If your application cannot bind to a specific interface, you may need a third-party utility such as ForceBindIP.

As with Linux and BSD tunnels, binding your service to the tunnel IP ensures that traffic is sent and received through the protected IP address.

We also recommend adding an allow-all ICMPv4 rule in Windows Firewall with Advanced Security so that we can test connectivity to your backend. It should look similar to this:

ICMP Allow

NAT

If your server is behind NAT, or the local address shown in our interface is unavailable on the server, X4B WinTunnel will ask you to select an interface. It will bind to that interface's primary IP address. You must configure your router or NAT device so that GRE/IPIP traffic sent to the provided public address reaches the backend server.

Router and NAT configurations vary, so our ability to assist with these setups is limited. In some cases, placing the backend server in the router's DMZ may forward the required IP traffic to it.

Troubleshooting

Npcap was not installed in WinPcap compatibility mode

A Windows libpcap implementation is required. Install Npcap (recommended for performance) or WinPcap. When using Npcap, ensure that WinPcap compatibility mode is enabled.

Potential system overload

This usually indicates an incoming-traffic overload from the filtering network. Possible causes include an attack leak (temporary or persistent), high traffic levels to your application, or insufficient CPU capacity. The message means that the application did not have enough local buffer space for a received packet because the service had not processed traffic quickly enough.

Packet loss can occur during the first 20 seconds after the traffic load or tunnel starts, particularly while your service is warming up. X4B WinTunnel actively balances load and latency by grouping received packets according to observed traffic rates. It targets packet-group reads every 1–1.5 ms, which adds roughly 1,000 system calls per second. The client profiles traffic aggressively during its first 20 seconds and then adjusts to the observed rate. If traffic peaks adversely affect your service, consider adding filtering rules.

High System CPU Usage

Higher-than-expected System CPU usage can indicate a moderately high rate of new connections. Windows is less efficient at connection tracking than Linux. To avoid load peaks, we recommend limiting new connections to fewer than 5,000 per second.

The application stops processing when text is selected

Depending on the console client and buffer size, selecting text can block the console and stop the application from processing data.

Solution: Avoid selecting text in the console window, and do not leave a console window with text selected.

High CPU Usage

If the server is at 100% CPU usage, latency may increase. The client transfers larger packet groups to minimise packet loss where possible. It runs at high priority, but so do many Windows system processes.

Too fast content production

The backend is producing content faster than X4B WinTunnel can transmit it over the internet. This is uncommon, as the client should exceed typical transmission rates. In the example above, the testing server required 4.8 Gbps (440k packets per second) to reach this limit.

CPU Stolen

Monitor other applications, particularly Windows system processes, that consume CPU. They can cause latency spikes. This is especially important for X4B WinTunnel because excess packets are not buffered by the application. Also avoid disk paging or memory compression caused by memory pressure from other applications.

Performance & Expectations

If you can run your application on either Windows or Linux, Linux networking may provide better performance, even when the application requires Wine or another compatibility layer.

In our testing, Windows Server 2022 reaches approximately 140,000 packets per second per reasonably powerful CPU core. On a single-core system, the client achieved roughly 140,000 packets per core per second, with up to 40,000 new connections per second due to Windows limitations. A four-vCPU AMD VPS reached 480,000 packets per second in a version 4.0.0alpha5 benchmark. On this hardware, System Interrupts (the network driver and Npcap) consumed the most CPU, followed closely by the client.

The console application can make full use of up to three CPU cores. System interrupts and processes can also consume resources on other cores, so a multi-core system is beneficial.

Your workload and hardware will differ from our test environment, so actual performance will vary.