Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

1.4 config files: bugtracking, feedback, discussion, questions, etc.

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
User avatar

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

1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby Pattern_Juggled » Wed Oct 01, 2014 3:37 am

note: folks seeking the most current client configuration files need not wade through this entire discussion thread! The current versions are always posted in a separate, dedicated thread, and will be continuously updated there. Continue reading this thread if you're curious about the details of the config files, want to see earlier versions of them, or have comments/feedback to provide - thanks! :thumbup:

I've shamelessly repurposed this older thread (as of 12 January) 2015, in which early-beta 1.4 conf's were distributed, since the 1.4 files are now in official production over at cryptostorm.org/conf. That's a locked thread, so I'm opening this as a more freewheeling place to do fine-grained analysis of these upgraded connection configurations.

Right off the bat, I expect there's still some bugs and small errors in at least a few of these... and, much as I hate to say it, likely still an error or two in the many hundreds of HAF-compliant hostname A Records that sit behind this whole endeavour. I've done every one of those edits myself, manually, over a period of several months of intermittent effort. Despite triple-checking every one, I just know that the statistics work against us on this one: somewhere in there, an IP address is mis-mapped. It's all but inevitable. This is not a security issue; the worst-case is basically that a windows member gets unintentionally routed to a Linux instance, which won't be happy with the slight variances in the sessions they support.

Also, let me speak bluntly: I killed off any mappings to pre-heartbleed cert instances. This was a huge debate amoungst the team; I'm not really sure who is right, in terms of the differing positions. I will say this: as our cryptographic specialist I can't say the pre-heartbleed instances worried me at all (long, boring discussion to explain why). However, in an operations framework, the decoupled certificate materials were a nightmare - and that was keeping people off the network. That is, therefore, a security matter - and I pull rank to make that decision, and thus improve member security overall.

I have no doubt some folks will be connecting in coming hours and days, and having inexplicable "certificate mismatch" errors all the sudden. Those'll be pre-hb cert fingerprints running up against post-hb instances. It's going to happen. I'm sorry for the hassle, but it's got to be done. The number of folks impacted will be small, but it's still something we hate to have to do.

So please report problems, bugs, typos, etc. here. The formal academic in me would keep fiddling with these 1.4 versions essentially forever, to ensure they are bug-free. That's not practical - we have to get them into production. So, as usual, we're counting on member and community feedback to help fine-tune these into the elegant little info-sculptures they're meant to be.

And yes, if something in them sucks or is broken - I am more or less solely to blame. The nature of this sort of work is that two people tend to have a harder time than one person working alone, and three even more so. It's tedious, detail-intensive, exhausting, important work... I love it, but if there's errors you've nobody to blame but me. I apologise in advance if I did not hit the standard I set for myself in finishing these, but on balance I am happy with the work done. Indeed, the benefits of HAF compliance are... enormous.

Also... how about all those bloody limes! :angel:

IMG_20141211_095709.jpg


Cheers,
~
    ~ pj

User avatar

cryptostorm_admin
ForumHelper
Posts: 74
Joined: Tue Jan 01, 2013 5:43 pm
Contact:

draft 1.4: dynamic balancer, Mac/OSX

Postby cryptostorm_admin » Sun Nov 02, 2014 11:26 am

Here is a draft 1.4 version of the Mac/OSC config file for the dynamic loadbalancer pool. It is currently undergoing final in-house testing, and as such if members are interested in a test-drive we're certainly appreciative of any feedback pro or con.


There are not major changes to this config as compared to the 1.3 version - most of the upgrades are being done via HAF-based loadbalancer refinements in the network infrastructure itself.

Thank you,

~ cryptostorm_admin


edit: added <br> after CA delimiters, because Tunnelblick is very picky about that; final proposed release version replaces previous attached conf.

EDIT: removed out-of-date config files
- cryptostorm_support

User avatar

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

central US & Lisbon (Portugal) draft 1.4 conf's

Postby Pattern_Juggled » Sat Dec 27, 2014 5:58 am

Here's the draft 1.4 conf versions for our Lisbon and central US exitnode clusters.

