go558a83nk

This is completely normal due to the way networks work. The server that's hosting the web server and VPN client can only reach the web server at localhost.

Thanks for following up. Unfortunately, you only have 1 other server in Montreal with highly limited capacity, appears you tap out at 1 gigabit. Thus your redundancy in Montreal is insufficient currently. Toronto servers are only 22ms from Montreal. I'd give my left arm for that latency. I'm stuck with 60ms being the best option.

You did what you could. But if you used the "SSL" option, which uses stunnel and openvpn, and that didn't work, then I guess Yemen was throttling all https connections with destination outside Yemen?

https://airvpn.org/contact/

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?

Yes. I also set the MTU to 1320, because that's what the AirVPN conf file said. if that isn't working or the 1280 as Staff suggests you can also try setting MTU and MSS directly on the wireguard interface instead of the LAN interface. I'd suggest 1280 for both MTU and MSS on the wireguard interface and test the sites that aren't working for you. Then try higher values and see if there's a value at which sites stop working again.

Did you complete the guide's instructions on setting MSS on the LAN interface?

the config generator doesn't create keys. it creates configs using the keys you've made in the key gen section. https://airvpn.org/devices/

It very well might be. Years ago pfsense came out with native wireguard but there were problems so they quickly removed it with a patch. Then somebody who knows what they're doing made a wireguard package which people have been using since then.

Wireguard would likely be faster. I can't say much more about updating because I use pfsense+ and I'm using a wireguard add-on package. You seem to imply that by updating wireguard is native? I followed a video guide on wireguard setup years ago. I'm not up to making one myself but you might find it by searching the web and the pfsense subreddit which is often helpful.

and if somebody did change from tls-auth to tls-crypt you'll need to change a few things in the openvpn config besides updating the certs. sha512, tls encryption and authentication, different remote IP off the top of my head.

Are you able to change the protocol to TCP and try? You should be able to just flip the option in dd-wrt and nothing else needs to change.

sha1 being used which is for old tls-auth configs but only staff can quickly say if the entry IP is 1 or 2 and not 3 or 4. that is to say, I'm guessing you and several others are getting tls-auth and tls-crypt things mixed up. edit: Ok I see your post below mine that shows you used a tls-auth config.