IPv6 support and new smart features

[kaymio 7]

Thank you @Staff.

 

kaymio, on 20 Jun 2018 - 11:52, said:

Great that you implemented IPv6 in your service. Thank you!

Although I got a few questions:

1. Port Forwarding is not working (yet)? I've already pointed a URL to the exit v6 and can ping it, but I can't establish a connection with SSH

Hello!

Thanks, this needs an investigation. When you test in IPv4, you have no problems with port forwarding, is this right? Does the same happen if you run Eddie with Network Lock enabled and disabled? Have you checked the firewall rules pertaining to IPv6, especially when you run some other software to connect?

 

My bad, I got the port numbers mixed up Port Forwarding is working just fine!!

 

 

 

kaymio, on 20 Jun 2018 - 11:52, said:

2. The test from https://test-ipv6.com/ is showing me a 10/10 but says "Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this."

Both my browsers (FF and Chromium) don't use IPv6 actively. Is this a problem because of the DNS using IPv4 or because the IPv6 of the tun device gets a Unique local address?

 

This is a matter we are aware of, but we still don't have a definite explanation. https://airvpn.org/topic/25140-the-issue-your-browser-is-avoiding-ipv6/

 

Good to know that this issue is being worked on.  The browsers should favor IPv6 by default. I had problems the other way around when my computer was using the unencrypted native IPv6 instead of your IPv4 tunnel. Disabling v6 was the solution then.

 

 

kaymio, on 20 Jun 2018 - 11:52, said:

EDIT: A test on Subra revealed some problems:

Danger! IPv6 sorta works - however, large packets appear to fail, giving the appearance of a broken website. If a publisher publishes to IPv6, you will believe their web site to be broken. Ask your ISP about MTU issues; possibly with your tunnel. Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big)

Gianfar and Kajam are working fine.

 

Thanks, that needs an investigation too.

 

I've tested all European Gen2 servers for this problem:

 

Of the Dutch servers are affected: Alcyone, Nash, Salm, Situla and Subra

 

German Servers: Cervantes, Errai and Ogma. The only Frankfurt server not having this problem is Adhara, as well as all three servers in Munich.

 

Spanish Servers: Eridanus and Mekbuda, while Taurus is working

 

The Latvian Phact Server is listed in the Config Generator as Gen2 but doesn't give an IPv6 address.

 

 

The Austrian Server, the Belgian Servers, the Swiss Servers, the CZ server and the six Swedish Servers are giving a 10/10

 

Keep up the good work! Long live AirVPN!

[Judas4all 3]

This thread will be periodically updated to provide the list of VPN servers new generation setup (internally, we call this new setup "Gen 2").

 

Hi, sounds great. Maybe I'm the only one, but how do I identify a Gen2 Server ?

[siberianwlf 3]

 

Updated documentation please

 

How would I use IPv4 and IPv6 on DD-WRT with tls-crypt for example?

 

I would also like to know that!

 

+1 for that info :-)

[ableounceony 6]

Updated documentation please

 

How would I use IPv4 and IPv6 on DD-WRT with tls-crypt for example?

 

Ditto for docs on how to do this through pfSense, too.  Some of us have tried to figure it out here:

 

https://airvpn.org/topic/26818-ipv6-pfsense-setup/

 

But, we've gotten nowhere.

[atelier23 2]

what is my ip address website still showed it failing, even tho i had latest beta installed and was connected to ALKAID server, still showed my home town location.  im manually disabily IPV6 and sticking to IPV4 for now.  :/

[Monotremata 22]

I get the same results at test-ivp6.com too. 10/10 but my browser (Chrome) isnt using ipv6, even though its supposed to favor it. They removed the option in old versions had where you had to enable it, and just made it the default. I get the same results with ipv6-test.com as well. I can pass with 15/20 there. It detects all my IPv4 and IPv6 info, but the browser is defaulting to IPv4 and not falling back to IPv6 at all. ipleak tells me the same thing, fallback always fails, and ipleak doesnt show me the IPv6 DNS server, but it does show me my IPv6 address. I used to get various results in Safari too, even if I would run the test like 3x in a row. One minute, it would default to IPv6, the next it would use v4, etc.. Still havent tried Firefox yet, it wouldnt open anymore the other day when I wanted to see, and now something has happened to Safari where if even manage to get it open, it will lock my system up for days heh. Thanks to ipleak though, I just found out by default Chrome leaks out my actual ISP IP with WebRTC.. Had to grab an extension to shut that off. Google's own IPv6 test, never finds IPv6 at all go figure. I think I got it to once when Castor first went up for testing it, but nowadays, it cant find IPv6 addresses to save its life hehe.

