go558a83nk

Russia has worked to prevent connections to other VPN providers so I'm not surprised they're now blocking access to AirVPN.

Best to try entry IP 3 and 4 and maybe needs to be SSH or SSL.  But no guarantee it'll work if they've been thorough. 

20 hours ago, yelpal said:

do you mind sharing a guide (if you used one) of how you configured WireGuard on pfsense? It would be interesting to see how it differs to mine, and if you got it working, I’ll just do the same. 

Server is definitely responding to correct port. As to making sure I’m hitting the correct IP address, can you elaborate on how I could carry out this test?

port forwarding works for me through a wireguard tunnel.

when you're testing make sure you're hitting the correct IP address at the correct port and make sure your server is actually running and responding on the correct port.

You misunderstood what the FAQ was trying to say.  It's saying that if you use an AirVPN app (like Eddie) you don't need to forward ports on your home gateway/router because everything takes place inside the encrypted VPN tunnel so the router can't manipulate it anyway.

However, with the VPN client actually on your router/gateway, such as yours, you do need to forward ports on said router/gateway.

In pfsense go to firewall>nat>port forward tab.  Make a new rule with [your wireguard interface] being the interface, the destination being "[your wireguard interface]address", the destination port should be whatever the local port is in the port forward rule you created on this web site, the redirect target IP is the IP of your NAS, and the redirect target port is whatever port your NAS server is listening on.  Finally, be sure to select "create new associated filter rule" at the filter rule association setting.

Save it, and you should be good to go.

15 hours ago, nocturnaltabernacle said:

I'm seeing some web pages not working through Wireguard while they work through OpenVPN on the same server.

For example Firefox status bar might say "Performing a TLS handshake..." and the page loads without images and styles, or the page doesn't load at all.

I'm running pfSense 2.6.0 as my router and AirVPN client and I tested from Linux and Mac workstations. What might be the issue?

I'm seeing the same thing

That's showing the latency to the Atlanta server is only 4ms

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              10.128.0.1 -    0 |    5 |    5 |    8 |    8 |    9 |    8 |
|                          23.103.107.254 -    0 |    5 |    5 |    8 |    8 |    8 |    8 |
|                      Request timed out. -  100 |    2 |    0 |    0 |    0 |    0 |    0 |
|   be2978.ccr41.dfw03.atlas.cogentco.com -    0 |    5 |    5 |    8 |    9 |   10 |    9 |
|   be2763.ccr31.dfw01.atlas.cogentco.com -    0 |    5 |    5 |    9 |    9 |    9 |    9 |
|   be2441.ccr41.iah01.atlas.cogentco.com -    0 |    5 |    5 |   14 |   14 |   14 |   14 |
|   be2687.ccr41.atl01.atlas.cogentco.com -    0 |    5 |    5 |   27 |   27 |   28 |   27 |
|   be2847.ccr41.atl04.atlas.cogentco.com -    0 |    5 |    5 |   28 |   28 |   29 |   28 |
|     ae0-49.cr1.atl1.us.unitasglobal.net -    0 |    5 |    5 |   26 |   26 |   26 |   26 |
|                           198.32.132.42 -    0 |    5 |    5 |   25 |   25 |   26 |   26 |
|  inap.cust.cr2.atl1.us.unitasglobal.net -    0 |    5 |    5 |   25 |   26 |   27 |   26 |
|         border2.ae1-bbnet1.acs.pnap.net -    0 |    5 |    5 |   25 |   35 |   74 |   25 |
|            usd-29.satedge2.acs.pnap.net -    0 |    5 |    5 |   25 |   25 |   27 |   25 |
|                  core.atl.dedicated.com -    0 |    5 |    5 |   27 |   33 |   50 |   30 |
|                            64.42.179.58 -    0 |    5 |    5 |   25 |   25 |   26 |   26 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)

12 hours ago, hbs said:

Do you happen to have a tutorial on how to set up WireGuard on PfSense 2.6?

I am thinking of getting started with it as well since my speed dropped considerably when I upgraded to the newest version of pfSense a while back.

Please, let me know.

