go558a83nk

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.

well, back when wireguard first came out as a package for pfsense I happened upon a youtube video from, I think, the guy who made the wireguard package while browsing the pfsense subreddit. but now when I search it's difficult to find that particular video. Sorry I can't be more help.

Set it to exclusive, of course. But also check that your browser isn't using some built in "secure dns" which would be encrypted and thus bypass AirVPN's DNS.

you need to use your devices page to make another device. download a new config for that new device. then when setting up the interface you'll need to change the net mask to /32 so that the two devices don't overlap IP range. https://airvpn.org/devices/

I've always had good luck using "mssfix 0" actually. And Also setting tun-mtu to something crazy high so the virtual adapter isn't a bottleneck.

setting the buffers to "0" just means the default for the OS, doesn't it? I'm thinking it needs to be bigger, not the default. Also, you might try messing with MTU/MSS stuff.

and I wouldn't have even known that since I don't think I've ever seen that in pfsense

you need to use iptables to create the proper rules on the asus router. see the following post.

I'm pretty sure I followed a guide back when I first started using wireguard on pfsense...a guide made by the guy that made the wireguard add-on package. Anyway, I have gateway address set to the same as interface address. When creating the interface I have to put in the internal IP that's given to me in the config and the same one goes in the gateway.

If I recall correctly the interface must be setup manually *and* then the gateway. So, no, it doesn't appear automatically.

there may not be very many people here that run opnsense. I wish I could help but I'm still using pfsense.

It seems that setting the mss and mtu for wireguard to the same value is the trick for many people

I am concerned that with this matter the network lock isn't really working and that's why the OP gets leaks. (or maybe the OP wasn't using network lock traditionally?) You see, if network lock rules are created based on the wrong interface/network adapter (i.e. traffic can go through only the wrong adapter and no other) then it seems network lock and its rules will do no good anyway.

Only reason I can think of is for DNS resolution when not connected to the VPN or if you decide to have devices not routed through the VPN.