go558a83nk

https://airvpn.org/contact/

In general people will use servers closest to them. Most people understand they aren't trying to evade the NSA but only their ISP so use what gives the best performance. And I would imagine far more customers are from the USA than from Sweden.

Do you get this same result when you're connected to the VPN using the config that works? Things definitely seem wrong in the test above. Are you running a proxy on your local network? Seems you've got something proxying your traffic so it replies with a local IP in order to tunnel traffic through the proxy to the real final destination. But that won't work for VPNs trying to connect.

So the question I have is what DNS are you using when the VPN isn't "on"? With VPN off, go to ipleak.net and check.

Yes, that's what I'm wondering. So I'm concerned that your DNS lookups were/are poisoned and that's why you couldn't connect. Your system was resolving de3.vpn.airdns.org to 127.124.0.3 according to the log. That's totally wrong. You definitely need a VPN to avoid whatever DNS your system was/is using but also change to a trusted, secure DNS for when you aren't using VPN.

Glad it's fixed. But what was the endpoint in the old configs?

I was thinking the same thing the day this was posted but didn't reply because I figured Staff would handle it or confirm the IP address was somehow correct. If the system is having to resolve the domain of the server and is getting 127.124.0.3 as the answer would that imply that there's some DNS poisoning happening by whatever DNS is being used by the OP prior to connecting to VPN?

This server was down for a couple days, then back up for a few hours, and is now down again. I'm guessing this particular server is having hardware problems considering the other servers in that DC are fine?

This happens for me almost all the time and it's my ISP causing it. Try TCP tls-crypt and see if that has the same problem.

You're looking at port forward and WAN rules which would control connections initiated from outside your network. But aren't VoIP services reliant on first creating a connection to a server, therefore no port forwarding is required because the connection is initiated from your network? I believe that's the case, therefore you need to be looking at your LAN rules. Something prevented your VoIP devices from creating *outgoing* connections most likely. Or if VoIP was forced out the VPN interface perhaps the VoIP service blocks connections from VPN servers.

If you enabled firewalls on your devices hosting transmission you'd need to make sure those firewalls allow the port that transmission is listening at.

Looks good to me! It's great that that router allows you to create port forwards for interfaces other than only the WAN. Just for confirmation your AirVPN port forwards page can test to see if the ports are open while the torrent clients are actively listening.

there's a lot missing here. 1) what VPN protocol? 2) did you follow a guide? 3) did you really follow the guide? 4) if you didn't follow a guide, do you know what you're doing?

I'm guessing you're putting the wrong data in the wrong place. AirVPN and pfsense work just fine From your config: the data in the <ca> field goes into the field where you "import an existing certificate authority" in the authorities section. the data in the <cert> and in the <key> field go into the certificate data and private key data in the certificates section where again you "import an existing certificate" the <tls-crypt> (or auth) data goes into the openvpn config in the TLS key section

The one thing that confuses me about this well known list of IP ranges is that 64.0.0.0/2 includes in its range the 127.x.x.x. addresses - localhost. So I guess then that any request on the system to localhost would be sent out the VPN tunnel except that it reaches its destination before it's sent to the virtual adapter?