Ξ 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 Ξ

Linux/Tunnelblick connect snags | RESOLVED (via 1.3 conf's)

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

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Linux/Tunnelblick connect snags | RESOLVED (via 1.3 conf's)

Postby DesuStrike » Mon Jan 13, 2014 4:37 am

{This is a collection of all threads and posts concerning the recent problems of connecting to certain exit nodes, certain OS instances and the strange situation where you are connected to an exit node but cannot resolve any adresses. This thread shall both serve as an easy point of reference for the team so they don't have to crawl all subforums and also as a call to all community members to go post here if they experience the same problems.
CONNECTION LOGS are highly welcome! So go and post them here when you run into this problem!
I will personally make sure the tech team will get notice of this thread!} ~DesuStrike




Using Ubuntu-Network Manager with RAW-FRANKFURT_1.2:

I can connect to the VPN but then I can't browse or connect to anything else. So it seems like I just get stuck inside the exit node. If I remember correct some members had the same problem in the past.

Side note: When I'm using the Cantus IP which directs to the "Windows" instance I can use the German exitnode with no problems.

Side note 2: I didn't do any too extensive testing but a quick "try out every node"-run I did shows the same/a similar behavior on all nodes. Speaking: If I use the IP for the RAW-instance I cannot connect or can't browse after connecting but if I use the old IP (now the Windows-instances) I can use the exitnode without any problems! (All testing was done without my personal leakblock!)
home is where the artillery hits

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm: client config discussions, bugs, requests,

Postby Pattern_Juggled » Mon Jan 13, 2014 7:30 am

DesuStrike wrote:Using Ubuntu-Network Manager with RAW-FRANKFURT_1.2:

I can connect to the VPN but then I can't browse or connect to anything else. So it seems like I just get stuck inside the exit node. If I remember correct some members had the same problem in the past.


Ooh, I am not sure the Network Manager connections were tested with these - that is an oversight that I'll pass to Tech Ops for confirmation.

Side note: When I'm using the Cantus IP which directs to the "Windows" instance I can use the German exitnode with no problems.


Which IP is this? I can then let you know which instance it's calling... I suspect it's actually the "raw" one but let's see what you've got before I make a guess.

Side note 2: I didn't do any too extensive testing but a quick "try out every node"-run I did shows the same/a similar behavior on all nodes. Speaking: If I use the IP for the RAW-instance I cannot connect or can't browse after connecting but if I use the old IP (now the Windows-instances) I can use the exitnode without any problems! (All testing was done without my personal leakblock!)


If you have a situation where you get the "connect but can't browse" behaviour, it'd be great to see the relevant output from the client error logs. A grep-hunt for the relevant entries server-side is becoming infeasible given the volume of traffic and sessions being supported across exitnodes currently. :-)

Note that this situation is a big part of why we're really actively working to make it unnecessary for people to do raw connections to specific IPs. As tempting as they are - find a "good" IP and just hit it directly, no hostnames required - they're brittle. Understandably, as we've sort of thrown ALL the hostnames up in the air and reshuffled them in the past week, the desire to jump past that to a specific instance on a specific machine totally makes sense... but it's also got some serious downsides.

This evening, I am writing up more of a set-theoretic exegesis covering the three-tiered hostname-based groupings for our hostnames. I think (hope) that, in doing so, it lays out a bit more of why this epic reshuffle during early January has been more than worth it for serious scalability. I also believe, having been the one tasked with the set-theoretic framing of the whole thing at a theoretical level, that we've got one in place that won't bump up against structural constraints in the foreseeable future. Looking back, of course, I think "geez, why didn't I realise this last year and put it in place right off the bat?' But, alas, hindsight is always such perfect clarity eh? :-P
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby DesuStrike » Mon Jan 13, 2014 12:35 pm

Hey PJ,

first of all I know this is in part my error. You offered me to do some debugging which would have shown any problems with Network Manager right away but I was too busy so here is what I get for not taking part in this process.

Here are the IPs which both work excellen on Ubuntu Network-Manager and Android:
(this is copy&paste from our active connections. So no mixup possible!)

Bruno: 70.38.46.226
Shadow: 198.50.119.171
Cantus: 46.165.222.207


Here are the IPs (actually we both tested IPs and hostnames) which are either getting us "stuck inside an exitnode" or time out even before we can connect at all:

Bruno: 70.38.46.224
Shadow: 198.50.119.172
Cantus: 46.165.222.246


As to the error logs Ubuntu is giving me the finger because they show no way (at least no obvious) to grab error logs if those are generated at all. If I can find the time I will search the web to see if logs are generated anywhere behind the scenes so I can grab those and sent you these. If I don't find these logs, or by chance have even more time, I will use Arnes client to test and send you those logs. Keep in mind that with Arnes client I can only use the IP as his client doesn't support multiple hostnames.

Also: I may was fixated on using 'naked' IPs for my configs in the past because I have to maintain my own leakblock but since the big "flavour update" I really prefer using your provided, totally unedited configs with hostnames. With all those new different configs around it gets way to complicated to keep up with every change and thus the smartest way is to stick with what you guys provide. (It also helps debugging! :angel: ) Still a bit annoying because I have to change my leakblock if IPs change but as I test new configs without leakblock this fact should never impact testing results. So the only reason I still do 'naked IPs' is that I had no luck with the new configs. :oops:
home is where the artillery hits

User avatar

Mousy
Posts: 18
Joined: Thu Oct 31, 2013 5:12 pm

COLLECTION: connection & adress resolving problems

Postby Mousy » Wed Jan 15, 2014 6:20 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi guys,

Just wondering anyone else is having problems with the Icelandic exitnode today?

I'm able to connect after what seemed like a very long time, but once connected I can't resolve any websites at all. As far as I can see nothing has changed from yesterday when I had a working connection, I went to bed and when I got up this morning it was behaving badly.

Just to be on the safe side I cleared out the configuration file from Viscosity, and then downloaded and installed the most recent config file from the forum. Still no joy.

Has anybody got any idea what might be going on?

Thanks

Mousy

OS X 10.9.
Viscosity.
Most recent version Icelandic config file.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJS1or4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RkQ5REY4NUVEMTQwRDZFNUYyMDZCMjA3
NURBOEMzNDc2NERENDg0AAoJEHXajDR2TdSEPIAH/3Xh7hkvH51uDiAI5kgMk2Wd
xHwrvi519b0mYavIbQqdI/0DD/5br1pu/1rONm6tIyPUZpoSr5qEt0A+5cRKtsdf
WATiAO3yLvc/lu7n3wqu0OVKXsW5QP23+uEOcVVqEzxdBGQERIuKfas+sDBGsMly
VhsqTefsZ5nHnpAHKZ13AqONTyzAuyJd5AhM5Y1toVFx7Wgxx2Tm890c7j07jC/t
hZGDLE3sLbElz//mHweo0nLc99fkzopH7josP7V5vVCql6hyiEBKoUWC2+N69eYx
YARr59kwl2/u73C+a6BoOVmJt3LhaHhaCFrf9ee4hBQLLgDMVNh8Parylq8OgtU=
=B514
-----END PGP SIGNATURE-----
    Key ID: 0x75DA8C34764DD484
    Key Fingerprint: 5FD9 DF85 ED14 0D6E 5F20 6B20 75DA 8C34 764D D484
    Download My PGP Key.

Mahatma Gandhi wrote:First they ignore you, then they laugh at you, then they fight you and then you win.

User avatar

marzametal
Posts: 517
Joined: Mon Aug 05, 2013 11:39 am

Re: Iceland exit node problems.

Postby marzametal » Thu Jan 16, 2014 5:04 am

Yeah same, made a post in another thread about it... Dynamic breaks when trying to get in via Iceland and hence, Iceland itself is broken. Frankfurt is still up if that is of any help to you. Haven't tried Montreal...

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: Iceland exit node problems.

Postby DesuStrike » Thu Jan 16, 2014 5:06 am

I have this problem with all Linux-Instances. I use the Windows ones to bypass this problem even though I'm on Linux...
home is where the artillery hits


Guest

Re: cryptostorm: client config discussions, bugs, requests,

Postby Guest » Thu Jan 16, 2014 6:04 am

The Montreal and Frankfort configs don't work for me. Attempted to connect via network-manager. I am using linux mint 13, openvpn 2.3.2 , openssl 1.0.1, network-manager 0.9.4.0 and, all dependcies for above packages.


Open network manager // vpn connections // Configure Vpn...
import cryptosorm_client_raw-montreal1_2
# the montreal.conf has raw-frankfurt.cryptostorm.net listed not sure if typo

for username: pasted decrypted hash
password: 93b66e7059176bbfa418061c5cba87dd

CA Certificate: Cryptostorm Certificate.crt

click save.


Select netowrk manager // vpn connections // cryptostorm_client_raw-montreal1_2 // Shows connection animation // Shows vpn connected icon

Attempt ping test

ping -c 10 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

-- 8.8.8.8 ping statistics --
10 packets transmitted, 0 received, 100% packet loss, time 9071ms

Check network settings

ifconfig

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.55.0.2 P-t-P:10.55.0.2 Mask:255.255.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:4316 (4.3 KB)

Check syslog

tail -f /var/log/syslog | grep -i vpn

NetworkManager[10159]: <info> Starting VPN service 'openvpn'...
NetworkManager[10159]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 12566
NetworkManager[10159]: <info> VPN service 'openvpn' appeared; activating connections
NetworkManager[10159]: <info> VPN plugin state changed: starting (3)
NetworkManager[10159]: <info> VPN connection 'cryptostorm_client_raw-montreal1_2' (Connect) reply received.
nm-openvpn[12570]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Oct 24 2013
nm-openvpn[12570]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
nm-openvpn[12570]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
nm-openvpn[12570]: UDPv4 link local: [undef]
nm-openvpn[12570]: UDPv4 link remote: [AF_INET]198.50.119.172:443
nm-openvpn[12570]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1606', remote='link-mtu 1602'
nm-openvpn[12570]: WARNING: 'mtu-dynamic' is present in local config but missing in remote config, local='mtu-dynamic'
nm-openvpn[12570]: [server] Peer Connection Initiated with [AF_INET]198.50.119.172:443
nm-openvpn[12570]: TUN/TAP device tun0 opened
nm-openvpn[12570]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1606 10.55.0.3 255.255.0.0 init
NetworkManager[10159]: <info> VPN connection 'cryptostorm_client_raw-montreal1_2' (IP Config Get) reply received.
NetworkManager[10159]: <info> VPN Gateway: 198.50.119.172
nm-openvpn[12570]: Initialization Sequence Completed
NetworkManager[10159]: <info> VPN connection 'cryptostorm_client_raw-montreal1_2' (IP Config Get) complete.
NetworkManager[10159]: <info> VPN plugin state changed: started (4)
nm-openvpn[12570]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
nm-openvpn[12570]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
nm-openvpn[12570]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
nm-openvpn[12570]: [server] Inactivity timeout (--ping-restart), restarting
nm-openvpn[12570]: SIGUSR1[soft,ping-restart] received, process restarting
nm-openvpn[12570]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
nm-openvpn[12570]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
nm-openvpn[12570]: RESOLVE: Cannot resolve host address: raw-montreal.cstorm.pw: No address associated with hostname
nm-openvpn[12570]: last message repeated 3 times



Replicate error? // retried steps above // able to replicate above log

added tun-mtu 1500 to config file // retry steps above // Same results as above // status shows connected // unable to ping out


ping -c 5 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

---8.8.8.8 ping statistics --
5 packets transmitted, 0 received, 100% packet loss, time 4030ms


check network status
ifconfig

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.55.0.3 P-t-P:10.55.0.3 Mask:255.255.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:4083 (4.0 KB)

check sys log
tail -f /var/log/syslog | grep -i vp

nm-openvpn[11294]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Oct 24 2013
nm-openvpn[11294]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
nm-openvpn[11294]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
nm-openvpn[11294]: UDPv4 link local: [undef]
nm-openvpn[11294]: UDPv4 link remote: [AF_INET]198.50.119.172:443
nm-openvpn[11294]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1606', remote='link-mtu 1602'
nm-openvpn[11294]: WARNING: 'mtu-dynamic' is present in local config but missing in remote config, local='mtu-dynamic'
nm-openvpn[11294]: [server] Peer Connection Initiated with [AF_INET]198.50.119.172:443
nm-openvpn[11294]: TUN/TAP device tun0 opened
nm-openvpn[11294]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1606 10.55.0.3 255.255.0.0 init
NetworkManager[29803]: <info> VPN connection 'cryptostorm_client_raw-montreal1_2' (IP Config Get) reply received.
NetworkManager[29803]: <info> VPN Gateway: 198.50.119.172
nm-openvpn[11294]: Initialization Sequence Completed
NetworkManager[29803]: <info> VPN connection 'cryptostorm_client_raw-montreal1_2' (IP Config Get) complete.
NetworkManager[29803]: <info> VPN plugin state changed: started (4)
nm-openvpn[11294]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
nm-openvpn[11294]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
nm-openvpn[11294]: [server] Inactivity timeout (--ping-restart), restarting
nm-openvpn[11294]: SIGUSR1[soft,ping-restart] received, process restarting
nm-openvpn[11294]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
nm-openvpn[11294]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
nm-openvpn[11294]: RESOLVE: Cannot resolve host address: raw-montreal.cstorm.pw: No address associated with hostname

Changing the mtu in the config file does not seem to help.

Lets see if problem is replicated across servers.

import cryptostorm_client_raw-frankfurt1_2

Repeated same steps above

tried to ping out

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

---8.8.8.8 ping statistics --
5 packets transmitted, 0 received, 100% packet loss, time 4030ms


check network

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.55.0.2 P-t-P:10.55.0.2 Mask:255.255.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:1942 (1.9 KB)


syslog

NetworkManager[29803]: <info> Starting VPN service 'openvpn'...
NetworkManager[29803]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 16335
NetworkManager[29803]: <info> VPN service 'openvpn' appeared; activating connections
NetworkManager[29803]: <info> VPN plugin state changed: init (1)
NetworkManager[29803]: <info> VPN plugin state changed: starting (3)
NetworkManager[29803]: <info> VPN connection 'cryptostorm_client_raw-frankfurt1_2' (Connect) reply received.
nm-openvpn[16339]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Oct 24 2013
nm-openvpn[16339]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
nm-openvpn[16339]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
nm-openvpn[16339]: UDPv4 link local: [undef]
nm-openvpn[16339]: UDPv4 link remote: [AF_INET]46.165.222.246:443
nm-openvpn[16339]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1606', remote='link-mtu 1602'
nm-openvpn[16339]: WARNING: 'mtu-dynamic' is present in local config but missing in remote config, local='mtu-dynamic'
nm-openvpn[16339]: [server] Peer Connection Initiated with [AF_INET]46.165.222.246:443
nm-openvpn[16339]: TUN/TAP device tun0 opened
nm-openvpn[16339]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1606 10.55.0.2 255.255.0.0 init
NetworkManager[29803]: <info> VPN connection 'cryptostorm_client_raw-frankfurt1_2' (IP Config Get) reply received.
NetworkManager[29803]: <info> VPN Gateway: 46.165.222.246
nm-openvpn[16339]: Initialization Sequence Completed
NetworkManager[29803]: <info> VPN connection 'cryptostorm_client_raw-frankfurt1_2' (IP Config Get) complete.
NetworkManager[29803]: <info> VPN plugin state changed: started (4)
nm-openvpn[16339]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
nm-openvpn[16339]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented
nm-openvpn[16339]: [server] Inactivity timeout (--ping-restart), restarting
nm-openvpn[16339]: SIGUSR1[soft,ping-restart] received, process restarting

Looks like the same problems across nodes. Looks like there is still an issue w/ mtu & fragment.
On a unrelated note what am i doing wrong thats causing the No server certificate verification method has been enabled.

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: cryptostorm: client config discussions, bugs, requests,

Postby DesuStrike » Fri Jan 17, 2014 6:16 pm

Hey! Thank you very much for posting these logs!

As already stated I also experience these errors when using the special "raw/Linux" configs but I wasn't able to grab some logs from Ubuntu. I guess Linux Mint and Ubuntu shouldn't give any different logs here, so you kinda saved me the trouble!

I'll forward your post directly to the tech-team so they can dig into this frustrating matter!
home is where the artillery hits


Username1000
Posts: 3
Joined: Thu Nov 21, 2013 3:48 am

Re: HOWTO: Mac connects | Tunnelblick

Postby Username1000 » Sun Jan 19, 2014 12:12 am

I have connected to CS using the above tutorial and it worked fine for about a month. The problem arose about a week after I started using a new token. Now what happens is when I try to connect is that in the pop-up box there is no speed/data downloaded for the "In" row and only ~4 B/s on the "Out" row. The log reads:

Code: Select all

2014-01-18 12:51:53 *Tunnelblick: openvpnstart starting OpenVPN:
                    *                    /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.2/openvpn --cd /Library/Application Support/Tunnelblick/Users/JohnDoe/Empty Tunnelblick VPN Configuration.tblk/Contents/Resources --daemon --management 127.0.0.1 1339 --config /Library/Application Support/Tunnelblick/Users/JohnDoe/Empty Tunnelblick VPN Configuration.tblk/Contents/Resources/config.ovpn --log /Library/Application Support/Tunnelblick/Logs/-SUsers-SJohnDoe-SLibrary-SApplication Support-STunnelblick-SConfigurations-SEmpty Tunnelblick VPN Configuration.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_817.1339.openvpn.log --management-query-passwords --management-hold --redirect-gateway def1 --script-security 2 --up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -atADGNWradsgnw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -f -atADGNWradsgnw --up-restart --route-pre-down /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -m -w -d -f -atADGNWradsgnw
2014-01-18 12:51:53 *Tunnelblick: Established communication with OpenVPN
2014-01-18 12:51:53 *Tunnelblick: Obtained VPN username and password from the Keychain
2014-01-18 12:52:17 *Tunnelblick: No 'reconnecting.sh' script to execute
2014-01-18 12:52:34 *Tunnelblick: No 'reconnecting.sh' script to execute
2014-01-18 12:52:51 *Tunnelblick: No 'reconnecting.sh' script to execute
2014-01-18 12:53:09 *Tunnelblick: No 'reconnecting.sh' script to execute
2014-01-18 12:53:27 *Tunnelblick: No 'reconnecting.sh' script to execute
2014-01-18 12:53:28 *Tunnelblick: Disconnecting; Disconnect button pressed
2014-01-18 12:53:28 *Tunnelblick: Disconnecting using 'killall'
2014-01-18 12:53:31 *Tunnelblick: No 'post-disconnect.sh' script to execute


However, this problem is intermittent - right now I am connected, but it has been off and on for the past week. Does anyone have insight?

I'm using Tunnelblick 3.3.0 (build 3518)
OS X 10.6.8

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: HOWTO: Mac connects | Tunnelblick

Postby DesuStrike » Sun Jan 19, 2014 1:04 am

This sounds like the good 'ol "getting stuck inside the exitnode"-bug. I thought it was only present in Linux but and at some time in the past with the windows widget but it seems to affect every OS instance at some point... AFAIK there is no solution to this right now but to change exitnodes and try out different OS-Instances.


Problem is: Your logging verbosity is set to 0 in the config. Do you know how to edit the config? It's as easy as editing a simple text file. If yes, please set the "verb 0" paramenter to "verb 9" (troubleshooting), reimport the config file and as soon as you run into this problem again you can copy and paste your logfile here or send it via mail to support.

Your help would be very much appricated!
home is where the artillery hits

User avatar

marzametal
Posts: 517
Joined: Mon Aug 05, 2013 11:39 am

Re: Iceland exit node problems.

Postby marzametal » Sun Jan 19, 2014 6:38 am

I think it is happening in Windows widget again...


Guest

Re: cryptostorm: client config discussions, bugs, requests,

Postby Guest » Sun Jan 19, 2014 4:49 pm

Same problem here. Can we please have this fixed ASAP? I am unable to use the VPN service for several days now...

Another question: I understand that for some reasons the IPs of the exit nodes are not fixed, but is there any way to be informed for example here on this forum when they change and have the updated IPs listed somewhere?

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: Iceland exit node problems.

Postby DesuStrike » Mon Jan 20, 2014 6:50 am

marzametal wrote:I think it is happening in Windows widget again...


When stuff like this happens then please head to the contact channels page and pick your favourite method (other than forum) to report such incidents. The team is looking into the forum quite regularly but sending them an email usually is the best way to get a quick reaction out of them.

Also I'm really nagging the team when things go wrong, almost to that extend that I fear PJ slowly sees me as a small Devil DesuStrike on his shoulders that always complains about stuff and pokes him in the ear with his trident. But a lot of people still have way more impact on team priorities than just me alone. It's not that the team won't listen to single community members but a crowd is always louder than a single guy. :mrgreen:

So please everybody: Take this one extra step and speed things up for everyone!
home is where the artillery hits


chickie
Posts: 2
Joined: Mon Dec 23, 2013 2:14 am

Trouble connecting, then can't open webpages or get email

Postby chickie » Mon Jan 20, 2014 4:55 pm

The past week, I've been having trouble getting connected. For a couple of days, could not connect at all. Now I can connect, but web pages won't load and email (Outlook) stalls and won't get mail.

What do I need to do?

And when are you going to fix the forum so I can see the input boxes? Black background, dark gray input boxes makes your support very frustrating to use. I've been here 3 times and finally more frustrated with my service than I am intimidated by trying to find where to login and where to put the title to my topic.


chickie
Posts: 2
Joined: Mon Dec 23, 2013 2:14 am

Re: COLLECTION: connection & adress resolving problems

Postby chickie » Mon Jan 20, 2014 9:39 pm

Not sure what to do. My eyes are burning from trying to read this page.

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: COLLECTION: connection & adress resolving problems

Postby Pattern_Juggled » Tue Jan 21, 2014 2:30 am

I'm front-running an "official" answer, but the short form is that the Network Manager tool in Ubuntu seems to have some serious limitations in how it handles connections. In particular, I suspect that it doesn't actually support declines of "comp-lzo" compression - something that we're working very, very hard to deploy across all OS and connection profiles. There's a thread here about why that's the case. Short form (again) is that "compression + encryption = asking for security fail" - and that's a general rule I have seen play out true enough times over the years to take as nearly axiomatic.

Those having issues with connecting to Iceland with *nix flavours are having those issues because... we don't have a *nix-flavoured daemon running on our Icelandic exitnode yet! "Forcing" the issue by using the Windows daemon will result in failure to route packets outside the subnet (due to MTU and comp-lzo interactions, undocumented problems deep inside the codebase of openvpn itself - again, discussed in depth in the client config thread here). Just as soon as that daemon is available, a proper config file will be posted here - tested, validated, and fully supported.

Finally... please, please, please don't hard-code IPs for network connections. Please. Seriously. If you do - as has been discussed elsewhere - we cannot provide on-the-spot support when problems arise. I know it seems "simple" to "just keep the same IPs," but consider this: we now have dozens of disparate instances of OpenVPN running on three (soon four) geographically disparate exitnodes and a pile of actual, physical servers. Each has its own IP allocation... allocations we do NOT control, as they are RIPE/ARIN assigned to the colos themselves (this is standard - universal - reality for all IPs on the internet: nobody really "owns" them).

We do change colos and servers from time to time. We retain that flexibility, by decoupling IPs from connection profiles, for several important reasons. First, if a colo gets censorship-happy, we can cancel service and move. Second, if we lose confidence in the physical/legal security of a colo provider, we move. Third, if a colo gets flooded by media cartel mercenary spambots and "demands" we snitch our customers or they'll cancel our service... we tell them, simply put, to "go fuck themselves." We wipe the server, cancel our business with them, and initiate fraud-protection procedures via our payment provider as we've always prepaid for said service in advance. This doesn't happen very often (the last one), but it does happen... and the ability to do this WITHOUT hammering customers via broken connection profiles is highly strategically valuable for the network.

If we support hard-coded IPs, we lose the ability to do all these (and more - we lose loadbalancing capability within exitnodes, which means we can't performance tune them in any meaningful way, and thus can't support high-bandwidth per-member sessions that sometimes approach 100megabits/second - per member!). If we support hard-coded IPs, I personally have to balance - when making decisions about situations like I outlined above: "do we inconvenience customers in order to retain network security overall... or do we sacrifice network security so we don't inconvenience customers?"

I reject that decision - it has no good answer.

Rather, we avoid putting the network in that bad-decision circumstance by avoiding a hard-tie to IPs.

Now, of course, members can connect to individual IPs - we're not going to script up some clever way to block that, not our style. But... if you do that, and a connection "breaks"... please don't scream bloody murder at us for not being able to get you back on track asap. We'll actually get you back on track, and sooner or later we'll get you data to fix your profile - but you're going to get queued behind member issues that come from properly-supported config settings, and other such things. That's fair - we don't have a staff of dozens of support folks to answer every query 24/7 no matter if it's an out-of-support issue.

Being an "open" network, as we are - anyone can throw connection attempts at any exitnode cluster, machine, IP, or node - it's inevitable that some folks will throw malformed attempts at certain daemons. It happens, because we don't block it. But... we support the actual configs (current version) that are posted, including the widget which has built-in configs (of course). We do our absolute best to provide backwards-compatibility to earlier config versions (this is actually my job, personally, and it's enormously complex and time-consuming to do - and never gives 100% success - but I feel it's important and worth the effort, rather than just saying "tough shit - use the current configs or don't expect it to work"), but using older configs to connect is not the best, and might result in transient or otherwise ephemeral problems with the connection.

So...

    1. if you are having "connection problems" and you're using an old config, a config that you've tweaked after downloading, or a direct-mapped IP that you've plugged in rather than the hostname --remote settings... please, before you report an "error," try the actual/correct/supported configs - as posted in conf.cryptostorm.org, which is ALWAYS the correct & current versions. If those configs don't work, then we have a major problem and the cryptostorm team will drop everything - in very literal terms - to fix it, no matter what.

    2. if you are using the widget, and you have connection problems (and you haven't tweaked configs manually, which is not very common), then let us know as it's a serious issue and we'll hunt it down, right away.

    3. if you've tweaked the config, and your tweaks pretty much make sense but they still don't work, post in this thread and we'll help you figure out what's going on - we have several team members who know an enormous amount about these settings and can most assuredly let you know what's up - but it might not be a super-fast turnaround as it's not really a direct production issue.

To close, the reason that improper config selection results in "I can connect, but not load web pages" is as follows: cryptostorm is very, very rigid about enforcing HMAC validation of all secure network packets. This means that a packet coming through cryptostorm to your client/PC has to pass a series of tests to be sure it's "legitimate." This, in turn, protects against a whole suite of Man-in-The-Middle (MiTM) attacks: these attacks are real, documented, and known to be used by the NSA (and others) against VPN sessions. This is not a joke.

Now, yes, it'd be way easier if we just "let the packets through" - like basically every other "VPN service" out there. No complaints, no "I can't connect" issues, no criticisms of things. The problem is that doing so fucks the entire security model of the network: security theatre results. It looks "secure," but it's not. And, yes, that's great for marketing: happy customers, no drama. That the "secure network" is insecure is mostly invisible to customers... so who cares, right?

We care.

It's frustrating to get things running right: secure network, no drama, easy connections. I understand that. In fact, that's why we're still in beta (officially) and have been for more than four months. To fine-tune these things - WITHOUT sacrificing security.

We're getting there, slowly but surely. One day soon, we'll announce an official exit from beta testing. We're close, but we've had some deep structural fiddling to do, this past month, to get things ready to support scaling and future growth at the levels we've been seeing. It's neither easy, nor glamorous, nor fast - but it's important, and it's the right way forward.

The end result is a secure network that's secure, fast, reliable, and as simple and drama-free to use as clicking a button to connect. That's the end-state goal, period. There's no shortcut to get there. We're getting there by doing it right.

    ~ pj



ps: I know that "VPN services" routinely just dump IPs into config files and have people connect that way. I also know, simply put, that doing so is fucking stupid. We're not a "VPN service" - we're a secure network provider. And we don't dump IPs into config files, period. If "they" do it and you think that's just peachy, then use their service - don't expect it to be secure, reliable, censorship-free, or able to defend against media cartel assaults... but, hey, have at it. I don't recommend it, personally, but everyone makes their decisions. We don't run that way. We're not a "VPN service." We do it right. The fact that we're not doing things like PatheticInternetAccess or whatever other fraudster "VPN service" has SEO'd themselves to "fame" lately is of exactly zero concern to our team. No, that's wrong: the fact that we don't do it the way they do is a strong indicator that we're doing it right.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


Guest

Re: COLLECTION: connection & adress resolving problems

Postby Guest » Tue Jan 21, 2014 3:47 am

If it helps any mac users: tunnelblix was working fine until yesterday when I started getting "connected" but the browser couldn't connect.

I switched to viscosity, using the same conf file as tunnelblix and now I'm back in business.

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: COLLECTION: connection & adress resolving problems

Postby DesuStrike » Tue Jan 21, 2014 5:44 am

First of all: I think I speak for the majority of the community when I say that we of course don't blame you or the team personally for all this stuff happening. The situation is just very frustrating...
Also: I was able to connect with the newest config via console. So you are right about that!


Aaaaand here is the feel of guilt for making you write such a long post and keeping you from whatever you where doing even though you and the team did everything for security and are mostly right. Mostly? Yes mostly!


I see myself as a totally mediocre user using Linux. As this kind of user I can tell you the situation literally screams for major changes/advances in the Widget/Leakblock section because otherwise we are more or less forced to use both the Ubuntu Network-Manager and modified configs with IPs in them. I don't say this out of frustration. My connection works fine the way I do things right now but it was a shitload of try and fail until I got everything running (often thanks to your awesome help!). So 9 out of 10 people probably won't do the same and just give up.


Here is my critique about the current situation:

Network Manager:
- Using the console to connect to CS is not feasible for everyday use! It's not so much having a terminal window open all the time but having absolutely no indication if you are actually connected to the network right now or if you were disconnected half an hour ago. It's just a blinking dot and you'd have to check whoer.net every 5 minutes to be sure that you are actually not surfing unprotected.

- The console is also not throwing any error messages about what is going wrong if things go haywire. (Very uncommon behavior for a console I might add.^^) There are lots of problems I would not have been able to debug myself or report to you if I wasn't using the network manager!

- Another problem is that using the console for connecting to CS is prone to fuckups. If you accidentally close the console window the connection does not just drop but Ubuntu rather gets into some strange limbo where you can't disconnect from the VPN but also not reconnect. Only solution: A system restart! This gets very frustrating after the third time.

- A lot of users will also criticize that it's not possible to connect to the VPN via 1 click or (easily) create an auto-connect for every system restart. With the Ubuntu Network-Manager you just configure your VPN-Profile one time and after that it's just a press of a button away for it to connect without entering username and password. (This might sound like luxury but my girlfriend for example would get crazy if she had to work in the console every time she starts the PC. I guess she represents the most common user with that attitude.)


Leakblock:
- You are a man of security and you live by it. I know that because I read enough forum posts of you and I talked enough with you in private to be VERY confident you really mean what you say and rather stop the CryptoStorm project than snitching on a single community member. May it be intentionally or by accident. You build everything to make it inherently secure. With that said you cannot argue in any way that a working leakblock is neglectable when using a VPN. It isn't! VPNs do drop from time to time and when this happens all the security fu black magic is for nothing. Period and end of discussion! (at least for me...) So going with that fact the situation on the leakblock side of things is totally unacceptable. I know the leakblock other so called "VPN-Services" provide are at best questionable. You took the time to show me that in great detail and I understand that so I don't ask you to copy them. What I do ask you is to make this on all OSes number one priority. Screw new exit nodes and shit. As you already said yourself: You have 4 exitnodes going with each soon having at least 5 OS specific instances running on them. (Windows/Linux/MAC/Android/iOS) Things are complicated enough already and people are going crazy with all those configs flying around. I can tell from my newly recruited friend who is no idiot but was happy as fuck there was a widget for windows. People need a "Make it work"-Button!

But I'm drifting off... What I want to say is: I'm very happy I'm on Linux because I can do my own IPtables-Leakblock. But this is also the reason why your talk about the advantages of hostnames over IPs in config files is absolutely irrelevant to me at this point of time. Even if I would be using hostnames (which for some reasons don't work with leakblock activated even though I whitelisted my DNS-Servers) I would run into the same problems as if I use IPs in my config, because my leakblock will block any IP other than the ones I whitelisted. After all this is what a leakblock is supposed to do. So an unexpected change in IPs will negatively affect me no matter what I do.



Conclusion:

So at least on Linux reality is rather different from what you in production might imagine as the current ideal behavior. I think the same goes for MAC but I can't really tell. IMO you need to get your priorities right. We don't need doggy coins, we don't need new exitnodes, or anything else fancy along those lines. We need special instances for every OS, we need a working leakblock and we need a nice client that incorporates all these for all Operating Systems ASAP! Until this is a reality you must accept that people will be either confused to hell or just take things into their own hands thus leaving the path you wish them to stay on.

I know you work hard on all the things I just said here while also debugging existing issues. This rant is not about talking you down or the work you do. But I had to set things into perspective as at least I as a responsible Linux user cannot follow your provision as much as I'd love to and it really frustrates me to see you just repeating those lines. Not because of me. The VPN works flawless for me right now. But I feel sorry for every Linux/MAC user who might not have the time or talent to work out everything like I did and thus cannot enjoy this wonderful VPN! :\
home is where the artillery hits

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: COLLECTION: connection & adress resolving problems

Postby Graze » Tue Jan 21, 2014 6:16 am

I have to say, that is very well written, and very compelling.

I am neither a security geek like some of the others on team, nor a linux expert, but the problem seems to me from my 30,000 foot view to be a problem about priorities. Not just priorities for us, but priorities for our clients. When we started this company, basically, here was our list of goals:

1) Security.

That's it, really. :P So, what that means is that we've sent the techie guys off to do a helluva lot of learning, and what they came back with was some decisions that we KNEW were bad for marketing. We knew we were making things tough by not doing automatic renewals, by choosing latest (and thus less supported) versions (thanks to Snowden insights, partially), etc. etc. but at every one of these junctures we were fighting and someone pointed to that list of priorities and we all sighed and said, ya, that's what we have to do.

Why I'm stating that this list of priorities means we took the hard road. So for that, I guess we sort of apologize for making it hell on everyone in the beta to test and to setup, and (as you point out) something that we'll need to constantly improve on. However, I don't think we're apologizing for making the list, as it's in the interest of our clients. It's the right priority, we think, it's just a lot more work to get close to that 99% done than if we just faked it like so many other companies and made lots of noise about privacy and just copied and pasted what everyone else did. It's just going to take us all a bit longer to work it all out together before we can call it done.

As a couple of asides, the Windows side seems really solid at the moment. There's work there, obviously, but it's the most stable client I've ever used, and I've used a number. It's Linux that apparently needs the tweaking.

Finally, I want to thank you personally: I've been off on other projects off and on, but whenever I come back in here and lurk over posts, your insights and suggestions are always spectacularly "on the mark." So thank you!!!

I'm sure PJ will have some thoughts on the linux/network stuff as that's his world, so I'll go back into lurk mode. :)

Thanks again!
G
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: COLLECTION: connection & adress resolving problems

Postby Pattern_Juggled » Tue Jan 21, 2014 9:53 am

Quick reply right now, as we're in the midst of finishing up the new Icelandic daemons & I don't want to ramble when I could be doing something useful :-)

