http://www.vpntracker.com/interop

For a general introduction to computer networking, VPNs and IPsec, there are several excellent introductions available online or as books, see for example here.

If you experience specific configuration problems, our technical engineers are happy to provide support for setting up VPN connections with VPN Tracker. In many cases, connection problems are related to misconfiguration of either VPN Tracker or the VPN gateway.

If you provide

• A problem description and information on what you've already tried
• A Technical Support Report from VPN Tracker ("Help" > "Generate Technical Support Report")
• Screenshots of the VPN gateway configuration
• A log from the VPN gateway

we can usually quickly spot the cause for a problem and provide advice on how to resolve it.

As there are several factors unrelated to VPN Tracker or the VPN gateway that can influence connectivity (e.g. firewalls/routers in between VPN Tracker and the VPN gateway), we cannot guarantee that a connection can be established under any circumstances.

While we try our best, our support options may be limited if

• you use a device which we did not test ourselves (most devices work just fine with VPN Tracker, though, and we're happy to take a look even at issues with untested VPN gateways)
• you do not provide the information we need in order to assist you (see above)
• your network administrator does not cooperate
• you change connection parameters while we're trying to debug the settings

By default, traffic to the remote network cannot be sent through the VPN tunnel if it is using the same network as the local network.

Resolving a Network Conflict using Traffic Control

You can use Traffic Control and VPN Tracker will send non-essential local network traffic over the VPN.

Activate Traffic Control:
> Go to Advanced > Traffic Control
> Check "Force traffic over the VPN if remote networks conflict with local networks"

Note that you will never be able to reach the following addresses over VPN: The IP address of your local router, your DHCP server, and your DNS server(s). If you need to reach those IPs over VPN, you will have to resolve the network conflict instead of using Traffic Control. The same applies for any IPs that you need to reach locally and over VPN.

Resolving a Network Conflict Manually

You have two basic options for resolving a conflict:

1. Change the local network to use a different network address. In most situations, this will entail changing the LAN settings on the local router (including DHCP settings if DHCP is used).
2. Change the remote network to use a different network address. With most setups, this entails changing the LAN on the VPN gateway (including DHCP settings if DHCP is used), and changing the IPs used by devices on the VPN gateway's LAN (or triggering a DHCP refresh, if DHCP is used). If the LAN is used in the VPN settings (such as for policies or firewall rules), these will need to be changed as well. Finally, change the remote network in VPN Tracker to match the new settings

If you decide to change the remote network, it makes sense to choose a private network that less commonly used. According to our informal statistics, conflicts are least likely using these networks:

• Subnets of 172.16.0.0/12
• Subnets of 192.168.0.0/16, excluding 192.168.0.0/24, 192.168.1.0/24 and 192.168.168.0/24

If these are not an option, use a subnet of 10.0.0.0/8, excluding 10.0.0.0/24, 10.0.1.0/24, 10.1.0.0/24, 10.1.1.0/24. However, since wireless network operators sometimes choose to use the entire 10.0.0.0/8 network, the first two options are preferred.

If you have a more sophisticated VPN gateway, in particular a SonicWALL, you may be able to set up an alternative remote network on the VPN gateway that is mapped 1:1 through Network Address Translation (NAT) onto the actual network. Users can then connect to this network instead if they have a conflict of networks. We have a guide available that describes this approach for SonicWALL devices.

If the conflict is caused by virtual network interfaces (e.g. Parallels, VMware), see here for more information.

VPN Tracker supports industry standard OpenVPN, IPsec (IKEv1 + IKEv2), L2TP, PPTP, SSL, SSTP, and WireGuard® protocols. This means that it will work with almost all devices supporting these types of VPN connections.

A list of tested devices is available on our website

What if my device is not on this list?

There are hundreds of VPN devices available on the market, and we'd love to offer device profiles for all of them. Unfortunately, it is impossible to test all devices. If your gateway is not in the list, it will probably still work with VPN Tracker.

Tip: Try out one of our custom protocol profiles to test your VPN connection free in VPN Tracker on Mac, iPhone or iPad.

To establish a VPN connection to a certain location (such as your office), you will need a VPN gateway at that location. This gateway could be a hardware VPN gateway device (see our compatibility page for compatible devices and setup guides).

The VPN gateway needs to be connected to the Internet (e.g. to a DSL modem or similar), preferably with a static IP address or it should be capable of using a service like DynDNS.org to map its dynamic IP to a hostname. Configuration is easiest if the VPN gateway is also the router (default gateway) of its network. If the VPN gateway is not the router of its network, a suitable routing setup may be necessary for traffic over the VPN to be routed correctly.

Configuration details can be found in the configuration guides for specific devices.

Symptom

As soon as you connect your VPN tunnel, Skype is not able to make calls any longer, however calls started prior to connecting the VPN continue to work.

Solution

Make sure the field Local Address is not empty. If it is, fill in a private IP address. A private IP address has the following form:

• 192.168.x.x
• 10.x.x.x
• 172.y.x.x

x: A number of the range 0 to 255.
y: A number of the range 16 to 31.

Only rule: It must not be an IP address from a remote network on the other side of the VPN tunnel (must not partially match an entry of the field "Remote Networks"), as choosing such an address will make the tunnel stop working (it will connect, but you cannot really reach anything over it).

Alternate Solutions

If the solution above does not fix your issues, make sure that

• DNS resolution still works once the VPN tunnel is up.
   
• Public Internet servers are still reachable once the VPN tunnel is up.
   
• In case of a Host to Everywhere connection, make sure the VPN gateway does not block any network traffic that is crucial for Skype to work.
   

Explanation

VPN Tracker creates a virtual tunnel interface for every VPN tunnel. Like any network interface, this virtual tunnel interface requires an IP address to be functional as an IP network interface. If your VPN gateway assigns you an IP address, the assigned address is applied to the tunnel interface. If not, the address you put into Local Address will be used. If you leave local address empty, the IP address of your primary network interface will be used.

In the last case, your system ends up with two interfaces with identical IP addresses. This is allowed and usually not a problem, unless a software does “stupid things”, like querying the network interface for a given IP address and then ignoring the order of precedence of the returned results.

Yes, NAT-Traversal is supported by VPN Tracker. VPN Tracker supports the current version of NAT-Traversal that uses UDP encapsulated packets on port 4500 (RFC 3947), as well as previous draft versions that send UDP encapsulated packets on port 500. In addition, Cisco's UDP encapsulation is also supported.

NAT-Traversal helps to establish VPNs from networks behind routers that perform Network Address Translation (NAT). Such routers can be found in many places: home DSL routers, wireless hotspots, Internet cafes, hotels, airports, etc. Many mobile ISPs (3G modems) also require NAT-Traversal to be used.

VPN Tracker automatically recognizes if NAT-Traversal is needed, and turns it on and off accordingly. It can even test your local router to see what NAT-Traversal method works best with it.

By itself, the IPsec protocol does not support usernames. If you were given a username from your network administrator for connecting to your corporate VPN solution, there are generally two possibilities:

• Your corporate VPN solution uses the term "username" for "identifiers". Please try to use your username as the "Local Identifier" in VPN Tracker.
• Your corporate VPN solution is using Extended Authentication (XAUTH). You can enable XAUTH in VPN Tracker. The software will then prompt for your username and password when the connection is being established.

Unfortunately, we cannot guarantee this. Secure networking is a complex subject. VPN Tracker is extremely reliable and is used by customers around the world. But there are some rare scenarios in which VPN connections cannot be established (e.g. when a firewall is set up to actively block VPN connections).

We recommend using the free trial version to test VPN Tracker with your particular network and usage scenario.

If you require any assistance setting up your VPN connection with VPN Tracker, you can contact equinux support at any time.

VPN Tracker Pro is a great asset if you are a consultant, a system or network administrator, or are working with multiple VPN connections:

• Export VPN connections for yourself and other users.
• Scan the remote network for services or to assist users.
• Connect to multiple VPNs at the same time.
• Manage a large number of VPNs using search, a condensed layout, and connection groups.
• Configure your Mac as a router to provide the entire network with a VPN tunnel using Network to Network connections.

Yes, as long as your VPN gateway uses Extended Authentication (XAUTH) to request the passcode, you can use any third party token with VPN Tracker.

Yes, this is possible. If you set up shared networking for the guest operating system it shares the network connection of your Mac and you can access all network resources that are accessible from OS X.

Note that if you are using remote DNS for your VPN connection, you will need to manually enter the DNS server in your guest operating system in order for it to work – there is no way for VPN Tracker to “transmit” this setting to the guest operating system

For information on how to set up VPN Tracker with Parallels, check out our VPN Tracker with Parallels Configuration Guide.

This depends on your settings. The most common setup is “Host to Network“, in which case only traffic to the specified remote network(s) will go through the VPN tunnel.

With a “Host to Everywhere” setup, all traffic – except traffic to the local network(s) – goes through the VPN. A Host to Everywhere connection requires a suitable setup on the VPN gateway.

• macOS 15.0 Sequoia
• macOS 14.0 Sonoma
• macOS 13.0 Ventura
• macOS 12.0 Monterey
• macOS 11.0 Big Sur
• macOS 10.15 Catalina
• macOS 10.14 Mojave
• macOS 10.13 High Sierra

As VPN Tracker has low-level access to your system, it is digitally signed and checks that the app has not been altered in any way every time you launch it. If VPN Tracker it looks as though changes have been made to the VPN Tracker app, you'll see that message.

Unfortunately other applications (e.g. Uninstaller/Deinstaller, Clean-Up Tools, and so on), that can cause this problem.

Should you repeatedly run into that issue, please send us a copy of your VPN Tracker app. Locate VPN Tracker on your harddrive, copy it to your Desktop and create a zip file (CTRL-/right click VPN Tracker, then choose "Compress VPN Tracker"). By comparing the broken copy we can find out what has been changed and offer advice how to prevent it from happening again.

Some kinds of software may cause issues with VPN Tracker:

1. Personal Firewalls / Desktop Firewalls
2. Protection Software (e.g Virus Scanners, Malware Protection)
3. Other VPN Clients / VPN Software (for example NCP Client)

Personal Firewalls usually ask the user, if an app should be allowed to send network traffic. It’s important to grant VPN Tracker full network access. If you have already added rules for VPN Tracker, please whitelist VPN Tracker.

Protection Software often sees VPN traffic as a potential source of threat, as it isn’t able to analyze that traffic because of its very strong encryption. Please ensure VPN Tracker is ignored by any protection software running on your Mac and allow VPN traffic to pass through.

Other VPN clients should not be a problem, if they are designed to co-exist with othe VPN apps. Unfortunately, not all other clients are and some capture all VPN traffic as soon as they are installed, even if the app is not running.
In these situations, you may need to uninstall the VPN client - we also suggest asking the vendor to improve its “cooperation” with other VPN apps.

Here are some common examples of the types of apps mentioned above. If you are uncertain whether any of these applications may be installed on your system, try the following:

• Open the app “Terminal”
• Copy and paste the following command: kextstat | grep -v com.apple

You’ll get a list of all kernel extensions that are not from Apple. Just compare that list with the identifiers in parenthesis below:

• Little Snitch
  (at.obdev.nke.LittleSnitch)
   
• TripMode
  (ch.tripmode.TripModeNKE)
   
• Sophos Anti Virus
  (com.sophos.kext.oas, com.sophos.nke.swi)
   
• Symantec Endpoint Protection / Norton AntiVirus
  (com.symantec.kext.SymAPComm, com.symantec.kext.internetSecurity, com.symantec.kext.ips, com.symantec.kext.ndcengine, com.symantec.SymXIPS)
   
• Kaspersky Internet/Total Security
  (com.kaspersky.nke ,com.kaspersky.kext.kimul, com.kaspersky.kext.klif, com.kaspersky.kext.mark)
   
• Intego Mac Internet Security
  (com.intego.netbarrier.kext.network, com.intego.virusbarrier.kext.realtime, com.intego.netbarrier.kext.process, com.intego.netbarrier.kext.monitor)
   
• Fortinet FortiClient
  (com.fortinet.fct.kext.avkern2, com.fortinet.fct.kext.fctapnke)
   
• Cisco Advanced Malware Protection (AMP)
  (com.cisco.amp.nke, com.cisco.amp.fileop)
   
• TUN/TAP based VPN Clients
  (net.sf.tuntaposx.tap, net.sf.tuntaposx.tun)
   
• eset Security Products
  (com.eset.kext.esets-kac, com.eset.kext.esets-mac und com.eset.kext.esets-pfw)
   

Testing VPN throughput using a remote file share is usually not a good idea for two reasons:

The first reason is the file sharing protocol itself. File sharing protocols like SMB, AFP, or NFS have been designed for local networks that are fast, reliable, and have a very low latency. The Internet on the other hand is slow (at least the connection to it), unreliable and has a very high latency. For realistic results, you need to use a protocol that was optimized for such a situation, like HTTP or FTP.

The second reason is the implementation of the file sharing protocol. Today most file shares use SMB, the Windows file sharing protocol. Apple has its own implementation of that protocol but this implementation is anything but good. While the SMB 3.x implementation is already poor, the SMB 1.x/2.x implementation (compatibility mode) is horrible, and for several reasons macOS will often fall back into that compatibility mode. When testing with a local NAS file share, we got 28 MBps using SMB 3 and only 18 MBps using SMB 1, compared to 50 MBps using AFP.

If you have a Mac at the remote side, it’s pretty easy to setup a benchmark HTTP server. All you need is to open the standard application “Terminal” (use spotlight to find it) and then run the following set of commands (every command is confirmed by Return/Enter):

mkdir /tmp/www-bench
cd /tmp/www-bench
dd count=1048576 bs=1024 if=/dev/random of=1GiB.dat
php -S 0.0.0.0:8080

The First command creates a new directory, the second one enters that directory, the third one creates a 1 GiB data file filled with random data, the last one starts a primitive HTTP server that serves the content of the current directory at port 8080. Now your VPN users can just open this address in Safari (or any other browser):

http://a.b.c.d:8080/1GiB.dat

Where “a.b.c.d” is the IP address of the Mac where you just typed the commands above. By watching the transfer speed in browser, you get a good idea of how capable your VPN is. Of course, this is limited by many factors, like the speed of your local Internet connection, the speed of the remote Internet connection, and the CPU power of the VPN gateway (which is usually far less than the CPU power of a Mac).

To clean up after the test, activate the terminal window again and hit CTRL+C to stop the HTTP server, and finally run the following two commands:

cd
rm -r /tmp/www-bench

VPN Tracker strictly follows Apple’s recommendation regarding where to place its files, so you will find VPN Tracker files only in standard system locations where they belong. Depending on the fact if these are system-wide or per-user files, they are either found in /Library (system-wide) or ~/Library (per-user), where ~ is a placeholder meaning "home of the current active user".

To access the system-wide library folder:

‣ In Finder Choose "Go" > "Go to Folder ..." 
‣ Enter /Library

To access the user library folder:

‣ In Finder Choose "Go" > "Go to Folder ..." 
‣ Enter ~/Library

Note: Some of these files may be currently loaded by the system, some of them also are cached. To get your system into a state as clean as if VPN Tracker was never installed on it, please restart your system after removing.