Jump to content
TorGuard

wireguard config validity changes


19807409
 Share

Recommended Posts

I noticed that since around a week, active connections are inactive after 24 hours despite being connected. On port forwarded IP's it actually makes no sense as internal ip stays the same and does not change, therefore it seems to still be reserved as activating over api makes it work again without even restarting. On shared IP's, if they expire, one needs to change also vpn IP, solution here is to run a script which reactivates it once in 24 hours.

@Support , is this something that happened by accident or will it stay that way? Asking, because some time ago torguard disabled expiration on connected clients => if you are connected and do not disconnect, configs do not expire, or better said, they expire 24 hours after you have been disconnected.

In any case, my scripts activating required IP's do run every few minutes and I have no issues about it, just wasn't sure if that change is an accident or a planned one.

Link to comment
Share on other sites

54 minutes ago, 19807409 said:

I noticed that since around a week, active connections are inactive after 24 hours despite being connected. On port forwarded IP's it actually makes no sense as internal ip stays the same and does not change, therefore it seems to still be reserved as activating over api makes it work again without even restarting. On shared IP's, if they expire, one needs to change also vpn IP, solution here is to run a script which reactivates it once in 24 hours.

@Support , is this something that happened by accident or will it stay that way? Asking, because some time ago torguard disabled expiration on connected clients => if you are connected and do not disconnect, configs do not expire, or better said, they expire 24 hours after you have been disconnected.

In any case, my scripts activating required IP's do run every few minutes and I have no issues about it, just wasn't sure if that change is an accident or a planned one.

 

Hey, it should not be the case - the time limit should have been removed - does it happen with any server you try or can you maybe let me know the location or a specific IP you saw this so we can check? thanks

Regards

Link to comment
Share on other sites

1 hour ago, Support said:

does it happen with any server you try or can you maybe let me know the location or a specific IP you saw this so we can check

you are welcome, for now on all tested, shared and 10Gbit server, if it helps I can write ip's but I guess it is global issue. I think I first time saw it happening a week ago but as I do run update script on another server my eye did not catch it.

You can try it, connect with wireguard (original client) and let it connected, exactly after 24 hours you will end up with no internet (connection is still there), for port-forwarding ip's it is less of an issue as temp workaround would be simply curl -k ..., where for non port-forwarded ip's internal ip changes and by that one needs to edit vpn ip before connecting, I guess some will have issues with staying connected that way if they do not use additional scripts and to do it by hand is nasty.

Link to comment
Share on other sites

I have had a Wireguard Config Running in my router and it has not had any disconnection issues recently. Within the past 14 days i have changed the config manually 2 times but that was only because i wanted to change the IP! - I have not experienced it disconnecting after 24 hours or becoming Invalid. I have not needed to Generate New config Files or anything except in a situation where i want to change the IP, Manually. So at the very least Canada Servers are not having the issue you are describing. As for other servers i have not Recently tried.

Link to comment
Share on other sites

7 hours ago, 19807409 said:

you are welcome, for now on all tested, shared and 10Gbit server, if it helps I can write ip's but I guess it is global issue. I think I first time saw it happening a week ago but as I do run update script on another server my eye did not catch it.

You can try it, connect with wireguard (original client) and let it connected, exactly after 24 hours you will end up with no internet (connection is still there), for port-forwarding ip's it is less of an issue as temp workaround would be simply curl -k ..., where for non port-forwarded ip's internal ip changes and by that one needs to edit vpn ip before connecting, I guess some will have issues with staying connected that way if they do not use additional scripts and to do it by hand is nasty.

 

Thanks, if you can list atleast 1 IP, we can check it out and resolve so we can check the config and see what's going on with that, maybe our dead peer service cleanup is running at the wrong time on some servers.

Regards

Link to comment
Share on other sites

5 hours ago, Dom1no said:

I have had a Wireguard Config Running in my router and it has not had any disconnection issues recently. Within the past 14 days i have changed the config manually 2 times but that was only because i wanted to change the IP! - I have not experienced it disconnecting after 24 hours or becoming Invalid. I have not needed to Generate New config Files or anything except in a situation where i want to change the IP, Manually. So at the very least Canada Servers are not having the issue you are describing. As for other servers i have not Recently tried.

 

Thanks for the info, i believe it may just be some servers where the config for some reason has not been updated but we will check it out.

Link to comment
Share on other sites

6 hours ago, Dom1no said:

I have had a Wireguard Config Running in my router and it has not had any disconnection issues recently.

you do not write how exactly you use it, especially if you use openwrt and my demo scripts, then it updates and there is no need to do it manually.

6 hours ago, Dom1no said:

