Leaderboard

Hello! We are glad to inform you that we support Mastodon as "Platinum" donors. Mastodon is an online, self-hosted, federated, community owned and ad-free social media and social networking service https://joinmastodon.org Check our mission page: https://airvpn.org/mission Kind regards and datalove AirVPN Staff

Hello! We proudly announce that today AirVPN has become an Electronic Frontier Foundation "Super Major Donor". The Electronic Frontier Foundation is the leading nonprofit organization defending civil liberties in the digital world. Founded in 1990, EFF champions user privacy, free expression, and innovation through impact litigation, policy analysis, grassroots activism, and technology development. We work to ensure that rights and freedoms are enhanced and protected as our use of technology grows. https://www.eff.org Check our mission page: https://airvpn.org/mission Kind regards and datalove AirVPN Staff

Well, if anything, the internet has become more absurd in Australia. Apart from the attacks on encryption in Australia - which continues unabated, but with no appreciable benefit being announced, the national broadband network, as the joke is called just continues to slip in world rankings. In January, 2018, Australia was 55th in the world in terms of speed: https://finance.nine.com.au/2018/01/08/10/17/australias-fixed-internet-speed-ranking-falls-two-places-to-55th In April, 2019, the country had slipped to 63rd - https://www.smh.com.au/federal-election-2019/australia-drops-to-62nd-in-global-broadband-speed-rankings-20190428-p51hz2.html This placed the country far behind many other advanced economies and a handful of developing nations. In 2016, Australians were among the least satisfied users of broadband in the world, being 23rd out of 26: https://www.smh.com.au/business/consumer-affairs/australia-ranked-23rd-out-of-26-countries-when-it-comes-to-broadband-satisfaction-20161022-gs89nu.html. It has not improved. Many users report unexplained dropouts, service interruptions and so on. The antiencryption have only made matters more absurd. As wintermude1912 said: welcome to the digital banana republic. Well, it's no longer confined to the digital world.

After a bit of tinkering I finally get 19/20 on ipv6-test.com running Waterfox 56.2.6 on Debian. I also get 19/20 on Chromium 70 and Firefox ESR (60.4.0). Waterfox addons also indicate that the browser connects to IPv6 addresses all the time. It doesn't seem to be an issue with getaddrinfo() or its config in gai.conf at all as mine is the same as Mr. kaymio's. So, what did I do? I am not entirely sure, to be honest. I disconnected from AirVPN and went on doing experiments on my ISP line with native IPv6. I set network.http.fast-fallback-to-IPv4;false network.notify.IPv6;false and restarted the browser. Then I reenabled the notify setting and restarted again. After that, Firefox/Waterfox magically started to prefer IPv6 and ipv6-test.com gave me 17/20. This is due to my router blocking ICMP (Fritz!Box calls this "Stealth Mode" ) so it should be 19/20 if I decide to stop filtering it. I reconnected to AirVPN and voilà, still prefers IPv6, now 19/20.

I ran the persistent command above. Afterward, I had a problem reaching airvpn.org with a server not found msg. I could reach other sites. After exiting Eddie, I could reach airvpn again. I did a Windows 10 network reset and a netsh Interface reset. Uninstalled and reinstalled Eddie with TAP. After a couple of reboots, IPv4/IPv6 continues to work while Eddie is running and I can connect to airvpn again. While on the VPN, IPv6 test shows browser default is IPv6 with IPv4 fallback < than 1 second for both Firefox and Chrome. 19/20 and 10/10 is the test results. Weird stuff. Also, ipleak.net test is good across the board which also reports IPv6 as browser default with IPv4 fallback. Update 01/19/2019: After doing the resets described above, Both Chrome and Firefox consistently and continuously connect with IPv6 as preferred with IPv4 fallback. Running with Win 10 64bit. Yay! To add, no browser settings were changed within the browser itself.

On windows 7, IPv6 is working by default. On Win 10, this command fixed it (cmd.exe) - netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=active Premanently fixed by command : netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=persistent

Hi there. The new laws are not encryption laws. They are ANTI encryption laws. They were passed shortly 19:00 AEST, 06 Dec and were signed into law the next day. As has been noted on other sites, the speecd with which this occurred indicates the authorities had a list of people/services and so forth they wanted to target. The laws provide a basis for mass surveillance and any type of internet cervice is subject to them. Not only encrypted apps such as telegram and signal, but ISPs, VPNs, data centres, and possibly (likely) software makers. The extent of the law is not yet known. But certainly VPNs and ISPs are within its range. Air does hot have a server in Australia, as many have noted. But Airvpn and a couple of others will be prime targets because of their uncompromising approach to security and anonymity. If an internet business has operations in Australia, and say other countries, it is say a data centre - and air has servers in that businesses data centre in another country, the intent of the law is to force that internet business to compromise servers in its data centres elsewhere. So, theoretically, air could be targeted. BUT: Several things may happen. The internet service might withdraw from Australia (and some have indicated privately they will spin off their Australian operations and seem to be doing so); or they will simply tell the Australian government to get stuffed. Protonmail has said as much. Or both will happen. Already a couple of internet startups have begun to move operations offshore. It is also illegal to tell people how to protect themselves against this law - i.e. beef up their cyber security to thwart it. It goes even further: even if you are not specifically telling people how to evade this law but are just telling them how to increase their security and anonymity generally, that is a breach of the law. The law, according to some technical experts, provides a legislative basis for mass surveillance. Two things we know it can do is facilitate MITM attacks and also the injection of malicious code via updates. One result and a clear aim, according to technical experts, is to harvest private keys and do so on an industrial scale, and so decrypt all communications. And it is indiscriminate. There has been a bit of discussion on redit, but also a lot on twitter. People are not happy but that does not really come into it.

