go558a83nk

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?

I'm sure your lawyers understand this much better than I do but I'm not really understanding why this applies to you anyway considering you don't have servers in Italy and such blocks should be made at the ISP level. Any blocking you would do to adhere to these edicts would be done on servers *outside* Italy. Am I misunderstanding something?

I'm thinking the speed increase is coming from some other change in the OS that's coincident. That's unfortunate that you can no longer control the buffers for the openvpn connection.

That makes openvpn not add routes to the system table automatically which requires you to do policy routing via firewall rules. That's great, the way I do it on pfsense. But just make sure you're actually using the VPN and the speed increase isn't because you're not actually using the VPN

Glad it seems to be working for you. Yes, the default gateway should be WAN.

https://nguvu.org/pfsense/pfsense-multi-vpn-wan/

yes, you can have multiple clients and use the firewall rules choose which one gets used or create a gateway group with the 3.

start with entry IP 3 or 4 using openvpn UDP. if that doesn't work try TCP. If that doesn't work try using SSL or SSH.

ok thank you for the explanation.