[Staff 9972]

 Thanks to ipleak though, I just found out by default Chrome leaks out my actual ISP IP with WebRTC..

 

Hello!

 

Wait, while the other issues could be caused by the browsers and other factors we can't have any control on, this should NOT happen if Network Lock is enabled. Can you please try again with Network Lock enabled AND Eddie version 2.15.2?

 

Kind regards

[Monotremata 22]

Network lock is always enabled if Eddie is running. The only time I shut off Eddie anymore, is if I have to restart my Mac. At ipleak, if you read the section on the WebRTC leaks though, it sounds like its a known issue with Chrome. I just installed the extension they tell you to and set it to ONLY broadcast my public IP, not the "private one" and now ipleak reads a clean slate, except for the no fallback to IPv6 (still shows me an IPv6 address though). Using address 3 seems to force it more often, at least that was the case for Safari, but for some reason its hit and miss connecting with it now. I tried earlier this afternoon, and it just hung while trying to connect. Switched it back to regular TCP (I take a big speed hit with UDP on Spectrum) and it connected like nothing again.

 

EDIT: Ok I just went back to ipleak to test it again because Im not sure if I ran the test before upgrading to 2.15.2 this afternoon or not. I turned off the WebRTC extension, and yep, double checked network lock is enabled, Im connected to Merope with address 1 TCP, and in Chrome it shows me my Spectrum IP address under the WebRTC detection section. Turned the extension back on, and now nothing.

[securvark 16]

Works perfect!

 

Setup with 5 OpvenVPN clients to different servers in different countries, all on port 443 opn entry ip 3 with TLS encrryption. Routing table shows no overlapping subnets:

 

Destination        Gateway            Flags     Netif Expire
default            .........          UGS         re0
10.10.86.0/24      10.10.86.1         UGS      ovpnc5
10.10.86.1         link#11            UH       ovpnc5
10.10.86.6         link#11            UHS         lo0
10.14.22.0/24      10.14.22.1         UGS      ovpnc2
10.14.22.1         link#8             UH       ovpnc2
10.14.22.4         link#8             UHS         lo0
10.15.182.0/24     10.15.182.1        UGS      ovpnc1
10.15.182.1        link#7             UH       ovpnc1
10.15.182.3        link#7             UHS         lo0
...
10.26.150.0/24     10.26.150.1        UGS      ovpnc3
10.26.150.1        link#9             UH       ovpnc3
10.26.150.11       link#9             UHS         lo0
10.32.198.0/24     10.32.198.1        UGS      ovpnc4
10.32.198.1        link#10            UH       ovpnc4
10.32.198.7        link#10            UHS         lo0
....
127.0.0.1          link#4             UH          lo0
...

[Staff 9972]

EDIT: Ok I just went back to ipleak to test it again because Im not sure if I ran the test before upgrading to 2.15.2 this afternoon or not. I turned off the WebRTC extension, and yep, double checked network lock is enabled, Im connected to Merope with address 1 TCP, and in Chrome it shows me my Spectrum IP address under the WebRTC detection section. Turned the extension back on, and now nothing.

 

Just to clarify, does WebRTC show your public IPv6 address, your public IPv4 address or your private addresses?

 

Kind regards

[securvark 16]

...

The internal load balancing is already active on all "Gen 2" servers.

 

As stated above I run 5 simultaneous connections to different servers across different countries from pfSense, configured in a gateway group. Previously when I downloaded or did a speed test, a single vpn connection would be used, capping out on around 120mbit (100% cpu on a single core).

 

Currently, I see it using 4 vpn connections simultaneously, and it saturates my 400mbit DSL.

 

On one hand, I think this is pretty neat, I'll have to see how it works over a longer period of time.

 

Before this, I was actually kind of happy that a single node in my network was unable to saturate my DSL as one client in the network would never be able to get more than 120mbit unless it would download multiple large files. PfSense is quite good distributing the load over multiple gateways in a gateway group. But with this load balancing, a single download could possibly cause lag for other users, and I might have to configure some QoS or throttling.

