Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

Serious Drops and packet loss South node

Looking for assistance with a cryptostorm connection issue? Post here & we'll help out. Also: if you're not sure where to post, do so here & we'll move things around as needed. Also: for quickest support, email our oddly calm & easygoing support reps at support@cryptostorm.is :)
User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Mon Dec 12, 2016 10:07 pm

@Guest

As far as we can see, the issue comes specifically during session re-negotiation, where the client's credentials are re-sent to the server; initial connection and authentication is always successful, unless there is an obvious failure - token expiry, dead server etc.

In the case of Manjaro, it might be useful to look a little deeper into what is actually going on. Would you be able to post some logs from your Manjaro install?


Topic Author
0x24d

Re: Serious Drops and packet loss South node

Postby 0x24d » Tue Dec 13, 2016 5:19 am

0x24d wrote:I just connected to Moldova and the connection disconnected after 20 minutes (after renegotiation).

I'll try the tor test and see if it is any different.

I am also in a different location/ISP next weekend so I will try connecting and doing the tor test then to see if I get different results.


Update

After I sent the above post I setup TOR as a socksproxy then connected to Latvia TCP using localhost:9050 as a proxy.

The TOR connection was fine but the VPN connection would connect and then disconnect/reconnect repeatedly due to a timeout, I could not connect to any sites and pinging cryptostorm.is returned 100% packet loss (due to no connection over TOR).

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Tue Dec 13, 2016 7:42 am

0x24d wrote:
0x24d wrote:I just connected to Moldova and the connection disconnected after 20 minutes (after renegotiation).

I'll try the tor test and see if it is any different.

I am also in a different location/ISP next weekend so I will try connecting and doing the tor test then to see if I get different results.


Update

After I sent the above post I setup TOR as a socksproxy then connected to Latvia TCP using localhost:9050 as a proxy.

The TOR connection was fine but the VPN connection would connect and then disconnect/reconnect repeatedly due to a timeout, I could not connect to any sites and pinging cryptostorm.is returned 100% packet loss (due to no connection over TOR).


Yeah, I tried the experiment as well and got the same result. OpenVPN over Tor looks like it's bugged in some way.


Topic Author
NOYB

Re: Serious Drops and packet loss South node

Postby NOYB » Tue Dec 13, 2016 7:53 am

Not running ads here. But our substitute VPN is still running with zero drops. IMO, the way it hasta work.

Now have every internet machine in the building connecting through that VPN proxy. Something I was always loath to do when Cryptostorm was the tunnel (too much for some users here ...they would never master recovering the connection).

Cryptostorm, a friendly suggestion. You need more eyes/new eyes on this problem. You *are* missing something. Could be important.

Have you ever traded problems with other VPN providers? If you have the courage, and they have the trustworthiness - can be a ruthlessly efficient tool. I've seen it work (other field).

Ego gets in the way when solving problems. Even "experts" miss things.


Topic Author
0x24d

Re: Serious Drops and packet loss South node

Postby 0x24d » Tue Dec 13, 2016 2:32 pm

Just a thought, I highly doubt that the issue is due to ISPs unless they are really only interested in 'attacking' one VPN provider rather than the whole OpenVPN protocol.

I bought a month of BlackVPN during their Black Friday sale and my connection to their servers is the same as what Cryptostorm used to be like.

Also other posters have mentioned AirVPN is running fine for them but Cryptostorm isn't.

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Tue Dec 13, 2016 11:55 pm

@0x24d

Not only that, but AirVPN and PIA are a bigger, juicier target. I still think the issue is related to re-auth during session renegotiation. Unfortunately, the problem isn't easy to reproduce (except for those who are affected, obviously) - I was affected by it on all nodes, but now the nodes will stay up longer term; my connection to the ENG node has now been up 5 days 9 hours.


Khariz
Posts: 162
Joined: Sun Jan 17, 2016 7:48 am

Re: Serious Drops and packet loss South node

Postby Khariz » Thu Dec 15, 2016 2:55 am

Questions
Are our respective ISPs all experimenting with some kind of DPI-based packet mangling which affects (or perhaps even targets) OpenVPN?
Are our ISPs innocent and the fault lies closer to the exit nodes, i.e. in the DC?
If so, why during session re-negotiation and not mid-session?
Why are only some of us affected and not others?