So, a few days ago I had a chat with an AirVPN member on XMPP and he/she remarked that it was not possible to reach other XMPP servers. It was tried to show the XMPP rooms at conference.riseup.net for example. It left us wondering whether AirVPN's XMPP server is indeed federated. I understand that Riseup might simply not send out the room list, given their ideology. So to rule this out I opened a XMPP server directory and cherry-picked some servers like jabber.at and jabber.de. Checking their status first, none of them showed me a room list. As everyone who has a Riseup account also has access to the Riseup XMPP server I tried to contact my Riseup account, following their "guide". The result is "remote server not found". This might indicate the server is not federated or there is a problem with federation, but at least that a connection issue to other servers persists. Did someone test this out as well? Were you successful? And is it possible to get a definite answer on the federation thing? Tests were done using Psi, the member used Pidgin.

Thanks for a quick response. Here's quite technical report what's happening now. I'm sorry if it looks unclear. The first test. I set DNS switch mode in the Preferences as Disabled. Then Eddie used these directives: client dev tun auth-nocache resolv-retry infinite nobind persist-key persist-tun verb 3 connect-retry-max 1 ping 10 ping-exit 32 explicit-exit-notify 5 dhcp-option DOMAIN-ROUTE . up /etc/openvpn/update-systemd-resolved down /etc/openvpn/update-systemd-resolved script-security 2 down-pre The scipt update-systemd-resolved is the following from github: #!/usr/bin/env bash # # OpenVPN helper to add DHCP information into systemd-resolved via DBus. # Copyright (C) 2016, Jonathan Wright <jon@than.io> # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. # This script will parse DHCP options set via OpenVPN (dhcp-option) to update # systemd-resolved directly via DBus, instead of updating /etc/resolv.conf. To # install, set as the 'up' and 'down' script in your OpenVPN configuration file # or via the command-line arguments, alongside setting the 'down-pre' option to # run the 'down' script before the device is closed. For example: # up /etc/openvpn/scripts/update-systemd-resolved # down /etc/openvpn/scripts/update-systemd-resolved # down-pre # Define what needs to be called via DBus DBUS_DEST="org.freedesktop.resolve1" DBUS_NODE="/org/freedesktop/resolve1" SCRIPT_NAME="${BASH_SOURCE[0]##*/}" log() { logger -s -t "$SCRIPT_NAME" "$@" } for level in emerg err warning info debug; do printf -v functext -- '%s() { log -p user.%s -- "$@" ; }' "$level" "$level" eval "$functext" done usage() { err "${1:?${1}. }. Usage: ${SCRIPT_NAME} up|down device_name." } busctl_call() { # Preserve busctl's exit status busctl call "$DBUS_DEST" "$DBUS_NODE" "${DBUS_DEST}.Manager" "$@" || { local -i status=$? emerg "'busctl' exited with status $status" return $status } } get_link_info() { dev="$1" shift link='' link="$(ip link show dev "$dev")" || return $? echo "$dev" "${link%%:*}" } dhcp_settings() { for foreign_option in "${!foreign_option_@}"; do foreign_option_value="${!foreign_option}" [[ "$foreign_option_value" == *dhcp-option* ]] \ && echo "${foreign_option_value#dhcp-option }" done } up() { local link="$1" shift local if_index="$1" shift info "Link '$link' coming up" # Preset values for processing -- will be altered in the various process_* # functions. local -a dns_servers=() dns_domain=() dns_search=() dns_routed=() local -i dns_server_count=0 dns_domain_count=0 dns_search_count=0 dns_routed_count=0 local dns_sec="" while read -r setting; do setting_type="${setting%% *}" setting_value="${setting#* }" process_setting_function="${setting_type,,}" process_setting_function="process_${process_setting_function//-/_}" if declare -f "$process_setting_function" &>/dev/null; then "$process_setting_function" "$setting_value" || return $? else warning "Not a recognized DHCP setting: '${setting}'" fi done < <(dhcp_settings) if [[ "${#dns_servers[*]}" -gt 0 ]]; then busctl_params=("$if_index" "$dns_server_count" "${dns_servers[@]}") info "SetLinkDNS(${busctl_params[*]})" busctl_call SetLinkDNS 'ia(iay)' "${busctl_params[@]}" || return $? fi if [[ "${#dns_domain[*]}" -gt 0 \ || "${#dns_search[*]}" -gt 0 \ || "${#dns_routed[*]}" -gt 0 ]]; then dns_count=$((dns_domain_count+dns_search_count+dns_routed_count)) busctl_params=("$if_index" "$dns_count") if [[ "${#dns_domain[*]}" -gt 0 ]]; then busctl_params+=("${dns_domain[@]}") fi if [[ "${#dns_search[*]}" -gt 0 ]]; then busctl_params+=("${dns_search[@]}") fi if [[ "${#dns_routed[*]}" -gt 0 ]]; then busctl_params+=("${dns_routed[@]}") fi info "SetLinkDomains(${busctl_params[*]})" busctl_call SetLinkDomains 'ia(sb)' "${busctl_params[@]}" || return $? fi if [[ -n "${dns_sec}" ]]; then if [[ "${dns_sec}" == "default" ]]; then # We need to provide an empty string to use the default settings info "SetLinkDNSSEC($if_index '')" busctl_call SetLinkDNSSEC 'is' "$if_index" "" || return $? else info "SetLinkDNSSEC($if_index ${dns_sec})" busctl_call SetLinkDNSSEC 'is' "$if_index" "${dns_sec}" || return $? fi fi } down() { local link="$1" shift local if_index="$1" shift info "Link '$link' going down" if [[ "$(whoami 2>/dev/null)" != "root" ]]; then # Cleanly handle the priviledge dropped case by not calling RevertLink info "Priviledges dropped in the client: Cannot call RevertLink." else busctl_call RevertLink i "$if_index" fi } process_dns() { address="$1" shift if looks_like_ipv6 "$address"; then process_dns_ipv6 "$address" || return $? elif looks_like_ipv4 "$address"; then process_dns_ipv4 "$address" || return $? else err "Not a valid IPv6 or IPv4 address: '$address'" return 1 fi } process_dns6() { address="$1" shift if looks_like_ipv6 "$address"; then process_dns_ipv6 "$address" || return $? elif looks_like_ipv4 "$address"; then process_dns_ipv4 "$address" || return $? else err "Not a valid IPv6 or IPv4 address: '$address'" return 1 fi } looks_like_ipv4() { [[ -n "$1" ]] && { local dots="${1//[^.]}" (( ${#dots} == 3 )) } } looks_like_ipv6() { [[ -n "$1" ]] && { local colons="${1//[^:]}" (( ${#colons} >= 2 )) } } process_dns_ipv4() { local address="$1" shift info "Adding IPv4 DNS Server ${address}" (( dns_server_count += 1 )) dns_servers+=(2 4 ${address//./ }) } # Enforces RFC 5952: # 1. Don't shorten a single 0 field to '::' # 2. Only longest run of zeros should be compressed # 3. If there are multiple longest runs, the leftmost should be compressed # 4. Address must be maximally compressed, so no all-zero runs next to '::' # # ... # # Thank goodness we don't have to handle port numbers, though parse_ipv6() { local raw_address="$1" log_invalid_ipv6() { local message="'$raw_address' is not a valid IPv6 address" emerg "${message}: $*" } trap -- 'unset -f log_invalid_ipv6' RETURN if [[ "$raw_address" == *::*::* ]]; then log_invalid_ipv6 "address cannot contain more than one '::'" return 1 elif [[ "$raw_address" =~ :0+:: ]] || [[ "$raw_address" =~ ::0+: ]]; then log_invalid_ipv6 "address contains a 0-group adjacent to '::' and is not maximally shortened" return 1 fi local -i length=8 local -a raw_segments=() IFS=$':' read -r -a raw_segments <<<"$raw_address" local -i raw_length="${#raw_segments[@]}" if (( raw_length > length )); then log_invalid_ipv6 "expected ${length} segments, got ${raw_length}" return 1 fi # Store zero-runs keyed to their sizes, storing all non-zero segments prefixed # with a token marking them as such. local nonzero_prefix=$'!' local -i zero_run_i=0 compressed_i=0 local -a tokenized_segments=() local decimal_segment='' next_decimal_segment='' for (( i = 0 ; i < raw_length ; i++ )); do raw_segment="${raw_segments[i]}" printf -v decimal_segment -- '%d' "0x${raw_segment:-0}" # We're in the compressed group. The length of this run should be # enough to bring the total number of segments to 8. if [[ -z "$raw_segment" ]]; then (( compressed_i = zero_run_i )) # `+ 1' because the length of the current segment is counted in # `raw_length'. (( tokenized_segments[zero_run_i] = ((length - raw_length) + 1) )) # If we have an address like `::1', skip processing the next group to # avoid double-counting the zero-run, and increment the number of # 0-groups to add since the second empty group is counted in # `raw_length'. if [[ -z "${raw_segments[i + 1]}" ]]; then (( i++ )) (( tokenized_segments[zero_run_i]++ )) fi (( zero_run_i++ )) elif (( decimal_segment == 0 )); then (( tokenized_segments[zero_run_i]++ )) # The run is over if the next segment is not 0, so increment the # tracking index. printf -v next_decimal_segment -- '%d' "0x${raw_segments[i + 1]}" (( next_decimal_segment != 0 )) && (( zero_run_i++ )) else # Prefix the raw segment with `nonzero_prefix' to mark this as a # non-zero field. tokenized_segments[zero_run_i]="${nonzero_prefix}${decimal_segment}" (( zero_run_i++ )) fi done if [[ "$raw_address" == *::* ]]; then if (( ${#tokenized_segments[*]} == length )); then log_invalid_ipv6 "single '0' fields should not be compressed" return 1 else local -i largest_run_i=0 largest_run=0 for (( i = 0 ; i < ${#tokenized_segments[@]}; i ++ )); do # Skip groups that aren't zero-runs [[ "${tokenized_segments[i]:0:1}" == "$nonzero_prefix" ]] && continue if (( tokenized_segments[i] > largest_run )); then (( largest_run_i = i )) largest_run="${tokenized_segments[i]}" fi done local -i compressed_run="${tokenized_segments[compressed_i]}" if (( largest_run > compressed_run )); then log_invalid_ipv6 "the compressed run of all-zero fields is smaller than the largest such run" return 1 elif (( largest_run == compressed_run )) && (( largest_run_i < compressed_i )); then log_invalid_ipv6 "only the leftmost largest run of all-zero fields should be compressed" return 1 fi fi fi for segment in "${tokenized_segments[@]}"; do if [[ "${segment:0:1}" == "$nonzero_prefix" ]]; then printf -- '%04x\n' "${segment#${nonzero_prefix}}" else for (( n = 0 ; n < segment ; n++ )); do echo 0000 done fi done } process_dns_ipv6() { local address="$1" shift info "Adding IPv6 DNS Server ${address}" local -a segments=() segments=($(parse_ipv6 "$address")) || return $? # Add AF_INET6 and byte count dns_servers+=(10 16) for segment in "${segments[@]}"; do dns_servers+=("$((16#${segment:0:2}))" "$((16#${segment:2:2}))") done (( dns_server_count += 1 )) } process_domain() { local domain="$1" shift info "Setting DNS Domain ${domain}" (( dns_domain_count = 1 )) dns_domain=("${domain}" false) } process_adapter_domain_suffix() { # This enables support for ADAPTER_DOMAIN_SUFFIX which is a Microsoft standard # which works in the same way as DOMAIN to set the primary search domain on # this specific link. process_domain "$@" } process_domain_search() { local domain="$1" shift info "Adding DNS Search Domain ${domain}" (( dns_search_count += 1 )) dns_search+=("${domain}" false) } process_domain_route() { local domain="$1" shift info "Adding DNS Routed Domain ${domain}" (( dns_routed_count += 1 )) dns_routed+=("${domain}" true) } process_dnssec() { local option="$1" setting="" shift case "${option,,}" in yes|true) setting="yes" ;; no|false) setting="no" ;; default) setting="default" ;; allow-downgrade) setting="allow-downgrade" ;; *) local message="'$option' is not a valid DNSSEC option" emerg "${message}" return 1 ;; esac info "Setting DNSSEC to ${setting}" dns_sec="${setting}" } main() { local script_type="$1" shift local dev="$1" shift if [[ -z "$script_type" ]]; then usage 'No script type specified' return 1 elif [[ -z "$dev" ]]; then usage 'No device name specified' return 1 elif ! declare -f "${script_type}" &>/dev/null; then usage "Invalid script type: '${script_type}'" return 1 else if ! read -r link if_index _ < <(get_link_info "$dev"); then usage "Invalid device name: '$dev'" return 1 fi "$script_type" "$link" "$if_index" "$@" fi } if [[ "${BASH_SOURCE[0]}" == "$0" ]] || [[ "$AUTOMATED_TESTING" == 1 ]]; then set -o nounset main "${script_type:-}" "${dev:-}" "$@" fi As a result of the above procedure, ipleak.net shows that I'm leaking my mobile broadband DNS (1.1.1.1) Cloudfare servers and I'm not using the AirVPN DNS at all. In the /etc/resolv.conf there is cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 And what really looks to cause the leak is the systemd-resolve. There is no AirVPN entry or any other entries at the Global section. My normal DNS IP is at the ppp0 section, as I use an USB Huawei mobile broadband stick. sudo systemd-resolve --status . . . Link 87 (tun0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no Link 69 (ppp0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 1.1.1.1 The second test. DNS switch mode set to Automatic. Eddie directives: client dev tun auth-nocache resolv-retry infinite nobind persist-key persist-tun verb 3 connect-retry-max 1 ping 10 ping-exit 32 explicit-exit-notify 5 /etc/resolv.conf: cat /etc/resolv.conf # Generated by Eddie v2.17.2 | https://eddie.website nameserver 10.13.144.1 nameserver fde6:7a:7d20:990::1 systemd-resolved: sudo systemd-resolve --status Global DNS Servers: 10.13.144.1 fde6:7a:7d20:990::1 . . . Link 86 (tun0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no Link 69 (ppp0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 1.1.1.1 So it seems that my normal DNS IP 1.1.1.1 is not removed the configuration. Ipleak.net shows that now I use the AirVPN DNS server, but also a bunch of 1.1.1.1 Cloudfare servers. At least it's a bit better than the first test. Update-systemd-resolved script It's also odd that Eddie 2.17.2 doesn't seem to trigger the update-systemd-resolved script. This is the log at the first test: I 2018.09.26 17.05.25 - Checking authorization ... ! 2018.09.26 17.05.26 - Connecting to Cepheus (Norway, Oslo) . 2018.09.26 17.05.26 - OpenVPN > OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018 . 2018.09.26 17.05.26 - OpenVPN > library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.08 . 2018.09.26 17.05.26 - Connection to OpenVPN Management Interface . 2018.09.26 17.05.26 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2018.09.26 17.05.26 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.26 17.05.26 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2018.09.26 17.05.26 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]82.102.27.170:443 . 2018.09.26 17.05.26 - OpenVPN > Socket Buffers: R=[212992->212992] S=[212992->212992] . 2018.09.26 17.05.26 - OpenVPN > UDP link local: (not bound) . 2018.09.26 17.05.26 - OpenVPN > UDP link remote: [AF_INET]82.102.27.170:443 . 2018.09.26 17.05.26 - OpenVPN > TLS: Initial packet from [AF_INET]82.102.27.170:443, sid=75532ad7 97e1cb91 . 2018.09.26 17.05.26 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100 . 2018.09.26 17.05.26 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2018.09.26 17.05.26 - OpenVPN > VERIFY KU OK . 2018.09.26 17.05.26 - OpenVPN > Validating certificate extended key usage . 2018.09.26 17.05.26 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2018.09.26 17.05.26 - OpenVPN > VERIFY EKU OK . 2018.09.26 17.05.26 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Cepheus, emailAddress=info@airvpn.org . 2018.09.26 17.05.26 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA . 2018.09.26 17.05.26 - OpenVPN > [Cepheus] Peer Connection Initiated with [AF_INET]82.102.27.170:443 . 2018.09.26 17.05.27 - OpenVPN > SENT CONTROL [Cepheus]: 'PUSH_REQUEST' (status=1) . 2018.09.26 17.05.27 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.13.144.1,dhcp-option DNS6 fde6:7a:7d20:990::1,tun-ipv6,route-gateway 10.13.144.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:990::101d/64 fde6:7a:7d20:990::1,ifconfig 10.13.144.31 255.255.255.0,peer-id 2,cipher AES-256-GCM' . 2018.09.26 17.05.27 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: peer-id set . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2018.09.26 17.05.27 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2018.09.26 17.05.27 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2018.09.26 17.05.27 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.26 17.05.27 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2018.09.26 17.05.27 - OpenVPN > ROUTE_GATEWAY ON_LINK IFACE=ppp0 HWADDR=00:00:00:00:00:00 . 2018.09.26 17.05.27 - OpenVPN > GDG6: remote_host_ipv6=n/a . 2018.09.26 17.05.27 - OpenVPN > ROUTE6: default_gateway=UNDEF . 2018.09.26 17.05.27 - OpenVPN > TUN/TAP device tun0 opened . 2018.09.26 17.05.27 - OpenVPN > TUN/TAP TX queue length set to 100 . 2018.09.26 17.05.27 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=1 . 2018.09.26 17.05.27 - OpenVPN > /sbin/ip link set dev tun0 up mtu 1500 . 2018.09.26 17.05.27 - OpenVPN > /sbin/ip addr add dev tun0 10.13.144.31/24 broadcast 10.13.144.255 . 2018.09.26 17.05.27 - OpenVPN > /sbin/ip -6 addr add fde6:7a:7d20:990::101d/64 dev tun0 . 2018.09.26 17.05.32 - OpenVPN > /sbin/ip route add 82.102.27.170/32 dev ppp0 . 2018.09.26 17.05.32 - OpenVPN > /sbin/ip route add 0.0.0.0/1 via 10.13.144.1 . 2018.09.26 17.05.32 - OpenVPN > /sbin/ip route add 128.0.0.0/1 via 10.13.144.1 . 2018.09.26 17.05.32 - OpenVPN > add_route_ipv6(::/3 -> fde6:7a:7d20:990::1 metric -1) dev tun0 . 2018.09.26 17.05.32 - OpenVPN > /sbin/ip -6 route add ::/3 dev tun0 . 2018.09.26 17.05.32 - OpenVPN > add_route_ipv6(2000::/4 -> fde6:7a:7d20:990::1 metric -1) dev tun0 . 2018.09.26 17.05.32 - OpenVPN > /sbin/ip -6 route add 2000::/4 dev tun0 . 2018.09.26 17.05.32 - OpenVPN > add_route_ipv6(3000::/4 -> fde6:7a:7d20:990::1 metric -1) dev tun0 . 2018.09.26 17.05.32 - OpenVPN > /sbin/ip -6 route add 3000::/4 dev tun0 . 2018.09.26 17.05.32 - OpenVPN > add_route_ipv6(fc00::/7 -> fde6:7a:7d20:990::1 metric -1) dev tun0 . 2018.09.26 17.05.32 - OpenVPN > /sbin/ip -6 route add fc00::/7 dev tun0 . 2018.09.26 17.05.32 - Shell(52) of '/sbin/ip', 7 args: 'route';'add';'82.102.27.171';'via';'10.13.144.1';'dev';'tun0'; . 2018.09.26 17.05.32 - Shell(52) done in 8 ms, exit: 0 . 2018.09.26 17.05.32 - Routes, added a new route, 82.102.27.171 for gateway 10.13.144.1 . 2018.09.26 17.05.32 - Shell(53) of '/sbin/ip', 8 args: '-6';'route';'add';'2001:ac8:38:22:7d4c:b9b3:86a8:fb0d';'via';'fde6:7a:7d20:990::1';'dev';'tun0'; . 2018.09.26 17.05.33 - Shell(53) done in 9 ms, exit: 0 . 2018.09.26 17.05.33 - Routes, added a new route, 2001:ac8:38:22:7d4c:b9b3:86a8:fb0d for gateway fde6:7a:7d20:990::1 . 2018.09.26 17.05.33 - Flushing DNS I 2018.09.26 17.05.33 - Checking route IPv4 I 2018.09.26 17.05.33 - Checking route IPv6 ! 2018.09.26 17.05.33 - Connected. . 2018.09.26 17.05.33 - OpenVPN > Initialization Sequence Completed If the script is triggered, there should be a log entry which looks like . . Wed Sep 26 17:11:23 2018 /sbin/ip link set dev tun0 up mtu 1500 Wed Sep 26 17:11:23 2018 /sbin/ip addr add dev tun0 10.23.160.225/24 broadcast 10.23.160.255 Wed Sep 26 17:11:23 2018 /sbin/ip -6 addr add fde6:7a:7d20:13a0::10df/64 dev tun0 Wed Sep 26 17:11:23 2018 /etc/openvpn/update-systemd-resolved tun0 1500 1553 10.23.160.225 255.255.255.0 init Wed Sep 26 17:11:23 2018 /etc/openvpn/update-systemd-resolved tun0 1500 1553 10.23.160.225 255.255.255.0 init <14>Sep 26 17:11:23 update-systemd-resolved: Link 'tun0' coming up <14>Sep 26 17:11:23 update-systemd-resolved: Adding DNS Routed Domain . <14>Sep 26 17:11:23 update-systemd-resolved: Adding IPv4 DNS Server 10.23.160.1 <14>Sep 26 17:11:23 update-systemd-resolved: Adding IPv6 DNS Server fde6:7a:7d20:13a0::1 <14>Sep 26 17:11:23 update-systemd-resolved: SetLinkDNS(84 2 2 4 10 23 160 1 10 16 253 230 0 122 125 32 19 160 0 0 0 0 0 0 0 1) <14>Sep 26 17:11:23 update-systemd-resolved: SetLinkDomains(84 1 . true) Wed Sep 26 17:11:28 2018 /sbin/ip route add 128.127.105.183/32 dev ppp0 Wed Sep 26 17:11:28 2018 /sbin/ip route add 0.0.0.0/1 via 10.23.160.1 Wed Sep 26 17:11:28 2018 /sbin/ip route add 128.0.0.0/1 via 10.23.160.1 Wed Sep 26 17:11:28 2018 add_route_ipv6(::/3 -> fde6:7a:7d20:13a0::1 metric -1) dev tun0 . . . The above log entry is generated when I connect to AirVPN using openvpn from the command line directly without Eddie and use the same directives as in the first test. In Eddie 2.16, there were indeed log entries like that. But not in Eddie 2.17.2. And when the script is triggered, no DNS "leak" happens. So using either Eddie 2.16 or Openvpn from the commandline ipleak.net shows only AirVPN servers. Edit: Using Openvpn from command line When I connect to an AirVPN server directly from command line, here are my DNS settings, which are generated by Openvpn itself (update-systemd-resolved script is used): cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 sudo systemd-resolve --status . . . Link 85 (tun0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.23.160.1 fde6:7a:7d20:13a0::1 DNS Domain: ~. Link 92 (ppp0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 1.1.1.1 . . . Edit2: In September 27th. Small, but very important addition to the vanilla Openvpn test. There is indeed a DNS entry of 1.1.1.1 in ppp0 section, but unfortunately I didn't notice it earlier (I had to scroll results of systemd-resolve --status by one more line). So the only difference between Eddie 2.17.2 DNS and vanilla OpenVPN DNS entries is the location of the VPN servers. In other words, if they are in the global or in the tun0 section.

Nice! Updated Eddie (2.17.2) fixes the issue for me as well...MacOS 10.13.6...Network Lock enabled at startup. Many thanks for the great and speedy work, as always, Staff!

Ok, the update fixed it for me! That was very fast, thanks Staff!

kaymio's suspicion is correct, this is caused by the behaviour mandated in RFC 6724. IPv6 is designed for operation by assinging a public (inside 2000::/3) range to each user, addresses in private (ULA) ranges are deliberately picked with low priority. Your OpenVPN setup instead uses a NAT and assigns private IPs to users, which the RFC does not account for at all. You can circumvent this bug by assigning addresses from an different, non-ULA and "unused" range: e.g. fe12:34:1234::/48 Hope this helps.

Updated to reflect changes on 03-Aug-18 (previously, access was blocked from most servers).

Windows 7 Firefox 61.0.1 Testing on Eridanus server with ipv6-test.com gives me a score of 19/20 test-ipv6.com score of 10/10 with no warnings

Thanks, Mikeyy

Oh maybe there's a better way. When I ran the script the first time, the vpn was disconnected and the script would just hang. Took me a bit of time to debug it to find the UPTIME=... the culprit. At the very least, if IPADDR isn't set the script should log it and exit since otherwise it just hangs (since the grep is waiting for stdin if IPADDR is empty).

Wow, good idea! Will add it. Not sure why you added other part? If VPN is off, current script will start it (when cronjob runs). If VPN is ON, but it's in error state (not letting traffic trough) it will kill VPN and start it again. EDIT: Added your contribution to tutorial. Changed some parts of tutorial. You no longer need to copy script to /usr/ folder. It's better if it stays in shared folder of your choice since there it will survive system upgrades.

OP, I 100% support your suggestion. EFF and FSF are two of the very few organizations that are actually fighting for privacy and freedom of information sharing. It's a David and Goliath battle and they need all the help and support they can get.

Hi, I am running Buffalo WZR-600DHP on DD-WRT 20180. I successfully used the config generator to connect to Arrakis. I always *seem* to be connected (speedtests and other geolocations report me in Virginia and the OPENVPN status always says "connected" when I check). But I was sometimes getting erratic behaviour so I checked the logs and found what appears to be an unstable connection (see below for copy/paste of the OpenVPN status tab. The question is: Should I try other Open VPN servers? Downgrade my DD-WRT to the previous buffalo supported build (looks oldish) or install the only build on the DD-WRT web site that is made for my router (BrainSlayer-V24-preSP2/2013/04-01-2013-r21153/) I am looking for a) Confirmation that my VPN is "flapping" (I am not familiar with OpenVPN logging....for all I know this is normal and my issues are elsewhere) Advice on the OpenVPN c) Advice on how to "switch" OpenVPN servers easily...is there an easier way than changing the connection IP in my setup? Is the rest of my config valid across the opther servers? Thanks StateServer: : Local Address: Remote Address: Client: CONNECTED: SUCCESS Local Address: 10.4.25.150 Remote Address: 10.4.25.149 Status LogServerlog Clientlog 20130615 14:20:20 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:20:20 D MANAGEMENT: CMD 'log 500' 20130615 14:20:20 MANAGEMENT: Client disconnected 20130615 14:25:01 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:25:01 D MANAGEMENT: CMD 'state' 20130615 14:25:01 MANAGEMENT: Client disconnected 20130615 14:25:01 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:25:01 D MANAGEMENT: CMD 'state' 20130615 14:25:01 MANAGEMENT: Client disconnected 20130615 14:25:01 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:25:01 D MANAGEMENT: CMD 'state' 20130615 14:25:01 MANAGEMENT: Client disconnected 20130615 14:25:01 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:25:01 D MANAGEMENT: CMD 'log 500' 20130615 14:25:01 MANAGEMENT: Client disconnected 20130615 14:28:02 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:02 D MANAGEMENT: CMD 'state' 20130615 14:28:02 MANAGEMENT: Client disconnected 20130615 14:28:02 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:02 D MANAGEMENT: CMD 'state' 20130615 14:28:02 MANAGEMENT: Client disconnected 20130615 14:28:02 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:02 D MANAGEMENT: CMD 'state' 20130615 14:28:02 MANAGEMENT: Client disconnected 20130615 14:28:02 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:02 D MANAGEMENT: CMD 'log 500' 20130615 14:28:02 MANAGEMENT: Client disconnected 20130615 14:28:45 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:45 D MANAGEMENT: CMD 'state' 20130615 14:28:45 MANAGEMENT: Client disconnected 20130615 14:28:45 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:45 D MANAGEMENT: CMD 'state' 20130615 14:28:45 MANAGEMENT: Client disconnected 20130615 14:28:45 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:45 D MANAGEMENT: CMD 'state' 20130615 14:28:45 MANAGEMENT: Client disconnected 20130615 14:28:45 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:28:45 D MANAGEMENT: CMD 'log 500' 20130615 14:28:45 MANAGEMENT: Client disconnected 20130615 14:41:07 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:41:07 D MANAGEMENT: CMD 'state' 20130615 14:41:07 MANAGEMENT: Client disconnected 20130615 14:41:07 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:41:07 D MANAGEMENT: CMD 'state' 20130615 14:41:07 MANAGEMENT: Client disconnected 20130615 14:41:07 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:41:07 D MANAGEMENT: CMD 'state' 20130615 14:41:07 MANAGEMENT: Client disconnected 20130615 14:41:07 MANAGEMENT: Client connected from 127.0.0.1:5001 20130615 14:41:07 D MANAGEMENT: CMD 'log 500' 19700101 00:00:00