[Monotremata 22]

 

EDIT: Ok I just went back to ipleak to test it again because Im not sure if I ran the test before upgrading to 2.15.2 this afternoon or not. I turned off the WebRTC extension, and yep, double checked network lock is enabled, Im connected to Merope with address 1 TCP, and in Chrome it shows me my Spectrum IP address under the WebRTC detection section. Turned the extension back on, and now nothing.

 

Just to clarify, does WebRTC show your public IPv6 address, your public IPv4 address or your private addresses?

 

Kind regards

 

I checked just now, and apparently its NOT any of my addresses. IPleak says its a "private use" one, its a 10.28.x.x address, which I think might be AirVPN?? I went through Eddies log and seeing it doing stuff with that address, but its not my WAN address, and my Mac's IP address is a 192.168 address so its definitely not that heh. Its still kinda odd that Chrome is the only one IPLeak can detect it on. Both Safari and Firefox never show anything for WebRTC detection. Now I just need to figure out what keeps shutting off my IPv6 address on my Mac. Still dont know if its my Mac or Eddie, but it likes to shut off my Airports IPv6 address, which usually kicks me right off one of the Gen 2 servers, and it won't let me reconnect with IPv6 until I actually shut off my wireless card, and turn it back on and let it get another address from the router. The IPv4 only servers still work fine, but no go on the new ones until it gets another address.

[securvark 16]

I checked just now, and apparently its NOT any of my addresses. IPleak says its a "private use" one, its a 10.28.x.x address, which I think might be AirVPN?? I went through Eddies log and seeing it doing stuff with that address, but its not my WAN address, and my Mac's IP address is a 192.168 address so its definitely not that heh. Its still kinda odd that Chrome is the only one IPLeak can detect it on. Both Safari and Firefox never show anything for WebRTC detection. Now I just need to figure out what keeps shutting off my IPv6 address on my Mac. Still dont know if its my Mac or Eddie, but it likes to shut off my Airports IPv6 address, which usually kicks me right off one of the Gen 2 servers, and it won't let me reconnect with IPv6 until I actually shut off my wireless card, and turn it back on and let it get another address from the router. The IPv4 only servers still work fine, but no go on the new ones until it gets another address.

 

A lot (all?) of AirVPN servers give you a virtual network interface with a private IP in 10.0.0.0/8 range. 10.28.x.x is probably the tunnel IP on your end, with a gateway leading to the "other side". Private IP ranges are never WAN addresses, as private IP's cannot be routed over the internet.

 

Opening a terminal or command prompt and running the command "netstat -rn" should give you more info. the commands "ip a" or "ifconfig" (both Linux or BSD) or "ipconfig /all" (Windows) should give you a list of local IP addresses.

 

This IP should not leak though. Search for Chrome webRTC leak, there are settings or addons that prevent Chrome from leaking this info.

[Staff 9972]

 

 

EDIT: Ok I just went back to ipleak to test it again because Im not sure if I ran the test before upgrading to 2.15.2 this afternoon or not. I turned off the WebRTC extension, and yep, double checked network lock is enabled, Im connected to Merope with address 1 TCP, and in Chrome it shows me my Spectrum IP address under the WebRTC detection section. Turned the extension back on, and now nothing.

 

Just to clarify, does WebRTC show your public IPv6 address, your public IPv4 address or your private addresses?

 

Kind regards

 

I checked just now, and apparently its NOT any of my addresses. IPleak says its a "private use" one, its a 10.28.x.x address, which I think might be AirVPN??

 

Yes, as securvark explained as well, that's the virtual private network IP address. Therefore Network Lock works as expected and you have never had any leak. Everything was and is fine.

 

Kind regards

[Guest]

I realize this must be dumb question but... How do i enable tlscrypt? Did not see it in protocols.

 

Using the newest stable. Do I need the experimental?

 

thanks

[go558a83nk 362]

I realize this must be dumb question but... How do i enable tlscrypt? Did not see it in protocols.

 

Using the newest stable. Do I need the experimental?

 

thanks

 

Read the first post of this thread again.

[JSD 6]

@ ZPKZ:

 

I asked the same question, and it was explained to me that the protocols with a server IPs of 3 or 4 were those with tls-crypt.

 

 

@ go558a83nk

 

