go558a83nk

Did some testing from my pfsense+ box. So far it works very well. It's lovely to see all the openvpn work being done in kernel here and 600mbit/s from this great distance seems very respectable.

yes, I know that it doesn't support compression. neither of my VPN providers uses compression and the only way I got AirVPN to connect was to have it ignore the comp-lzo push as opensourcerer wrote first elsewhere in this forum

hmm interesting, only thing i can think of is maybe tls-crypt being enabled on your airvpn one and not on the other or vice versa? compare and contrast the logs with some higher level logging and openvpn should tell you why nope, I tried with a tls-auth config for Air and it still didn't work. It may have to do with compression settings. I had to use some advanced directives regarding compression to get it to even connect to Air. I didn't have to do such for the other provider but neither use compression. So, I'm betting there's a sweet spot in compression settings that'll get it to work for Air. I just haven't played with it much.

imminent is probably like a year or more away. if you are concerned about speeds (struggling to get over 300 mbps without openvpn going insane on latency, then consider migrating to wireguard. I've done that recently and can push 800 mbps through a single gateway. I'm using wireguard with great speed now but will be in a nation where VPN access is known to be restricted soon so I was hoping for DCO. The weird thing is I'm able to connect to my other VPN provider using DCO on my (client) end and it works fine as documentation said it would (that there will be benefit if even just the client has DCO enabled). But when I do the same for AirVPN no traffic flows but logs say the connection initiated fine. I doubt that other VPN provider has an updated openvpn version so I'm guessing it's some other little quirk with the VPN tunnel options.

How wireguard is setup there I don't know for sure but on pfsense the gateway is the same as the interface address which is 10.144.77.131 for you in the screenshot.

I'd guess that server port is how to access it for control, like a web gui? It looks like you need to just open 47854 47855 (obfuscated port) but you should not open/forward any ports on your tplink router unless your router *is* your VPN client. edit: and disable nat-pmp

How imminent is this deployment? We're nearing 3 months since this post and I'm eager to test.

I was able to get DCO to connect with pfsense+ 23.05 (thanks to opensourcerer's notes about compression above) but no data actually transfers and after a bit I get a ping restart. The client area session info also indicates no traffic moving. Would something need to change on AirVPN's end? My understanding that even if only the client is running DCO some improvement in throughput could be had so I figured it would just work without Air changing anything on their end.

good point but I don't think this little box supports it. I'll find out.

I just realized that Pfsense+ software (which is still free for home users) has DCO capability while the pfsense CE software does not. So I'm migrating to it today in preparation for testing DCO. I believe I'll have need for openvpn (again) in the future and would love an openvpn that is faster on my pfsense box with one of those new N100 CPUs. Wireguard is blazing fast, BTW, and the power usage is tiny. So, can't wait for a DCO test to begin here!

well, I actually need more time. only 81 days left. I should have bought during the last sale.

did you mean to buy that much? ;)

correct, you're logged into your account on the web site so it knows what certs/keys to put in the config file (takes the place of username/password) based on what "device" you selected in the config generator.

I get no leak from that surfshark test site. It shows only the one DNS server that I have indeed configured.

It sounds like you have some policy routing going on, or maybe your web browser is using it's own "secure DNS".

I'm saying that the setting in the openvpn config will force your system to obey the pushed DNS server that it receives from the VPN server when connecting. And if you're using policy routing it'll do that for only the rules routed through that VPN client. The setting name is "accept DNS configuration"

In merlin you're able to set the DNS configuration in the openvpn client setup. I suggest "exclusive".

Russia has worked to prevent connections to other VPN providers so I'm not surprised they're now blocking access to AirVPN. Best to try entry IP 3 and 4 and maybe needs to be SSH or SSL. But no guarantee it'll work if they've been thorough.

I read the guide that you used and it's the same as what I did. Setting up the interface, gateway, all that is just how you do it. I can't think of why it's not working.

port forwarding works for me through a wireguard tunnel. when you're testing make sure you're hitting the correct IP address at the correct port and make sure your server is actually running and responding on the correct port.

You misunderstood what the FAQ was trying to say. It's saying that if you use an AirVPN app (like Eddie) you don't need to forward ports on your home gateway/router because everything takes place inside the encrypted VPN tunnel so the router can't manipulate it anyway. However, with the VPN client actually on your router/gateway, such as yours, you do need to forward ports on said router/gateway. In pfsense go to firewall>nat>port forward tab. Make a new rule with [your wireguard interface] being the interface, the destination being "[your wireguard interface]address", the destination port should be whatever the local port is in the port forward rule you created on this web site, the redirect target IP is the IP of your NAS, and the redirect target port is whatever port your NAS server is listening on. Finally, be sure to select "create new associated filter rule" at the filter rule association setting. Save it, and you should be good to go.

Go into the wireguard interface that you created and change MTU and MSS to 1420 or some other matching lower value but for me 1420 is fastest.

I'm seeing the same thing

That's showing the latency to the Atlanta server is only 4ms

|------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 10.128.0.1 - 0 | 5 | 5 | 8 | 8 | 9 | 8 | | 23.103.107.254 - 0 | 5 | 5 | 8 | 8 | 8 | 8 | | Request timed out. - 100 | 2 | 0 | 0 | 0 | 0 | 0 | | be2978.ccr41.dfw03.atlas.cogentco.com - 0 | 5 | 5 | 8 | 9 | 10 | 9 | | be2763.ccr31.dfw01.atlas.cogentco.com - 0 | 5 | 5 | 9 | 9 | 9 | 9 | | be2441.ccr41.iah01.atlas.cogentco.com - 0 | 5 | 5 | 14 | 14 | 14 | 14 | | be2687.ccr41.atl01.atlas.cogentco.com - 0 | 5 | 5 | 27 | 27 | 28 | 27 | | be2847.ccr41.atl04.atlas.cogentco.com - 0 | 5 | 5 | 28 | 28 | 29 | 28 | | ae0-49.cr1.atl1.us.unitasglobal.net - 0 | 5 | 5 | 26 | 26 | 26 | 26 | | 198.32.132.42 - 0 | 5 | 5 | 25 | 25 | 26 | 26 | | inap.cust.cr2.atl1.us.unitasglobal.net - 0 | 5 | 5 | 25 | 26 | 27 | 26 | | border2.ae1-bbnet1.acs.pnap.net - 0 | 5 | 5 | 25 | 35 | 74 | 25 | | usd-29.satedge2.acs.pnap.net - 0 | 5 | 5 | 25 | 25 | 27 | 25 | | core.atl.dedicated.com - 0 | 5 | 5 | 27 | 33 | 50 | 30 | | 64.42.179.58 - 0 | 5 | 5 | 25 | 25 | 26 | 26 | |________________________________________________|______|______|______|______|______|______| WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider) no indication that the server isn't in atlanta to me. it's just that your ISP making your traffic to the server's network go the long way around somewhere. show us the mtr so we can see it ourselves.