So at the very least Canada Servers are not having the issue you are describing

I did not test Canada Servers this week, one 10Gbit server and one shared server, the issue occured same day on 10Gbit server and on shared server.

1 hour ago, Support said:

Thanks for the info, i believe it may just be some servers where the config for some reason has not been updated but we will check it out.

Well, check UK's 10Gbit server, there it happens.

Link to comment
Share on other sites

10 hours ago, 19807409 said:

you do not write how exactly you use it, especially if you use openwrt and my demo scripts, then it updates and there is no need to do it manually.

I did not test Canada Servers this week, one 10Gbit server and one shared server, the issue occured same day on 10Gbit server and on shared server.

Well, check UK's 10Gbit server, there it happens.


I Generate the Config i place it into the router and i hit connect and it stays Connected/Valid. No idea about any special demo scripts and all that jazz, I don't use any special scripts. I just generate it and insert it and it works, OpenWRT.

I think like Support mentioned it's likely only some servers having this issue possibly unless it's some sort of issue with your scripts or whatever setup your using, Try Canada Servers and if you still have the problem then it may be on your end.

Link to comment
Share on other sites

@Support right now I see it live, connected but connection got invalidated, server with a public key:

ydMhcNakO+DfbCOd28jBr1PlouUZz5tscwkTujQUiSw=

it is a shared server.

3 minutes ago, Dom1no said:

I Generate the Config i place it into the router and i hit connect and it stays connected. No idea about any special demo scripts and all that jazz, I don't use any special scripts. I just generate it and insert it and it works, OpenWRT

It is not about fancy, when torguard released wireguard, nobody knew how to use it without torguard client, by using and testing this has been created where back then a connection got invalidated after 10 minutes (just like the issue I describe above with 24 hours) and back then for ability to keep it active, a service or cronjob was used to call the api. And yeah, I wrote it specifically for openwrt back then. This is what I meant with scripts, as those are/were used and is still working.

6 minutes ago, Dom1no said:

I think like Support mentioned it's likely only some servers having this issue possibly unless it's some sort of issue with your scripts or whatever setup your using, Try Canada Servers and if you still have the problem then it may be on your end.

Well, I have no problem in staying connected, it is more the opposite, TorGuard might have a problem if there is something that does not work as supposed, which was the reason to report it here. It is not just one server, randomly picked 2 servers, one shared one premium, both having the issue and even if Canada has no issues, it still does not fix other servers having that issue. If that is based on their side and as support said there might be some issue with peer cleanup script which I do believe is the case. It has nothing to do with scripts which I use or do not use, connection should be valid if not disconnected.

I will run a test for Canada so that I can tell you if canada servers are affected, however, it takes 24 hours after connection, meaning the results will be after tomorrow, of course unless torguard fixes the issue earlier, all IP's I connected to in last 7 days have same issue on multiple different devices, the issue is for sure not on user's side.

Link to comment
Share on other sites

I just Generated UK 10GBIT Config , I'll toss it in my router and see if it is still working in 24 hours. Will post here Tmrw with Results.

  • Thanks 1
Link to comment
Share on other sites

12 minutes ago, Dom1no said:

I just Generated UK 10GBIT Config , I'll toss it in my router and see if it is still working in 24 hours. Will post here Tmrw with Results.

I did not mean to waste your time ;), but thanks for testing. Can you also write about how you created the config, with a config generator on your account page or with the api?

Sometime in about 5-8 hours 24 hours will be over for my connection with UK's 10Gbit server and I will see if it happens today again, on a shared server just few minutes ago it happened, if you want to test that shared one too which invalidated few minutes ago, here is the IP: 37.120.155.10

EDIT: @Support If this is intentional or not, maybe it would be quite practical if api call would deliver epoch timestamp of the end of validity (or even begin, better the end as users do not need to get confused about when it expires in case of changes on your side).

Link to comment
Share on other sites

3 minutes ago, 19807409 said:

I did not mean to waste your time ;), but thanks for testing. Can you also write about how you created the config, with a config generator on your account page or with the api?

Sometime in about 5-8 hours 24 hours will be over for my connection with UK's 10Gbit server and I will see if it happens today again, on a shared server just few minutes ago it happened, if you want to test that shared one too which invalidated few minutes ago, here is the IP: 37.120.155.10


I just use the Config Generated In the My Account Area on the website , I don't use any api scripts or anything. I will leave the UK Config in my router for about 25 hours and will post the results tmrw - then i will try testing the shared server IP you listed.

Link to comment
Share on other sites