Please do note that some fine-grained details of these are likely to change before final release and inclusion in the top post of this thread. Such edits will be small - a few parameters fine-tuned to reflect new syntax in the openvpn protocol - and will not result in any compatability issues for those using these pre-release 1.4 versions - but we do want to make it clear there might be a few.

Larger updates to the conf's, including a few additional hardening tricks against some fairly esoteric forms of DDoS/DoS attacks on the network overall, will be collected into a 1.5 conf release scheduled for Q1 2015. Nothing in 1.5 will require folks to upgrade from 1.4 (thanks to the HAF methodology) and indeed we're working hard to ensure that any required conf updates are very few and very far between... if needed at all.

Anyway, these are HAF-compliant and will work with the existing clusters in Lisbon and the midwest US; for those who simply want to those clusters and prefer not to wait for the final little fiddling before release, here you go:



Cheers,

    ~ pj

EDIT: removed out-of-date config files
- cryptostorm_support


loop

Re: 1.4 config files (draft versions posted here)

Postby loop » Sat Dec 27, 2014 1:25 pm

On the uscenteral node the address linux-uscentral.cryptostorm.nu routes to wrong address.

User avatar

cryptostorm_support
ForumHelper
Posts: 296
Joined: Sat Jan 26, 2013 4:31 am
Contact:

Re: 1.4 config files (draft versions posted here)

Postby cryptostorm_support » Sat Dec 27, 2014 3:51 pm

loop wrote:On the uscenteral node the address linux-uscentral.cryptostorm.nu routes to wrong address.


I've just checked the resolution from several machines in the network, and it appears to resolve to the intended instance (linux-mishigami1 | 167.88.9.27)l; are you seeing the same results, or is that instance not behaving as expected.

Thanks,

cryptostorm support


loop

Re: 1.4 config files (draft versions posted here)

Postby loop » Sun Dec 28, 2014 4:33 am

Sorry about that posted the wrong address it's linux-uscentral.cstorm.pw

Name: linux-uscentral.cstorm.pw
Address: 79.134.255.83


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

Re: 1.4 config files (draft versions posted here)

Postby cryptostorm_ops » Sun Dec 28, 2014 11:13 am

loop wrote:Sorry about that posted the wrong address it's linux-uscentral.cstorm.pw

Name: linux-uscentral.cstorm.pw
Address: 79.134.255.83


Excellent catch. The HAF entry was actually nonexistent, and our DNS resolvers were providing essentially a default value - which isn't an instance-mapped IP at all.

In doing some testing on this, it appears the TLD registrar's domain management system has an odd behavior when faced with hostnames including capital letters. The HAF entries were, in some of our internal systems, listed as "UScentral" - when those were added as A Records, they simply didn't get processed by the registrar. No error, no warning, the commit screen appears successful - but the entry has not been made.

It's fixed now, and we'll be more careful in our assumption that input scrubbing is being done on such fields, with respect to capitalisation, in the future.

Thanks again,

cs ops

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: 1.4 config files (draft versions posted here)

Postby DesuStrike » Mon Dec 29, 2014 12:00 am

I don't see a discussion thread so I reply here:

I wonder whats the difference between V1.3 and V1.4.

I use the V1.3 configs for all nodes and aside from the hostnames which I don't use it's identical to the V1.4 configs posted here. :eh:
home is where the artillery hits


loop

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby loop » Tue Jan 13, 2015 1:14 am

These addresses don't route correctly.
linux-paris.cryptostorm.net
linux-uswest.cryptostorm.nu

When trying to resolve addresses getting this.
server can't find linux-paris.cryptostorm.net: NXDOMAIN
server can't find linux-uswest.cryptostorm.nu: NXDOMAIN

uscenteral is missing this in the configs.
persist-tun
persist-key

Other than that the new conf's look great. Good work staff.

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby DesuStrike » Tue Jan 13, 2015 1:46 am

loop wrote:These addresses don't route correctly.
linux-paris.cryptostorm.net
linux-uswest.cryptostorm.nu


Confirmed.
I did a quick check and can reproduce these results.
home is where the artillery hits

User avatar

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

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby Pattern_Juggled » Tue Jan 13, 2015 8:31 pm

loop wrote:These addresses don't route correctly.
linux-paris.cryptostorm.net


Got it - this one was missing from the entries I did. Added now, and should resolve clean per my tests from a few nodes.

