go558a83nk

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.

Maybe being signed in is the problem. I can assure you that remote port 39196 and local port 32400 is perfectly fine. Plex always listens at 32400 on localhost/LAN, but typically we cannot reserve 32400 with the AirVPN system. So we create the rule with 32400 internal, and tell plex what external port we've been assigned. Plex accommodates this with the "manually specify public port" option for these cases where default 32400 is not being used on the WAN.

I don't know what you're seeing regarding TCP and UDP for the port forward, but it's testing both TCP and UDP according to the images. Also, plex always listens at 32400 but an external port of 39196 mapped to 32400 internal is probably what the user has setup and that should work. That's why you must instruct plex that the external port opened is 39196 and not the default 32400.

no need to do anything on your router so remove what you did there for security. your image of plex remote access settings shows that remote access is working. if you click the "test open" button what happens?

what other VPN is headquartered in Italy?