Jump to content
TorGuard

Leaderboard


Popular Content

Showing content with the highest reputation since 01/18/2019 in all areas

  1. 1 point
    Good day. I guess this a Feature Request? I think the port-reservation website should let us pick a "pool" (a city) and then suggest a server automatically; even better if it looks at which port we want and then picks a server that doesn't have that port already reserved.Here is why I'd like this: When you connect to a "pool" the VPN client picks a server randomly from that pool. This means that on average, every server in the pool will have the same load - the same number of users using it. However, if 1000 people have reserved ports on Server A, then we can expect that particular server to have, on a bad day, 1000 more people using it, since TorGuard graciously lets us pick which server we connect to (you can "pin" a server in the client, or even multiple ones if you want.) So if I were to want to pick a server for my own port forwards, I'd want the server with the least amount of people already reserving ports on it Because that particular server should be the one with the least load, on average. As it is, I can't really pick any server over any another in the same pool, since they all ping about the same - I can't tell which has the least load. This should also benefit TorGuard, helping to distribute load across servers more evenly. Regards,
  2. 1 point
    Anyconnect worked for me a month ago. The speed was slow, but worked.
  3. 1 point
    Has this ever been resolved? Unless I setup port forwarding to every potential server for a particular location I don't see an easy way to setup port forwarding. It would be very helpful if we could setup port forwarding based on LOCATION instead of IP ADDRESS.
  4. 1 point
    This would be awesome 👍 and i hope developer add "tls -crypt " to all port not only port 53
  5. 1 point
    Application specific option. Apparently this was in development....
  6. 1 point
    Yes but didnt get anywhere however after extensive troubleshooting, this is a digital signature issue with ver 1809 of Windows 10, I went back to 1803 and its OK
  7. 1 point
    I would suggest you open a support ticket here https://torguard.net/submitticket.php and explain your problem. Thanks
  8. 1 point
    Hi, Please try using different ports switching between TCP and UDP, if that fails, enable stealth proxy under Settings and recheck to see if that connects. Regards
  9. 1 point
    support answer was "To be honest, there's nothing to fix here, a WAIT status doesn't indicate a problem with the client, it normally means for some reason you cannot reach the server to connect or your ISP regularly filters UDP on specific ports - does this happen with all servers/ports or just the one?" If it does happen to you then try to use other ports, i will keep in touch with support if its happening again in the future.
  10. 1 point
    This was an issue a year or two ago when I used TorGuard and it still seems to be an issue now. There's nothing you can do to fix it. TorGuard's server config is botched in such a way that you can't negotiate with it. I'll use connecting to UDP port 53 as an example. These are the listed ciphers. cipher AES-256-CBC* cipher AES-128-GCM cipher AES-256-GCM cipher AES-128-CBC cipher BF-CBC A proper OpenVPN server would use cipher AES-256-CBC and then ncp-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC:BF-CBC. An older OpenVPN client (pre 2.4) would pass cipher AES-256-CBC in their client config. These don't support cipher negotiation, so OpenVPN 2.3 or less, or Open 2.4+ with cipher negotiation disabled, would use AES-256-CBC. But once cipher negotiation is in play (ncp), the cipher config is overridden in favor of ncp-ciphers. An OpenVPN client could pass a list in order of preference and as long as the server accepts them, the first one the server supports gets used. I build my own OpenVPN servers so I have worked with this. An example in my case, I only want to support the AES-256-GCM cipher as I only let the latest clients connect. I set cipher AES-256-CBC as is proper, then ncp-ciphers AES-256-GCM. Since any client with OpenVPN 2.4 by default will use negotiation, and I only list AES-256-GCM, the client absolutely must support and use AES-256-GCM. Technically, they could disable ncp client side and connect with AES-256-CBC (and a 2.3 client might be able to connect, but then I use 2.4+ features so they wouldn't work anyway). I could allow additional ciphers server side by setting ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC. Now, a 2.4+ client with ncp enabled will default to AES-256-GCM, but they can set ncp-ciphers in the client config to force any one of those 4. TorGuard will need to fix their servers to remedy this. There is nothing you can do on your end to force AES-256-GCM properly. I posted here awhile ago about this issue and it looks like they never fixed it. It would also be nice if they would allow SHA-512 on their tls-crypt servers, but at least according to the specs page that no configuration supports that, as opposed to the specs page stating all listed ciphers are valid on 2.4+ despite this being provably false due to their configuration error. On both ASUS Merlin and pfSense, there is no setting that allows me to get AES-256-GCM without the local/remote error and issues that follow from there. So I've just disabled ncp and used AES-256-CBC.
  11. 1 point
    Thanks for your suggestions, we are working to improve port forwards and will take note Regards
  12. 1 point
    Uk Manchester other providers have manchester
  13. 0 points
    Agreed. I hunted around for a while until I found a server in my preferred region with decent throughput, then set up port forwards manually. I'd be happy for the option of a longer connection setup time but dynamically created port forwards. As it is, if my chosen server is heavily loaded, I stay on it (increasing the problem of load) - because manually creating port forwards on another server is quite long-winded. 'Camping' port forward allocations on multiple servers, so I can hop around depending on load, is something I've not done because I think it's antisocial. The port forwarding features and design needs a bit of TLC
×