That's not my problem. I have been connected for 1 week and three days to an AirVPN server on a standard UDP 443 connection. It's not a problem on my end.


Topic Author
Guest

Re: Serious Drops and packet loss South node

Postby Guest » Thu Dec 15, 2016 11:00 am

Unfortunately tomato advanced on netgear r7000 exhibits the same behaviour.


Topic Author
Guest

Re: Serious Drops and packet loss South node

Postby Guest » Fri Dec 16, 2016 5:02 am

Fresh flash's of the latest dd-wrt kong, and advancedtomato exibit the same connection drop every 20 min like clockwork- none of the many tweeks I've tried seam to have any affect. I've tested with raw IP's on the seattle node, also georgia, chicago; and I've tried using the DNS entries such as remote-linux-uswest.cryptostorm.org - I"ve tried with and without the router handling the PPPOE direct from ISP. regardless, it always hangs while negotiating the tls control channel.

dd-wrt used to be exceptionally stable on CS with the same config- I could leave it unattended for weeks without complaints from anyone. Whatever changed, it happened a bit over a month ago.

Here's where it hangs: (this is tomato- hangs same in dd-wrt, slightly different message)
Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

also- I get past the tls handshake and still auth fail on the first couple reconnect attempts if I manually restart things. -are you positive this problem isn't in the auth system somehow?

manual restart prior to successful connection example:

Code: Select all

daemon.notice openvpn[17232]: Socket Buffers: R=[120832->120832] S=[120832->120832]
daemon.notice openvpn[17232]: TCP/UDP: Preserving recently used remote address: [AF_INET]173.234.56.116:443
daemon.notice openvpn[17232]: UDPv4 link local: [undef]
daemon.notice openvpn[17232]: UDPv4 link remote: [AF_INET]173.234.56.116:443
daemon.notice openvpn[17232]: TLS: Initial packet from [AF_INET]173.234.56.116:443, sid=********...
daemon.notice openvpn[17232]: VERIFY OK: depth=1, C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is
daemon.notice openvpn[17232]: VERIFY OK: nsCertType=SERVER
daemon.notice openvpn[17232]: VERIFY OK: depth=0, C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=server, emailAddress=certadmin@cryptostorm.is
daemon.notice openvpn[17232]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
daemon.notice openvpn[17232]: Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
daemon.notice openvpn[17232]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
daemon.notice openvpn[17232]: Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
daemon.notice openvpn[17232]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
daemon.notice openvpn[17232]: [server] Peer Connection Initiated with [AF_INET]173.234.56.116:443
daemon.notice openvpn[17232]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
daemon.notice openvpn[17232]: AUTH: Received control message: AUTH_FAILED
daemon.notice openvpn[17232]: SIGUSR1[soft,auth-failure] received, process restarting
daemon.notice openvpn[17232]: Restart pause, 10 second(s)

Next try it will connect, without any config change.

 ! Message from: parityboy
Added code tags for clarity

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Tue Dec 20, 2016 6:50 am

@thread

My connection to the ENG node just died after 11 days, 10 hours.

UPDATE
My connection to US West died after ~34 hours. A second session has lasted ~4 hours. A second session to the ENG node has lasted 19h20m.

UPDATE #2
My connection to US West lasted 2 hours. My connection to England lasted ~1 hour. My connection to NL lasted ~23 mins.


Topic Author
0x24d

Re: Serious Drops and packet loss South node

Postby 0x24d » Sat Dec 24, 2016 7:11 pm

Earlier this week I decided to test to see whether the token re-authentication issue would happen with multiple tokens.

I have been connected to the Lithuania node with a secondary token I bought a month after I bought the token I was using originally. The connection has been fine, the longest I have been connected is 10 hours and that was due to turning my PC off and not due to the connection dropping.

My original token still disconnects after 20 minutes (to Lithuania), I am authenticating using the sha256 hashes of each token so the issue isn't to do with non-hashed vs hashed tokens.

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Sat Dec 24, 2016 11:22 pm

@0x24d

Thank you very very much for this, it's certainly an interesting data point and kind of reinforces my belief that the issue is with the authentication system. I believed at first that the issue was network-based, but it would appear that some token data is either
a) already corrupted in some way while sitting in the database,
b) is mangled before being sent to the authentication process, or
c) is mangled during processing by the authentication system

