go558a83nk

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.

They're also living under the assumption that government is benevolent and righteous. Have they forgotten that the government of the very thing they detest (nazism) made illegal many things...was it ok because the government made them illegal?

If you need to change the certs you can add them the same way you added the the others you've been using and then update the openvpn config such that it uses the new certs instead of the old ones (simple drop down selection). If you, like alanm, are trying to use entry IP 3 or 4 then you'll need to adjust for tls-crypt usage. However, I do wonder if your old version of pfsense has a new enough version of openvpn to even support tls-crypt.

Are the servers moving to a different datacenter?

1) management: client disconnected is not the VPN client disconnecting. it's pfsense's openvpn management client that's disconnecting from...managing it I guess. 2) otherwise the log shows very little. after the line UDPv4 link remote: [AF_INET]128.127.104.82:443 usually you'd see something about initial TLS packet. If you're not getting any response from the VPN server then perhaps something's blocking it, like a local firewall or your ISP.

pfsense warned me last month that some old certs were expiring so I'm not surprised that some people are seeing this results. It's unfortunate that software (eddie) or this web site didn't warn people they were using certs about to expire.

LOL thanks. I forgot I could use the config generator to narrow down the list. 😳

Hello, is Marsic the only server that supports DCO or have more been added to this test? Thanks.

Happens to me on any proxy/VPN, not just AirVPN.

You can likely insert postup and predown iptables rules (I assume that's what they are) into the AirVPN configs or do other things as listed in the following link

yes, no need to change anything else.

9 212.222.6.229 72.747 ms 53.818 ms 52.890 ms 10 213.200.116.225 75.413 ms 67.799 ms 65.760 ms 11 87.119.97.186 62.010 ms 61.559 ms 61.516 ms 12 81.95.2.138 66.963 ms 66.516 ms 66.997 ms 13 * * * 14 128.241.10.42 157.959 ms 135.565 ms 135.466 ms 15 129.250.2.252 132.307 ms 134.168 ms 134.819 ms 16 129.250.2.155 136.883 ms 136.940 ms 136.883 ms 17 128.241.9.243 141.064 ms 138.435 ms 137.656 ms 18 37.123.210.65 146.810 ms 141.526 ms 138.384 ms Route trace to the new servers from my ISP. Seems like a problem going from GTT to NTT network which is like hop 12-14. Hop 12 is already in Amsterdam.

my quick look tells me you're perhaps not creating a firewall rule on the correct interface. You've got a port forward rule for airvpn_wan_WG_0 but you're not showing a corresponding firewall rule for that interface for port forwarding. when you create the port foreward rule use the filter rule association option at the bottom of the port forward rule setup to create new associated filter rule. this will automatically put the necessary firewall rule on the correct interface. also you're using an alias for NAT IP for the port forward rule. this should be the IP of the device running the server. I see no reason for an alias as it should be just one local IP, e.g. 192.168.2.22. again, no reason for an alias for destination ports and NAT ports as AirVPN port forward rules can only forward 1 port each.

this is my experience but @Staff seems to be saying this isn't the way it works. 27183 mapped to 32400 on Air's servers, pfsense is instructed to forward port 32400 on the VPN interface to my laptop:32400 where plex is listening. I have to instruct plex that the actual public port is not 32400 but 27183. Note that by manually specifying public port plex does not change the private port it listens on - it's always 32400. I could make the port forwarding rule on the Air web site 27183-27183 and then change my port forwarding rule in pfsense to VPN interface:27183-laptop:32400 and that would work also. So, you can see why I say what I say. I'd have to look more into behaviors when the VPN client is on the same device as the plex server but one thing holds true, I know : plex always listens at localhost:32400. https://support.plex.tv/articles/200931138-troubleshooting-remote-access/ So I really see it as impossible that a port forwarding rule 2***7 forwarded to 2***7 works unless somewhere else in the chain 2***7 forwarded to 32400.