Dear sir,

Please do me a favor. When I use Android Smartphone, The icon of indicator of when VPN connectivity is established or not is always same mark after running the app. So, When the VPN connection was disconnected by unstable data transmission such free Wi-Fi, I can not identify smoothly whether I'm safe without making anyone to detect my proper current location by IP.

Why I got VPN client is for Instagram follower who use Business account that they might be able to detect my location by my access logs such IP address like Google Analytics console. Hence, I'd like to avoid their behavior. So, I got VPN client this time from you.

I don't want to making FB account for Instagram. So, I can not verify the functionality of business user account enough and whether business user can grab my lnformation in location.

It's very risky for me to make them detect my actual location.

Could you kindly implement two functions in below?
1. Displaying the status by the color or changing figures of indicator on the top of the screen after runs Viper VPN.
2. Establishing VPN tunnel automatically when specific Android app "Instagram" runs with one of network connectivities such unsecured Wi-Fi, secured Wi-Fi, LTE(4G) or 3G.

Hi,

Like many folks (esp in the IT profession), I use VMWare Fusion to allow for the running of "guest" Virtual Machines (VM) on my "host" Mac. This is useful for running Windows apps natively on a Mac, to run linux-based utilities - on and on.

VMWare builds so-called "vmnet" logical interfaces that act as sort of a bridge or switch to pass IP traffic between the host and its guests. These typically are given private RFC1918 addresses (e.g. 192.168.1.1). Here's a snippet (edited for brevity) of my current IP interface scenario:

MacBook-Pro:~ smv$ ifconfig
lo0: flags=8049 mtu 16384
options=1203
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201
gif0: flags=8010 mtu 1280
stf0: flags=0<> mtu 1280
XHC20: flags=0<> mtu 0
XHC0: flags=0<> mtu 0
XHC1: flags=0<> mtu 0
en0: flags=8863 mtu 1500
ether dc:a9:04:99:53:36
inet 10.0.1.27 netmask 0xffffff00 broadcast 10.0.1.255
media: autoselect
status: active
**vmnet1: flags=8863 mtu 1500**
ether 00:50:56:c0:00:01
**inet 192.168.26.1 netmask 0xffffff00 broadcast 192.168.26.255**
vmnet8: flags=8863 mtu 1500
ether 00:50:56:c0:00:08
inet 172.16.240.1 netmask 0xffffff00 broadcast 172.16.240.255
tun0: flags=8851 mtu 1500
inet 10.3.x.y --> 10.3.x.y netmask 0xffffff00
open (pid 2664)
MacBook-Pro:~ smv$

(Apologies that I couldn't figure out how to preserve indentation, which would've made the above vastly more readable.)

When kill switch kicks in, network connectivity between the host and guests is blocked - in spite of the fact that the host has an IP address in the 192.168.26.0/24 subnet. This should obviously qualify as LAN traffic, and I do not have Vyper set to block such traffic during kill switch activation.

Please consider this as a feature request to properly classify vmnet interfaces as belonging to the LAN (or come up with some other mechanism to unblock vmnet interface traffic). One would have to be really paranoid to want to block even traffic contained entirely within one's own local machine! :wink:

Thank you.