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

Montreal cluster - background & discussion

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!
User avatar

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

Montreal cluster - background & discussion

Postby cryptostorm_admin » Thu Jul 24, 2014 6:27 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:

Within the next couple of days, the cryptostorm admin team is finishing deployment of an upgrade/migration of the core nodes within the Montreal exitnode cluster, and we wanted to give folks some background information and a place to discuss things as the process unfolds. So... here goes.

Since our alpha launch last year, we've had our core Montreal cluster hardware provisioned via iWeb. That's been a mutually beneficial relationship, and we do appreciate everything iWeb has done over the past year for the cryptostorm project. During that time, we've gone from an early-alpha concept with a few dozen testers using the service, to one that nowadays has member connecting from all around the globe in ever-growing volume. Whereas we used to watch aggregate traffic for gigabit-level perturbations, nowadays the network transits terabits of traffic per day... and those are on the slow days.

In other words, much has changed during that time; it's been quite a ride. And, sadly, now it's time for us to part ways from our colleagues at iWeb.

Back in the day, our traffic volumes fit well into their business model (that's what we've been told, anyway - they can of course speak for themselves!). But since then, iWeb has been sold, cryptostorm has grown like the proverbial weed, and now we find ourselves often disagreeing about billing issues. That's usually a good sign that it's time to part company, and retain a collegial and mutually respectful relationship along the way. It's a small world, after all, and surely our paths will cross again.

As a result, in the next few days/weeks, you'll notice - if you're the sort who watches such things closely - that IP resolutions for various cluster- & loadbalancer-based HAF entries will stop pointing at iWeb-based IPs, and start rolling over to new infrastructure providers. Mostly, we wanted to let folks know that panic is not required: this isn't the NSA or someone else pwning our infrastructure, or domain resolution functionality, or anything else scary. Rather, it's just us growing and expanding and deploying infrastructure that best fits the project's ever-expanding ability to serve more members, more effectively, around the world.