The Network Manager in Ubuntu (and I'm going to use bold to emphasize this) is a fully-supported, useful connection tool that is preferred by quite a few cryptostorm members. As such, it is our responsibility to support it with config options that make it reliable, easy, and efficient for members to use it.

We were not testing the Network Manager connects independently from command-line Debian validations of every conf file version. That was, to speak bluntly, a fuck-up on our part. I, personally, sort of assumed "someone else" was doing those tests, on the team. As did everyone else. It wasn't added to our formal testing procedure checklist as a separate "OS" for specific testing. As I said, a fuck up - simply put.

So we're looping back to do those tests, update the howto for the Network Manager (if needed), and make any and all sever-side conf tweaks needed to support full Network Manager connectivity (if needed)... up to and including instantiating entirely distinct exitnode daemons with their own IPs for Network Manager session acceptance if needed (I doubt this will be needed, but if it is needed it's not difficult for us to do given our new framework deployment earlier this month).

Further, we've escalated the above-cited testing & tweaking to the top of the queue for Tech Ops.

I've some other comments about how this sort of thing can slip thru the cracks on our end, but I'll save those for a time when they're useful for folks and not just me rambling about internal team process considerations - which most folks, understandably, find painfully boring to read. Short form, however, is that having engaged, outspoken, high-standards network members - such as the folks posting in this thread, above - is HUGELY helpful in resolving stuff like this. That kind of intensity tends to quickly surface any substantive issues, and that surfacing makes it so much more possible to resolve them fast, as well. This is where the community/member engagement in the project becomes enormously valuable for the success and ongoing improvement of the project as a whole.