However, it would appear that this issue is transient (and therefore likely does not involve data-at-rest) because the very same token I have been using was re-authenticated successfully for 10 days straight and then recently started playing up again.

EDIT
By the way, the hashes are SHA512. SHA256 hashes will not authenticate. :)


Topic Author
0x24d

Re: Serious Drops and packet loss South node

Postby 0x24d » Sat Dec 24, 2016 11:55 pm

parityboy wrote:@0x24d

Thank you very very much for this, it's certainly an interesting data point and kind of reinforces my belief that the issue is with the authentication system. I believed at first that the issue was network-based, but it would appear that some token data is either
a) already corrupted in some way while sitting in the database,
b) is mangled before being sent to the authentication process, or
c) is mangled during processing by the authentication system

However, it would appear that this issue is transient (and therefore likely does not involve data-at-rest) because the very same token I have been using was re-authenticated successfully for 10 days straight and then recently started playing up again.

EDIT
By the way, the hashes are SHA512. SHA256 hashes will not authenticate. :)


I tried editing the post to say sha512 instead of sha256 after posting but I couldn't due to not having an account.

I would buy another token and see if that one works correctly but I don't have access to my BTC wallet until next week.

User avatar

Fermi
Site Admin
Posts: 228
Joined: Tue Jun 17, 2014 11:42 am

Re: Serious Drops and packet loss South node

Postby Fermi » Sun Dec 25, 2016 5:12 am

0x24d wrote:Earlier this week I decided to test to see whether the token re-authentication issue would happen with multiple tokens.

I have been connected to the Lithuania node with a secondary token I bought a month after I bought the token I was using originally. The connection has been fine, the longest I have been connected is 10 hours and that was due to turning my PC off and not due to the connection dropping.

My original token still disconnects after 20 minutes (to Lithuania), I am authenticating using the sha256 hashes of each token so the issue isn't to do with non-hashed vs hashed tokens.


If it disconnects systematically each 20 minutes, you most likely have reached your session limit. Check your token @ cryptostorm.nu while connected. If it states max sessions reached, please send the token referring to this topic to support@cryptostorm.is.

/fermi


Topic Author
0x24d

Re: Serious Drops and packet loss South node

Postby 0x24d » Sun Dec 25, 2016 5:29 am

Fermi wrote:
0x24d wrote:Earlier this week I decided to test to see whether the token re-authentication issue would happen with multiple tokens.

I have been connected to the Lithuania node with a secondary token I bought a month after I bought the token I was using originally. The connection has been fine, the longest I have been connected is 10 hours and that was due to turning my PC off and not due to the connection dropping.

My original token still disconnects after 20 minutes (to Lithuania), I am authenticating using the sha256 hashes of each token so the issue isn't to do with non-hashed vs hashed tokens.


If it disconnects systematically each 20 minutes, you most likely have reached your session limit. Check your token @ cryptostorm.nu while connected. If it states max sessions reached, please send the token referring to this topic to support@cryptostorm.is.

/fermi


I have just checked whilst not being connected and I got the max sessions message, sent an email to the support address.


Topic Author
0x24d

Re: Serious Drops and packet loss South node

Postby 0x24d » Sun Dec 25, 2016 6:10 am

Have been connected to Lithuania for ~30 minutes and no longer have the max sessions reached message on cryptostorm.nu. Seems like that issue has been resolved.


Topic Author
NOYB

Re: Serious Drops and packet loss South node

Postby NOYB » Sun Dec 25, 2016 8:25 am

Now over 2 months. Can anyone claim they are closer to understanding problem causality?

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Tue Dec 27, 2016 6:43 pm

0x24d wrote:Have been connected to Lithuania for ~30 minutes and no longer have the max sessions reached message on cryptostorm.nu. Seems like that issue has been resolved.


Yeah I sent a message to staff as well about this, my token is doing the same thing.


Topic Author
Guest

Re: Serious Drops and packet loss South node

Postby Guest » Wed Dec 28, 2016 12:32 pm

same issue here- max sessions reached. I'm only using one.
will try and get someone on irc.

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Wed Dec 28, 2016 9:32 pm

