How can I benefit from your service given that I can simply get a hosted server, say, from Amazon and fire up my own VPN server?

You are most welcome to do as you say. Our service is intended for users who don’t possess your degree of expertise. There are a lot of people out there who cannot or rather would not run their own VPN server. Besides free Amazon hosting will ultimately expire so that you will have to pay for it or rebuild you server every time your trial period ends.

Furthermore, keep in mind that modern home networking equipment varies widely in terms of VPN tunneling support. So you will have to run multiple services to simultaneously support PPTP, L2TP, IPSec and OpenVPN connections on your hosted VPN server.

This is by all means doable, but why bother? Using our service you will set everything up and join all your devices into a single home network in under 15 minutes.

 

 

Is it truly free for 2 tunnels?

Yes, VPNKI is a free service for 2 tunnels and 1 URL publish. This means that we are committed to helping people for free, out of enthusiasm. For anyone willing to help we used to have a donate button… but nobody clicked it so we decided to remove it altogether.

 

 

Why are doing it for free, what’s the catch?

There’s no catch, really. The point is actually two-fold:

First of all we, the developers are users too. We use VPNKI for our own flats, country houses and small businesses. It’s clear to us that this system is unlikely to earn us money. Still it’s useful for us. Why not let others make use of it too?

Second aspect is purely technical. Providing “anonymous” Internet access is pretty easy. There are lots of VPN providers out there. But it’s harder to connect people to their own, private LANs. This is the technological challenge we are solving and at present we are testing the solution.

Some might say: “Suppose I link up to you and then you will see my traffic”. What can we say? We take no interest in your traffic. You can encrypt it before sending our way. And you can set up you firewall. You can do whatever blows your whistle, it’s of no concern to us, for all we do is just providing network transport.

 

 

So how many different services do you provide exactly? I think I lost track of them…

Fundamentally there are 3 different services:

  • joining your VPN tunnels together into a single network capable of routing private networks like 10.0.0.0 or 192.168.0.0
  • setting up one VPN tunnel to your site modem (or router) to provide access to your internal network resources via HTTPS or SOCKS5 proxy with username/password authentication. We call this service “proxy-based access”
  • setting up one VPN tunnel to your site modem (or router) to provide access to your WEB-based internal resources (like 192.168.1.1) via a special domain name https://your-name.vpnki.com. We call this service “URL publishing”.

You can mix and match services as you require.

 

 

What are the traffic exchange points and how many of them do you have?

We have two independent servers to interconnect VPN tunnels. We call them exchange points. The first and primary one is in Moscow (with separate registration process) and early in 2017 we set up a new commutation point in Amsterdam. Some of our users have lower network delay while utilizing Amsterdam server simply because of its geographic proximity. VPNKI architecture allows for deployment of new exchange points anywhere on the Internet in minutes, should the need arise.

 

 

Who can “see” my traffic?

Every user’s traffic is kept separate and it would be technically correct to say that users’ networks are kept in distinct network segments that don’t interact or exchange traffic in any way. This architecture is best described by term VRF (Virtual Routing and Forwarding). It lets every user have a personal, independent routing table, traffic filtering rules, etc. Thanks to that different users’ traffic doesn’t mix and our exchange point successfully routes overlapping users’ networks. By associating every user with his personal routing table, our system distinguishes between private address ranges 192.168.0.0 employed by many users simultaneously without using NAT but still keeping each user’s traffic separate.

There’s no way you can access other user’s tunnels even if you know his addressing scheme. Likewise no other user can access your tunnels or your private networks.

 

 

What are the service limitation?

Actually there are a few ones:

  • All your networks being connected must use DIFFERENT network numbers. For example, 192.168.1.0/24 and 192.168.2.0/24. Only if that is true VPNKI can route traffic among them. If your networks collide, you have to renumber them until there is no overlap.
  • Your devices that initiate tunnels will receive IP addresses from 172.16.0.0/16 network. If this network overlaps with your home networks, you have to renumber the latter. Or alternatively wait for the upcoming VPNKI version which is planned to support user choice of 192.168.0.0/16, 172.16.0.0/16 or 10.0.0.0/16 for interconnect.

 

 

Is PPTP still the only supported protocol? Have you added support for other protocols as promised?

Initially we chose PPTP as the simplest protocol with widespread support. But is can cause problems in case your provider blocks PPTP control channel (TCP/1723) or, more commonly, data channel which is GRE. We just hope that’s not the case. Anyway, we have added support for other protocols so you can use unencrypted L2TP, encrypted L2TP over IPSec and OpenVPN.

 

 

Why PPTP is used without encryption?

We use PPTP without MPPE encryption to provide connectivity options for legacy devices that don’t support encryption. If you want to use PPTP without encryption use only CHAP authentication. If you want to use PPTP with encryption you must use MS-CHAPv2 authentication. If you desire encryption, use L2TP over IPSec or OpenVPN there is encription in "on" by default.

 

 

Do you support authentication methods other than CHAP?

