Things are back to normal. Routing issues makes sense. IP/DNS detect looked weird yesterday. Looks sane today so I guess it's fixed. Thanks.

[b]@rwilcher[/b]

The Icelandic leg of the CryptoStorm network was down yesterday due to routing issues, is back up now though. Are you still having issues?

Unfortnatly, this has returned.

I have been having problems with this widget since this morning. Token I am sing verifies correctly . The test page fails to
verify correct operation. when I go to the test page it fails. I can also no longer login to the member forum. Was working
perfectly yesterday. Widget comes up and says I am connected. Though evidently I am not. I can go to the token test page
and it verfies. Attached is the long fro the widget . I have run virus stuff and checked browser plugins. I am using chrome
Version 44.0.2403.18 beta-m (64-bit). Maybe you have an idea. Thanks. The log from widget startup follows.

Wed Jun 03 12:50:31 2015 us=860495 Current Parameter Settings:
Wed Jun 03 12:50:31 2015 us=860495 config = '..\user\custom.conf'
Wed Jun 03 12:50:31 2015 us=860495 mode = 0
Wed Jun 03 12:50:31 2015 us=860495 NOTE: --mute triggered...
Wed Jun 03 12:50:31 2015 us=860495 357 variation(s) on previous 3 message(s) suppressed by --mute
Wed Jun 03 12:50:31 2015 us=860495 OpenVPN 2.3.6 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 1 2014
Wed Jun 03 12:50:31 2015 us=860495 library versions: OpenSSL 1.0.2 22 Jan 2015, LZO 2.08
Wed Jun 03 12:50:32 2015 us=94495 LZO compression initialized
Wed Jun 03 12:50:32 2015 us=94495 Control Channel MTU parms [ L:1606 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Jun 03 12:50:32 2015 us=94495 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Jun 03 12:50:32 2015 us=250495 Data Channel MTU parms [ L:1606 D:1450 EF:106 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Jun 03 12:50:32 2015 us=250495 Fragmentation MTU parms [ L:1606 D:1400 EF:105 EB:135 ET:1 EL:0 AF:3/1 ]
Wed Jun 03 12:50:32 2015 us=250495 Local Options String: 'V4,dev-type tun,link-mtu 1606,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Wed Jun 03 12:50:32 2015 us=250495 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1606,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-server'
Wed Jun 03 12:50:32 2015 us=250495 Local Options hash (VER=V4): 'ff724a72'
Wed Jun 03 12:50:32 2015 us=250495 Expected Remote Options hash (VER=V4): '545e2783'
Wed Jun 03 12:50:32 2015 us=250495 UDPv4 link local: [undef]
Wed Jun 03 12:50:32 2015 us=250495 UDPv4 link remote: [AF_INET]76.164.234.13:443
Wed Jun 03 12:50:32 2015 us=375296 TLS: Initial packet from [AF_INET]76.164.234.13:443, sid=96861992 222eaea9
Wed Jun 03 12:50:32 2015 us=375296 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jun 03 12:50:33 2015 us=108497 VERIFY OK: depth=1, C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite / cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is
Wed Jun 03 12:50:33 2015 us=108497 VERIFY OK: nsCertType=SERVER
Wed Jun 03 12:50:33 2015 us=108497 VERIFY OK: depth=0, C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite / cryptostorm_darknet, OU=Tech Ops, CN=server, emailAddress=certadmin@cryptostorm.is
Wed Jun 03 12:50:33 2015 us=732498 NOTE: --mute triggered...
Wed Jun 03 12:50:33 2015 us=732498 5 variation(s) on previous 3 message(s) suppressed by --mute
Wed Jun 03 12:50:33 2015 us=732498 [server] Peer Connection Initiated with [AF_INET]76.164.234.13:443
Wed Jun 03 12:50:36 2015 us=134902 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jun 03 12:50:36 2015 us=228502 PUSH: Received control message: 'PUSH_REPLY,persist-key,persist-tun,redirect-gateway def1,redirect-gateway bypass-dhcp,dhcp-option DNS 76.164.234.11,route-gateway 10.44.0.1,topology subnet,ping 20,ping-restart 60,ifconfig 10.44.0.10 255.255.0.0'
Wed Jun 03 12:50:36 2015 us=228502 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jun 03 12:50:36 2015 us=228502 NOTE: --mute triggered...
Wed Jun 03 12:50:36 2015 us=244102 5 variation(s) on previous 3 message(s) suppressed by --mute
Wed Jun 03 12:50:36 2015 us=244102 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Jun 03 12:50:36 2015 us=244102 open_tun, tt->ipv6=0
Wed Jun 03 12:50:36 2015 us=259702 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{A8B3C977-EE54-47CD-9B2F-82B858FC7670}.tap
Wed Jun 03 12:50:36 2015 us=259702 TAP-Windows Driver Version 9.9
Wed Jun 03 12:50:36 2015 us=259702 TAP-Windows MTU=1500
Wed Jun 03 12:50:36 2015 us=259702 Set TAP-Windows TUN subnet mode network/local/netmask = 10.44.0.0/10.44.0.10/255.255.0.0 [SUCCEEDED]
Wed Jun 03 12:50:36 2015 us=259702 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.44.0.10/255.255.0.0 on interface {A8B3C977-EE54-47CD-9B2F-82B858FC7670} [DHCP-serv: 10.44.255.254, lease-time: 31536000]
Wed Jun 03 12:50:36 2015 us=259702 DHCP option string: 06044ca4 ea0b
Wed Jun 03 12:50:36 2015 us=259702 Successful ARP Flush on interface [24] {A8B3C977-EE54-47CD-9B2F-82B858FC7670}
Wed Jun 03 12:50:41 2015 us=470112 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Wed Jun 03 12:50:41 2015 us=470112 C:\Windows\system32\route.exe ADD 76.164.234.13 MASK 255.255.255.255 198.31.176.201
Wed Jun 03 12:50:41 2015 us=470112 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed Jun 03 12:50:41 2015 us=470112 Route addition via IPAPI succeeded [adaptive]
Wed Jun 03 12:50:41 2015 us=470112 C:\Windows\system32\route.exe ADD 198.31.176.201 MASK 255.255.255.255 198.31.176.201 IF 12
Wed Jun 03 12:50:41 2015 us=470112 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed Jun 03 12:50:41 2015 us=470112 Route addition via IPAPI succeeded [adaptive]
Wed Jun 03 12:50:41 2015 us=470112 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.44.0.1
Wed Jun 03 12:50:41 2015 us=470112 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Jun 03 12:50:41 2015 us=470112 Route addition via IPAPI succeeded [adaptive]
Wed Jun 03 12:50:41 2015 us=470112 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.44.0.1
Wed Jun 03 12:50:41 2015 us=470112 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Jun 03 12:50:41 2015 us=470112 Route addition via IPAPI succeeded [adaptive]
Wed Jun 03 12:50:41 2015 us=470112 Initialization Sequence Completed
Connected

Nice to watch masters at work :clap:

Thanks for your attention and concern. Top flight support people. Unbelievable.

Thanks for posting up the details, and clarifying wrt the extra "8" - everything I see there is legit, so at this point I'll mark this item closed as it seems we've got things smoothed out fully.

Cheers,

~ pj

Heres part of the interaction from troubleshooting my issue.

User Actions
Following

cryptostorm ҉ðåяќйἔт
‏@cryptostorm_is
@neo11 ...but the widget is fairly obsessive about 'zombie sessions' showing inaccurately as connected. Depends on how paranoid you are! :-)
Reply Retweet Favorite
More
RETWEET
1
Fermi
1:20 PM - 11 May 2015

Tweet text
Reply to @cryptostorm_is
Who's in these photos?
neo11 ‏@neo11 May 11
@cryptostorm_is Weird. Never seen it act like this. Ran vscan nothing found.
1 retweet 1 favorite
Reply Retweet1 Favorite1 View Tweet activity
More
Kağan Kongar ‏@KaganKongar May 11
@neo11 @__Fermi__ @cryptostorm_is may I suggest protocol and port change; from default UDP 443 to for example TCP 8888 and try again...
0 retweets 0 favorites
Reply Retweet Favorite Follow
More
neo11 ‏@neo11 May 11
@KaganKongar @__Fermi__ @cryptostorm_is How 2 do ?
0 retweets 0 favorites
Reply Retweet Favorite View Tweet activity
More
Fermi ‏@__Fermi__ May 11
@KaganKongar @neo11 @cryptostorm_is interesting approach, any thoughts behind it?
0 retweets 1 favorite
Reply Retweet Favorite1 Follow
More
Kağan Kongar ‏@KaganKongar May 11
@neo11 @__Fermi__ @cryptostorm_is widgets options tab, you'll see those. Just start widget and click options.
0 retweets 0 favorites
Reply Retweet Favorite Follow
More
neo11 ‏@neo11 May 11
@__Fermi__ @KaganKongar @cryptostorm_is Ok found in widget
0 retweets 1 favorite
Reply Retweet Favorite1 View Tweet activity
More
Kağan Kongar ‏@KaganKongar May 11
@__Fermi__ @neo11 @cryptostorm_is Increasing number of networks blocking UDP and/or VPN. Since we know nothing about that; seemed logical.
0 retweets 0 favorites
Reply Retweet Favorite Follow
More
neo11 ‏@neo11 May 11
@KaganKongar @__Fermi__ @cryptostorm_is Dropdown only shows UDP.
0 retweets 1 favorite
Reply Retweet Favorite1 View Tweet activity
More
Fermi ‏@__Fermi__ May 11
@neo11 @KaganKongar @cryptostorm_is try udp 8888
0 retweets 1 favorite
Reply Retweet Favorite1 Follow
More
Kağan Kongar ‏@KaganKongar May 11
@neo11 @__Fermi__ @cryptostorm_is I pass, not on computer.
0 retweets 0 favorites
Reply Retweet Favorite Follow
More
neo11 ‏@neo11 May 11
@__Fermi__ @KaganKongar @cryptostorm_is Done restarting.
0 retweets 0 favorites
Reply Retweet Favorite View Tweet activity
More
Fermi ‏@__Fermi__ May 11
@neo11 @KaganKongar @cryptostorm_is if still not working, we can try fiddling with conf file ...
0 retweets 1 favorite
Reply Retweet Favorite1 Follow
More
neo11 ‏@neo11 May 11
@__Fermi__ @KaganKongar @cryptostorm_is Hot damn. Works now test page is green.

[quote="Pattern_Juggled"][quote="rwilcher"]Ok I changed port to random port in the Widget. after that no more problems. Things are working perfectly now after
several reboots/Widget restarts. Haven't seen this since. I received mail from some one in support saying they found the
problem.[/quote]

I can confirm that we'd added capacity over the weekend in the US-central exitnode cluster, but the new machine didn't get added to the list driving the on-[url=https://cryptostorm.is/test]cstorm testing page[/url]. That has now been resolved, and the test page is giving results based on a complete and official list of cstorm nodes and addresses.

As to the port "88888" issue, we'd love to know where that recommendation came from and exactly what the widget did when presented with that alleged port. Internal testing confirms that it should have thrown an error message with an out-of-range port attempt (ie any port not in the range (1-65535). Depending on OS details, attempts to use such ports may be re-mapped down to a valid port number... but the widget doesn't do that onboard, and doesn't pass such queries out to the OS in the first place.

So this is still a bit worrisome to me, in terms of unexpected behaviours from the installed widget. If you've got more data to share, we're all ears :-)

Cheers,

~ pj[/quote]

Sorry . My fault. too many digits. Widget won't allow entering that. Got the suggestion during on line twitter trouble shooting.
I understand your concern. Esp with security stuff. I will look for the specific tweet if it's not gone and enter it here. Thanks.

pj, rwilcher,

Indeed there's no port 88888. Was able to retrieve the twitter feed (will not post the link here as some aliases used in twitter don't match the aliases used here :) ).
A skilled person proposed using TCP 8888, reasoning that some ISP's are doing efforts to fiddle with VPN connections. Apparently selecting TCP isn't an option in the widget (didn't test it). Than I proposed using UDP 8888.

I believe this all boils down to the fact that 142.54.172.52 (linux-uscentral.cryptostorm.net) wasn't 'known' by the Cryptostorm test page.

Ofc widget behaviour in such cases are extermely important to monitor, as pj already indicates.

Greetz,

/Fermi

[quote="rwilcher"]Ok I changed port to random port in the Widget. after that no more problems. Things are working perfectly now after
several reboots/Widget restarts. Haven't seen this since. I received mail from some one in support saying they found the
problem.[/quote]

I can confirm that we'd added capacity over the weekend in the US-central exitnode cluster, but the new machine didn't get added to the list driving the on-[url=https://cryptostorm.is/test]cstorm testing page[/url]. That has now been resolved, and the test page is giving results based on a complete and official list of cstorm nodes and addresses.

As to the port "88888" issue, we'd love to know where that recommendation came from and exactly what the widget did when presented with that alleged port. Internal testing confirms that it should have thrown an error message with an out-of-range port attempt (ie any port not in the range (1-65535). Depending on OS details, attempts to use such ports may be re-mapped down to a valid port number... but the widget doesn't do that onboard, and doesn't pass such queries out to the OS in the first place.

So this is still a bit worrisome to me, in terms of unexpected behaviours from the installed widget. If you've got more data to share, we're all ears :-)

Cheers,

~ pj

Ok I changed port to random port in the Widget. after that no more problems. Things are working perfectly now after
several reboots/Widget restarts. Haven't seen this since. I received mail from some one in support saying they found the
problem.

[quote="rwilcher"]UPDATE: This happened to me again today. By changing to a random port , on the widget I got the conn back to green on the test page.
To get this working yesterday, I was instructed to change from the default port 'on the widget' to port 88888. This got it working.
Somethings going on. :crazy: Hope I don't have to do this every time but if so, so be it.[/quote]

Woah woah woah!

There is no "port 88888" so that's not legit.

Please contact us immediately - via email or another channel, so we can figure out what's going on with your local desktop environment.

Thanks,

~ pj

[quote="Guest"]I'm having similar funkiness issues. ipleak.net seems to check out, in that all the information seems the same. Only difference is the unfamiliar IP address. That IP address is unfamiliar to https://cryptostorm.is/test as well.[/quote]

I have a suspicion this is a simple oversight on our part.

We've been adding capacity to the network, in the form of new server 'nodes,' at a steady and solid clip in recent months. Most is redundant capacity for existing clusters, which enables resiliency and other good things... but which is not really very announcement-worthy on a per-node basis. Plus of course we're terrible at making announcements anyhow, so there's that...

Anyway, the list of IPs defining what is - and is not - "on cstorm" is manually updated. That's intentional, as it's a check against certain forms of trickery that are unlikely and sort of Rube Goldberg-esque to imagine... but we imagine them, and model them, and pre-structure things to make such trickeries more difficult for even the most patient attackers. And in this case, an actual human on the core team is required to modify that list of legit cstorm nodes; it doesn't auto-refresh, or auto-anything.

And I suspect we've not done so in a bit, because I can't remember anyone mentioning doing it... and I am pretty sure I didn't do it. So that means the list is stale, most likely. I'll get with the network ops team right now, and ensure it's updated (if it was in fact stale), and post results here.

If that's the case, our apologies - and it's a process we'll be putting better follow-on tracking around, as well, so it doesn't happen again.

Regards,

~ pj

Looks like the packet masters have licked this issue as of today. Thins seem to be working as expected. Some corner
case or something. Looks fixed now. Will poke around a bit to be sure.

UPDATE: This happened to me again today. By changing to a random port , on the widget I got the conn back to green on the test page.
To get this working yesterday, I was instructed to change from the default port 'on the widget' to port 88888. This got it working.
Somethings going on. :crazy: Hope I don't have to do this every time but if so, so be it.

rwilcher, Guest,

The Kali issue was solved by changing the dns configuration to deal with a persistent unchangeable configuration pushed by the router/modem.
Configuration in /etc/network/interfaces was set to static.
/etc/resolvconf/resolv.conf.d/base holds the correct deepdns nameservers.

Actually this was a DNS leak, where the leaked DNS address was actually the IP address the customer was connecting with ... .

/Fermi

I'm having similar funkiness issues. ipleak.net seems to check out, in that all the information seems the same. Only difference is the unfamiliar IP address. That IP address is unfamiliar to https://cryptostorm.is/test as well.

rwilcher,

Talking to someone experiencing a similar issue using Kali as an OS ... .
IP leak websites show ISP IP and CS IP, but https://cryptostorm.is/test turns green ... .
Indeed the outcome of tracert can show the path taken to the destination ... .
If more info, I'll post.

/Fermi

Hi all. This morning I am having a weird issue. I am using the latest windows widget. Comes up and connect normally. After completion says
I am connected to the dark net. All green. Everything appears to be OK. However when I go to the test page https://cryptostorm.is/test
It shows all red. My token tested with 21 days remaining. No errors from widget except a may be replay warning. Also always gets the
same IP address each time. 142.54.172.52. I am kinda stuck bareback and confused.