@thread

OK, having sent a message to staff, my token is now fixed and counts the sessions correctly. I'll now see how long the connection stays up. :)

Guest wrote:same issue here- max sessions reached. I'm only using one.
will try and get someone on irc.


Send a message to support@cryptostorm.is with this thread title as the subject line and quoting your token or token hash. If you want to send it securely, their public key is here. :)

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Thu Dec 29, 2016 4:19 pm

@thread

UPDATE
Despite the session issues with my token being resolved, my test connection to the England node lasted 15 hours before I got an "inactivity timeout".


Topic Author
NYOB

Re: Serious Drops and packet loss South node

Postby NYOB » Fri Dec 30, 2016 1:57 am

parityboy wrote:@thread

UPDATE
Despite the session issues with my token being resolved, my test connection to the England node lasted 15 hours before I got an "inactivity timeout".


Parityboy,

You've been a real trooper. This was never your task to perform.

Yet here we are 2+ months later - and nothing has changed.

It is what it is. Accept the reality and embrace it.



Last night I faced a "small blip in the force" when our alternative setup slowed down. Within minutes, speeds were good again. Investigating the mystery....found that two of the alternate supplier's servers were experiencing "high packet loss". Their system had automatically moved me to another server on my preferred list. Everything was as before.

Was I impressed? You bet!

Have been with Cryptostorm a long time. Reliability is not their strong suite, nor is completing tasks.


Topic Author
Guest

Re: Serious Drops and packet loss South node

Postby Guest » Fri Dec 30, 2016 4:27 pm

Connection has been near perfect for me since the session thing was reset. logs show PPPOE hung up and reset twice in the middle of the night- but I doubt that has anything to do with CS, likely a telco issue. Was back up automatically within 30 sec each time.

NYOB
The idea that reliability isn't CS's strong suit is pure hogwash.
I've had solid service from their team in one form or another for near a decade- most of the last few years 24/7 connected via router. Admittedly this latest issue has been extraordinarily frustrating, by far the worst issue I've ever experienced with CS- Sometimes tech is an unruly bitch like that. Post logs, try to help- be part of the solution...

This ONE recent issue aside- CS has been extraordinarily stable, just like all 3 services the team did prior to this one. I'm far from the only person that's been a patron that long. That said- The 'reliability' we stick around for is of a different nature; one your not going to find at any other vpn.

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Fri Dec 30, 2016 7:04 pm

NYOB wrote:Parityboy,

You've been a real trooper. This was never your task to perform.


Actually, it was. :) Nailing down network issues - especially transient network issues - is hard work and can be frustrating. The staff aren't connected to every network in the world, so as many users as possible providing as much feedback as possible which is as detailed as possible is always going to be helpful.

Also, as the poster above has stated, we stick with (and support) CS for reasons other than reliable torrent connections. :thumbup:


Topic Author
NOYB

Re: Serious Drops and packet loss South node

Postby NOYB » Sat Dec 31, 2016 10:34 pm

Guest wrote:Connection has been near perfect for me since the session thing was reset. logs show PPPOE hung up and reset twice in the middle of the night- but I doubt that has anything to do with CS, likely a telco issue. Was back up automatically within 30 sec each time.

NYOB
The idea that reliability isn't CS's strong suit is pure hogwash.
I've had solid service from their team in one form or another for near a decade- most of the last few years 24/7 connected via router. Admittedly this latest issue has been extraordinarily frustrating, by far the worst issue I've ever experienced with CS- Sometimes tech is an unruly bitch like that. Post logs, try to help- be part of the solution...

This ONE recent issue aside- CS has been extraordinarily stable, just like all 3 services the team did prior to this one. I'm far from the only person that's been a patron that long. That said- The 'reliability' we stick around for is of a different nature; one your not going to find at any other vpn.


Nope. No torrenting. Just very conventional web access. And I've tried perhaps 6-10 suppliers over the last 10 years. Have you?

It's gotta work, and the disciplines required to accomplish that must be in place. No one ever claimed this was easy. And dismissing questions of reliability as "unworthies" never to be mentioned sounds like the beginning of a cult.

Ultimately, such cults are really suicide pacts. Because customers generally just walk away. Can lead to sudden collapse when revenue abruptly ceases.....


