Leaderboard

Hi, thanks for the report. I also experience both IPv6 addresses, randomly, only with Firefox under Windows. Note: a request to ipv4.ipleak.net (having only A record, not AAAA) is received server-side as IPv6, inexplicably. It seems related to some network 'optimization'. Currently, I disabled the keep-alive server-side, it seems related and the issue is resolved, but still under investigation. We also have an 2nd problem: DNS detection throws errors sometimes, but this is not related to the issue above.

This is normal for Google. Since geoIP is such a mess, they don't completely trust what geoIP databases report. Instead they use the data they get from browsers visiting from each IP and try to guess if some IP is now being used elsewhere. Since Russia is currently heavily censoring internet access, AirVPN likely has a lot of Russian users who happen to be using NL servers. Google detects a lot of users with Russian locale are using NL node IPs -> they start offering Russian site by default. Not sure if there are workarounds for this, other than logging in. But this is not a sign of compromise, so no need to be paranoid. If Russia really was listening, they wouldn't route traffic through Russia. ;)

Hello! You need to insert the directive "reneg-sec" in your OpenVPN client configuration (see below a paste from the OpenVPN manual). Detailed instructions vary according to the client or OpenVPN wrapper you're running. With our client Eddie you can insert the directive in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives". Enter "reneg-sec 1800" in the left box reserved to additional directives, click "Save" and start a connection with a VPN server. Kind regards --reneg-sec n Renegotiate data channel key after n seconds (default=3600). When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour. Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.