linux-uswest.cryptostorm.nu


This one was already in the entries pushed up to the registrar for cryptostorm.nu; perhaps it propagated slowly? Here's what I get:

[root@fenrir windowsvpn-newcert]# nslookup linux-uswest.cryptostorm.nu
Server: 79.134.240.23
Address: 79.134.240.23#53

Non-authoritative answer:
Name: linux-uswest.cryptostorm.nu
Address: 23.19.35.14


...so let me know if you're still seeing resolve-fails for it from somewhere, ok?

uscenteral is missing this in the configs.
persist-tun
persist-key


Ack, yes - I thought I'd propagated those across all the conf's. I'll add that and re-up right now.

Other than that the new conf's look great. Good work staff.


Thanks so much for helping to track down these bugs!

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

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

Re: new exitnode cluster: London (UK) | 1st node: turing.cryptostorm.net

Postby marzametal » Wed Jan 14, 2015 4:04 am

Paris:onyx:windows:windows-paris.cstorm.pw
Paris:alors:windows:windows-paris.cstorm.pw

Do they point to the same node?
Tried connecting to Mishigami, but TLS handshake error and then it went to connect to 212.129.25.237 (in France, but not Onyx, possibly Alors?)

User avatar

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

Re: new exitnode cluster: London (UK) | 1st node: turing.cryptostorm.net

Postby Pattern_Juggled » Wed Jan 14, 2015 3:57 pm

marzametal wrote:Paris:onyx:windows:windows-paris.cstorm.pw
Paris:alors:windows:windows-paris.cstorm.pw

Do they point to the same node?


...not any more, I hope! :-)

