On Jul 27, 2018 9:57 AM, "Ahmed Kamal" <email.ahmedkamal at googlemail.com> wrote: > >Thanks a lot Daniel! This seems to have resolved the issue. There is a >remaining tangential issue, which you might be able to help with. So >here I go. Unfortunately Egypt is performing DPI and seems to be >killing the DTLS stream, so I cannot connect over DTLS even though I'm >using v7.08 (from brew on OSX). The client emits the error message: >DTLS handshake failed: Resource temporarily unavailable, try again. > >and on the server side "# tcpdump -ni eth0 udp and port 443" is >showing zero packets reaching the server! Unfortunately it seems the >DPI is effective here. My question is, is there any extra >encryption/obfuscation that can be done on the DTLS stream? Would >using newer ciphers like TLS_1.3 perhaps help? I know it's a long >shot, but worth trying. Thanks again! AFAIK, Egypt's censorship blocks *all* DTLS and IPSEC (IKE+ESP) traffic, plus *some* TLS traffic by blacklisted domains, detected via DNS and SNI (e.g. Signal and WhatsApp encrypted chat). VPN TLS traffic can't be distinguished from ordinary TLS traffic (e.g. HTTPS) so it can't be banned entirely without enormous collateral damage, though of course the censors could block your VPN's domain or IP if they notice it and decide it's a VPN. >From what I've heard from Israelis traveling to the Sinai, VoIP and video chat don't work reliably either, which probably means other UDP traffic is being blocked or interfered with. Given this situation? you're stuck with connecting to your ocserv VPN via TLS only. It's perfectly secure, but can be slow if the client-server connection has a lot of congestion or packet loss. Setting compression=true in your ocserv config might offset this, slightly, for some kinds of traffic. Dan