Initially that’s what our guides used to say. But lately we have added support for MS-CHAPv2 too so our users have a choice of these two protocols. In fact PAP can still be used in some scenarios. We haven’t disabled it yet for compatibility reasons. Still PAP is unsecure so its use is strongly discouraged. It may be disabled on our servers without a warning.

 

 

Proxy-based access – what is it good for?

We have added a feature to provide access to your private network via a proxy. This means that you still need to set up one VPN tunnel from your home network to our server, but you can substitute your browser or any other application client that supports proxies for a second tunnel. Two kinds of proxy are available: HTTP/HTTPS and SOCKS5. HTTP/HTTPS proxy lets you access any Web-based resources of your home network while SOCKS5 proxy will work with any TCP-based applications, for example SSH and VNC. See our instructions for details.

 

 

URL publishing – what is it good for?

We have added a feature to support publishing internal Web resources (for example, http://192.168.1.1) using special URL like https://your-name.vpnki.com accessible from anywhere on the Internet. This service is unlike Dynamic DNS, Web site or application hosting. The technology under the hood is reverse proxy. This means that you still need one VPN tunnel from your home network to VPNKI server but for a second tunnel you can substitute a mapping of internal and publicly-accessible URLs. This service can come in handy when you can’t or just plain don’t want to set up more than one tunnel and only require access to select internal Web-based resources. Naturally only this type of internal resources can be used and there are certain additional technical restrictions. See our instructions for details.

 

 

How come there is a delay pinging my internal network devices after starting up the VPN connection?

This is done purposefully and only affects PPTP and L2TP VPN connections. The thing is many users have slow and unreliable Internet connections at their country houses. In these cases there is sometimes a significant delay before we receive DHCP requests for routes and other settings from their client systems. We have introduced a delay to see if the client is going to send DHCP packet our way. This delay amounts to 8 seconds; after that we conclude that there will be no DHCP exchange and complete the connection as is.

This delay doesn’t apply to OpenVPN connections since that protocol provides for a different mechanism to push information to the clients.

 

 

Do you provide user access to the routing tables in use at the exchange point?

At present users have read-only access to the routing table. A similar interface is also provided to view the effective firewall rules. We are considering providing an interface to manipulate routes and firewall rules directly. It’s worth mentioning that routing information is available only when the VPN tunnel is active.

 

 

Can I access the Internet through VPNKI?

No. We don’t provide Internet access. However you can channel all your sites Internet traffic though one site of your choosing. This may potentially be used to bypass Internet providers’ traffic filters. But the latter are likely to be consistent across all your sites so that will probably be of little use.

 

 

Could you please elaborate upon the technology behind the service?

Once a user registers, he or she gains the ability to create tunnels.

Each tunnel requires a login and password to set up. The former is assigned automatically while the latter is up to the user to make up. The user programs these credentials into his device: home router, cellular, etc. An IP address is furnished for each tunnel, the user can view it in his site personal area and it will look like 172.16.xxx.xxx. At the moment VPNKI doesn’t support changing tunnel logins or passwords: to change them one has to delete and recreate the tunnel.

The next step consists of defining networks reachable VIA the device participating in the tunnel. This must be done for all tunnels built from devices that are routers (modems, home routers) and not endpoints (smartphones). For example one might specify network 192.168.10.0/24 to be reachable via tunnel “user123”.

Once all that is done, VPNKI will be ready to receive connections from one’s devices. Upon successful connection and authentication VPNKI will supply routes to destinations in your newly-formed personal network via DHCP options 121 and 249. That will be done if your device requests this information by sending DHCP-Inform.

If one’s device lacks support for receiving routes via DHCP (Android, Linux), he or she has set that device with static routes manually. User settings take effect on VPNKI and get propagated to one’s devices upon a new connection. So always reconnect your tunnels after reconfiguration.

 

 

 

What are additional tools that are available to VPNKI users?

We have a few additional tools. Here is the list:

  • “Whitelist” – this a list of public IP addresses that VPNKI will accept incoming tunnels from. This list is maintained by user; by default any address is permitted. This list can help secure your private network.
  • “Connection statistics” and “Security events” – these two pieces of information are available on your home page and are meant to help troubleshoot problems.
  • “Guest access” – this allows you to set access rules to be applied to a specific tunnel. This way you can assign one tunnel for guest use and give away credentials for it. The guest will have specified restrictions applied to his tunneled traffic.
  • “Route default via tunnel” – this lets you direct all your sites Internet traffic into VPN tunnels so that all Internet traffic is exchanged through one site you specify
  • “Tunnel Up/Down E-mail notifications” – as the name suggests this monitoring tool will provide E-mail messaging useful both as troubleshooting aid and an added security measure
  • “Instruments” – provides an overview of one’s virtual router (VRF) settings. They include the routing table, firewall rules and ping utility
  • “Tunnels status” – this is an interactive Web page that provides status information regarding all your tunnels and also allows for forceful server-side termination of any tunnel.