I am not sure that verifying the connection "manually" is possible. From most of the logs I looked at, the connection is re-established inside 3 seconds. You pointed out 1 example where minutes seem to occur, but this looks like an exception. I checked again a few minutes ago and the connection seems to fail every 5 minutes, but is re-established inside 0-1-2 seconds. I don't know of a good method of checking the VPN status inside this timeframe? I can't just refresh the log page to wait for another window of a few minutes... Do you have any experience with the more recent build of DD-WRT I mentioned earlier (21153?). Is this something that can get fixed by another build?

Hello! a) It might be a problem in the management, not in the OpenVPN client connection itself. Chances are that your connection is actually always on, but of course further investigation is mandatory. Could you please post the complete logs for an additional check? c) Unfortunately not with the DD-WRT web interface alone. Kind regards

I recall federation was disabled, probably to reduce spam.

this problem still exists; https://airvpn.org/topic/28866-eddie-on-opensuse-linux-leap-15-or-tumbleweed/ So back to version 2.13.6 again.

@kaymio Our assigned ULAs are in fde6:7a:7d20::/48 which is inside the range officially reserved to ULA so we don't understand why a browser should discriminate against them in favor of a local IPv4 address... Kind regards

Great idea mate. I think it would be a natural fit. I'm a member of the EFF anyway, but anything that the good folk at AirVPN can do to help the other good folk at EFF would be the very definition of a 'win-win'.