Cheers,

    ~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

1.3 - Network Manager & Linux terminal config

Postby cryptostorm_team » Tue Jan 21, 2014 9:10 pm

As notice came to us that members were reporting problems with some OS/client combinations when connecting to the correct exitnode instances, we have worked continuously to identify the underlying issue, test solutions, and prepare successful results for the member community to use.

    Summary: we have created a version 1.3 "generic" configuration setting - client & server - which has been tested internally to support both terminal-based and Network Manager-initiated connections with cryptostorm for Linux-housed members. These have been deployed on newly-deployed Linux-specific nodes within our Icelandic exitnodes. Once we have broader member consensus that these 1.3 settings are robust, they will be deployed for Linux instances across the cryptostorm network.

Our testing has confirmed member reports that the Ubuntu "Network Manager" plug-in was not behaving as expected. In particular, problems with --fragment and --mtu directives were noted. This no longer surprises us, as we've seen similar unexpected results with these directives under other OS and client setups, as well. The result was that terminal-based Linux connections behaved as expected (and as tested), but Network Manager connections threw negative results for connected members, caused by variances in packet sizes that, in turn, result in 100% failure of HMAC validation and thus complete absence of successful data transfer via the "data" channel of the session framework.

Systematic validation of these results confirmed that numerous configuration versions that, in theory, were structurally sound would either be correctly parsed by the terminal-based client, the Network Manager, or neither... but not both concurrently.

