I fully understand GoldenFrog's efforts to counteract the VPN’s blockages of streaming service companies, such as Amazon Prime, Netflix, etc. I particularly use the vyprVPN APP on my Amazon Fire TV stick and it has had its ups and downs in terms of restrictions. 1) Since I have the service with you, I never been able to connect with AMAZON PRIME because I am GEO-BLOCKED and 2) with NETFLIX, sometimes it works and other times it realizes that I have an UNBLOCKER.

I have followed the rough steps of your instructions indicated on the https://support.goldenfrog.online/hc/en-us/articles/205938498-Trouble-accessing-content-streaming-services- web page, but they are very general and basically it is aimed for PC or Android devices such cell phones and tablets. It would be a good idea that YOU DIVERSIFY those instructions for the different types of devices, since THERE ARE NO SPECIFIC INSTRUCTIONS for the users of FIRE TV / FIRESTICK, CHROMECAST or SmarTV’s, which should be THE MAJOR MAJORITY. The instructions for Android on that page, are not valid for the above devices, or worse, are not valid for ROUTERS

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.