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

To stay ahead of new and evolving threats, cryptostorm has always looked out past standard network security tools. Here, we discuss and fine-tune our work in bringing newly-created capabilities and newly-discovered knowledge to bear as we keep cryptostorm in the forefront of tomorrow's network security landscape.

Currently I'm using AirVPN's SSL tunnel (using stunnel) option to tunnel all my traffic through an OpenVPN connection masked as an HTTPS connection through port 433. This because I need to bypass a DPI firewall that only supports HTTPS through port 433. All other ports are blocked and VPN protocols through 433 are getting blocked as well.

I'm using stunnel with an .ssl config file provided by AirVPN. I'd like to move to cryptostorm, but with the general setup, it does not work.

Using OSX, Viscosity, used this thread to set up and get the ovpn config.

Currently it gets blocked. Any instructions on getting cryptostorm to work wrapped in an SSL layer are welcome

Can you post the ssl config you've been using from Air? That might help narrow down what's going on here, topologically. I'm sure others will have additional questions and suggestions, but that's the first thing that comes to my mind.

The *.ssl certificate can easily be modified to point to cryptostorm servers. The ovpn however, is telling me it's invalid when I change it like so (changing remote, removing random, and adding proto udp):

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

<ca>-----BEGIN CERTIFICATE-----MIIFHjCCBAagAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQKFC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQxETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUGCSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTE0MDQyNTE3MTAxNVoXDTE3MTIyMjE3MTAxNVowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJaOSYIX/sm+4/OkCgyAPYB/VPjDo9YBc+zznKGxd1F8fAkeqcuPpGNCxMBLOumLsBdxLdR2sppK8cu9kYx6g+fBUQtShoOj84Q6+n6F4DqbjsHlLwUy0ulkeQWk1vvKKkpBViGVFsZ5ODdZ6caJ2UY2C41OACTQdblCqaebsLQvp/VGKTWdh9UsGQ3LaSTcxt0PskqpGiWEUeOGG3mKE0KWyvxt6Ox9is9QbDXJOYdklQaPX9yUuII03Gj3xm+vi6q2vzD5VymOeTMyky7Geatbd2U459Lwzu/g+8V6EQl8qvWrXESX/ZXZvNG8QAcOXU4ktNBOoZtws6TzknpQF3AgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUOFjh918zL4vR8x1q3vkp6npwUSUwge8GA1UdIwSB5zCB5IAUOFjh918zL4vR8x1q3vkp6npwUSWhgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rvcm0uaXOCCQCnpKRl8V74WzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAK6B7AOEqbaYjXoyhXeWK1NjpcCLCuRcwhMSvf+gVfrcMsJ5ySTHg5iR1/LFayIEGFsOFEpoNkY4H5UqLnBByzFp55nYwqJUmLqa/nfIc0vfiXL5rFZLao0npLrTr/inF/hecIghLGVDeVcC24uIdgfMr3Z/EXSpUxvFLGE7ELlsnmpYBxm0rf7s9S9wtHo6PjBpb9iurF7KxDjoXsIgHmYAEnI4+rrArQqn7ny4vgvXE1xfAkFPWR8Ty1ZlxZgEyypTkIWhphdHLSdifoOqo83snmCObHgyHG2zo4njXGExQhxS1ywPvZJRt7fhjnX03mQP3ssBs2YRNR5hR5cMdC-----END CERTIFICATE-----</ca># confirms via RSA-based public-key crypto that server instance is legitimately cryptostorm# does NOT identify client, and is used solely as part of anti-Man In The Middle (MiTM) hardening

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

# log devnull.txt# verb 0# mute 1# commented out for OSX sessions as they do not play nicely with our local nomenclature syntax yet

It does not contain the a certificate and a private key to construct the HTTPS tunnel I think... Can someone please confirm that this wel never work without cryptostorm servers to fully support SSL tunnelling?

1. You could connect over Tor, but that's likely to be dog-slow and your ISP will know you're using Tor2. You could use another VPN provider with OpenVPN to provide a first connection, but then your ISP will know you've up with that provider instead of CS.

@parityboy ok thanks. It's more that I would like to have one VPN to "rule 'em all" as in: provides anonymity for personal activities and that can bypass the DPI firewall at my office. Hopefully CS will provide SSL wrapping in the future..

vinchat wrote:@parityboy ok thanks. It's more that I would like to have one VPN to "rule 'em all" as in: provides anonymity for personal activities and that can bypass the DPI firewall at my office. Hopefully CS will provide SSL wrapping in the future..

+1

It's been almost 4 years. DPI is becoming very common in public WiFi hotspots all over the US. I'd say about 25% of the libraries I visit won't let me connect to cryptostorm using openvpn.

Is cryptostorm any closer to being able to wrap my openvpn connection in stunnel over port 443?

@GuestWe are planning to add stunnel some time in the near future.For now, most DPI can be bypassed by simply using our ECC instances, since they don't disclose the OpenVPN handshake whenever you connect (thanks to --tls-crypt)

df wrote:@GuestWe are planning to add stunnel some time in the near future.For now, most DPI can be bypassed by simply using our ECC instances, since they don't disclose the OpenVPN handshake whenever you connect (thanks to --tls-crypt)

Stunnel would be great -- I suffer a lot due to DPI, and the high port used by the ECC instances I think does me no favours.

@LanThat's something I'm working on at the moment, offering ECC on other ports outside of 5060.I'm pretty sure I've figured out a way to do ECC & RSA instances on the same IP both on ports 1-29999 (excluding 30000-65535 since that's reserved for port forwarding). For UDP, the iptables u32 module is used to do this. For TCP, haproxy is used. With the haproxy setup, it'll be fairly easy to also add SSH & SSL tunneling to the mix as well, also on the above ports.All that's left is to do more tests from different devices to make sure it actually works in all scenarios.If I can get it to work the way I imagine it will, it means all of our current VPN IPs (probably excluding the legacy ones) will have RSA & ECC OpenVPN and Wireguard on all UDP ports of every IP, and for TCP it would be RSA & ECC OpenVPN plus SSL & SSH tunneling on all TCP ports of every IP.The only thing I know I won't be able to implement is Ed25519 or Ed448 in the same way, so those two will have to continue to stay on ports 5061 and 5062. That should be fine though since most customers aren't using OpenSSL 1.1.1 yet, which both of those require.