Thanks for clarification, the reason why I ask is, I still assume that api call and config generator operate same way, both run over the same api as does the torguard client. By that those scripts are not some/any scripts, but those which torguard client officially uses. However, torguard never published any info about config generator and if registers ip's and keys over the same api.

Link to comment
Share on other sites

11 hours ago, 19807409 said:

@Support Few minutes ago UK 10Gbit got invalidated

 

Can you retry this now please? I have made a couple of small changes. Thanks

Link to comment
Share on other sites

Just now, Support said:

Can you retry this now please? I have made a couple of small changes. Thanks

Thanks, I noticed it, my UK connection broke few minutes ago, guess to those changes, I am reconnected by simply updating api, now we have to wait 24 hours to see.

  • Thanks 1
Link to comment
Share on other sites

I have been Connected now to the 10GBIT UK server ending in IP > .139 For 25 Hours!.  It is still Valid and working - I am surfing the internet and posting right now seems to be still Connected and Valid without any issues at all.

@support Mentioned they made a few changes but that did not effect my Config at all still Valid and smooth 25 hours in Now.
 

Link to comment
Share on other sites

On 10/29/2021 at 2:43 PM, Support said:

Can you retry this now please? I have made a couple of small changes. Thanks

No change, got invalidated

Link to comment
Share on other sites

@Support additional difference/issue/bug to how it is supposed to work is, if one runs api on a server without portforwarding, in the moment where current connection is valid, then it invalidates current connection as api assigns different ip address due to the api call. It worked (is supposed to work) that if one is still connected and connection is valid, then running the api was/should result in same/active ip address.

This is how it worked before current issue was observed. This means, that even if one runs api call on IP's where port forwarding is not used, then the interface has to be restarted with new ip address.

Link to comment
Share on other sites

23 hours ago, Dom1no said:

I have been Connected now to the 10GBIT UK server ending in IP > .139 For 25 Hours!.  It is still Valid and working - I am surfing the internet and posting right now seems to be still Connected and Valid without any issues at all.

Thanks for reporting, @Support it seems there is some issue on your side, as there is no way a user can invalidate own connection which is connected except running api call which in fact would deliver same ip and connection would not drop, in case of getting new ip connection would be invalidated, in this case you could claim that on my side somewhere a script updates it and invalidates, but that scenario can not happen with port forwarded ip as there internal assigned ip stays the same and calling api would just extend validity.

Taken in mind we have now somebody who reports that it works, it means there are different results which should not be the case, any explanation?

What is the difference in api and config generator? As @Dom1no used config generator, check if config generator does anything differently than what the api does, I have not other tips more for you as it is your internal system :) .

Hope it helps you finding out what the issue is.

Link to comment
Share on other sites

Everything seems to be working Flawlessly for me, 50 Hours without any problems so Far on UK 10GBit and Shared IP Tested both*. Still running smoothly - Still Valid.

@19807409 I Think it might be a problem Related to your API Script which you use for Generating the Config Files or whatever because i tried Both the IP's you listed and both are staying Valid and working Perfectly for me. 

Is the API Script your using Provided by and Approved and "supported" by Torguard? Because if it isn't then i do not think the issue is on their end as they should not have to provide support for  unsupported methods of generating config files. I believe Torguard supports generating them in the My Account Area.... I don't see any mention anywhere about API Scripts and Alternate ways to generate the Config Files so the way your doing it MIGHT not be very official? Or supported. 

All I know is that Generating the Config Files from the My Account Area on the website which is provided by and supported works flawlessly.

Link to comment
Share on other sites

@19807409, I tested a config myself and its still connected after 24hrs - any chance you can PM me your username?

Thanks

Link to comment
Share on other sites

1 hour ago, Dom1no said:

@19807409 I Think it might be a problem Related to your API Script which you use for Generating the Config Files or whatever because i tried Both the IP's you listed and both are staying Valid and working Perfectly for me. 

If that would be the case, then I would not get connected in first line, it just delivers you the values for the config. If the config would be faulty then:

1. it would not connect at all

2. it would not suddenly after years stop working

3. torguard client would fail with same issue, as torguard client uses the same api

4. it would not affect different devices, operating systems and networks

I never said that I do not believe that you stay connected.

1 hour ago, Dom1no said:

Is the API Script your using Provided by and Approved and "supported" by Torguard?

I already said multiple times, the api and is the one which TorGuard client uses, therefore, I would assume that torguard "approved" and "supports" it ;). You do not need to believe me, such things are verifyable, you can do so by debuging torguard client.

1 hour ago, Dom1no said:

I believe Torguard supports generating them in the My Account Area.... I don't see any mention anywhere about API Scripts and Alternate ways to generate the Config Files so the way your doing it MIGHT not be very official? Or supported.

