Home › Forums › Discussions › Support › Issue with Wiresock Client when subnet on remote network conflicts
- This topic has 5 replies, 2 voices, and was last updated 4 months, 2 weeks ago by mackid1993.
-
AuthorPosts
-
August 6, 2024 at 12:06 am #13801
I’m running into an issue with Wiresock where I don’t have any issues with the official Wireguard client. Just curious if there is a workaround for this?
So my local network at home is 192.168.2.x and when I’m at work the network I connect to is also 192.168.2.x which means when I try to access devices on my home network from work such as my Unraid server and 192.168.2.40 I can’t because of the conflict, however I don’t have any issues with the official Wireguard client.
Are there any workarounds for this? I know it’s not ideal.
Thanks!!
August 6, 2024 at 12:31 am #13802Could you share your Wireguard configuration, excluding the keys and server endpoint? Additionally, I have a question: Are you using WireSock in transparent mode or virtual adapter mode (-lac)?
August 6, 2024 at 12:42 am #13803I’m actually using Wiresock UI to connect. Everything is pretty much default. This is my config.
[Interface]
#
PrivateKey=
Address=10.253.0.5/32DNS=192.168.2.1
[Peer]
PresharedKey=
PublicKey=Endpoint=mydomain.com:51820
AllowedIPs=0.0.0.0/24August 6, 2024 at 1:14 am #13804I ended up changing my subnet at home to 192.168.200.X to prevent conflicts like this as it’s unlikely any network I’m connecting on will use such an obscure subnet. I’m curious if there is a workaround for this just for my own knowledge though.
August 6, 2024 at 9:44 am #13805Do you have Virtual Adapter mode enabled in the WireSockUI settings?
I’m also a bit confused about the
AllowedIPs
value. In this context,0.0.0.0/24
represents the IP range from0.0.0.0
to0.0.0.255
. However, this is typically not a useful or valid range because0.0.0.0
is a non-routable meta-address used to designate an invalid, unknown, or non-applicable target (often referred to as the default route).Usually,
AllowedIPs
would be set to a range of IPs that are meaningful for the network, such as192.168.1.0/24
to route a local network, or0.0.0.0/0
to route all traffic through the VPN. Therefore,0.0.0.0/24
is likely a mistake and should be corrected to reflect the intended IP range.August 6, 2024 at 3:13 pm #13807You are completely right, I was messing with my config and when I changed it back I accidentally put /24 instead of /0. It should be:
[Interface]
#
PrivateKey=
Address=10.253.0.5/32DNS=192.168.X.X
[Peer]
PresharedKey=
PublicKey=Endpoint=mydomain.com:51820
AllowedIPs=0.0.0.0/0I’m not using virtual adapter mode. I’m back at work today and changing my subnet at home to 192.168.200.0 seemed to do what I needed.
-
AuthorPosts
- You must be logged in to reply to this topic.