Additional exploration of the configuration landscape identified a combination of parameters that finds correct parsing both via terminal and Network Manager, as well as retaining all necessary security components within the larger cryptostorm framework itself. Internal testing has validate first-tier performance and secure session capabilities, and the configuration - version 1.3 nomenclature - is being released for member testing prior to being fully deployed. At present, the 1.3 framework is limited to the Icelandic exitnode cluster.

The relevant client-side configuration file is included below.

Tested Network Manager connections successfully imported the 1.3 configuration file, as posted below. If members find that additional steps are needed to support successful Network Manager connections, we will summarize them in the relevant connection guide thread, for broader availability.

Mappings for --remote parameter to support "raw"/Linux connections to the Icelandic exitnode are, per cryptostorm convention, of the form: cluster-iceland.cryptostorm.net - additional mappings of raw-iceland.cryptostorm.net are also mapped and supported. Per cryptostorm-wide production standards, four-tier TLD redundancy is provided and supported for all cluster hostname mappings - and is included in the below-attached 1.3 configuration framework.

Finally, we have not been able to test this 1.3 version under Viscosity and Tunnelblick, and thus do not know if it will find concomitant success under these OS/platform environments. We ask that members provide their results when 1.3 is put to use on these platforms, and based on that input one of two decisions will be made: either we'll continue to include these OS/platform flavours within the "raw"/Linux versioning during the roll to 1.3 across the network, or we will further fork the framework to expose Mac-specific daemons to optimally support members coming to the network from these platforms. In preparation, we have soft-reserved internal IP assignments for use in these Mac-specific connection platforms.
cryptostorm_client_raw-iceland1_3.conf



