- This topic has 2 replies, 2 voices, and was last updated 1 week, 6 days ago by
.
-
Posts
-
Hello. I am attempting to pass Wireguard traffic through a Shadowsocks tunnel that has the entry point on the same machine. Having seen other topics on related attempts, I set the endpoint IP to be the LAN IP of this PC instead of localhost. Configured this way, Wiresock actually attempts to connect and sends a handshake but does not manage to establish a connection.
Examination with Wireshark confirms that the Shadowsocks client does in fact send the handshake response to Wiresock so the problem seems to be related to it. Moreover, a similar configuration with the vanilla Wireguard client works fine, however, for regular usage it’s insufficient because it doesn’t have split tunneling functionality.
Is this still the “can’t connect to localhost” problem or something else?
As a sidenote, when I attempt to connect to the Wireguard server directly (used to work, now doesn’t, presumably protocol gets blocked), Wiresock logs having received the handshake response and (according to the UI button) seems to believe the connection to be established, but when observing with Wireshark during these tests, I’m not seeing any incoming WG traffic whatsoever. Which is the opposite of the experience described in the original post
Currently, localhost connections are not supported because they were not prioritized as essential functionality. While the initial handshake packet is sent over Windows sockets, the subsequent packets are injected directly into the NDIS layer, causing them to be misdirected in case of localhost server. I plan to address this and add localhost support in future releases.
- You must be logged in to reply to this topic.