App-based VPN using SOCKS5

Under the Hood By Nick Pestell | Posted on July 13, 2022

Today we’re launching our new SOCKS5 proxy service, available on all IVPN servers. This enables multiple new features but I feel the most exciting is the ability to configure individual apps (or browser tabs!) to route their traffic through a different VPN server than the one you are connected to. For example, you could connect to the Paris VPN server using the IVPN app, but configure your web browser to exit through the Singapore VPN server. With this setup, all the traffic generated by apps on your device will by default exit through the Paris server, except for traffic from the web browser which will exit through the Singapore VPN server. This feature can be supercharged for customers using Firefox by installing the “Firefox Multi-account Containers” addon which enables you to configure a different SOCKS5 proxy for each browser tab. See the section below for more details, including a video demo.

Secondly, with the SOCKS5 service you can implement an application kill-switch, so traffic from the application would be unrouteable if the VPN connection is terminated. The IVPN app firewall already prevents any traffic leaking outside of the VPN connection, but for those not using the IVPN app SOCKS5 can provide a kill-switch functionality. IVPN app users may also benefit from an additional killswitch if they need to disable the IVPN firewall to access local or remote resources, or if they feel more comfortable having multiple anti-leak controls. This works, because our SOCKS5 proxies are only available when the VPN is connected, so if the VPN is disconnected, the proxy is not available and no traffic can leak from the application.

For more information on how to configure SOCKS5 please refer to our SOCKS5 Knowledgebase article.

Firefox Multi-Account Containers

Besides being able to configure containers with their own VPN server, you can associate specific websites with a container. When you open the website, it will open in the associated container and all traffic will be routed through the associated VPN server. For example, you can create a container to route traffic through the London, UK server and associate the BBC news website with that container. When you visit the BBC news website, Firefox will launch it in the associated container, and the connection will be routed through the London, UK server without you having to do anything. Note that you need to be connected to the VPN first for this to work.

Some technical details

Each VPN server has a SOCKS5 proxy listening on port 1080. Once you are connected to any VPN server using Wireguard, OpenVPN, or IPSec you can configure your application to use the SOCKS proxy on any server in our network, including the one you are connected to. Every server in our network is interconnected using a Wireguard mesh. If you connect to Amsterdam using OpenVPN and then proxy your Firefox traffic to the Kyiv server, your Firefox traffic is encrypted to the Amsterdam server using OpenVPN, and then re-encrypted for the Kyiv server via the WireGuard mesh, where it will exit to its final destination.


Although this appears to be a multi-hop connection, it doesn’t offer the same security properties as the multi-hop service available from within the apps. When using multi-hop via the IVPN apps, your data is encrypted for the exit server, so an attacker with access to the entry server would only see the encrypted data. When using a SOCKS5 proxy, an attacker with access to the entry server could see your unencrypted traffic after it has been decrypted by the OpenVPN tunnel, and before encrypting for the WireGuard mesh. This risk is somewhat mitigated by the use of layer 5+ encryption e.g. SSL/TLS. For customers with a threat model that requires multi-hop, and a fully end-end encrypted tunnel to the exit server, we recommend establishing a multi-hop connection from within the app before using a SOCKS5 server (thereby establishing a triple-hop connection if you use a SOCKS5 proxy on a different server to your entry or exit server).

We invite you to discuss this post in our Reddit community or on Twitter. You can also send your feedback to

Independent security audit concluded

By Nick Pestell


IVPN applications are now open source

By Viktor Vecsei


Beta IVPN Linux app released

By Viktor Vecsei

Battery life improvements with Apple silicon builds Under the Hood

Battery life improvements with Apple silicon builds

Posted on November 10, 2021 by Alexandr Stelnykovych Viktor Vecsei

We have tested the battery consumption rate of the IVPN app with constant VPN connectivity using two protocols (WireGuard and OpenVPN) on two different app builds (M1 and Intel). We concluded that using a dedicated Apple silicon app build with WireGuard protocol can offer up to 22% increase in battery life over OpenVPN on Intel build version when bandwidth is not limited.
Kill switch changes in IVPN for Android Under the Hood

Kill switch changes in IVPN for Android

Posted on October 14, 2021 by Aleksandr Mykhailenko

TL;DR - Before our latest Android update (2.7.0) customers had two different options for a kill switch: one implemented by IVPN, and another available through device settings in the Android OS. We have removed our custom solution from the IVPN app and suggest using the native Android solution from now on.
Spotted a mistake or have an idea on how to improve this page?
Suggest an edit on GitHub.