Yo may be able to find the answer in the first post, but I guarantee you that the vast majority of internet users will NOT be able to do so. This is certainly also true for the vast majority of people who are (interested in) using a VPN. (On average, AIR users may have a better technical understanding.)

Most people will not even have a glimpse of how tls-crypt works, and will not be able to understand the explanations on the internet that I was able to google, because they don’t even know there is a control channel and a data channel in OpenVPN.

 

Some of those who are familiar with computer technology may tend to look down on these people (I do NOT insinuate you are doing this).

 

But at last, they are (potential) customers.

 

And the vast majority of people driving cars know very little about the technology behind cars, and the vast majority of people inhabiting houses know very little about architectonics. And yet car companies and architects make sure that these people can use cars and houses, respectively, without any problems.

[go558a83nk 362]

@ ZPKZ:

 

I asked the same question, and it was explained to me that the protocols with a server IPs of 3 or 4 were those with tls-crypt.

 

 

@ go558a83nk

 

Yo may be able to find the answer in the first post, but I guarantee you that the vast majority of internet users will NOT be able to do so. This is certainly also true for the vast majority of people who are (interested in) using a VPN. (On average, AIR users may have a better technical understanding.)

Most people will not even have a glimpse of how tls-crypt works, and will not be able to understand the explanations on the internet that I was able to google, because they don’t even know there is a control channel and a data channel in OpenVPN.

 

Some of those who are familiar with computer technology may tend to look down on these people (I do NOT insinuate you are doing this).

 

But at last, they are (potential) customers.

 

And the vast majority of people driving cars know very little about the technology behind cars, and the vast majority of people inhabiting houses know very little about architectonics. And yet car companies and architects make sure that these people can use cars and houses, respectively, without any problems.

 

 

It takes no technical understanding of how tls-crypt works to know how to "use" tls-crypt with the Eddie app.  From the first post of this thread, "'tls-crypt' support, TLS 1.2 forced  on entry-IP addresses 3 and 4 of Gen 2 servers" (bolded is their formatting).  So, tls-crypt on entry IP 3 and 4.  See the attachment to see that entry IP 3 and 4 are clearly shown in the Eddie preferences.

[ghulands 0]

Are there any plans to vend out routable ipv6 addresses so that we can use NPt? 

[Staff 9972]

Are there any plans to vend out routable ipv6 addresses so that we can use NPt? 

 

Hello!

 

At the moment this is not planned, we're sorry. We want to maintain the protection you have with IPv4, where the exit-IPv4 address is shared between all the clients connected to a certain VPN, and the nodes are behind a NAT with a private address in some subnet.

 

Kind regards

[madrat 19]

First time trying to connect to a IPv6 server (Rana). Tried connecting once, failed and then connected to a IPv4 server. On a Mac 10.11.6 running Eddie 2.15.2. Tried a second time and noticed one unusual thing happening. Under system preferences/network/advanced/TCP/IP - configure IPv6 was set to automatically prior to trying to connect. After failing to connect, it defaulted back to "off". Any ideas? Log is attached:

