Introduction
Important We are currently in the process of preparing v4.0.0 for stable release. v4 (currently available as "latest unstable" in your dashboard) includes substantially better performance particularly on multi-core systems. Performance is now largely limited by the Windows network stack and not the application. If you need the performance we recommend considering using v4.0.0 for new installations.
Microsoft Windows does not natively support Generic Routing Encapsulation (GRE) or IP-in-IP (IPIP) tunnels. However with the assistance of a userland client (available to all X4B clients) these features can be emulated and it therefore possible to fully encapsulate (preserve backend IP) services running on the Microsoft Windows platform.
This software which is provided through the Dashboard of your X4B Account, from the Tunnel Page Action > Setup will automatically configure a GRE, IP-in-IP (IPIP).
This Guide is up-to-date as of software version v4.0.x
Notes
- The application requires that Windows Firewall is enabled on the server
- Ensure all your services are whitelisted in your firewall.
- Tested on Windows Server 2022 (primary target), 2018 & Windows 11
- Supports both IP-in-IP and GRE tunnels
- Requires an Ethernet (802.1 or 802.1Q) Network Connection
- The tunnel software supports multiple tunnels in a single instance. Running multiple instances of the tunnel software is not supported.
Steps
Please follow the steps below carefully.
Step 1
Download and install Npcap from the Npcap Downloads page. Npcap is a Driver for capturing packets from the Network card before the Operating system's network stack processes them. WinPCAP can also be used. Npcap must be installed installed in WinPCAP compatibility mode.
Note: If you have trouble detecting adapters then consider restarting your system after installing Npcap. On some systems this is required and may be advisable on all systems.
Step 2
From v4.0.0 (currently the unstable release) this step must be skipped. If you are upgrading from 3.x.x to 4.x.x you must uninstall the TAP driver before upgrading (no TAP adapters should be in your Network Connections list). If you are upgrading from earlier version of 4.x.x allow the installer to download a new wintun.dll by removing any you have downloaded.
Download and install OpenVPN's TUN/TAP Driver. If you have already installed OpenVPN you should already have the driver installed.
Only the TUN/TAP driver is required to be installed, OpenVPN is not required. We recommend installing the latest version of the driver (latest tested 9.24.2). A list of all versions can be found here.
When installing the TUN/TAP driver select to install the supplied utilities when asked. The screen may look like the above, note that both the Adapter (driver) and TAP Utilities are selected.
If asked during setup, you must agree to trust the driver developed by OpenVPN. OpenVPN developed of the TUN/TAP driver being installed.
Step 3
From your X4B services Tunnels page, find your tunnel and navigate to Action > Setup.
From here you can download the customized tunnel application to your Windows server.
Step 4
Run this application as Administrator. On Windows 7 or greater this can be done via Right Click > Run as Administrator if you are not logged in as the Administrator user.
You may also wish to add this executable to your startup to run on boot. In that case ensure that you have "Run as Administrator" enabled in the compatibility properties.
Conclusion & Testing
Your tunnel should now be online. You should now be able to ping the EncapsulatedRemote address from your Windows Server.
Running the Web Server / Game Server / Service
Ensure that your game server, web server or service is correctly bound to the 10.x.x.x interface on your PC. The IP address for your backend tunnel can be found in the Tunnel Information page.
If your game server is unable to bind to a specific interface you may need to utilize a 3rd party utility to do so (e.g ForceBindIP)
Like Tunnels running on Linux or BSD ensure your game server or service is bound to the tunnel IP address (running on 10.x.x.x). This will ensure all communication is made through the protected IP, and received through the protected IP.
We also recommend adding a ICMPv4 allow all rule in "Windows Firewall with Advanced Security" to allow us to ping your backend. This will look something like:
NAT
If you are behind NAT, or the Local address provided in our interface is not found on the server X4B WinTunnel will ask you to provide an interface and the application will bind to the main IP of that interface. It is your responsibility to ensure that GRE/IP-in-IP traffic sent to the publicly routable address provided in the interface is delivered to your backend.
We can not provide you with much assistance with these setups as each router / NAT device is different. You may however be able to set your backend server to the DMZ and this may forward the IP traffic to your backend server.
Troubleshooting
Did not install npcap (or install in WinPCAP compatibility mode)
A Windows libpcap implementation must be installed on this system. Either npcap (recommended for performance) or winpcap should be installed.
Potential system overload
Typically indicative of an overload of incoming traffic from the filtering network. This may be attack leak (temporary or persistent), high traffic levels to your application or insufficient CPU. This message basically means there wasnt enough space to store the packet we received locally because your application has not had the time / resources to receive it yet.
Packet loss during the first 20 seconds after starting the traffic load or tunnel may ocur if warm starting your service. X4BWintunnel employs active latency management to optimise load vs latency. Packets are grouped for receive based off typical traffic rates with the aim of acheiving packet group reads every 1 - 1.5ms (overheads of 1,000 syscalls per second). Traffic rates are profiled aggressively in the first 20 seconds after startup and adjust based on observed traffic rates. It may be a good idea to add additional filtering rules if making use of Windows Tunneling in an application where you are adversely affected by traffic peaks.
High System CPU Usage
If you are seeing Higher than expected System CPU usage this may mean you are receiving a moderately high number of new connections per second. Windows is not as performant as linux in this area. We particularly recommend limiting the rate of new connections accepted to less than 5,000/s to prevent load peaks with connection tracking in Windows.
Application stop processing when text is selected
Depending on your console client and buffer sizes selecting text may cause the Console to block. This will stop data processing within the application.
Solution take care not to select text in the console window. And definately do not leave windows with text selected.
High CPU Usage
If your server is sitting at 100% CPU latency may suffer. We will transfer larger groups of packets to try and prevent packet loss as best we can. Our application runs with High Priority status, however so do many system processes.
Too fast content production
Content served by your backend exceeded the ability of x4bwintunnel to transmit over the internet. This is rare as x4bwintunnel should be capable of exceeding all reasonable transmission rates. In the test above sending at 4.8Gbps (440k PPS) was required to reach the limits on our testing server.
CPU Stolen
Be wary of other applications particularly system applications on your server consuming CPU. This can cause latency spikes. While this is true for any application it is particularly true for x4bwintunnel as it overflows of packets are not buffered in the application. Further any disk paging or compression due to memory pressure from other applications must also be avoided.
Performance & Expectations
If you have the choice for your application on running it on Windows, or on Linux you may find that Linux networking is higher performing. Even if your application must be run with Wine or another emulation layer.
In our testing Windows Server 2022 maxes out at rougly 140k pps per reasonably high powered core. With our application being able to acheive roughly 140k packets per core per second (but no more than 40k new connections per second due to Windows performance) on a single core system and a 480k PPS (benchmark of v4.0.0alpha5) on a 4 VCPU AMD VPS. The largest user of CPU in this situation is "System Interrupts" (network driver & npcap) followed closely by our application on this hardware.
The console application is able to make full use of up to 3 cores. System Interupts and System processes are overheads that can occur on different cores as well. This application will therefore benifit from a multi-core system.
Of course you will have an application to run with its own resource requirements and different hardware to us so YMMV.
