go558a83nk

yes, you need to use merlin's asus firmware.  he's coded in policy based routing via GUI of the openvpn client page.

Step 1:
First configure the Tomato VPN client (I am using Shibby's AIO build 134, but any of the recent VPN builds that have policy based routing included should work) so that all traffic is sent through the VPN and ensure that works. Once that is working, you can continue. Getting that working is outside the scope of this guide, and a good guide can be found here.
 
Step 2:
On the 'Advanced' tab of the VPN client, check the Ignore Redirect Gateway (route-nopull) option and on the Routing Policy tab, check the Redirect Through VPN option, and add the devices you want to redirect through the VPN. In my case, I added Source IP 192.168.1.120, as this is the only client on my LAN I want to be routed through the VPN.
 
Once that's done, ensure the VPN client is running and see if you have internet access through the tunnel for the specified client. I use ipleak.net to test. You will likely notice that while your IP address is that of the VPN, DNS is still being served by whichever DNS servers your router has configured. This is normal, and is solved in step 3.
 
Step 3:
On the Advanced -> DHCP/DNS tab, in the advanced configuration:
# Create a tag for clients to use a specific DNS server dhcp-option=tag:vpn,option:dns-server,10.30.0.1 # Tell these clients when they connect to use the VPN tag dhcp-host=XX:XX:XX:XX:XX:XX,set:vpn,hostnameyouwanttouse,192.168.1.120 The XX:XX:XX:XX:XX:XX above is the MAC address of your device's network interface. You can find this easily on the Status -> Device List tab. This line is essentially assigning static DHCP for the client with the MAC address specified.
 
This tells all clients tagged as 'vpn' to use 10.30.0.1 as their DNS server. Disconnect your client that you wish to route through the VPN and reconnect it so that it renews the DHCP lease. You may also need to flush the DNS on the client. On Windows this is done from a command prompt run as administrator and typing:
ipconfig /flushdnsNote: I am connecting to air on port 2018 to make QoS rules easier, so that's why you see 10.30.0.1 for the DNS server. Use whichever Air DNS server is appropriate for your connection.
 
Step 4:
Now, in Administration -> Scripts -> Firewall add the following:
iptables -t nat -I PREROUTING -i br0 -s 192.168.1.120 -p udp --dport 53 -j DNAT --to 10.30.0.1 iptables -t nat -I PREROUTING -i br0 -s 192.168.1.120 -p tcp --dport 53 -j DNAT --to 10.30.0.1 iptables -I FORWARD ! -o tun11 -s 192.168.1.120 -j DROP The first two lines prevent the specified client from specifying their own DNS servers, so if this is an issue for you, these rules will make sure the client always uses Air's DNS server. The third line prevents ANY traffic from that client using anything other than the VPN interface "tun11".
 
Note: tun11 is the interface Tomato creates for VPN Client 1. If you use VPN Client 2 use tun12 instead.
 
Routing an entire bridge:
To take this a step further I also created an entire bridge (br1) on a different subnet (172.16.0.1/24), and a virtual wireless network on that bridge that 100% uses the VPN tunnel. The rules for an entire subnet are a little different. Configuring additional bridges and virtual wireless access points in Tomato is outside the scope of this guide.
 
Again, in the VPN Client Policy Routing tab, add the "Source IP" and enter 172.16.0.0/24, then in Advanced -> DHCP/DNS:
dhcp-option=tag:br1,option:dns-server,10.30.0.1 This tells all clients that connect to br1 to use 10.30.0.1 as their DNS server. Tomato, by default, tags the clients with the bridge they are connected to, so that's all that is required to tell clients on that bridge to use a different DNS server.
 
Then in the Firewall:
iptables -t nat -I PREROUTING -i br1 -p udp --dport 53 -j DNAT --to 10.30.0.1 iptables -t nat -I PREROUTING -i br1 -p tcp --dport 53 -j DNAT --to 10.30.0.1 iptables -t nat -I POSTROUTING -s 172.16.0.1/255.255.255.0 -o tun11 -j MASQUERADE iptables -I FORWARD -i br1 -o tun11 -j ACCEPT iptables -I FORWARD -i tun11 -o br1 -j ACCEPT iptables -I FORWARD ! -o tun11 -s 172.16.0.1/255.255.255.0 -j DROP Again, the first two lines prevent clients from specifying their own DNS servers. The next three lines are required, as Tomato's VPN client doesn't automatically add them for bridges other than br0. Without these, no traffic will move between br3 and tun11 (and hence, you will not get a connection). The last line prevents all traffic on br1 if the VPN is down.
 
Port Forwarding:
This is straight from AirVPN's FAQ, copied here for completeness. To forward ports to clients, four firewall rules are required for each port you wish to forward. Here I am forwarding port 12345 (both UDP and TCP) to my one VPN'd client on my main LAN.:
iptables -I FORWARD -i tun11 -p udp -d 192.168.1.120 --dport 12345 -j ACCEPT iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.120 --dport 12345 -j ACCEPT iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 12345 -j DNAT --to-destination 192.168.1.120 iptables -t nat -I PREROUTING -i tun11 -p udp --dport 12345 -j DNAT --to-destination 192.168.1.120 
Preventing leaks on the main LAN when not using policy routing:
If you are not interested in policy based routing, and just want to prevent leaks while routing all traffic through the VPN, make sure you check Redirect Internet traffic in the VPN Client Advanced tab and then the following firewall rules:
iptables -t nat -I PREROUTING -i br0 -p udp --dport 53 -j DNAT --to 10.30.0.1 iptables -t nat -I PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to 10.30.0.1 iptables -I FORWARD ! -o tun11 -s 192.168.1.1/255.255.255.0 -j DROP The above is completely untested by me as I don't want to route my main LAN (other than a single client) over the VPN. It may cause connectivity issues with the router itself if the tunnel goes down. If someone does test, please come back here and report your results!
 
I hope this guide helps anyone wishing to use Tomato's VPN client to get connected and if you run in to any trouble, I am happy to try and help solve the issue.
 
Troubleshooting:
If something isn't working and you've entered everything correctly, I've found that rebooting the client you want routed through the VPN or restarting the VPN client can help. Also, rebooting the router will flush out anything left over between configuration steps and can sometimes solve problems. You can also rebuild the firewall rules in Tomato by going to the Tools->System Commands tab in the interface, and sending service firewall restart. If these don't help, double check that everything is configured appropriately.

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Spain is available: Mekbuda.
 
The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").
 
The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP.
 
Just like every other Air server,  Mekbuda supports OpenVPN over SSL and OpenVPN over SSH.
 
As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.
 
Do not hesitate to contact us for any information or issue.
 
Kind regards and datalove
AirVPN Team
 

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Vancouver, Canada is available: Gemma.
 
The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").
 
The servers accept connections on ports 53, 80, 443, 2018 UDP and TCP.
 
Just like every other Air server,  Gemma supports OpenVPN over SSL and OpenVPN over SSH.
 
As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.
 
Do not hesitate to contact us for any information or issue.
 
Kind regards and datalove
AirVPN Team
 

I let OpenVPN connect randomly to either Nusakan or Kitalpha, so one day I shall do what you say, the other day I shall stand my ground.

Hello!

We're very glad to inform you that four new 1 Gbit/s server located in Vancouver, Canada are available: Cynosura, Homam, Kleeia and Mimosa.
 
The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator").
 
The servers accept connections on ports 53, 80, 443, 2018 UDP and TCP.
 
Just like every other Air server,  Cynosura, Homam, Kleeia and Mimosa support OpenVPN over SSL and OpenVPN over SSH.
 
As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.
 
Do not hesitate to contact us for any information or issue.
 
Kind regards and datalove
AirVPN Team

My 10 cents; Governments such as the UK (mine) are using their proganda machines to demonize anything that might make it difficult or impossible for them to snoop upon. So anyone using any type of encryption must be doing something underhand or illegal, unless you are using a bank or shopping on line but don't mention those because they are legit and people might start thinking encryption is good.
 
If terrorists or any criminal wants to keep stuff secret, they will (try at least), no matter what the stupid governments want with regard to back doors and other such nonesense. There is little difference in essence than before digital technology was around, cryptography has been alive and well for centuries.
 
I just hate slimey underhand liars, (lots of expletives) governments, totally hypocritical teapot heads, members of who do loads of secretive deals and other such deeds that they would not like in the public arena. Thank the Lord for Snowden and others like him.

It's upon law enforcement officers (LEOs) to prove guilt or gain access to private property.  That's liberty for the citizen.  How silly to think the property owner should be expected to open his/her "doors" to LEOs.  The constitution of the USA protects the citizens in this way, though it's certainly not being followed by government.  For example, a person is allowed to NOT speak.  It behooves the home owner to *not* open his/her "door" to LEOs.  That is his right.  However, if the LEOs have sufficient reason to search private property then they should seek justice in what lawful way they can.  Still, it is not upon the property owner to provide means.  Again, if gaining access to a domicile authorities with probable cause don't wait for the door to be opened for them.  They bust the door down.  So why should we now be expected to provide access to a locked device?  No, it should be upon the FBI to bust the door down of the iphone.

No, the server doesn't report anything. GeoIP databases are those reporting IP location. CPV just performs some latency tests to a connecting computer to verify if it is where the server is according to GeoIP.
 
 
No, CPV is independent from anything of this kind. The one-way delay checks are performed on the application layer, therefore, CPV could be implemented into a website and the VPN server would just forward everything as expected.
 
Just so you know, it's not something to find out your real location. This technique is just used to verify the correctness of your alleged location.
 
 
The triangles are fairly big, so I think when I connect to the geographically nearest server, chances are high that I'm still in the triangle, causing a false negative. 400 km in all directions from my location cover Frankfurt, Berlin, the Netherlands and maybe Munich and parts of France and Switzerland.

It's upon law enforcement officers (LEOs) to prove guilt or gain access to private property.  That's liberty for the citizen.  How silly to think the property owner should be expected to open his/her "doors" to LEOs.  The constitution of the USA protects the citizens in this way, though it's certainly not being followed by government.  For example, a person is allowed to NOT speak.  It behooves the home owner to *not* open his/her "door" to LEOs.  That is his right.  However, if the LEOs have sufficient reason to search private property then they should seek justice in what lawful way they can.  Still, it is not upon the property owner to provide means.  Again, if gaining access to a domicile authorities with probable cause don't wait for the door to be opened for them.  They bust the door down.  So why should we now be expected to provide access to a locked device?  No, it should be upon the FBI to bust the door down of the iphone.

Hello!
Due to the following vulnerability:
 
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
 
and having seen that patches are now available for all of our systems, we inform you that we are upgrading ALL of our servers.
 
The maintenance will have an impact on connected clients which will be disconnected by the VPN servers. Each upgraded server will remain unavailable for a couple of minutes.
 
Web site can remain unavailable for two minutes during the maintenance.
 
Upgrade is starting at 13.10 CET.
 
EDIT: maintenance completed successfully.
 
Kind regards
AirVPN Staff

Hello,
 
the Data Channel cipher for packets authentication is HMAC SHA (edit: note that there is no GCM support for the data channel yet... it will be probably implemented in OpenVPN 2.4). Perhaps your libraries do not support DHE-RSA-AES256-GCM-SHA384 with TLS 1.2 (also listed as "TLS-DHE-RSA-WITH-AES-256-GCM-SHA384" in OpenVPN 2.3.8). In this case use "TLS-DHE-RSA-WITH-AES-256-CBC-SHA".
 
Edit: note that there is absolutely no rational reason to rush to SHA384 and drop HMAC SHA1 which is NOT vulnerable to SHA collisions. We often read (even in our forum) a confusion pertaining to SHA1 vulnerabilities, which are thought (with an unexplainable mistake) to be extended to HMAC SHA1. See also here:
https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure
 
Back to the Control Channel, which is the subject of this topic. By default, OpenVPN 2.3.3 or higher will first choose TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 if available, over TLS-DHE-RSA-WITH-AES-256-CBC-SHA, so if you needed an explicit directive for the first, very probably your system does not support it. So, at the end of the day, you normally do not need any additional directive, OpenVPN will pick automatically the best cipher between those available both in your and our systems. See also "openvpn --show-tls".
 
One more edit: please see also here https://security.stackexchange.com/questions/92638/openvpn-cipher-vs-tls-cipher , in particular:
 
 
 
Kind regards

@Staff after a long research I managed to find addresses on M247 which Maxmind respects as CZ.
Those are at 83.143.240.0/27.
So if they have 3 IPs still available, that might work great.
 
Forget it, it's SWIP made in November for another VPN provider.
Seems this is the only way with M247, sub-leasing /27 and asking Maxmind to change it.
However 83.143.240.32-39, 83.143.240.40 - 83.143.240.47 are still correct with CZ and seem not to be SWIPed, so if they squeeze in some 3 IPs all users should be happy.

http://bgp.he.net/ 
look up IP blocks and see what their description is.

He meant corporate firewalls with SSL termination capabilities.
This requiers a self signed local root CA installed on all machines, but this does not affect OpenVPN.
The capability of terminating SSL connections is mainly used for URL filtering and DLP over text protocols,
it is completely useless with tunnelling protocols, and they cannot see your traffic.

http://bgp.he.net/ 
look up IP blocks and see what their description is.

Hello!

We're very glad to inform you that two new 1 Gbit/s servers located in New York City and Atlanta, GA (US) are available: Zosma and Kaus.
 
UPDATE 16-JUL-16: ZOSMA WITHDRAWN (reason: provider could not keep up anymore with the previously agreed monthly traffic)
 
The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator").
 
The servers accept connections on ports 53, 80, 443, 2018 UDP and TCP.
 
Just like every other Air server, Zosma and Kaus support OpenVPN over SSL and OpenVPN over SSH.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

openvpn connect on iOS uses polarSSL instead of openSSL like many other openvpn setups.  polarSSL hasn't had the security vulnerabilities that openssl has had.  that is one reason why there's been no need to update it.
 
on iOS what features are you missing that you would ask for an update?

this is an AirVPN forum, not Asus router forum.  don't be surprised to get no answer.

It's a faq? Oops. Enough forums for today.. thank you for reminding me of looking at the most obvious places.

https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses/

This is a quite interesting article about honeypot awareness copied from cryptostorm's forum. "We" and "our" express the opinions of cryptostorm.
 
 

Hello!

We're very glad to inform you that a new 100 Mbit/s server located in Hong Kong is available: Cebalrai.

The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accept connections on ports 53, 80, 443, 2018 UDP and TCP.

Just like every other Air server, Cebalrai supports OpenVPN over SSL and OpenVPN over SSH.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

Looks cool
 
https://github.com/adrianchifor
 
Ever came across other commit graph "pictures"? Post them here!

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Paris (FR) is available: Thuban.

The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accept connections on ports 53, 80, 443, 2018 UDP and TCP.

Just like every other Air server, Thuban supports OpenVPN over SSL and OpenVPN over SSH.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team