Reminder: all remnants of configuration files in this thread are very old, and you should NOT try to use them to connect; They won't work anyway. Please refer to this thread instead for current, working configurations.

Code: Select all

# this is the cryptostorm.is client settings file, versioning...
# cryptostorm_client_raw-iceland1_3.conf

# it is intended to provide connection solely to the Iceland exitnode cluster
# DNS resolver redundancy provided by cluster-iceland randomised lookup queries
# Chelsea Manning is indeed a badassed chick: #FreeChelsea!
# also... FuckTheNSA - for reals


client
dev tun
resolv-retry 16
nobind
float

remote-random
# randomizes selection of connection profile from list below, for redundancy against...
# DNS blacklisting-based session blocking attacks


<connection>
remote cluster-iceland.cryptostorm.net 443 udp
</connection>

<connection>
remote cluster-iceland.cryptostorm.org 443 udp
</connection>

<connection>
remote cluster-iceland.cryptostorm.nu 443 udp
</connection>

<connection>
remote cluster-iceland.cstorm.pw 443 udp
</connection>


comp-lzo no
# specifies refusal of link-layer compression defaults
# we prefer compression be handled elsewhere in the OSI layers
# see forum for ongoing discussion - https://cryptostorm.org/viewtopic.php?f=38&t=5981

