ANSWERED Can't connect to myself through forwarded port

[tduiwz 0]

On Windows PC running Eddie/WireGuard, I can connect to the forwarded port from any computer except the PC running the VPN software. This is rather inconvenient since I can't easily test the connections from the same computer, or have two services on the same computer communicate with each other over the VPN tunnel (e.g. two torrent clients, both with forwarded ports)

I tried a variety of tools to test, but for example, in one terminal on the PC
$ netcat -l -p [FORWARDED PORT]

then in another terminal:
$ netcat [VPN exit IP] [FORWARDED PORT]

the TCP connection fails.

but if I run the exact same command to connect to the server from any other computer, the connection is successful

Edited ... by tduiwz

[Staff 10608]

8 hours ago, tduiwz said:

On Windows PC running Eddie/WireGuard, I can connect to the forwarded port from any computer except the PC running the VPN software.

Hello!

This is expected. It is also unavoidable: consider that inside the VPN server packets originated by your node when it is a source pass through public entry-IP address -> virtual network -> exit-IP address -> final destination. When your node is a destination from external source, packets reaching the exit-IP address are forwarded to the virtual network, encrypted and sent to your VPN IP address

So, if your VPN IP address is both source and destination and the packet should simultaneously get out of and enter the exit-IP address etc., what happens? You create a network loop because there's no self-routing logic for your packet between entry -> VPN -> exit -> exit again -> VPN and finally entry addresses, and the packet is lost. The VPN is not designed as a loopback device, so to speak. Use your system loopback interface to have the system communicate with itself as a simultaneous source and destination.
 

8 hours ago, tduiwz said:

have two services on the same computer communicate with each other over the VPN tunnel

This is a different issue and this behavior is explicitly blocked in the infrastructure for security reasons. It is a valuable VPN feature (allowing sharing resources, sharing the same network) in virtual networks where all the nodes are known and trusted, but it is dangerous in a public VPN service or in general where nodes can not be trusted by each other. The only shared resource in the VPN is the DNS server. No node can reach another node inside the VPN itself.

Kind regards
 

[tduiwz 0]

I see. Thanks for the clarification.