go558a83nk

It doesn't have to be an intel chip. AMD chips have AES-NI too. AES-NI is what's important. For a pfsense box you don't need a huge CPU with 8+ cores. Mine is AMD, has 2 cores, and can do at least 430mbit/s openvpn with AES-256-GCM data channel. I don't know how much faster as that's my ISP max.

I was connected to another AirVPN server the other day and rarbg was telling me my IP was banned. It wouldn't let me post comments to torrents, or vote on comments, or look past page 2 of the list of torrents. But, I had no problems downloading torrent files. I went to another AirVPN server and had no problems. Obviously there are users of AirVPN who are morons and cause problems for the rest of us.

Yes, the AC68 will limit you to about 50mbit/s max. The CPU in routers can't encrypt/decrypt super fast.

10.4.0.1 will remain a DNS server accessible to all subnets.

Things are changing and you think people won't need to go through a transition period? If this was a reply to me, then I think you didn't understand what I wrote. I said the subnet changed after simply reconnecting - same port/protocol/server. Staff said above "not random, they are unique (and always the same)" speaking of each openvpn daemon's subnet. So, the question then is do I get a different openvpn daemon even though I connect to the same server/port/protocol combination? It doesn't matter to me. I reported it in case it was an important problem for Staff to fix considering what they'd already said.

AirVPN won't do that as they ARE in the business of security and privacy but they do have a list of ciphers that can be used. One may be easier on your CPU than aes-256-gcm but usually gcm is the fastest. https://airvpn.org/specs/

Looks like maybe they've fixed it. Of note, I reconnected to the same server, same port, same everything. Just a reset of the connection. But, I got a different subnet. My understanding was those subnets would stay the same. Previously was 10.32.82.1, now 10.32.70.1. tracert 10.4.0.1 Tracing route to 10.4.0.1 over a maximum of 30 hops 1 28 ms 26 ms 28 ms 10.32.70.1 2 27 ms 29 ms 27 ms 199.249.230.254 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 ^C

Hello! 10.4.0.1 remains good for your purpose. It is ping-able from any subnet. It is also a DNS server IP address which is reachable from any subnet. Kind regards As has been established in the other thread, 10.4.0.1 is not pingable...at least on many servers. Three of us have responded in that thread with no reply from you. I can use it for DNS resolution nslookup airvpn.org 10.4.0.1 Server: UnKnown Address: 10.4.0.1 Non-authoritative answer: Name: airvpn.org Addresses: 2001:1af8:4010:a08d:22:: 5.196.64.52 But I can't ping it ping 10.4.0.1 Pinging 10.4.0.1 with 32 bytes of data: Reply from 38.122.207.9: Destination net unreachable. Request timed out. Request timed out. Ping statistics for 10.4.0.1: Packets: Sent = 3, Received = 1, Lost = 2 (66% loss), The trace is interesting tracert 10.4.0.1 Tracing route to 10.4.0.1 over a maximum of 30 hops 1 181 ms 209 ms 126 ms 10.32.82.1 2 99 ms 119 ms 121 ms 199.249.230.254 3 * * 38.122.207.9 reports: Destination net unreachable. The trace to 10.4.0.1 is going outside your server network it seems as it encounters 38.122.207.9...which is encountered when I do trace to outside your Dallas DC. tracert 8.8.8.8 Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops: 1 226 ms 182 ms 135 ms 10.32.82.1 2 122 ms 39 ms 34 ms 199.249.230.254 3 98 ms 50 ms 34 ms 38.122.207.9 4 181 ms 90 ms 59 ms be2664.ccr31.dfw01.atlas.cogentco.com [154.54.41.201] 5 28 ms 34 ms 42 ms be2763.ccr41.dfw03.atlas.cogentco.com [154.54.28.74] 6 29 ms 33 ms 34 ms tata.dfw03.atlas.cogentco.com [154.54.12.106] 7 68 ms 47 ms 37 ms 209.85.172.106 8 92 ms 142 ms 155 ms 108.170.240.129 9 214 ms 123 ms 89 ms 64.233.175.103 10 93 ms 84 ms 94 ms google-public-dns-a.google.com [8.8.8.8]

Looks like your network or your ISP is preventing UDP connections. Try TCP.

10.4.0.1 must be ping-able from any subnet, if you experience this issue there's something wrong either in the server or in your connection. For a preliminary check can you please tell us the server(s) you experience this problem on? Kind regards On Volans and Equuleus my LAN clients can use 10.4.0.1 as DNS server but can't ping it. edit: I connect via IPv4. my pfsense setup isn't IPv6.

I use pfsense. My setup is to pass the DNS server I want to use (10.4.0.1) to clients through DHCP and force clients to use only that DNS via firewall rules. 10.4.0.1 can be used by my clients with no additional routing setup.

10.4.0.1 still works for me with Gen 2 servers.

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.

Read the first post of this thread again.

Hi, I'm a bit lost on this. As soon as I switch to Encryption and Authentication pfSense refused to connect. I guess I have to use different Keys ? Where do I find the tls-crypt.key ? Ive just downloaded a new config file and all I get is (inline) : ca cert key tls-auth Jun 24 11:26:57 openvpn 39318 UDPv4 link remote: [AF_INET]185.189.112.18:80 Jun 24 11:26:57 openvpn 39318 UDPv4 link local (bound): [AF_INET]89.245.13.38:0 Jun 24 11:26:57 openvpn 39318 TCP/UDP: Preserving recently used remote address: [AF_INET]185.189.112.18:80 Jun 24 11:26:57 openvpn 39318 Initializing OpenSSL support for engine 'rdrand' Jun 24 11:26:57 openvpn 39318 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jun 24 11:26:57 openvpn 39318 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. Jun 24 11:26:57 openvpn 39318 mlockall call succeeded Jun 24 11:26:57 openvpn 39200 library versions: OpenSSL 1.0.2m-freebsd 2 Nov 2017, LZO 2.10 Jun 24 11:26:57 openvpn 39200 OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Mar 16 2018 Jun 24 11:26:57 openvpn 39200 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6 That's if, after a timeout it re-tries it. Any help is much appreciated You need to download tls-crypt configs from the config generator.

tls-crypt itself shouldn't give any speed degradation. The reason SSL has a speed degradation is because it necessitates TCP. Try using tls-crypt with on a UDP port to see how it works for you.

@Staff, I saw your tweet about Atik and the huge amount of traffic on it. For testing purposes were you directing all connections to the Netherlands region to that server to put a huge load on it?

Curious. Why a release for linux and OS X if the only change is for Windows?

As I understand it if the app crashes the network lock is still active because the network lock (via WFP) is only removed when the app is shut down properly. But, you'll have to remain vigilant.

you have to disregard what I said about pinging. I don't use the app so I didn't realize that the app by default allowed pings out even with network lock on. prove it to yourself by trying to browse in a web browser with VPN not connected but network lock on.

There's nothing about the servers that can change latency. Latency is a measure of the trip BETWEEN you and the servers and AirVPN doesn't control all that internet.

It's easy to test if the above result using WFP is a bug by just disallowing pings in the settings right?

https://airvpn.org/topic/28326-psa-windows-firewall-network-lock-is-broken-in-2145/ see that thread. make sure your network lock settings are WFP

https://airvpn.org/topic/28327-airvpn-dropping-connection-and-leaving-vulnerable/?do=findComment&comment=74816 another user, most likely using "automatic", reporting network lock not working??

well is the padlock open or closed?