(you likely caught the nodelist just as we were adding a new machine in Paris, "alors" - I've confirmed it's mapped properly via HAF entries, so if there's any snags at this point I blame df!

Tried connecting to Mishigami, but TLS handshake error and then it went to connect to 212.129.25.237 (in France, but not Onyx, possibly Alors?)


Mishi is in re-provisioning currently; the widget then tried a fallback connection to a secondary machine when Mishi wasn't available, and managed to hit an instance on alors... likely right before alors went fully live. Let us know if you're still seeing any snags on alors connects, ok?

Cheers,

~ pj

ps: moved these two posts over the 1.4 thread, for clariy.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

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

User avatar

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

Re: configuration/connection files for cryptostorm! (rev. 1.4)

Postby parityboy » Wed Jan 14, 2015 5:09 pm

@OP

What does the "smoothed" config do?

p.s. Thread locking obviously doesn't work. :P

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: configuration/connection files for cryptostorm! (rev. 1.4)

Postby DesuStrike » Wed Jan 14, 2015 5:43 pm

afaik dynamic switches you to a new random node with every reconnect from a lost connection. So if you've got an unstable mobile connection for example, you will regularly switch IPs.

smooth on the other hand gives you a random IP on first connection and then "locks you in" for the duration of the session even if you temporarily lose connectivity. To get a new IP you have to end the session and start a new one.
home is where the artillery hits



ballast

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby ballast » Thu Feb 12, 2015 2:03 pm

I'm having trouble connecting, get the same error for all nodes and booted back to command line. I'm running Arch Linux and have added

Code: Select all

auth-user-pass password


Where password is a plaintext file with the hashed token.

Code: Select all

Option 'explicit-exit-notify' in cstorm_linux_iceland_1-4(1).conf:53 is ignored by previous <connection> blocks
 Option 'mssfix' in cstorm_linux_iceland_1-4(1).conf:61 is ignored by previous <connection> blocks


ballast

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby ballast » Thu Feb 12, 2015 2:17 pm

Trouble connecting to any nodes.

Using Archlinux, 1.4 configs. I pass hashed token by doing:

Code: Select all

auth-user-pass password


This was working before in 1.3.

I get these errors, and then booted back to command line.

Code: Select all

Option 'explicit-exit-notify' in cstorm_linux_london_1-4.conf:53 is i
Option 'mssfix' in cstorm_linux_london_1-4.conf:61 is ignored by prev


User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby DesuStrike » Fri Feb 13, 2015 4:08 am

I probably know whats wrong:
In the plaintext password file you need to put the token in the first line and some random characters in the second line. The token alone isn't enough!

For example:

Code: Select all

*YOUR HASHED TOKEN*
sgwer43t34tgerter
home is where the artillery hits

User avatar

Operandi
Posts: 88
Joined: Fri Nov 22, 2013 4:23 pm

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby Operandi » Fri Feb 13, 2015 1:27 pm

ballast wrote:I pass hashed token by doing:

Code: Select all

auth-user-pass password

You're doing it wrong.

From the OpenVPN wiki:

--auth-user-pass [up]
Authenticate with server using username/password. up is a file containing username/password on 2 lines [...]

If up is omitted, username/password will be prompted from the console.

And, as far as I know, the password should be:

Code: Select all

93b66e7059176bbfa418061c5cba87dd

(See http://beta.cryptostorm.org/ for details.)


ballast

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby ballast » Fri Feb 13, 2015 7:55 pm

I was using "password" as a plaintext file, first line hashed token, second line about 20 letters of gibberish for password.
Changed to Operandi's suggestion of default password, still the same problem.

openvpn version

Code: Select all

openvpn-2.3.6-1

traceroute:

Code: Select all

cryptostorm.is: Name or service not known
Cannot handle "host" cmdline arg `cryptostorm.is' on position 1 (argc 1)


Still no luck.

User avatar

Fermi
ForumHelper
Posts: 217
Joined: Tue Jun 17, 2014 11:42 am

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby Fermi » Fri Feb 13, 2015 10:19 pm

conf files and openvpn version 2.3.6

When connecting with the 1.4 conf files using the openvpn command, you'll see the following warning:
Option 'explicit-exit-notify' in cstorm_linux_dynamic_1-4.conf:125 is ignored by previous <connection> blocks
Option 'mssfix' in cstorm_linux_dynamic_1-4.conf:133 is ignored by previous <connection> blocks

This behaviour seems to be new in version 2.3.6 . I've verified on windows an linux.
If the conf file contains connections ex:
    <connection>
    remote linux-london.cryptostorm.net 443 udp
    </connection>
and you want to apply the explicit-exit-notify and mssfix option to all 'connection items', than these two options need to in front of 'remote-random' .

When you use verbosity 6 you'll see these settings propagating throughout all 'connection items'

If you leave as is, propagation will not happen.

/Fermi

User avatar

Fermi
ForumHelper
Posts: 217
Joined: Tue Jun 17, 2014 11:42 am

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby Fermi » Fri Feb 13, 2015 10:23 pm

ballast wrote:Trouble connecting to any nodes.

Using Archlinux, 1.4 configs. I pass hashed token by doing:

Code: Select all

auth-user-pass password


This was working before in 1.3.

I get these errors, and then booted back to command line.

Code: Select all

Option 'explicit-exit-notify' in cstorm_linux_london_1-4.conf:53 is i
Option 'mssfix' in cstorm_linux_london_1-4.conf:61 is ignored by prev



ballast,

for the warnings on the options see: viewtopic.php?f=51&t=8451&p=13277#p13277
These warnings shouldn't prevent you from connecting ...

/Fermi

User avatar

Fermi
ForumHelper
Posts: 217
Joined: Tue Jun 17, 2014 11:42 am

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby Fermi » Fri Feb 13, 2015 10:29 pm

ballast wrote:I was using "password" as a plaintext file, first line hashed token, second line about 20 letters of gibberish for password.
Changed to Operandi's suggestion of default password, still the same problem.

openvpn version

Code: Select all

openvpn-2.3.6-1

traceroute:

Code: Select all

cryptostorm.is: Name or service not known
Cannot handle "host" cmdline arg `cryptostorm.is' on position 1 (argc 1)


Still no luck.


ballast,

Can you connect without the password file (manually providing hash and pwd)?
The password file needs to be in the same directory as the conf file?
Perhaps you can post logging ... .

/Fermi


ballast

Re: 1.4 config files: bugtracking, feedback, discussion, questions, etc.

Postby ballast » Wed Feb 18, 2015 2:17 pm

Thanks everyone.

Fixed it. Was some weird netctl thing. Switched to NetworkManager and works a treat now.


Return to “general chat, suggestions, industry news”

Who is online

Users browsing this forum: Yahoo [Bot] and 10 guests

Login