Well, it is officially supperted, yes, under my account there is a config generator, not only for wireguard. And again, I doubt that torguard would waste ressources on creating additional ressource doing the same as the api, therefore I strongly believe (until supports denies :) it) that when you do use config generator, then the same api is called in the background, the same as does TorGuard client call. When you call the api, then on the server side few processes take place, and on that point there seems also to be no error as otherwise neither me nor you would be able to connect in first line.

Config generator was finally creator for those who did not want to use the api but instead some simple generator. Creating it over my account takes much longer than calling the api (or even just opening api url in browser) from where you simply replace the values of your existing config, this saves you a step to login to torguard and click the whole process. Another problem with config generator is that you can not really automate it, api calls you can as you receive all the values which you need.

In the github link I posted is description of the api and how it works, if you dislike it, you really can debug torguard client by yourself to verify it, you do not need to believe me, you can check it.

1 hour ago, Dom1no said:

All I know is that Generating the Config Files from the My Account Area on the website which is provided by and supported works flawlessly.

It seems that it works for your username flawlessly, you can not claim that it works for everybody which obviously does not. I am just trying to help TorGuard as on my side I could care less too as I can adapt scripting even if torguard invalidates it every minute.

47 minutes ago, Support said:

@19807409, I tested a config myself and its still connected after 24hrs - any chance you can PM me your username?

Thanks

You are welcome, but you do know that it is a bad idea to send you over forum pm with my username ;)  but if for everybody everything works, then my public key is somehow marked which seem unrealistic to me for the case of invalidation after 24 hours. I do not belive that config generator uses different api than TorGuard client, but can you confirm? The only big changes which TorGuard seem to have made are somehow updating proxies, like I said, up to I guess a week or two ago everything worked flawless on all devices, since then I had to reactivate my keep valid scripts to stay online without hassle. 

  • Haha 1
Link to comment
Share on other sites

@Dom1no

here is example config which you can test/compare to the one which you generate, I added comments and steps to do to edit it, you can open your api url in browser too. I've included UK's 10Gbit ipv6 api too which works (not sure if connecting over same ipv6 would work but you can try if you have ipv6, I guess port is not open on ipv6, but again, you can know it only if you try it.

# 1. change private key of your interface
# 2. change public key of your interface in api url
#
# my interface pubkey: LdoUtx56PnQwoCD+wfO7qoOTZMSaq9DYqsnpfz3Hbhs=
# my interface pubkey Url encode: LdoUtx56PnQwoCD%2bwfO7qoOTZMSaq9DYqsnpfz3Hbhs%3d
#
# API url - UK 10GBit - IPv4
# api url uk: https://YourUsername:[email protected]:1443/api/v1/setup?public-key=LdoUtx56PnQwoCD%2bwfO7qoOTZMSaq9DYqsnpfz3Hbhs%3d
# API url - UK 10GBit - IPv6
# https://YourUsername:[email protected][2a02:2498:e004:22:e61d:2dff:fe00:cfa0]:1443/api/v1/setup?public-key=LdoUtx56PnQwoCD%2bwfO7qoOTZMSaq9DYqsnpfz3Hbhs%3d
#
# Activate/Reactivate
# Open api url in browser or run in terminal (unsecure, for secure you can use torguards certificate and run without -k option):
# curl -k YOURAPIURL, example for IPv4
#   curl -k https://YourUsername:[email protected]:1443/api/v1/setup?public-key=LdoUtx56PnQwoCD%2bwfO7qoOTZMSaq9DYqsnpfz3Hbhs%3d
[Interface]
SaveConfig = false
PrivateKey = YKTje4ZlYHsxNFNUzQGdWeU2+NDtax/FBC+s0WII9lI=
Address = 10.123.123.123/32
ListenPort = 51820
DNS = 10.9.0.1,10.8.0.1
#DNS2606:4700:4700::64,2606:4700:4700::6400
#DNS = 1.1.1.1,1.0.0.1

# torguard peer UK permium IPv4
[Peer]
PublicKey = BoYBbzOUSX4LmFLeLs1XDCc9+j/z9MWdb0Pv5G2cjlQ=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 88.202.231.139:1443
PersistentKeepalive = 10

## torguard peer UK permium IPv6
#[Peer]
#PublicKey = BoYBbzOUSX4LmFLeLs1XDCc9+j/z9MWdb0Pv5G2cjlQ=
#AllowedIPs = 0.0.0.0/0, ::/0
#Endpoint = [2a02:2498:e004:22:e61d:2dff:fe00:cfa0]:1443
#PersistentKeepalive = 10

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...