Topic Author
NOYB

Re: Serious Drops and packet loss South node

Postby NOYB » Sat Dec 31, 2016 10:39 pm

Khariz wrote:I'm already primarily using AirVPN. They are the only other guys that seem to take privacy and security seriously. One of the few VPN providers that is OpenVPN only with no other protocols. The Atlanta servers with AirVPN are much more stable than CS South node. It's on sale for 35% off right now too, so it's a good time to try it out.

I'm an aleph token holder over here at CS, so I'll always keep coming back and checking. But I agree that it's not ideal right now.
I've been meaning to mention that I'm now experiencing the same problems as everyone else. I'm technically staying connected to CS but I'm now experiencing the massive packet loss and spikes in latency that others are.



@Khariz

Save them from themselves. There's much denial here, and it's starting to border on "wishful thinking".

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Sun Jan 08, 2017 7:54 am

@ntldr

Check your token here while it's logged in on a single session. If the checker complains that the maximum number of sessions has been reached, send a message to support@cryptostorm.is

So far I have session to two nodes, and they have been solid for ~48 hours (previous token ran out).

@thread

UPDATE
That session lasted 3d6h30m before failing with "inactivity timeout".

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Fri Jan 13, 2017 6:35 am

@thread

My latest session lasted 3d23h45m before failing due to "inactivity timeout". I checked the token and it had not run out of sessions.


Topic Author
NOYB

Re: Serious Drops and packet loss South node

Postby NOYB » Fri Jan 13, 2017 8:13 pm

parityboy wrote:@thread

My latest session lasted 3d23h45m before failing due to "inactivity timeout". I checked the token and it had not run out of sessions.


Respectfully, this is not good enough.

User avatar

Fermi
Site Admin
Posts: 228
Joined: Tue Jun 17, 2014 11:42 am

Re: Serious Drops and packet loss South node

Postby Fermi » Tue Jan 17, 2017 6:21 pm

The issue can be triggered by the session limitation parameter. Officially Cryptostorm allows one connection / token. To technically deal with slow disconnects etc, the limit is put on three. This means that technically spoken there can be three concurrent connections, taking into account that there is no simultaneous renegotiation occurring.
After doing some extensive testing, we are confident that the majority of these 'Inactivity timeout' issues are related to the session limit. Simulation shows that when all sessions are occupied, renegotiation (happens every 1200 seconds), which includes authentication, doesn't result in a AUTH_FAILED message, but leads to the 'Inactivity timeout' issue.
There no way OpenVPN differentiates between an initial authentication and a authentication as a result of a renegotiation. If the latter would have been the case than this issue would have an issue solution.
When you are prepared to log extra data like (non-conclusive and non-exhaustive) IP, node, timestamp ..., one can also tackle this issue. But Cryptostorm is very reluctant to add additional critical data to the process.
We're looking into this, but for now please monitor your tokens wrt. the sessions. When sessions are not properly handled, this can lead to zombie sessions. In that case please contact us.

regards,

/Fermi ;)

User avatar

parityboy
Site Admin
Posts: 1283
Joined: Wed Feb 05, 2014 3:47 am

Re: Serious Drops and packet loss South node

Postby parityboy » Wed Jan 18, 2017 3:25 am

@Fermi

Many thanks for the post. After a few minutes of napkin logic, I think there maybe a way to do this without having to a) log too much information and b) patch OpenVPN.

A possible solution would be to - in addition to the current session counter - track the sessions and their ages. If we assume a re-negotiation interval of 1200 seconds with a max period of 1337 seconds, there is a window of 137 seconds in which to account for slow re-negotiation.

In this concept, the sessions for each token are stored in a table and expressed as:

Code: Select all

TOKEN_HASH       SESSION_ID     TIMESTAMP
<512-bit hash>   <uuid>         22:55:00


Every time an authentication request is made, pre-auth logic sweeps the table for that token hash, deleting any sessions which are greater than 1337 seconds old and adjusting the session counter accordingly. After this logic has run, the normal authentication request is run, and if successful the session is written into the table as above and the session counter is adjusted accordingly.