down-pre
# runs client-side "down" script prior to shutdown, to help minimise risk...
# of session termination packet leakage

allow-pull-fqdn
# allows client to pull DNS names from server
# we don't use but may in future leakblock integration

explicit-exit-notify 3
# attempts to notify exit node when client session is terminated
# strengthens MiTM protections for orphan sessions

hand-window 37
# specified duration (in seconds) to wait for the session handshake to complete
# a renegotiation taking longer than this has a problem, & should be aborted

mssfix 1400
# congruent with server-side --fragment directive

auth-user-pass
# passes up, via bootstrapped TLS, SHA512 hashed token value to authenticate to darknet

# auth-retry interact
# 'interact' is an experimental parameter not yet in our production build.

ca ca.crt
# specification & location of server-verification PKI materials
# for details, see http://pki.cryptostorm.org

<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAPXIBgkKVkuyMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTEzMTAxMTEz
NDA0NloXDTE3MDYwOTEzNDA0NlowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDS4TuqOoT6NrE7oNXj5il97Ml306F9rmEf22+E/5uCsiTNL7inanLsDixihq2l
e0anBK8UvDPExYIWLpXu4ERFFsWS//AoZer8BlVYKnEEgzPh5UV8Jy2TyOlZ26Yz
g1A4MRcDFdPUXLq5Z8hw09k1uqOPU6trv5J+5TwhzMHrMunip8hvx8uXjzQ4DLPK
RKfRzwl+2ydyXgAGdfY1zLlvYvzvVUc4GcLXmAOLT4ZjWKxl4MoqNwf9VBfdLWn5
mWuYp/tT3RxNjKHnuqZlYhCvfWp1hbzSW/OdlO13B1C/PSfFnfFzlANWh31bfvos
pbCIFYG6RXIiP+Arc2sLVgTHAgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUWmCUeZzm
Qa+zcOA+KWfNF1e2Z9cwge8GA1UdIwSB5zCB5IAUWmCUeZzmQa+zcOA+KWfNF1e2
Z9ehgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQD1yAYJClZLsjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQDKDYRtxELcCUZwnGvQa8hp5lO/U87yYzOSP3OON4hBS6YWEmRyV3GvZtGibadl
8HbOU0TRS1skcS0g8OfiY+t/qitIpBuLMHgJHubBMWQ5SP9RlSy2ilxt7J+UGbw3
Xi6u7RRG1dOEZkN0RxpbZQeGf7MD6RTI+4JMRvstI0t2wpfAk0eF0FM++iqhR9mu
aH8apEFDUvCQv4NnDrXJqDUJi8Z56SHEJQ5NMt3ugv7vtY3kI7sciuPdW3hDPsJh
/T3cOWUeYeIVknVHwMuUFf6gdxZ8crrWkANpjwOm0gVh1BPRQzXXPKlSVUGgEVFD
XgJyvkX663aTcshEON1+bXp6
-----END CERTIFICATE-----
</ca>

ns-cert-type server
# requires TLS-level confirmation of categorical state of server-side certificate for MiTM hardening.

auth SHA512
# data channel HMAC generation
# heavy processor load from this parameter, but the benefit is big gains in packet-level...
# integrity checks, & protection against packet injections / MiTM attack vectors

cipher AES-256-CBC
# data channel stream cipher methodology
# we are actively testing CBC alternatives & will deploy once well-tested...
# cipher libraries support our choice - AES-GCM is looking good currently

replay-window 128 30
# settings which determine when to throw out UDP datagrams that are out of order...
# either temporally or via sequence number

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
# implements 'perfect forward secrecy' via TLS 1.x & its ephemeral Diffie-Hellman...
# see our forum for extensive discussion of ECDHE v. DHE & tradeoffs wrt ECC curve choice
# http://ecc.cryptostorm.org

