Issue with UDP mode: the client attempts to reach server using its private IP instead of the public one

[eerffree]

Hello,

Thanks for the great work. It is very valuable to have a vpn that will work on pretty any hotspot / public network, bypassing the restrictions!

I'm interested in installing my own Linux server but I'm facing a problem:
Everything is ok but UDP.

• It works well when I install the server via the vpnhood access web service but if I install it manually, UDP isn't working.

• the two setups are tested under same conditions: with same network at server and client, same client, server installed on the same host. Firewall is disabled both side.
  -All UDP ports are opened on the server and redirected from its public IP to the local one. the vpn server binds on the local address.

• tcpdump at server shows no incoming udp packet when the server is manually installed. There is the expected udp traffic when installed via vpnhood access.

• With Wireshark and the windows client I can see the UDP packets being sent to the local IP of the server (10.0.0.8) what obviously explains why no packet actually reach the server.

• Wireshark confirms that using an access token from the httpaccess manager, the destitnation IP for the UDP pack is the server's public address.

Comparing the tokens manually generated and from the web service, doesn't give hint and I can't find anything in docs. Maybe the config downloaded by server from the httAccesManager has something I should add to appsetting.json?

Thanks for your help!

[trudyhood]

Thank you for choosing VpnHood!

Based on your description, I believe I understand the issue you're encountering. Could you please confirm if your concern relates to the UdpChannel? Specifically, are you expecting to observe encrypted UDP packets that encapsulate the client's actual packets?

Additionally, does your Server listening local IP address differ from your public IP address? This could occur if you're using an alternative gateway, router or a service like AWS Elastic IP, where the IP address your server listens on is actually unreachable, and traffic is being forwarded from a different IP address. Is this accurate?

[eerffree]

Thanks for your quick answer, I'm glad you alredy have an idea about what's wrong here!

Could you please confirm if your concern relates to the UdpChannel? Specifically, are you expecting to observe encrypted UDP packets that encapsulate the client's actual packets?

Yes, my concern is about UDP channel, when allowing UDP mode on client.
I'm expecting to see an udp "connection" between my client IP and the server, at the server port declared as the UDP end point in appsetting.json. I'm also expecting to see the proxied UDP "connections" between the server and the destination hosts (dns, etc.). That's exactly what happens when configuring with http access manager. With manual config, the client sends the UDP packet to the right port but not to the public IP.

does your Server listening local IP address differ from your public IP address?
My server is an Oracle Cloud Instance. From the server I can see only the local network interface (10.0.0.x). The trafic to/from the public IP is allowed and forwarded to thus interface. But, the VPN binds only to the local interface, not the one with public address.

I know the port are open and reachable because I've tested them with netcat and other applications that require to listen to public ports in a similar way are working well. Moreover, everything work as expected (according to the doc) when configuring from the website.

[trudyhood]

OK, now we are trying to change the protocol the servers declare its UDP port. Let's continue this discussion after this update.
Please keep in touch with us.

[eerffree]

Ok Trudy, thank you.
Do you happen to know why it works well with the httAccessManager?
Since the same setup (same binaries, same networks, etc.) works with httpAccessManager but not manually, it looks like something is missing in my config. Does the manager provide some params that are not exposed in appsetting.json, so we can't do the same manually?
Thanks

[trudyhood]

Double Check UdpEndPoints!
After the next release, I will come back to you. It must work.

[eerffree]

Already triple checked! :-) But maybe I didn't see something. By the way, I've tried to use the remoteConfig json dumped from httAccesManager when running "vhserver start", the UdpEndPoints are configured just as I did, and it didn't work. Also I haven't many options for UdpEndPoints since I can bind only to one interface.
Let's wait for the next release!

[trudyhood]

OK, we have released version 470. Please update both the server and client and let us know the problem. If the problem continues, I am here for you until the issue has been solved.

[eerffree]

Works well! Good job! Thank You.
I now enjoy the UDP for app that make use of it. By the way, the TCP mode is already good. The optimization with TcpDatagramChannel is a good thing.