go558a83nk

I noticed just now as I used the config generator that wireguard now uses entry IP 3.  Will we need to change all configs or will entry IP 1 still work?  Also, why the change?

Thanks.

3 hours ago, OpenSourcerer said:

Now that I'm seeing this thread again… I was able to reach around 120 MB/s download using Wireguard, but I'm faced with a very different challenge now: Finding content with a size big enough to reach those average speed readings for the status page, and stable enough to get this throughput over a longer period of time.
BitTorrent is the best option so far, and I was experimenting with tens of Linux torrents for that matter, but they're done so quickly, it's impossible show up with those MB/s. I managed to appear with around 750 by a download-delete-check-redownload routine, but that's not giving me continuous readings. -.-
What a problem to have…

16 minutes ago, Air4141841 said:

this is great for us Airvpn users.

since mullvad doesn’t even use tls auth, let alone crypt 
it’s no wonder they have so many issues it’s connectivity 
 

I've found that tls-crypt TCP 443 allows me to connect when tls-auth openvpn requires me to use stunnel.

Are you sure that this UDP in TCP is required for your location?

The main reason to have your VPN client on your router is so that your whole house can go through the VPN if you wish - devices that can't run a VPN client themselves can be routed through the VPN tunnel.

But for your situation it sounds like just running Eddie when you need to torrent is the best option.  The main reasons being the simplicity of the setup and the speed.  Routers are known for being slow for openvpn unless they have specific chipsets that can accelerate AES.

Wireguard is fast(er) on routers, yes, but still since you don't use VPN much and only for your windows PC it's not worth getting VPN client running on router IMO.

Is PolarBear Tunnel the name of an adapter Eddie makes or is that from some other VPN software?  I'm thinking the latter.

24 minutes ago, moejoe said:

mullvad is linked to pango. Inc ?
Any evidence for this


 

 I think this can also be caused by MTU problems?

1 hour ago, OpenSourcerer said:

Because that necessitates running a VPN connection, which necessitates monitoring it and reacting to incidents, even if not at home. Which might necessitate investing time at the most untimely of times – right when I need them but can't use them.

You seem to be implying that the peering for 1 of the 4 servers in the same datacenter is different from the other 3 servers. Was that your intention?

Being blacklisted from services is par for the course for VPN IPs.

Yeah, in the last few months (since other VPN providers stopped providing port forwarding) the usage of the Dallas servers has gone from negligible to huge.  They certainly could use some attention.

P.S. if you look at Dallas server usage don't trust the "bar" of bandwidth used.  Go into the server page and look at the daily usage charts.  For some reason the Dallas servers often report incorrect instantaneous usage.

Seems like there's a bug then because I was using pfsense+ some time ago and it was working normally.  DCO would connect to Marsic and non-DCO would connect to other servers.

10 minutes ago, Staff said:

Hello!
Correct. The old <servername>.airvpn.org for the entry-IP address 1 has been maintained for backward compatibility for some years only on old servers for a smoother transition. New server domain names (for all servers) follow the current documentation for example https://airvpn.org/faq/servers_ip/

Kind regards
 

superba3.airservers.org

superba3.vpn.airdns.org

6 minutes ago, dIecbasC said:

Thanks for the insight, I haven't seen this before. I noticed it because the config generator didn't provide a non-resolved config file when requested too. 
 

2 minutes ago, dIecbasC said:

Is DNS taking time to propagate or is this a change to config generation etc? 
 

% ping -c 1 superba.airvpn.org
ping: cannot resolve superba.airvpn.org: Unknown host

% ping -c 1 sneden.airvpn.org
PING sneden.airvpn.org (68.235.52.35): 56 data bytes
64 bytes from 68.235.52.35: icmp_seq=0 ttl=50 time=65.048 ms

1 hour ago, veryhadu said:

Data Ciphers : AES-256-GCM
Fallback Data Encryption Algorithm : AES-256-CBC
Auth digest algorithm : SHA512

I've had issues for years with various VPN providers with some public trackers blocking various VPN servers.  However, I could sometimes find a VPN server that wasn't blocked by the public trackers.

But I've never had problems with private trackers blocking VPN servers.

So, not sure what to say but to try different server locations since if the tracker is blocking the VPN servers they've likely blocked the whole IP range.

11 hours ago, veryhadu said:

To give you the most accurate answer:

- Cryptographic Hardware = AES-NI CPU based acceleration
- Hardware Checksum Offloading = enabled
- Hardware TCP Segmentation Offloading = disabled
- Hardware Large Receive Offloading = disabled
- hn ALTQ support = disabled

Configuration at MTU/MSS 1420 is very stable

22 hours ago, veryhadu said:

Thank you go558a83nk and benfitita

After setting the MTU and MSS I get values of 250 Mb/s in download and 300 Mb/s in upload.

MTU: 1420
MSS: 1420

Good for you

15 hours ago, veryhadu said:

Hello everyone,

I configured on pfsense 23.05.01 a wireguard tunnel quite easily. The file provided by our excellent provider AIRVPN allows me to connect without error. My Xeon E3 provides bandwidth of +/- 500Mbits/s "with openvpn" on the same remote server as the wireguard without any worries.

It's from now or I don't know where to go to get the same bandwidth or at least half with the wireguard protocol which is reputed to be at least as fast as OpenVPN.

I only manage to obtain quite unstable 20Mbits/s in download and the upload seems slightly more stable but not more than 22Mbits/s. Which should be enough to access youtube and twitch video resources fairly quickly, but this is done with untimely freezes that prevent continuous playback. Also browser search requests are very slow and sometimes not successful. Positive point: the response time (ping) is constant and stable, the online game is 100% ok...

What about you? under pfsense with wireguard as an AIRVPN client.

Knowing that a test under Windows with the official wireguard client I obtain with my ryzen an occupation of 85-90% of my total bandwidth. Everything else is 100% ok.

What I'm wondering about is the stability of pfsense with or without a Xeon E3 getting a decent connection through Wireguard as a client ?

Thank you for all your work team, the best supplier is here.

On 4/30/2023 at 2:26 AM, Staff said:

Hello!

It's a problem affecting intermittently three Dallas servers, apparently, which fail to compute the correct bandwidth due to network interface traffic counters premature reset. So you see the correct amount of connections, but a much lower bandwidth. Chamaeleon, Pegasus and Mensa are currently suffering this issue. A new investigation will be opened.

Kind regards
 

too many USA servers but the servers are busy?  sounds like there aren't enough USA servers then. ;)

On 7/4/2023 at 1:59 PM, Flx said:

On 7/3/2023 at 12:29 PM, go558a83nk said:

it wasn't clear but my comment was in reference to AES-128-GCM being fast with DCO

No matter what cipher you pick the CPU load stays the same?

1 hour ago, Wolf666 said:

pfSense Plus software supports ChaCha20-Poly1305 with OpenVPN DCO, but currently only IPsec-MB can accelerate that algorithm. At this time, neither AES-NI nor QAT can accelerate ChaCha20-Poly1305. Some newer QAT hardware may be capable of accelerating ChaCha20-Poly1305, but the current QAT drivers do not yet include support for that encryption algorithm.

In pfSense+ I found using ChaCha20-Poly1305 and enabling IPsec-MB be faster than wireguard.