tls-client
key-method 2
# specification of entropy source to be used in initial generation of TLS keys as part of session bootstrap

log devnull.txt
verb 5
mute 1
# sets logging verbosity client-side, by default, to zero
# no logs kept locally of connections - this can be changed...
# if you'd like to see more details of connection initiation & negotiation
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

Mousy
Posts: 18
Joined: Thu Oct 31, 2013 5:12 pm

Re: COLLECTION: connection & adress resolving problems

Postby Mousy » Tue Jan 21, 2014 10:53 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Guys,

Thanks for sorting out the new Iceland exit node, I was having lots of problems with the old configuration file using Viscosity on OS X 10.9. I've now been using the new cluster for about 45 minutes, I've been getting blazing fast speeds with no connection issues whatsoever!

Excellent work all round!

Just for completeness, I've been using the following to connect:

Config: cryptostorm_client_raw-iceland1_3.conf
OS: OS X 10.9.1
Viscosity VPN client

Fun fact:

When importing the cryptostorm_client_raw-iceland1_3.conf file into the Viscosity VPN client, it shows up as four distinct connections rather than one like so:

Image

Now, I'm just guessing but could this be because there are four distinct connections inside the configuration file? And do you think there are any security concerns with this behaviour?

Thanks again

Mousy
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJS3rPGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RkQ5REY4NUVEMTQwRDZFNUYyMDZCMjA3
NURBOEMzNDc2NERENDg0AAoJEHXajDR2TdSEJVMH/i8rvIVh6tz15fdC9WMZNjn+
qo1mzekjQ8wTn1TGo8eb+T3e5aB1afVqbdyQAADCK+HVOn9lTT0OjImki8FRU6J8
yF+kgCji2jnMiLYgdde8W9+Hbl9kesBuSmFytSMgl3nm9vkQHuQK/rLAcdINnvZ1
brrdh/tqGhz52zVpK9nYswBzVIURHM5HFtivVkq9PevCpcq3DKMtGKyWA0GGExNd
P+zIsLhLtpvOQSc1Ha/DO/qE9GZjw/6ZgvfAgGEABmIlJipOcwBx+u2EK6Uw75//
dUXGiHMBtT7kwCN4uMbk+MoU/xW/TC0b7Sw3hH5X52XWNV8w3NvDjZfp/tzvuZI=
=QZ6/
-----END PGP SIGNATURE-----
    Key ID: 0x75DA8C34764DD484
    Key Fingerprint: 5FD9 DF85 ED14 0D6E 5F20 6B20 75DA 8C34 764D D484
    Download My PGP Key.

Mahatma Gandhi wrote:First they ignore you, then they laugh at you, then they fight you and then you win.

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: 1.2 conf Linux/Tunnelblick connect problems & solutions

Postby DesuStrike » Wed Jan 22, 2014 5:01 am

I'm using the new 1.3 config for RAW/Iceland with Ubuntu Networ-Manager and it's working totally fine. Whatever you did behind the scenes (because neither server conf nor client conf differ other than mssfix afaik) is working great.

I know you hate this but I had to change the hostnames to an IP because of my leakblock. It makes me happy to see that you already planned a feature for future leakblock inside the config file. Maybe this DNS push method will help clients to connect via hostnames. :)

Anyways: Thanks a lot! I hope you see lots of positive network traversal statistics on Icleand exitnode so this can be pushed to all exitnodes soon!

I'll continue using Iceland as much as I can so you get enough traffic to evaluate everything.

Cheers!


EDIT: The performance is a bit choppy. The download speed is a bit volatile and lower than what I get on the other exit nodes. I guess this is rather due to the heavy load on the exit node than actually a configuration problem. Still I wanted to report it.
home is where the artillery hits

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

redundant TLDs & <connection> profiles in .conf's

Postby Pattern_Juggled » Wed Jan 22, 2014 4:21 pm

Mousy wrote:Now, I'm just guessing but could this be because there are four distinct connections inside the configuration file? And do you think there are any security concerns with this behaviour?


I am confident that your explanation is correct, in that there's four distinct <connection> profiles within each config file.

There's no security issues with this, because those four connections all resolve to exactly the same underlying IPs (or, more accurately, round-robin within the same pool of IPs) - there's four of them to ensure that, if a firewall or other bad entity does a domain-based block of one of the TLDs in question, connections are still successful.

For example, if some censor someplace thinks "ok, enough with this cryptostorm nonsense - I can't do my censorship duties if people are just routing around my list of banned materials... so I'll just go to our BGP routers for my country, and add cryptostorm.net to the blacklist - that way, nobody can connect since they won't be able to find the exitnodes without being able to resolve that domain name, so there!" - there's three fallback TLDs: .org, .nu, and .pw.

Obviously, someone can block all four - but we've striped them across divergent registrars and registration authorities so it's less simple to do a blanket ban on them at the TLD level itself. Further, if someone does a "registrar attack" where they try to de-register or freeze one of the canonical domains itself, there's redundancy in the others. Freezing all four would take some work, because of the divergence in registrar foundations. We're in process of adding a whack more, from diverse TLDs, to further harden against this.

In any case, this is a layer of the connection methodology that is designed to be redundant - any of them will work, and there's only four to improve network-wide resilience. I still have a draft essay on the OO-structured framework underlying this three-tier exitnode-lookup procedure we've implemented... but we've been a bit busy implementing to allow for time to get that essay polished for publication. Someday, I promise! :angel:
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: 1.2 conf Linux/Tunnelblick connect problems & solutions

Postby Pattern_Juggled » Wed Jan 22, 2014 4:26 pm

DesuStrike wrote:EDIT: The performance is a bit choppy. The download speed is a bit volatile and lower than what I get on the other exit nodes. I guess this is rather due to the heavy load on the exit node than actually a configuration problem. Still I wanted to report it.


Thanks to Datacell, we've got capacity to burn in the Icelandic cluster - serious capacity. So it's not a gross capacity bottleneck.

Rather, we're still fine-tuning some of the kernel-level usage of physical resources. The machines in question are, to be blunt, higher-horsepower than anything I've personally deployed previously (in terms of cores/CPUs and RAM); we're learning how to make use of all that horsepower in the context of our network/crypto framework.

For the next few days, that might result in a bit of swing when it comes to session throughput - unfortunately, the only way to really test out most of these settings is in production: apply them, see what happens for a few hours, compare notes, fine-tune. They're all kernel or NIC-level params, so there's no resets of SIGHUPs of the daemons themselves, no worries there.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Leakblock & focus

Postby Pattern_Juggled » Wed Jan 22, 2014 4:49 pm

DesuStrike wrote:So at least on Linux reality is rather different from what you in production might imagine as the current ideal behavior. I think the same goes for MAC but I can't really tell. IMO you need to get your priorities right. We don't need doggy coins, we don't need new exitnodes, or anything else fancy along those lines. We need special instances for every OS, we need a working leakblock and we need a nice client that incorporates all these for all Operating Systems ASAP! Until this is a reality you must accept that people will be either confused to hell or just take things into their own hands thus leaving the path you wish them to stay on.


I hear you on the Leakblock deployment, and I accept your critique.

As I often end up being the one on the team who (by default, mostly) ends up deciding on macro-level resource allocation, I'm accountable for those decisions - good or bad. We've been holding off on the final push for a production Leakblock engine as we've been working thru the various layers of tuning necessary to move from beta (where we're still, technically, at) into full production.

