-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ISSUE: ZeroTier can't be contacted through TunnlTo/WireSock #158
Comments
There is the option of setting up zerotier as a client on your VPN server and configuring some routes to negate having to use 2 clients completely. I've not used Zerotier but I'll have a look over the weekend (if I get a chance to see if I can replicate the issue) |
The problem is that is there's an assumption I'm in control of the VPN server. Unfortunately, I'm not. |
@Permanently this appears to be an issue at the WireSock level. If it's still a problem I suggest making a thread over on the Wiresock support forums. |
Describe the issue
Whenever connected through TunnlTo, 95% of the time I can't communicate through ZeroTier. I typically get a response of "Connection timeout". Split-tunneling doesn't seem to make a difference, not split-tunneling the subnet. Pinging works, but not connections like SSH.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expected to be able to establish connections on my ZeroTier subnet.
Tested on official WireGuard client
Just tested on WireGuard (without kill-switch enabled), and it worked. It also worked when using Mullvad's client.
Tested on different VPN servers
Yes.
Screenshots and GIF's
N/A (unless if "connection timed out" is useful?)
Tunnel Config
Provide a screenshot of your tunnel config with tunnel name, private key, public key, pre-shared key and endpoint removed.
Logs
Here you go. I made a connection to a ZeroTier IP, and it was not listed at all in logs. See here.
Starting WireSock directly
If possible, follow the instructions below and comment on the outcome:
Same issue. Nothing in logs, and no change in behaviour.
The text was updated successfully, but these errors were encountered: