go558a83nk

From logs posted above Eddie attempts to connect to 217.138.195.21 but gets no response. This does seem to be a correct AirVPN IP address so DNS doesn't seem poisoned. Rather it does look like ISPs are preventing connection to that IP address. I do wonder if TCP, rather than UDP, would work.

AirVPN doesn't use username and password. They use a certificate and key.

actually that log is them trying UDP entry 3 and then TCP and SSH and SSL. none of them worked. so, yes, chances are some software is blocking the connection.

Eddie is getting no response from the servers. Do you live in a nation that blocks VPNs? I think you'll need to try TCP. Go into settings > protocols. Uncheck automatic. Choose openvpn TCP any port and entry IP 3 or 4. If that doesn't work, you'll have to try SSL or SSH.

I've yet to have an ISP that supports IPv6 besides mobile data.

Can we still expect a new server soon? The 25th came and went.

Wireguard in Eddie? Or wireguard the app? Wireguard in Eddie

make sure to try wireguard if you haven't already

it wasn't me but that's really nice of somebody!

The phoenix location is definitely spoofed. You can check the m247 site to see their list (or a map) of their actual locations. The Phoenix location as it is adds bandwidth but not route diversity since it's likely found by the same route as the LA location. Something better may be out there but maybe not. https://m247.com/eu/data-center-locations/

I don't blame you for wanting to use wireguard especially on a router but openvpn using tls-crypt does connect easily from Egypt.

have you confirmed it also announces the specified IP address to DHT peers or only tracker based peers?

Thank you, this answers the question that had been rolling around in my head. I do think it would be good to allow users to pick the exit IP for each connection VPN connection.

I currently have need to be able to connect to the same server and get the same exit IP address for both connections. I'm not using port forwarding. With this new system is it possible that one of the two connections will get a different exit IP?

So is it working? The other thing that often breaks port forwarding on pfsense is if there are any rules in the openvpn or wireguard "group" firewall rules since those group rules override individual interface rules.

I'm confused because you said "it is down a lot of time". But not enough for you to break the contract legally?

You only need the first port forward rule, for your AirVPN interface, assuming that's the interface/gateway that the transmission device is allowed to use in policy routing. So, delete the one you made for your WAN. The only mistake I see is setting filter rule association to pass. You need to set that to "create new associated filter rule" and save. That'll create the necessary firewall rule. Of course, make sure transmission is listening at 192.168.3.102:19151 when you test to see if the port is open.

I'm curious why you signed a contract that didn't give you the option of abandoning the contract if they didn't keep certain quality and uptime requirements?

It used to be that you could use the same "device" for openvpn for multiple connections to the same server so long as you connect to different ports. I'm not sure if that's the same for wireguard... Because, as I'm sure you've realized, with wireguard, you have that pesky tunnel address that isn't auto created when you connect like with openvpn. So, yes, you have to make a new "device" for each wireguard tunnel you want to have on your pfsense box. But, the good news is that if you want to switch to a different AirVPN server, whether it's openvpn or wireguard, all you have to do is change the IP address of the endpoint/server. (with wireguard you need to disable the peer first, in my experience)

Neither AirVPN's port open test nor yougetsignal's port open test will show "green" unless your whole chain is working and your server (qbit) is listening and responds to the query. This is important. Your server must be up and responding. So if things seem correct on pfsense then then problem is somewhere else, that's my thought.

yeah, for me the group rules section is empty. but the individual interface gets auto created by using the associated filter rule option in the port forward. your problem may be due to a firewall on the unraid box and/or the qbit container?

so they're saying they had an any/any rule in their firewall/rules/openvpn or /firewall/rules/wireguard group which overrode the automatically created rule (when you create the port forward) in firewall/rules/individual_interface

Last I read the current suite of protocols in use by AirVPN (specifically, tls-crypt or SSL tunnel if needed) allowed AirVPN to work even in the most restricted countries. Have I misunderstood?

Everything looks correct. The two things I wonder are: 1) are the external and internal ports matching for the port forward you created with AirVPN? By default they do match but just making sure. 2) Have you reconnected the VPN connection since making the port forward rule? Often that's required.

Looked at this some more using https://bgp.he.net/traceroute/ Traceroute from 50.7.176.70 to 134.19.179.210 Using GLOBALPING, Probe 56112cb6-e168-5c3c-81c2-968fd9bdec55 STARTED QUERY AT 2024/08/14 10:36:06 UTC traceroute to 134.19.179.210 (134.19.179.210), 20 hops max, 60 byte packets 1 10.10.10.1 (10.10.10.1) 1.675 ms 1.620 ms 2 be4671.rcr21.b047839-0.ams03.atlas.cogentco.com (149.14.141.25) 1.020 ms 1.032 ms 3 be2796.ccr42.ams03.atlas.cogentco.com (154.54.58.125) 1.598 ms 1.738 ms 4 be2154.rcr22.ams06.atlas.cogentco.com (130.117.50.206) 2.302 ms 2.555 ms 5 204.68.252.53 (204.68.252.53) 2.210 ms 2.212 ms 6 connected-by.global-layer.com (37.123.210.71) 8.296 ms 8.301 ms 7 connected-by.global-layer.com (134.19.179.210) 1.479 ms 1.493 ms Completed in 2.07s And from my ISP: lft -pINA dalim.airservers.org Tracing ...............*...T TTL LFT trace to connected-by.global-layer.com (134.19.179.210)/icmp 11 [174] [COGENT-154-54-16] be2780.ccr42.par01.atlas.cogentco.com (154.54.72.225) 52.1ms 12 [174] [COGENT-154-54-16] be12266.ccr42.ams03.atlas.cogentco.com (154.54.56.173) 60.5ms 13 [174] [COGENT-EUROPEAN-OPERATIONS-001] be2154.rcr22.ams06.atlas.cogentco.com (130.117.50.206) 61.3ms 14 [AS?] [NULL] 204.68.252.53 128.1ms 15 [49453] [GLOBALLAYER] connected-by.global-layer.com (37.123.210.71) 137.6ms 16 [49453] [GLOBALLAYER] [target] connected-by.global-layer.com (134.19.179.210) 131.9ms Note how both go through 130.117.50.206 and 204.68.252.53 as they make their way to the endpoint. Now, for me, 52ms to Paris and 60ms to AMS is normal - the abnormal latency starts after. But for the ping from globalping there's no big jump in latency between 130.117.50.206 and 204.68.252.53 like there is for me. Remember, the routes test of all the servers showed abnormal latency to my ISP only for AMS servers. So, there seems to be some relegation by Cogent to and from my ISP or my region, etc.