And, good or bad, it is my nature to focus obsessively on a small set of things at a time. In English we have the saying: "don't put all of your eggs in one basket," with similar aphorisms in French and Spanish (as well as other languages, I'm quite sure). One of my academic mentors had a favourite rejoinder to that, which she shared liberally when the opportunity arose: :fuck that - put them all in one basket, make sure it's a good basket... and watch that basket fucking close!"

Indeed.

Particularly in the tech world, getting a team spread too thin over too many cool projects is a path to disaster - particularly when it comes to security-intensive services. If it makes anyone feel better, I can assure you that our team is even more fed up with my tendency to watch that basket fucking close, versus haring off onto the next iteration of cool stuff. And we do have a roadmap of cool stuff to come: layer after layer of expansions, enhancements, additions, and kick-ass new approaches to deploy. It'll be great.

But first, we make the core framework sing. Perfectly. And by "perfectly," I mean... perfectly. You know what my target number of customer service queries is per day? Zero. Exactly zero... because, when everything works right, there's no need for customers to waste time and effort asking for assistance in the first place. One member problem per day is one too many - we'll resolve it for her, of course... but it's still a failure. The optimal number is: zero.

We're close, actually. We go for days at a time without a single reported "issue" with the network - from any members, connected via any OS or platform. Not to get cocky, but that's not too shabby... given our member usage metrics, hitting zero even for one day is... well, it's unprecedented in the "VPN service" industry. I'd know, as I helped create this industry from nothing.

It's also funny, because "not having any customer service issues" is not really one of those marketing-hype buzzphrases that make for good PR spin; it should be, but it's not. However, as Graze eloquently pointed out, our priorities are all about member security - first, second, third, and fourth. Support issues impact that security, because a member with an "issue" connecting or staying connected is not being secured effectively. Q.E.D. Likewise, bad user-interface or ease-of-use considerations impact security, because clunky tools push members away from using them and/or result in use that isn't congruent with optimal security procedures.

Which is all to say: Leakblock's crucial, agreed. But it's not "more crucial" than having the core foundation rock-solid, reliable, and scalable. As much as parallel development seems tempting, it rarely if ever works - tech life ends up being serial, mostly: do this, then do that. And we could stick resources on Leakblock who aren't core to the cryptostorm team - but doing so means that the expertise and hard-won wisdom of the core team isn't being invested in every little element of the Leakblock framework. And that's not acceptable - we need that expertise. There's no shortcuts.

Leakblock is marketing catnip, so we've been pushed by some folks to "just get it out there" so we can hype it and drive membership. Yeah, makes sense... except, fuck that. Nope. It'll go out when it's fucking badassed, stable, and something of which we're proud. Of course, it won't be perfect on day one - that's what beta testing is about. But you can't "beta test" a framework, or an ontological pinning, or a choice in foundational technical architecture. You either do it right, or you throw it all out and start from scratch. Those, yet again, are decisions that rarely get alot of glamorous marketing adoration - but they're the ones that really matter.

If one walks thru a minefield and nothing happens, that's a good thing. Indeed, it's wonderful.

We're not in the business of making a bunch of noise and playing the part of "being secure." We do our best to be secure, period. That means some stuff gets delayed as we work on the core elements, but that's just how it goes. The good news is that, when one resolves to do one thing and do it brilliantly, one is able to set those things in motion and move forward to the next new thing confident that the prior won't come undone the minute it's not being hand-managed.

Measure twice, cut once.

~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: Linux/Tunnelblick connect snags | RESOLVED (via 1.3 conf

Postby DesuStrike » Wed Jan 22, 2014 8:25 pm

Thanks for the special reply to this one topic.

In my personal view a working leakblock is part of the overall security construct. It's like a safety net if something goes wrong and you happen to fall out of the Safe Haven that is named cryptostorm-darknet.

But I also see your point that a leakblock gets rather irrelevant if the underlying security of the VPN is not perfect because then you can be compromised even if you don't accidentally fall out of your crypto bubble.
So yes, I understand that and support your procedures there. The absence of a leakblock is still frustrating and brings it's own set of problems but I think we just have to grit our teeth and tackle those remaining session problems and then we can together work on getting a working leakblock out there. :)


PS: The figure of speech with the eggs does not work in German BUT you will love the German equivalent!
"Man sollte nicht alles auf ein Pferd setzen!" --> "You shouldn't bet all your money on one horse!"
home is where the artillery hits


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Linux 1.3 Frankfurt conf now available

Postby cryptostorm_ops » Wed Jan 22, 2014 8:26 pm

We've just released the 1.3 "raw"/Linux connection profile and concomitant server-side updates for the Frankfurt exitnode cluster. They have been posted up via the usual conf.cryptostorm.org location, and we are also posting a copy here for ease of access.

As we have the Icelandic cluster - and its 1.3 nodes - offline currently to complete final hardware adjustments & performance tuning, we have pushed to put this Frankfurt Linux cluster into production for those seeking a short term 1.3 alternative.

Finally, this Frankfurt 1.3 update was pushed through internal testing faster than usual. Please, if any unexpected behaviors are seen we ask that you note them here or in an email to our support team so that we can immediately research and rectify them.

Thank you.

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: Linux/Tunnelblick connect snags | RESOLVED (via 1.3 conf

Postby Pattern_Juggled » Wed Jan 22, 2014 8:44 pm

DesuStrike wrote:"Man sollte nicht alles auf ein Pferd setzen!" --> "You shouldn't bet all your money on one horse!"


That, naturalisch, depends on the specific horse in question! :thumbup:
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: Linux/Tunnelblick connect snags | RESOLVED (via 1.3 conf

Postby DesuStrike » Wed Jan 22, 2014 9:02 pm

I just tested the new config. It works great, everything resolves fine and it's very fast in both ping and up/down terms! :)

There is a very funny behavior though: I can only connect to it when I'm using hostnames. If I use the IP (46.165.222.246) the connection attempt times out. The icleand exit node today shows the same behavior even though yesterday I was able to connect to it fine via IP.

I know you cannot provide offical support for this but I guess it's interesting to know. Also I don't understand how this is possible at all.
home is where the artillery hits

User avatar

Topic Author
DesuStrike
ForumHelper
Posts: 345
Joined: Thu Oct 24, 2013 2:37 pm

Re: Linux/Tunnelblick connect snags | RESOLVED (via 1.3 conf

Postby DesuStrike » Thu Jan 23, 2014 7:13 pm

UPDATE!

I was so used to the fact that hostnames don't work with my leakblock that I didn't test it with the Config Version 1.3

Well, dress me up and call me Sally because I tried cryptostorm_client_raw-frankfurt1_3.conf out of curiosity and BAM! It works! 8-)

Good job CryptoStorm Team! :thumbup:
home is where the artillery hits


cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

1.3 upgrade complete

Postby cryptostorm_ops » Mon Jan 27, 2014 6:41 pm

Please note that all of the client configuration files for Linux/"raw" connections have now been upgraded to 1.3 versioning. This includes both cluster-specific connection profiles, as well as the locked/dynamic network-wide meta-profiles.

They have been, per standard, posted to the canonical conf.cryptostorm.org resource in order to be available for production deployment.

Anyone using earlier versions of the configs is strongly encouraged to update. We have done our best to support backwards-compatability, but it has not been possible to provide full coverage of all prior config versions without crippling performance improvements. As such, use of earlier configs is likely to result in sporadic, unreliable network connectivity.

We do not expect to be deploying substantive changes to these Linux/"raw" 1.3 configuration profiles for some time; major functionality updating has been compressed into this one, larger break with prior versioning. It has not been convenient for network members, and we regret that - however, in doing so, we've cleared a path forward with no visible roadblocks looming ahead.

Thank you,

~ cryptostorm_ops


Return to “member support & tech assistance”

Who is online

Users browsing this forum: Bing [Bot] and 21 guests

Login