Set it to exclusive, of course.  But also check that your browser isn't using some built in "secure dns" which would be encrypted and thus bypass AirVPN's DNS.

you need to use your devices page to make another device.  download a new config for that new device.  then when setting up the interface you'll need to change the net mask to /32 so that the two devices don't overlap IP range.

https://airvpn.org/devices/

1 minute ago, htpc said:

Thanks for your answer.

I tried higher values for the buffers as well already. 

tun-mtu und mssfix is a good recommendation. Just tried that. Evaluated the MTU size with the ping fragment method and set it accordingly in the client config. There is indeed a minimal speed increase but almost negligible. 

8 hours ago, htpc said:

This is remotely related to another earlier topic but as the question is pretty specific, I though I'd better start a new topic.

On a low powered  Enigma2 box with a Broadcom 2-core (BCM7362) CPU I'm seeing lower than expected OpenVPN speeds. It's perfectly possible that the hardware just doesn't support better speeds but before I invest in more powerful hardware I wanted to make sure that all possible errors were eliminated and all optimization options were utilized.

Here's what I did to test the openssl capabilities of the device:
 

openssl speed aes-128-cbc                                                          
Doing aes-128 cbc for 3s on 16 size blocks: 1545626 aes-128 cbc's in 2.84s                        
Doing aes-128 cbc for 3s on 64 size blocks: 442085 aes-128 cbc's in 2.94s                         
Doing aes-128 cbc for 3s on 256 size blocks: 114144 aes-128 cbc's in 2.92s                        
Doing aes-128 cbc for 3s on 1024 size blocks: 28866 aes-128 cbc's in 2.95s                        
Doing aes-128 cbc for 3s on 8192 size blocks: 3591 aes-128 cbc's in 2.89s                         
Doing aes-128 cbc for 3s on 16384 size blocks: 1784 aes-128 cbc's in 2.82s                        
OpenSSL 1.1.1l  24 Aug 2021                                                                       
built on: Sat Oct 15 10:37:44 2022 UTC                                                            
options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr)                                  
compiler: mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32 --sysroot=recipe-sysroot -
Os -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=                      -fdebug-prefix
-map=                      -fdebug-prefix-map=                      -fdebug-prefix-map=  -mel -mab
i=32 -mhard-float -march=mips32 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_
ASM -DSHA256_ASM -DAES_ASM -DNDEBUG                                                               
The 'numbers' are in 1000s of bytes per second processed.                                         
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes        
aes-128 cbc       8707.75k     9623.62k    10007.15k    10019.93k    10179.06k    10364.91k 

This suggests a more than 80 Mbit/s capability for SSL

Then I conducted a theoretical OpenVPN throughput test with the following output:
 

time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-128-cbc                                                                                        
Sat Dec 10 12:43:11 2022 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode                                                                                                                                                              
real    1m31,731s                                                                                 
user    1m30,007s                                                                                 
sys     0m0,712s  

Following calculation examples from other posts this suggests a theoretical throughput capability of (3200/91,731) approx. 35 Mbit/s.

The speeds I'm seeing though are +/- 8 Mbit/s when running online speed tests resulting in choppy playback of HD video streams that run smoothly on other devices on the same network or when disabling OpenVPN on the device.

My config looks like this:
 

client
dev tun
remote xxx.xxx.xxx.xxx 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
verb 3
explicit-exit-notify 5
push-peer-info
setenv UV_IPV6 yes
ca "ca.crt"
cert "user.crt"
key "user.key"
remote-cert-tls server
cipher AES-128-CBC
ncp-disable
comp-lzo no
proto udp
fast-io
tls-auth "ta.key" 1
log /etc/openvpn/openvpn.log

I also tried to further optimize with different values for those parameters without any improvement:
 

sndbuf 0
rcvbuf 0
txqueuelen 2000

Is there anything suspicious in the numbers I posted? Are the slow speeds I see to be expected despite the suggested higher numbers of the conducted tests? Is there anything else I can try to improve the throughput? Or do I have to live with the fact that the device is simply underpowered?

Thanks in advance!

 

8 minutes ago, securvark said:

