[Vadim Smirnov]

I’m afraid something is wrong with your Dante server configuration. Unfortunately, it is difficult to guess and advise.

[Vadim Smirnov]

Check if you allowed configured UDP port range on Dante server machine, e.g. for 40000-45000 range it can be done by the command below:

iptables -I INPUT -p udp --dport 40000:45000 -j ACCEPT

[Vadim Smirnov]

According to the wiresock log, the authentication and UDP ASSOCIATE commands succeeded, but the handshake packet did not reach its destination. Most likely, it was blocked by the firewall (iptables or VPS provider). Please check this post for configuration details. They are specific to the Oracle cloud, but should be close to any other VPS.

[Vadim Smirnov]

Unfortunately, the SOCKS5 proxy provided by the SSH client does not support UDP and you cannot use it to forward the handshake. You need to set up a SOCKS5 UDP-enabled proxy (Dante) on the remote machine to use this option.

[Vadim Smirnov]

Hmm, the main question is when and how this client ID is assigned. If this is agreed before the start of the Wireguard session and already presented in the handshake packet, then this would require reverse engineering of the protocol used by Warp to authenticate and assign a client ID.

[Vadim Smirnov]

I think it’s doable, it just needs a little research. If you have already done this, could you share the details?

[Vadim Smirnov]

Your system can use more than one network adapter at the same time. However, to determine the default Internet interface, you can use GetBestInterface and specify some well-known IP address as a parameter, such as 1.1.1.1.

[Vadim Smirnov]

As I mentioned above, I once re-implemented NAT as a C++/CLI class library having the interface below. However, it’s a little complicated for the sample and I also need to preserve some sugar cubes for the customers.

// natcl.h

#pragma once

using namespace System;
using namespace Collections::Generic;
using namespace Threading;
using namespace msclr::interop;

namespace nat_managed_lib
{
public ref class managed_network_adapter_info sealed
{
String^ adapter_name_;
String^ friendly_name_;
List<String^>^ ip_addresses_;

public:
property String^ AdapterName
{
String^ get() { return adapter_name_; }
void set(String^ value) { adapter_name_ = value; }
}

property String^ FriendlyName
{
String^ get() { return friendly_name_; }
void set(String^ value) { friendly_name_ = value; }
}

property List<String^>^ IpAddresses
{
List<String^>^ get() { return ip_addresses_; }
void set(List<String^>^ value) { ip_addresses_ = value; }
}
};

public ref class nat_wrapper sealed
{
public:
event EventHandler^ AdaptersListChangeEvent;

private:
ManualResetEvent^ adapters_list_change_notify_event_;
Thread^ adapter_list_change_notify_thread_;
volatile bool is_adapter_list_change_thread_active_ = true;

bool set_adapter_list_change_event();
void adapter_list_change_thread();

native::nat_unmanaged* native_nat_provider_;

public:
explicit nat_wrapper(String^ device_name);
!nat_wrapper();
~nat_wrapper();

List<managed_network_adapter_info^>^ get_network_adapters();

Boolean set_nat_parameters(
// provider interface name
String^ provider,
// client interface name
String^ client,
// provider IP address to be used for NAT (adapter may have multiply IP addresses)
String^ nat_ip,
// DNS IP address for DNS forwarding
String^ dns_ip,
// Enable DNS forwarding (redirect DNS requests to the IP above). Otherwise client provided IP is used for DNS.
Boolean dns_forwarding
);

Boolean start_nat();
Boolean stop_nat();
Boolean is_started();

Boolean is_ip_routing_dynamic_success();

void re_initialize();

Boolean block_client_ip_address(String^ ip_address);
Boolean block_client_mac_address(String^ mac_address);
};
}

[Vadim Smirnov]

Unfortunately, no. Personally, I prefer C/C++ for protocol header manipulation, and when I had a need for NAT in a C# project, I implemented it as a C++/CLI class library.

[Vadim Smirnov]

I would start with port forwarding on your router and firewall configuration on the server. It looks like the handshake packet can’t get through.

[Vadim Smirnov]

If you had problems with v1.2.4 and don’t have them with v.1.2.5, then it was probably the same bug reported here.

[Vadim Smirnov]

Using a VPN may affect your ping, the details depend on the location of the VPN and the game server. Sometimes you can win, sometimes you can lose. Wiresock software itself has very low latency, unless you use verbose logging, don’t forget that I/O operations are always expensive.

[Vadim Smirnov]

Hmm, are you sure the handshake was successful? If you’re using stock Wireguard for Windows on the client side, what tunnel statistics do you see?

[Vadim Smirnov]

I assume you have installed official WireGuard for Windows and Wiresock VPN Gateway and created the Wireguard tunnel using wg-quick-config. I also assume that port forwarding is configured on your router, and you can connect to your Wireguard server using the client application. Correct?

Please check, can you ping the Wireguard server virtual IP address from the client? It should normally work even without Wiresock VPN Gateway service running, which is only responsible for forwarding client connections to the external network.

It could also be helpful if you could share server and client configuration files (just strip endpoint and key information out).

[Vadim Smirnov]

Thanks for pointing this out. I’ve resolved the issue in v.1.2.5, please give it a try.

[Author]

Posts