Kill switch blocking local VMWare Traffic

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<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> 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<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> 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<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:50:56:c0:00:01
inet 192.168.26.1 netmask 0xffffff00 broadcast 192.168.26.255
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:50:56:c0:00:08
inet 172.16.240.1 netmask 0xffffff00 broadcast 172.16.240.255
tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> 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.

Edit: Please also ensure that traffic to the loopback address of 127.0.0.1 is not being blocked - there are corner cases where traffic is sent/received via this logical construct.

Hello @SMV,

Sorry to hear you are having trouble with the Kill Switch feature. As long as the block LAN traffic is unchecked, I don’t see any reason why VyprVPN would prevent the Host <—> Guest traffic. I don’t believe that sort behavior would be defined either, so there may be other routing variables at work that are beyond my understanding.

I was going to suggest using the ‘Per-App’ feature and see if you can place your VMWare outside of the VPN all together. But I’d also like to get clarification on whether the issue you reported is by design. I will touch base with our product team tomorrow and see if they can provide some more insight.

I will let you know what I find out. Thanks for your patience.

Regards,
Wes
Customer Support

Hello @SMV,

Thank you for your patience. I checked in with our product team and found that Kill Switch doesn’t behave in the way I initially suspected. As it happens, the virtual adapter is seen as a single tunnel and cannot differentiate what is local and what is not.

We even did some internal testing and tried privatizing the VM to the Mac via VM Fusion’s network settings, but it didn’t seem to influence Kill Switch’s behavior in any way. Sorry we could not be more of assistance.

I think suggesting that as a feature request sounds like a great idea. If you are interested in doing so, you can post your idea to the following page: http://ideas.goldenfrog.com/

This will allow other users to comment and vote on your idea as well.

Regards,
Wes
Customer Support

Thanks for the very prompt and thorough follow-ups/replies, Wes!

I will indeed post to the ideas section…

Best,

SMV