I just started tinkering with VPN on my Synology as well. I have set it up succesfully using the above guide. But I have some connections that need to go around the VPN as well (mainly SSL connections to usenet servers). I have created a passthrough by adding static routes to the routing table in the Synology configuration that explicitly go to the specific usenet server (ranges). This seems to work quite well, but of course is not useful if the IP address of the destination servers do change.

This is just part of old tutorial. It still works same as new tutorial above, I just wanted to simplify it to people so they don't have to use Putty, vi, edit crontab etc. 5. Auto reconnection when VPN is down. Since when you made your VPN connection on your Synology, you checked "Reconnect" option, Syno will try to reconnect automaticly when connection fails. But in some cases, your network will be offline long enough and Syno will stop trying to reconnect, or will hang with VPN connection established, but not working. In those cases you can use this auto reconnect script. This is reconnect script. Save it in file named whatever you want. I'm using file name "synovpn_reconnect". All instructions how to use it are inside script in comments, but I will repeat them in this post also. #VPN Check script modified Sep 11, 2016 #Script checks if VPN is up, and if it is, it checks if it's working or not. It provides details like VPN is up since, data #received/sent, VPN IP & WAN IP. #If VPN is not up it will report it in the log file and start it #Change LogFile path to your own location. #Save this script to file of your choosing (for example "synovpn_reconnect"). Store it in one of your Synology shared folders and chmod it: "chmod +x /volume1/shared_folder_name/your_path/synovpn_reconnect" #Edit "/etc/crontab" and add this line without quotes for starting script every 10 minutes: "*/10 * * * * root /volume1/shared_folder_name/your_path/synovpn_reconnect" #After that restart cron with: "/usr/syno/sbin/synoservicectl --restart crond" #!/bin/sh DATE=$(date +"%F") TIME=$(date +"%T") VPNID=$(grep "\[.*\]" /usr/syno/etc/synovpnclient/openvpn/ovpnclient.conf | cut -f 2 -d "[" | cut -f 1 -d "]") VPNNAME=$(grep conf_name /usr/syno/etc/synovpnclient/openvpn/ovpnclient.conf | cut -f 2 -d "=") LogFile="/volume1/filmovi/Backup/airvpn/check_airvpn_$DATE.log" PUBIP=$(curl -s -m 5 icanhazip.com) #PUBIP=$(curl -s -m 5 ipinfo.io/ip) #PUBIP=$(curl -s -m 5 ifconfig.me) CHECKIP=$(echo $PUBIP | grep -c ".") start_vpn() { echo "VPN is down. Attempting to (re)start now." >> $LogFile # /usr/syno/bin/synovpnc kill_client --protocol=openvpn --name=$VPNNAME /usr/syno/bin/synovpnc kill_client /bin/kill `cat /var/run/ovpn_client.pid` 2>/dev/null sleep 35 echo 1 > /usr/syno/etc/synovpnclient/vpnc_connecting echo conf_id=$VPNID > /usr/syno/etc/synovpnclient/vpnc_connecting echo conf_name=$VPNNAME >> /usr/syno/etc/synovpnclient/vpnc_connecting echo proto=openvpn >> /usr/syno/etc/synovpnclient/vpnc_connecting /usr/syno/bin/synovpnc reconnect --protocol=openvpn --name=$VPNNAME >> $LogFile } sleep 6 echo "======================================" >> $LogFile echo "$DATE $TIME" >> $LogFile if ifconfig tun0 | grep -q "00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00" then if [ "$CHECKIP" == 1 ] then IPADDR=$(/sbin/ifconfig tun0 | grep 'inet addr' | cut -d: -f2 | awk '{print $1}') RXDATA=$(/sbin/ifconfig tun0 | grep "bytes:" | cut -d: -f2 | awk '{print $1,$2,$3}') TXDATA=$(/sbin/ifconfig tun0 | grep "bytes:" | cut -d: -f3 | awk '{print $1,$2,$3}') UPTIME=$(cat /var/log/messages | grep "$IPADDR" | awk '{print $1}' | tail -1) UPTIME=$(date -d"$UPTIME" +"%Y/%m/%d %H:%M:%S") echo "VPN is up since: $UPTIME" >> $LogFile echo "Session Data RX: $RXDATA" >> $LogFile echo "Session Data TX: $TXDATA" >> $LogFile echo "VPN IP is: $IPADDR" >> $LogFile echo "WAN IP is: $PUBIP" >> $LogFile else start_vpn fi else start_vpn fi exit 0 (1) Enable SSH on your Synology if you didn't already. - As admin go to "Control panel" - "Terminal & SNMP" (you need to enable advanced mode in top right corner of control panel for this) - Check "Enable SSH service" - Click "Apply" (2) Save script above in file "synovpn_reconnect". Make sure to save it in UNIX UTF8, not windows. You can do that on windows with Notepad++, just open file with Notepad++, click "Encoding" - "Convert to UTF-8 without BOM" and them save file. (3) Edit script variables so it works for your system. You only need to edit this part: LogFile="/volume1/video/Backup/airvpn/check_airvpn_$DATE.log" Thanks to foobar666, you no longer need to enter VPNID or VPNNAME, it will detect them automatically. Now you only need to change your LogFile variable to match your wishes. After you finish editing script, save it. (4) Move or copy "synovpn_reconnect" to your Synology shared drive. Doesn't matter which, just be sure to know full path to it. If you only have 1 volume/drive, with multiple shared folders, your path should look similar to this: /volume1/shared_folder_name/your_path/ So for example, if you keep your files in default CloudStation folder, your path should look something like this: /volume1/home/your_username/CloudStation/ You can also do all this with VI, check original tutorial for that. (5) Now use Putty if you are on windows, or your terminal on linux, to access your Synology via SSH. I will not tutor you how to do that, learn. admin@192.168.1.100 or username@192.168.1.100 + password, or whatever your Syno LAN IP is. (6) Now type this into Putty/terminal: sudo chmod +x /volume1/shared_folder_name/your_path/synovpn_reconnect You need to chmod it to be executable. You will notice I use "sudo". It's because my admin username isn't default "admin". If you are using default "admin" user, then you probably don't need sudo. (7) Setup cron so it automatically starts your script every X minutes / hours / days. To setup it enter this: vi /etc/crontab And then press "i" to enter editing mode. Go to last line, and start new line with this: */10 * * * * root /volume1/shared_folder_name/your_path/synovpn_reconnect Note that those ARE NOT spaces, those are TABS. This will start your script every 10 minutes. Change to whatever you want. Then press ESC key, and then type: :wq To exit VI and save file. After that type: /usr/syno/sbin/synoservicectl --restart crond To restart cron (or restart your Synology). Tip: If you don't want logfile, you can comment out those lines, or remove ">> $LogFile" code from whole script.