Crosspost from:
http://forum.goldenfrog.com/t/vyprvpnservice-exe-constantly-running/1247/8
"vyprVPNservice.exe constantly running"

Crossposted here at request of Golden Frog.

@keegan

Thanks for the update! I had also noticed this behavior and figured that something like the reasons you enumerated were the cause of it.

Suggestion:
This is especially important on potentially memory-starved systems where the user may wish to use VyprVPN, but cannot afford to have it running full-time, or on the Android version where memory and processor cycles are very likely to be at a premium:

* Create separate option items for "Start Application and start Service on startup, where "Start Application on startup" would automatically enable service start too.

* Add the behavior that, if both "Start application" and "Start service" at startup are not selected, when the application quits that all subordinate processes are killed as well.
** Alternately, there could be an option " 'Quit' also kills background services" that would be enabled if neither of the previous options are selected. (i.e. This option would be greyed-out if either of the two prior options get selected.)

* Add the behavior that, if the service is not running at application startup, that the service gets started silently. (This would also solve the "Cannot Contact Service" issues everyone is reporting!) An exception (error) would only get thrown if the service could not be started within a reasonable amount of time, or after "X" number of attempts.

The justifications for these actions are thus:

* If the user does not want the app to run at startup, he probably has a good reason for not wanting it to run at all. (i.e. He's on a trusted network, etc.) Forcing the user to specifically hunt-down and kill the service, if not selected at startup, is just pissy and annoying.

* If the user wants the service to run at startup, it can be selected. It can even be selected as the default setting during installation.

* In memory starved environments, or operating systems that are just pigs, (make that read "Windows 8"), leaving the service running can impact system performance.

* Android systems, especially on phones, are often memory and processor cycle starved. Leaving potentially unnecessary services running can have a seriously negative impact on performance, causing the user to ultimately un-install the app to avoid the performance crunch.

Thanks again for an excellent application, and I hope that these suggestions will receive expedited consideration.

Jim (JR)

At the moment, VyprDNS seems to be only available for users of the VyprVPN apps (confirmed by online support team).

In my case my Synology NAS need to connect as a client to VyprVPN (which works fine using the howto), but DNS queries are not resolved over VyprDNS as there seems to be no way to set the VyprDNS server address in /etc/resolv.conf (at least for me it does not get set automatically).

Would be great if we could get the VyprDNS server IP addresses to use for manual setups.

Now I have to use Google DNS servers as using the router IP address will bypass the VPN connection on DNS lookups (Wireshark confirmed). This only gives partial protection (only a degree of anonymity).

Of course, this might be integrated in a Synology NAS application, but that might still clash with my setup as the NAS is also my DHCP and DNS server (dnsmasq) for resolving internal network addresses (depending on how the app would be written of course).

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.