We don't expect any actual "hiccups" in the process; it should all be more or less transparent to members. You might, if you're a denizen of the Montreal cluster, see a network session drop and reconnect at some point (if you stay connected continuously for days at a time, this is more likely - not that there's anything wrong with that, just to be clear!). Otherwise, one time you reconnect to Montreal, that new connection will auto-magically resolve to the new instance IPs... and away you go. No muss, no fuss.

There will also be a migration of our much-beloved tokenizer (i.e. cryptostorm.nu) - which borrows infrastructure resources mostly from Montreal, for historical reasons too boring to explain here. Again, that should be a fairly seamless cut-over: just a divergence in IPs to which the host record resolves. But, in the event there's weirdness in some local DNS lookup caching on the part of members, we wanted to let everyone know so there's no unnecessary panic.

Also: if you do notice weirdness, we suggest you take whatever steps are needed to flush your local DNS cache. The process for doing so varies quite a bit between OSes and whatnot; if you're not sure how to do that, post a note in this thread & surely someone will share the needed info. Mostly, this isn't necessary... but sometimes it is. We thought you should know, anyhow.

In terms of improvements, we're cautiously optimistic that this infrastructure upgrade will result in consistently better throughput for all of our Montreal-based nodes. Historically, one of our machines in the cluster (dear old, beloved Bruno...) had some issues with a less-than-modern NIC; folks might remember that, last winter, we worked hard to upgrade the drivers for several of the Montreal NICS. Mostly that was successful, and we didn't migrate back then as a result. But, there have been transient performance hiccups ever since.

Basically, we were driving those machines too hard for what they're really able to support. In the "old days" of last fall, that wasn't a big deal. Nowadays, with so many members pushing 20+ megabit sessions up & down, consistently, that older-era hardware struggles to keep up (NICs are a big problem, even more so than proc or memory bottlenecks, usually). So upgrading is required.

tl;dr is that it's a good thing, and shouldn't be a big hassle - but we wanted everyone to know, so there's not worry about Bad Things having taken place mysteriously :-)

By all means, feel free to post questions and comments and suggestions here. As always. In the meantime, if there's any major info updates, we'll post 'em here as well. If you don't hear anything like that, it means the migration/upgrade has gone off more or less smoothly. No news, in this case, is actually good news.

Cheers,

    ~ cryptostorm_admin
cryptostorm_admin - a mostly-shared, admin team forum account (sort of a person, but also shared)
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-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

vpnDarknet
Posts: 129
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: Montreal cluster - background & discussion

Postby vpnDarknet » Thu Jul 24, 2014 10:54 am

Best of luck, I hope it all goes smoothly and without glitch!

new infrastructure providers


Hypothetical security question; the server space is rented, how does this not compromise user security?
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me

User avatar

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

Re: Montreal cluster - background & discussion

Postby parityboy » Thu Jul 24, 2014 6:40 pm

@thread

One thing to watch out for is for all you users who do not use the DNS names to contact the VPN nodes, but use IPs instead. My sig. has the a link to all of the current IP addresses, but they should probably be maintained in a sticky on the forum.

@admin

With regard to the NIC issue, who makes them? Intel, Broadcom or someone else?


Montreal

Re: Montreal cluster - background & discussion

Postby Montreal » Mon Sep 01, 2014 7:12 am

Hi,

I still haven't been able to connect to Montreal. I am using Linux Mint 17. I flushed my DNS and downloaded the config files again from the linux set up page and the cert. Iceland and Dynamic connects, but not to the Montreal servers. Are the config files on the linux connection page up to date? There was another post linking to a conf file called Maple, but it was a Windows conf file, so I'm wondering if the Monreal conf files on that page are out of date.

Thanks!

User avatar

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

Re: Montreal cluster - background & discussion

Postby Fermi » Tue Sep 02, 2014 8:45 pm

Hi Montreal,

The only difference (next to the hosts of course) between the Montreal and Frankfurt config files (on:https://cryptostorm.org/viewtopic.php?f=37&t=5996), is the following snippet, which is present in the Montreal config:
txqueuelen 486
# expanded packet queue plane, to improve throughput on high-capacity sessions

sndbuf size 1655368
rcvbuf size 1655368
# increase pre-ring packet buffering cache, to improve high-throughput session performance


Can you try by deleting these lines in the Montreal config and reconnecting?
Any log messages?

Regards,

/Fermi


Guest

Re: Montreal cluster - background & discussion

Postby Guest » Wed Sep 03, 2014 5:56 am

Didn't work unfortunately.

This is what it looks like when I connect to dynamic, which works properly:

Sep 2 19:48:55 Comp-uter NetworkManager[862]: <info> Starting VPN service 'openvpn'...
Sep 2 19:48:55 Comp-uter NetworkManager[862]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 5852
Sep 2 19:48:55 Comp-uter NetworkManager[862]: <info> VPN service 'openvpn' appeared; activating connections
Sep 2 19:48:55 Comp-uter NetworkManager[862]: <info> VPN plugin state changed: init (1)
Sep 2 19:48:55 Comp-uter NetworkManager[862]: <info> VPN plugin state changed: starting (3)
Sep 2 19:48:55 Comp-uter NetworkManager[862]: <info> VPN connection 'cryptostorm_client_raw-dynamic1_3' (Connect) reply received.
Sep 2 19:48:55 Comp-uter nm-openvpn[5857]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 4 2014
Sep 2 19:48:55 Comp-uter nm-openvpn[5857]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sep 2 19:48:55 Comp-uter nm-openvpn[5857]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 2 19:48:55 Comp-uter nm-openvpn[5857]: UDPv4 link local: [undef]
Sep 2 19:48:55 Comp-uter nm-openvpn[5857]: UDPv4 link remote: [AF_INET]46.165.222.246:443
Sep 2 19:48:58 Comp-uter nm-openvpn[5857]: [server] Peer Connection Initiated with [AF_INET]46.165.222.246:443
Sep 2 19:49:01 Comp-uter nm-openvpn[5857]: TUN/TAP device tun0 opened
Sep 2 19:49:01 Comp-uter nm-openvpn[5857]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper tun0 1500 1602 10.55.0.10 255.255.0.0 init
Sep 2 19:49:01 Comp-uter NetworkManager[862]: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
Sep 2 19:49:01 Comp-uter NetworkManager[862]: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> VPN connection 'cryptostorm_client_raw-dynamic1_3' (IP Config Get) reply received.
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> VPN connection 'cryptostorm_client_raw-dynamic1_3' (IP4 Config Get) reply received.
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> VPN Gateway: 46.165.222.246
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Tunnel Device: tun0
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> IPv4 configuration:
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal Gateway: 10.55.0.1
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal Address: 10.55.0.10
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal Prefix: 16
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal Point-to-Point Address: 0.0.0.0
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Maximum Segment Size (MSS): 0
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Forbid Default Route: no
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal DNS: 213.73.91.35
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal DNS: 213.138.101.252
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal DNS: 80.237.196.2
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> Internal DNS: 194.150.168.168
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> DNS Domain: '(none)'
Sep 2 19:49:01 Comp-uter NetworkManager[862]: <info> No IPv6 configuration
Sep 2 19:49:01 Comp-uter nm-openvpn[5857]: Initialization Sequence Completed
Sep 2 19:49:02 Comp-uter NetworkManager[862]: <info> VPN connection 'cryptostorm_client_raw-dynamic1_3' (IP Config Get) complete.
Sep 2 19:49:02 Comp-uter NetworkManager[862]: <info> Policy set 'cryptostorm_client_raw-dynamic1_3' (tun0) as default for IPv4 routing and DNS.
Sep 2 19:49:02 Comp-uter NetworkManager[862]: <info> Writing DNS information to /sbin/resolvconf
Sep 2 19:49:02 Comp-uter dnsmasq[2403]: setting upstream servers from DBus
Sep 2 19:49:02 Comp-uter dnsmasq[2403]: using nameserver 194.150.168.168#53
Sep 2 19:49:02 Comp-uter dnsmasq[2403]: using nameserver 80.237.196.2#53
Sep 2 19:49:02 Comp-uter dnsmasq[2403]: using nameserver 213.73.91.35#53
Sep 2 19:49:02 Comp-uter dnsmasq[2403]: using nameserver 213.138.101.252#53
Sep 2 19:49:02 Comp-uter dbus[533]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Sep 2 19:49:02 Comp-uter NetworkManager[862]: <info> VPN plugin state changed: started (4)
Sep 2 19:49:02 Comp-uter dbus[533]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'



This is what happens when I try to connect to Montreal. This always times out and does not connect.

Sep 2 19:47:06 Comp-uter wpa_supplicant[1467]: wlan0: CTRL-EVENT-SCAN-STARTED
Sep 2 19:47:12 Comp-uter wpa_supplicant[1467]: nl80211: send_and_recv->nl_recvmsgs failed: -33
Sep 2 19:47:13 Comp-uter NetworkManager[862]: <info> Starting VPN service 'openvpn'...
Sep 2 19:47:13 Comp-uter NetworkManager[862]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 5797
Sep 2 19:47:13 Comp-uter NetworkManager[862]: <info> VPN service 'openvpn' appeared; activating connections
Sep 2 19:47:13 Comp-uter NetworkManager[862]: <info> VPN plugin state changed: starting (3)
Sep 2 19:47:13 Comp-uter NetworkManager[862]: <info> VPN connection 'cryptostorm_client_raw-montreal1_3' (Connect) reply received.
Sep 2 19:47:13 Comp-uter nm-openvpn[5802]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 4 2014
Sep 2 19:47:13 Comp-uter nm-openvpn[5802]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sep 2 19:47:13 Comp-uter nm-openvpn[5802]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 2 19:47:13 Comp-uter nm-openvpn[5802]: UDPv4 link local: [undef]
Sep 2 19:47:13 Comp-uter nm-openvpn[5802]: UDPv4 link remote: [AF_INET]198.50.119.172:443
Sep 2 19:47:54 Comp-uter NetworkManager[862]: <warn> VPN connection 'cryptostorm_client_raw-montreal1_3' (IP Config Get) timeout exceeded.
Sep 2 19:47:54 Comp-uter NetworkManager[862]: <info> Policy set 'A Wi-Fi Hotspot' (wlan0) as default for IPv4 routing and DNS.
Sep 2 19:47:54 Comp-uter nm-openvpn[5802]: SIGTERM[hard,] received, process exiting

Thanks for helping!

User avatar

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

Re: Montreal cluster - background & discussion

Postby Fermi » Wed Sep 03, 2014 5:37 pm

Hi Montreal,

I see what the issue is:
Sep 2 19:47:13 Comp-uter nm-openvpn[5802]: UDPv4 link remote: [AF_INET]198.50.119.172:443
Sep 2 19:47:54 Comp-uter NetworkManager[862]: <warn> VPN connection 'cryptostorm_client_raw-montreal1_3' (IP Config Get) timeout exceeded.

The entries from the config file:

remote cluster-montreal.cryptostorm.net 443 udp
(resolves to 70.38.46.224)
remote cluster-montreal.cryptostorm.org 443 udp
(resolves to 198.50.119.172)
remote cluster-montreal.cryptostorm.nu 443 udp
(resolves to 70.38.46.224)
remote cluster-montreal.cstorm.pw 443 udp
(resolves to 70.38.46.224)

are not valid, I do not know if the DNS records will be changed, so that the conf file will be reusable, or if CS will change the conf file.

In the mean time you can use Montreal by trying the conf file: cryptostorm_client_raw-montreal1_3 v2.conf
This used the following FQDN's:
raw-maple.cryptostorm.org 443 udp
raw-maple.cryptostorm.net 443 udp
(both resolving to 198.27.89.56 being the IP address of the raw type Maple node)


Regards,

/Fermi

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


Montreal

Re: Montreal cluster - background & discussion

Postby Montreal » Wed Sep 03, 2014 6:01 pm

Hi Fermi,

Thanks so much for looking into this. Unfortunately the v2 file did not work :S The output is:

Sep 3 07:51:52 Comp-uter NetworkManager[862]: <info> Starting VPN service 'openvpn'...
Sep 3 07:51:52 Comp-uter NetworkManager[862]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 12178
Sep 3 07:51:52 Comp-uter NetworkManager[862]: <info> VPN service 'openvpn' appeared; activating connections
Sep 3 07:51:52 Comp-uter NetworkManager[862]: <info> VPN plugin state changed: starting (3)
Sep 3 07:51:52 Comp-uter NetworkManager[862]: <info> VPN connection 'cryptostorm_client_raw-montreal1_3 v2' (Connect) reply received.
Sep 3 07:51:52 Comp-uter nm-openvpn[12183]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 4 2014
Sep 3 07:51:52 Comp-uter nm-openvpn[12183]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sep 3 07:51:52 Comp-uter nm-openvpn[12183]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 3 07:51:52 Comp-uter nm-openvpn[12183]: UDPv4 link local: [undef]
Sep 3 07:51:52 Comp-uter nm-openvpn[12183]: UDPv4 link remote: [AF_INET]198.27.89.56:443
Sep 3 07:51:57 Comp-uter nm-openvpn[12183]: VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite / cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is
Sep 3 07:51:57 Comp-uter nm-openvpn[12183]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sep 3 07:51:57 Comp-uter nm-openvpn[12183]: TLS Error: TLS object -> incoming plaintext read error
Sep 3 07:51:57 Comp-uter nm-openvpn[12183]: TLS Error: TLS handshake failed
Sep 3 07:51:57 Comp-uter nm-openvpn[12183]: SIGUSR1[soft,tls-error] received, process restarting
Sep 3 07:51:59 Comp-uter nm-openvpn[12183]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sep 3 07:51:59 Comp-uter nm-openvpn[12183]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 3 07:51:59 Comp-uter nm-openvpn[12183]: UDPv4 link local: [undef]
Sep 3 07:51:59 Comp-uter nm-openvpn[12183]: UDPv4 link remote: [AF_INET]198.27.89.56:443
Sep 3 07:51:59 Comp-uter nm-openvpn[12183]: VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite / cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is

It repeats this block message for another 10 or so times and then times out.

If it's a bigger issue it's not a big deal for me. I still get a very solid connection on the german and icelandic servers. It's only that Montreal is a bit closer to me and I do get a faster connection with it. But no rush for a fix right now!

Thank you!

User avatar

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

Re: Montreal cluster - background & discussion

Postby Fermi » Wed Sep 03, 2014 10:21 pm

Montreal,

As Maple is a post-heartbleed node we need to use the new certificate (this has been overlooked in previous reply: cryptostorm_client_raw-montreal1_3 v2.conf).
Please use: cryptostorm_client_raw-montreal1_3 v2_post_hb.conf

Regards and humble apologies for the confusion,

/Fermi

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

User avatar

vpnDarknet
Posts: 129
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: Montreal cluster - background & discussion

Postby vpnDarknet » Thu Sep 04, 2014 12:50 pm

Something I've noticed on Maple, think since after the weekend, is that torrents are not working, although everything else seems as good as ever.

Confirmed I'm uising the *.conf file you linkd to /Fermi, but the port Transmission is using isn't open.

The Frakfurt exit node behaves as expected, has anything changed, is this related to the downtime?
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me

User avatar

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

Re: Montreal cluster - background & discussion

Postby Fermi » Thu Sep 04, 2014 1:05 pm

Hi vpnDarknet,

The torrent issue shouldn't be related to the cryptostorm.is outage, as the latter is isolated from the VPN exit nodes.
Did you send a message to support on this?

Greetz,

/Fermi

User avatar

vpnDarknet
Posts: 129
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: Montreal cluster - background & discussion

Postby vpnDarknet » Thu Sep 04, 2014 3:18 pm

Thaks man,
Nah not yet, I'll drop them a mail, no urgency as it works via other exit node
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me


Montreal

Re: Montreal cluster - background & discussion

Postby Montreal » Mon Sep 15, 2014 9:13 am

Fermi,

BTW I got this working. The certificates that are posited on parityboy's email sig (ca2.crt) make my linux mint connect to the montreal server properly. I recommend to CryptoStorm staff to update the certificates on the official "how-to" connect page for linux to use the new certificates, because the one that is on that page is not up to date.

Have Cryptostorm thought about having a single page to keep most of this info aggregated for proper versioning? It would make it easier for non-experts like me to find the right, or 'official' information.

Thanks for your help earlier!!
M


Montreal

Re: Montreal cluster - background & discussion

Postby Montreal » Mon Sep 15, 2014 9:19 am

Scratch part of that last post.

Montreal Servers work with ca2.crt
Iceland and German servers don't work with ca2.crt

Iceland and German servers work with certificate from the official how-to linux connection page.
Montreal server doesn't work with the certificate from the official how-to linux connection page.

Possibly I'm using pre hb config files for Iceland and German servers. If that's the case could you point me to those please?

Thanks!
M

User avatar

vpnDarknet
Posts: 129
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: Montreal cluster - background & discussion

Postby vpnDarknet » Wed Sep 17, 2014 1:06 pm

Hi there, I've been trying to keep all of the details together on this page: cryptostorm wiki

Please feeback if anything looks out of place, or feel free to request a login to add material yourself :)
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me



bedrock
Posts: 1
Joined: Fri Jun 06, 2014 6:32 pm

Re: Montreal cluster - background & discussion

Postby bedrock » Fri Jan 16, 2015 2:27 am

Thu Jan 15 14:50:58 2015 us=397691 NOTE: --mute triggered...
Thu Jan 15 14:50:58 2015 us=829716 54 variation(s) on previous 3 message(s) suppressed by --mute
Thu Jan 15 14:50:58 2015 us=829716 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite / cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is
Thu Jan 15 14:50:58 2015 us=829716 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Thu Jan 15 14:50:58 2015 us=829716 TLS Error: TLS object -> incoming plaintext read error
Thu Jan 15 14:50:58 2015 us=829716 NOTE: --mute triggered...
Thu Jan 15 14:50:58 2015 us=829716 1 variation(s) on previous 3 message(s) suppressed by --mute
Thu Jan 15 14:50:58 2015 us=829716 TCP/UDP: Closing socket
Thu Jan 15 14:50:58 2015 us=829716 SIGUSR1[soft,tls-error] received, process restarting
Thu Jan 15 14:50:58 2015 us=829716 Restart pause, 2 second(s)


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 4 guests

Login