. 2018.06.25 16:24:51 - macOS - PF rules updated, reloading
! 2018.06.25 16:24:52 - Disconnecting
. 2018.06.25 16:24:52 - Routes, removed a route previously added, 71.19.252.32 for gateway 10.4.0.1
. 2018.06.25 16:24:52 - Sending management termination signal
. 2018.06.25 16:24:52 - Management - Send 'signal SIGTERM'
. 2018.06.25 16:24:52 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2018.06.25 16:24:52 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2018.06.25 16:24:58 - OpenVPN > /sbin/route delete -net 71.19.252.31 192.168.1.254 255.255.255.255
. 2018.06.25 16:24:58 - OpenVPN > delete net 71.19.252.31: gateway 192.168.1.254
. 2018.06.25 16:24:58 - OpenVPN > /sbin/route delete -net 0.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:24:58 - OpenVPN > delete net 0.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:24:58 - OpenVPN > /sbin/route delete -net 128.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:24:58 - OpenVPN > delete net 128.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:24:58 - OpenVPN > Closing TUN/TAP interface
. 2018.06.25 16:24:58 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
. 2018.06.25 16:24:58 - Connection terminated.
. 2018.06.25 16:24:58 - IPv6 restored on network adapter (SAMSUNG Modem)
. 2018.06.25 16:24:58 - IPv6 restored on network adapter (Ethernet)
. 2018.06.25 16:24:58 - IPv6 restored on network adapter (FireWire)
. 2018.06.25 16:24:58 - IPv6 restored on network adapter (Wi-Fi)
. 2018.06.25 16:24:58 - DNS of a network adapter restored to original settings (SAMSUNG Modem, to Automatic)
. 2018.06.25 16:24:58 - DNS of a network adapter restored to original settings (Ethernet, to Automatic)
I 2018.06.25 16:24:58 - Checking authorization ...
! 2018.06.25 16:24:59 - Connecting to Rana (Canada, Toronto, Ontario)
. 2018.06.25 16:24:59 - OpenVPN > OpenVPN 2.4.6 x86_64-apple-darwin17.5.0 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Apr 27 2018
. 2018.06.25 16:24:59 - OpenVPN > library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
. 2018.06.25 16:24:59 - Connection to OpenVPN Management Interface
. 2018.06.25 16:24:59 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3101
. 2018.06.25 16:24:59 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:24:59 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:24:59 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET6]2604:6880:c713:5e84:45b1:390b:9c7e:9838:443
. 2018.06.25 16:24:59 - OpenVPN > Socket Buffers: R=[196724->262144] S=[9216->262144]
. 2018.06.25 16:24:59 - OpenVPN > UDPv6 link local: (not bound)
. 2018.06.25 16:24:59 - OpenVPN > UDPv6 link remote: [AF_INET6]2604:6880:c713:5e84:45b1:390b:9c7e:9838:443
. 2018.06.25 16:24:59 - OpenVPN > write UDPv6: No route to host (code=65)
. 2018.06.25 16:24:59 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3101
. 2018.06.25 16:25:01 - OpenVPN > write UDPv6: No route to host (code=65)
. 2018.06.25 16:25:31 - Above log line repeated 3 times more
. 2018.06.25 16:25:31 - OpenVPN > [uNDEF] Inactivity timeout (--ping-exit), exiting
. 2018.06.25 16:25:31 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2018.06.25 16:25:36 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
! 2018.06.25 16:25:36 - Disconnecting
. 2018.06.25 16:25:36 - Connection terminated.
I 2018.06.25 16:25:40 - Checking authorization ...
. 2018.06.25 16:25:41 - IPv6 disabled on network adapter (SAMSUNG Modem)
. 2018.06.25 16:25:41 - IPv6 disabled on network adapter (Ethernet)
. 2018.06.25 16:25:41 - IPv6 disabled on network adapter (FireWire)
. 2018.06.25 16:25:41 - IPv6 disabled on network adapter (Wi-Fi)
! 2018.06.25 16:25:41 - Connecting to Kleeia (Canada, Vancouver)
. 2018.06.25 16:25:41 - OpenVPN > OpenVPN 2.4.6 x86_64-apple-darwin17.5.0 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Apr 27 2018
. 2018.06.25 16:25:41 - OpenVPN > library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
. 2018.06.25 16:25:41 - Connection to OpenVPN Management Interface
. 2018.06.25 16:25:41 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3101
. 2018.06.25 16:25:41 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:25:41 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:25:41 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]71.19.252.31:443
. 2018.06.25 16:25:41 - OpenVPN > Socket Buffers: R=[196724->262144] S=[9216->262144]
. 2018.06.25 16:25:41 - OpenVPN > UDP link local: (not bound)
. 2018.06.25 16:25:41 - OpenVPN > UDP link remote: [AF_INET]71.19.252.31:443
. 2018.06.25 16:25:41 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3101
. 2018.06.25 16:25:41 - OpenVPN > TLS: Initial packet from [AF_INET]71.19.252.31:443, sid=df676e5d ad3da923
. 2018.06.25 16:25:41 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2018.06.25 16:25:41 - OpenVPN > VERIFY KU OK
. 2018.06.25 16:25:41 - OpenVPN > Validating certificate extended key usage
. 2018.06.25 16:25:41 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2018.06.25 16:25:41 - OpenVPN > VERIFY EKU OK
. 2018.06.25 16:25:41 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Kleeia, emailAddress=info@airvpn.org
. 2018.06.25 16:25:42 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2018.06.25 16:25:42 - OpenVPN > [Kleeia] Peer Connection Initiated with [AF_INET]71.19.252.31:443
. 2018.06.25 16:25:43 - OpenVPN > SENT CONTROL [Kleeia]: 'PUSH_REQUEST' (status=1)
. 2018.06.25 16:25:43 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.1.47 255.255.0.0,peer-id 78,cipher AES-256-GCM'
. 2018.06.25 16:25:43 - OpenVPN > Pushed option removed by filter: 'redirect-gateway def1 bypass-dhcp'
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: compression parms modified
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: peer-id set
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625
. 2018.06.25 16:25:43 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified
. 2018.06.25 16:25:43 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM'
. 2018.06.25 16:25:43 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2018.06.25 16:25:43 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2018.06.25 16:25:43 - OpenVPN > ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=en0 HWADDR=00:23:df:8c:a0:ae
. 2018.06.25 16:25:43 - OpenVPN > Opened utun device utun0
. 2018.06.25 16:25:43 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0
. 2018.06.25 16:25:43 - OpenVPN > /sbin/ifconfig utun0 delete
. 2018.06.25 16:25:43 - OpenVPN > ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
. 2018.06.25 16:25:43 - OpenVPN > NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
. 2018.06.25 16:25:43 - OpenVPN > /sbin/ifconfig utun0 10.4.1.47 10.4.1.47 netmask 255.255.0.0 mtu 1500 up
. 2018.06.25 16:25:43 - OpenVPN > /sbin/route add -net 10.4.0.0 10.4.1.47 255.255.0.0
. 2018.06.25 16:25:43 - OpenVPN > add net 10.4.0.0: gateway 10.4.1.47
. 2018.06.25 16:25:43 - OpenVPN > /sbin/route add -net 71.19.252.31 192.168.1.254 255.255.255.255
. 2018.06.25 16:25:43 - OpenVPN > add net 71.19.252.31: gateway 192.168.1.254
. 2018.06.25 16:25:43 - OpenVPN > /sbin/route add -net 0.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:25:43 - OpenVPN > add net 0.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:25:43 - OpenVPN > /sbin/route add -net 128.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:25:43 - OpenVPN > add net 128.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:25:43 - DNS of a network adapter forced (SAMSUNG Modem, from Automatic to 10.4.0.1)
. 2018.06.25 16:25:44 - DNS of a network adapter forced (Ethernet, from Automatic to 10.4.0.1)
. 2018.06.25 16:25:44 - Routes, added a new route, 71.19.252.32 for gateway 10.4.0.1
. 2018.06.25 16:25:44 - Flushing DNS
. 2018.06.25 16:25:44 - macOS - PF rules updated, reloading
I 2018.06.25 16:25:45 - Checking route IPv4
I 2018.06.25 16:25:45 - Checking DNS
! 2018.06.25 16:25:46 - Connected.
. 2018.06.25 16:25:46 - OpenVPN > Initialization Sequence Completed
. 2018.06.25 16:27:55 - Updating systems & servers data ...
. 2018.06.25 16:27:57 - Systems & servers data update completed
. 2018.06.25 16:33:32 - macOS - PF rules updated, reloading
! 2018.06.25 16:33:33 - Disconnecting
. 2018.06.25 16:33:33 - Routes, removed a route previously added, 71.19.252.32 for gateway 10.4.0.1
. 2018.06.25 16:33:33 - Sending management termination signal
. 2018.06.25 16:33:33 - Management - Send 'signal SIGTERM'
. 2018.06.25 16:33:33 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2018.06.25 16:33:33 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2018.06.25 16:33:38 - OpenVPN > /sbin/route delete -net 71.19.252.31 192.168.1.254 255.255.255.255
. 2018.06.25 16:33:38 - OpenVPN > delete net 71.19.252.31: gateway 192.168.1.254
. 2018.06.25 16:33:38 - OpenVPN > /sbin/route delete -net 0.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:33:38 - OpenVPN > delete net 0.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:33:38 - OpenVPN > /sbin/route delete -net 128.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:33:38 - OpenVPN > delete net 128.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:33:38 - OpenVPN > Closing TUN/TAP interface
. 2018.06.25 16:33:38 - Connection terminated.
. 2018.06.25 16:33:38 - IPv6 restored on network adapter (SAMSUNG Modem)
. 2018.06.25 16:33:38 - IPv6 restored on network adapter (Ethernet)
. 2018.06.25 16:33:38 - IPv6 restored on network adapter (FireWire)
. 2018.06.25 16:33:38 - IPv6 restored on network adapter (Wi-Fi)
. 2018.06.25 16:33:38 - DNS of a network adapter restored to original settings (SAMSUNG Modem, to Automatic)
. 2018.06.25 16:33:38 - DNS of a network adapter restored to original settings (Ethernet, to Automatic)
. 2018.06.25 16:33:38 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
I 2018.06.25 16:33:38 - Checking authorization ...
! 2018.06.25 16:33:39 - Connecting to Rana (Canada, Toronto, Ontario)
. 2018.06.25 16:33:40 - OpenVPN > OpenVPN 2.4.6 x86_64-apple-darwin17.5.0 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Apr 27 2018
. 2018.06.25 16:33:40 - OpenVPN > library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
. 2018.06.25 16:33:40 - Connection to OpenVPN Management Interface
. 2018.06.25 16:33:40 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3101
. 2018.06.25 16:33:40 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:33:40 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:33:40 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET6]2604:6880:c713:5e84:45b1:390b:9c7e:9838:443
. 2018.06.25 16:33:40 - OpenVPN > Socket Buffers: R=[196724->262144] S=[9216->262144]
. 2018.06.25 16:33:40 - OpenVPN > UDPv6 link local: (not bound)
. 2018.06.25 16:33:40 - OpenVPN > UDPv6 link remote: [AF_INET6]2604:6880:c713:5e84:45b1:390b:9c7e:9838:443
. 2018.06.25 16:33:40 - OpenVPN > write UDPv6: No route to host (code=65)
. 2018.06.25 16:33:40 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3101
. 2018.06.25 16:33:41 - OpenVPN > write UDPv6: No route to host (code=65)
. 2018.06.25 16:34:11 - Above log line repeated 3 times more
. 2018.06.25 16:34:11 - OpenVPN > [uNDEF] Inactivity timeout (--ping-exit), exiting
. 2018.06.25 16:34:11 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2018.06.25 16:34:16 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
! 2018.06.25 16:34:16 - Disconnecting
. 2018.06.25 16:34:16 - Connection terminated.
I 2018.06.25 16:34:19 - Checking authorization ...
. 2018.06.25 16:34:20 - IPv6 disabled on network adapter (SAMSUNG Modem)
. 2018.06.25 16:34:20 - IPv6 disabled on network adapter (Ethernet)
. 2018.06.25 16:34:20 - IPv6 disabled on network adapter (FireWire)
. 2018.06.25 16:34:20 - IPv6 disabled on network adapter (Wi-Fi)
! 2018.06.25 16:34:20 - Connecting to Kleeia (Canada, Vancouver)
. 2018.06.25 16:34:21 - OpenVPN > OpenVPN 2.4.6 x86_64-apple-darwin17.5.0 [sSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Apr 27 2018
. 2018.06.25 16:34:21 - OpenVPN > library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
. 2018.06.25 16:34:21 - Connection to OpenVPN Management Interface
. 2018.06.25 16:34:21 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3101
. 2018.06.25 16:34:21 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:34:21 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.25 16:34:21 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]71.19.252.31:443
. 2018.06.25 16:34:21 - OpenVPN > Socket Buffers: R=[196724->262144] S=[9216->262144]
. 2018.06.25 16:34:21 - OpenVPN > UDP link local: (not bound)
. 2018.06.25 16:34:21 - OpenVPN > UDP link remote: [AF_INET]71.19.252.31:443
. 2018.06.25 16:34:21 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3101
. 2018.06.25 16:34:21 - OpenVPN > TLS: Initial packet from [AF_INET]71.19.252.31:443, sid=7e320946 71933355
. 2018.06.25 16:34:21 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2018.06.25 16:34:21 - OpenVPN > VERIFY KU OK
. 2018.06.25 16:34:21 - OpenVPN > Validating certificate extended key usage
. 2018.06.25 16:34:21 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2018.06.25 16:34:21 - OpenVPN > VERIFY EKU OK
. 2018.06.25 16:34:21 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Kleeia, emailAddress=info@airvpn.org
. 2018.06.25 16:34:21 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2018.06.25 16:34:21 - OpenVPN > [Kleeia] Peer Connection Initiated with [AF_INET]71.19.252.31:443
. 2018.06.25 16:34:22 - OpenVPN > SENT CONTROL [Kleeia]: 'PUSH_REQUEST' (status=1)
. 2018.06.25 16:34:22 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.1.47 255.255.0.0,peer-id 53,cipher AES-256-GCM'
. 2018.06.25 16:34:22 - OpenVPN > Pushed option removed by filter: 'redirect-gateway def1 bypass-dhcp'
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: compression parms modified
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: peer-id set
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625
. 2018.06.25 16:34:22 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified
. 2018.06.25 16:34:22 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM'
. 2018.06.25 16:34:22 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2018.06.25 16:34:22 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2018.06.25 16:34:22 - OpenVPN > ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=en0 HWADDR=00:23:df:8c:a0:ae
. 2018.06.25 16:34:22 - OpenVPN > Opened utun device utun0
. 2018.06.25 16:34:22 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0
. 2018.06.25 16:34:22 - OpenVPN > /sbin/ifconfig utun0 delete
. 2018.06.25 16:34:22 - OpenVPN > ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
. 2018.06.25 16:34:22 - OpenVPN > NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
. 2018.06.25 16:34:22 - OpenVPN > /sbin/ifconfig utun0 10.4.1.47 10.4.1.47 netmask 255.255.0.0 mtu 1500 up
. 2018.06.25 16:34:22 - OpenVPN > /sbin/route add -net 10.4.0.0 10.4.1.47 255.255.0.0
. 2018.06.25 16:34:22 - OpenVPN > add net 10.4.0.0: gateway 10.4.1.47
. 2018.06.25 16:34:22 - OpenVPN > /sbin/route add -net 71.19.252.31 192.168.1.254 255.255.255.255
. 2018.06.25 16:34:22 - OpenVPN > add net 71.19.252.31: gateway 192.168.1.254
. 2018.06.25 16:34:22 - OpenVPN > /sbin/route add -net 0.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:34:22 - OpenVPN > add net 0.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:34:22 - OpenVPN > /sbin/route add -net 128.0.0.0 10.4.0.1 128.0.0.0
. 2018.06.25 16:34:22 - OpenVPN > add net 128.0.0.0: gateway 10.4.0.1
. 2018.06.25 16:34:22 - DNS of a network adapter forced (SAMSUNG Modem, from Automatic to 10.4.0.1)
. 2018.06.25 16:34:22 - DNS of a network adapter forced (Ethernet, from Automatic to 10.4.0.1)
. 2018.06.25 16:34:23 - Routes, added a new route, 71.19.252.32 for gateway 10.4.0.1
. 2018.06.25 16:34:23 - Flushing DNS
. 2018.06.25 16:34:23 - macOS - PF rules updated, reloading
I 2018.06.25 16:34:23 - Checking route IPv4
I 2018.06.25 16:34:24 - Checking DNS
! 2018.06.25 16:34:25 - Connected.
. 2018.06.25 16:34:25 - OpenVPN > Initialization Sequence Completed
. 2018.06.25 16:38:03 - Updating systems & servers data ...
. 2018.06.25 16:38:05 - Systems & servers data update completed

[JSD 6]

@ go558a83nk

 

Seems you are right and I missed it.

 

@ Staff:

 

This said, it would be welcome if there was an official and easy to find documentation telling people that they can use tls-crypt on IPs 3 and 4. Most people who are new will not find it here in the forum with ease.

 

[Guest]

Yup. My bad. 

 

Just had to read it again. I was just expecting it to appear in protocols. I went through options several times in the quest to find it lols

[Staff 9972]

 

This said, it would be welcome if there was an official and easy to find documentation telling people that they can use tls-crypt on IPs 3 and 4. Most people who are new will not find it here in the forum with ease.

 

 

When the whole infrastructure supports it, sure. In the meantime, is there anything unclear in the first post of this thread, in the Eddie protocols menu and in the Configuration Generator? They seem to tell what you want.

 

Kind regards

[JSD 6]

@ Staff:

 

...is there anything unclear in the first post of this thread...

No, it was my fault, admittedly.
 

When the whole infrastructure supports it, sure.

This is fine.

 

By the way, may I say that there are some options in the settings that are not yet explained (even not in the thread about advanced features)? In some other cases, features are explained, but most people will probably not know the implications or advantages and disadvantages of these settings, and what is recommanded and what not. Maybe the explanation section can be updated some time.