An obvious issue with this is database locks/timeouts, and I'm no database admin. The other obvious issue is whether recording only the timestamp of session establishment (so no node IP or any other data) is data which can be used in any kind of correlation attack.

Assuming the session data fell into the wrong hands, the most they would see would be the establishment of sessions and their start times. Is that enough to be potentially dangerous?


Topic Author
NOYB

Re: Serious Drops and packet loss South node

Postby NOYB » Wed Jan 18, 2017 3:36 am

Fermi wrote:The issue can be triggered by the session limitation parameter. Officially Cryptostorm allows one connection / token. To technically deal with slow disconnects etc, the limit is put on three. This means that technically spoken there can be three concurrent connections, taking into account that there is no simultaneous renegotiation occurring.
After doing some extensive testing, we are confident that the majority of these 'Inactivity timeout' issues are related to the session limit. Simulation shows that when all sessions are occupied, renegotiation (happens every 1200 seconds), which includes authentication, doesn't result in a AUTH_FAILED message, but leads to the 'Inactivity timeout' issue.
There no way OpenVPN differentiates between an initial authentication and a authentication as a result of a renegotiation. If the latter would have been the case than this issue would have an issue solution.
When you are prepared to log extra data like (non-conclusive and non-exhaustive) IP, node, timestamp ..., one can also tackle this issue. But Cryptostorm is very reluctant to add additional critical data to the process.
We're looking into this, but for now please monitor your tokens wrt. the sessions. When sessions are not properly handled, this can lead to zombie sessions. In that case please contact us.

regards,

/Fermi ;)



I'm not following this line of reasoning. In our case, we *always* used the same box (a privoxy proxy) to access cryptostorm. So there never were any "extra openvpn sessions". One connection *only*. I use cryptostorm free with a linux box - but that's it. Never even attempted to install that paid token on other machines. Arrgh one exception. Recently used that token on a portable wifi box while attempting to use your OBFS feature to punch through a public library firewall (it failed). But that experiment was performed months after Cryptostorm connections became unreliable.

So again, how is it that my other openvpn connection stays up? Always. This is not exaggeration, it's just fact.


Topic Author
NOYB

Re: Serious Drops and packet loss South node

Postby NOYB » Wed Jan 18, 2017 3:46 am

Fermi wrote:The issue can be triggered by the session limitation parameter. Officially Cryptostorm allows one connection / token. To technically deal with slow disconnects etc, the limit is put on three. This means that technically spoken there can be three concurrent connections, taking into account that there is no simultaneous renegotiation occurring.
After doing some extensive testing, we are confident that the majority of these 'Inactivity timeout' issues are related to the session limit. Simulation shows that when all sessions are occupied, renegotiation (happens every 1200 seconds), which includes authentication, doesn't result in a AUTH_FAILED message, but leads to the 'Inactivity timeout' issue.
There no way OpenVPN differentiates between an initial authentication and a authentication as a result of a renegotiation. If the latter would have been the case than this issue would have an issue solution.
When you are prepared to log extra data like (non-conclusive and non-exhaustive) IP, node, timestamp ..., one can also tackle this issue. But Cryptostorm is very reluctant to add additional critical data to the process.
We're looking into this, but for now please monitor your tokens wrt. the sessions. When sessions are not properly handled, this can lead to zombie sessions. In that case please contact us.

regards,

/Fermi ;)



"Zombie/Phantom" sessions making Cryptostorm unusable?

Simpler answer?

https://www.youtube.com/watch?v=hLmuF-0P4tk

Perhaps a forgetting of "what we're here for"?


Price of a token is really chump change for most here, but I'll wager if a person grabbed equivalent change in the physical world - they'd be popped in the mouth.

You own this one Cryptostorm. Shame on you! You covered your ass at our expense.

User avatar

Fermi
Site Admin
Posts: 228
Joined: Tue Jun 17, 2014 11:42 am

Re: Serious Drops and packet loss South node

Postby Fermi » Fri Jan 20, 2017 12:38 pm

We're looking into the OpenVPN source code on how to differentiate between an authentication cycle issued by key renewal and initial login.
If we are able to do that we can solve this issue without having to add extra logging/data on our end.
We'll keep you posted.

/fermi


Return to “member support & tech assistance”

Who is online

Users browsing this forum: No registered users and 29 guests

Login