I cannot edt the subject, I would tag it [resolved] but its not my topic.

Nevertheless, the solution (for me) was this tickbox on the interface for the tunnel:

you need to use iptables to create the proper rules on the asus router. see the following post.
 

12 minutes ago, securvark said:

Oke, that's oke I can do that .. but where do I find the gateway address?

With OpenVPN, the gateway address is set to "dynamic", and I cannot select the same when I create a gateway manually so I still need a gateway address in order to manually create the gateway.

Thanks!

 

7 hours ago, securvark said:

Its very similar. Did your gateway appear automatically after creating the wireguard connection and interface? Mine doesn't.

To which server are you connecting and what gateway address does it pick?

Thanks!

there may not be very many people here that run opnsense.  I wish I could help but I'm still using pfsense.

It seems that setting the mss and mtu for wireguard to the same value is the trick for many people

I am concerned that with this matter the network lock isn't really working and that's why the OP gets leaks.  (or maybe the OP wasn't using network lock traditionally?)  You see, if network lock rules are created based on the wrong interface/network adapter (i.e. traffic can go through only the wrong adapter and no other) then it seems network lock and its rules will do no good anyway.

Only reason I can think of is for DNS resolution when not connected to the VPN or if you decide to have devices not routed through the VPN.

5 hours ago, Staff said:

Hello!

Do you declare an MTU size on the WireGuard conf file? Relevant for this discussion: https://superuser.com/questions/1537638/wireguard-tunnel-slow-and-intermittent

Different networks may require different sizes. This is probably the reason for which WireGuard developers opted for the smallest allowed size in Android, 1280 bytes. Of course if it's possible to set higher sizes the performance will improve.

Kind regards
 

  I'll have to check it out when I get a chance.

With wireguard on pfsense setting each wireguard interface I create to 1420 MTU and MSS seems to result in no problems and good performance. 

simply just outdated geolocation databases cause errors like this.  When I trace to the IP, I can see that it's in Brussels or nearby that, although there is a PTR error at line 14 because it claims to be in Los Angeles. 
 

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              10.128.0.1 -    0 |    4 |    4 |    7 |    7 |    8 |    7 |
|                          23.103.107.254 -    0 |    4 |    4 |    8 |    8 |    8 |    8 |
|                      Request timed out. -  100 |    1 |    0 |    0 |    0 |    0 |    0 |
|   be2978.ccr41.dfw03.atlas.cogentco.com -    0 |    4 |    4 |    8 |    8 |    8 |    8 |
|   be2763.ccr31.dfw01.atlas.cogentco.com -    0 |    4 |    4 |    8 |    8 |    9 |    9 |
|   be2432.ccr21.mci01.atlas.cogentco.com -    0 |    4 |    4 |   18 |   39 |   62 |   60 |
|   be2831.ccr41.ord01.atlas.cogentco.com -    0 |    4 |    4 |   30 |   30 |   30 |   30 |
|   be2717.ccr21.cle04.atlas.cogentco.com -    0 |    4 |    4 |  121 |  121 |  122 |  121 |
|   be2889.ccr41.jfk02.atlas.cogentco.com -    0 |    4 |    4 |  124 |  124 |  125 |  125 |
|   be2317.ccr41.lon13.atlas.cogentco.com -    0 |    4 |    4 |  123 |  124 |  127 |  123 |
|  be12194.ccr41.ams03.atlas.cogentco.com -    0 |    4 |    4 |  123 |  123 |  124 |  123 |
|   be3676.rcr21.bru01.atlas.cogentco.com -    0 |    4 |    4 |  124 |  127 |  135 |  124 |
|                          149.11.170.218 -    0 |    4 |    4 |  119 |  120 |  124 |  119 |
|          vlan2909.as02.lax1.us.m247.com -    0 |    4 |    4 |  131 |  133 |  139 |  131 |
|          vlan2911.as01.bru1.be.m247.com -    0 |    4 |    4 |  120 |  120 |  120 |  120 |
|            155.251.187.194.in-addr.arpa -    0 |    4 |    4 |  119 |  119 |  120 |  119 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)