There are a number of possible causes for such a behavior. This FAQ will help you to find out what is causing the problem in your specific situation. In this FAQ we will be using destination device as a generic term for the device you are trying to connect to. The destination device can be anything from a normal computer, to a server, to a network printer.

1. Are you trying to connect to the destination device using a host name?

If you are using a host name, please try once using its IP address instead. If that works, the problem has to do with DNS resolution. Please make sure DNS is enabled for the VPN connection and correctly configured. Note that using Bonjour or NETBIOS hostnames is generally not possible over VPN.

2. Is the IP address you are connecting to really part of the remote network?

For example, if your remote network is 192.168.13.0/24, you should be able to connect to IPs starting with 192.168.13.x, but connections to IPs starting with 192.168.14.x will not work as they are outside the address range of traffic tunneled through the VPN.

3. Is the local address in VPN Tracker part of the remote network?

Using a local address in VPN Tracker (Basic > Local Address) that is part of the remote network is not possible with most VPN gateways. Please use a local address that is outside all remote networks. For example, if your remote network is 192.168.13.0/24, do not use an address starting with 192.168.13. If you are using an automatic configuration method (e.g. Mode Config, EasyVPN, DHCP over VPN) you may be able to assign a local address to VPN Tracker that is part of the remote network. Refer to the configuration guide for your VPN gateway for more information.

4. Could multiple VPN users use the same local address?

If multiple VPN users exist, pleas make sure no two users are using the same local address (Basic > Local Address), otherwise one of them will not be able to use the tunnel anymore whenever both of them are connected. If that field is empty in your configuration, VPN Tracker will just use the IP address of your primary network interface as local address, and of course, this can also cause an address conflict with another user, that’s why we do not recommend to leave that field empty if there are multiple VPN users.

5. Can you ping the LAN address of the VPN gateway?

You can find a ping tool directly in VPN Tracker under Tools > Ping Host. The LAN address of the VPN gateway is special in the regard that this address doesn’t need to be routed at all. So if you can ping that address but no other remote address, it is most likely a routing issue at the remote end.

6. If you can't ping anything, try re-running the VPN Availability Test

The VPN Availability Test can be found in the menu: Tools > VPN Availability Test. Then try connecting the VPN again. The results of this test depend on the capabilities of your local Internet router/modem or the Internet connection itself and they influence how the VPN tunnel is established. VPN Tracker automatically runs the test for every new Internet connection it is able to detect but even if a connection has been tested before, there are various reasons why the behavior of that connection may have changed in the meantime.

7. Is your VPN gateway the default gateway (router) of its network?

If the VPN gateway is not the default gateway, you will in many cases need a suitable routing setup in order for responses to reach you. Whenever a device doesn’t know how to reach an IP address directly, it forwards its reply to its default gateway and if that isn’t the VPN gateway, it won’t know what to do with that reply data. In that case its important to configure the default gateway to forward replies to VPN users to the VPN gateway.

8. Is your VPN gateway the default gateway (router) of its network?

For more details, we would like to direct you to the following FAQ entry.

Configuring the Pre-Shared Key for a new VPN connection

I have lost my Pre-Shared Key - how can I get it back?

1. Check if you have stored the affected connection in your Personal Safe. If so, you may be able to download the connection again.
2. Check the Keychain (Applications > Utilities > Keychain Access). The Pre-Shared Key is usually saved here. Enter "Shared Secret" into the search bar to view a list of all your saved PSKs.
3. Are you using Time Machine Backup? You could try restoring an older connection with the Pre-Shared-Key.
4. Check your firewall or ask the relevant VPN Administrator. Refer to your device handbook to find out where to obtain this information on your specific firewall.

• If you haven't already, you can download VPN Tracker using this link.
• After the download has completed, launch the app and click the "Login" button in the top left-hand corner of the app home page.
• Enter your equinux ID and password in the space provided. Hint: This is the login you first created when purchasing VPN Tracker in our online store.

Are you a World Connect User?

You will need to download VPN tracker World Connect. You can do so using this link. VPN Tracker World Connect must be installed using the App Store. Once you've installed the app on your device, sign in with your equinux ID and password.

There are multiple passwords that VPN Tracker may require: Your admin password for installation, passwords needed for connecting to your VPN or accessing your Keychain, etc.

This guide shows all password prompts you may encounter in VPN Tracker, explains why they are needed and lets you know which password should be entered.

Administrator password prompts

VPN Tracker will occasionally require you to enter an administrator password - for example during the macOS installation process in order to approve the System Extension needed to allow VPN Tracker to work effectively.

Account + licensing

To log in to VPN Tracker on Mac or iOS, or to log in to your account on my.vpntracker.com, you will need to enter your equinux ID and password. This password gives you access to your VPN Tracker account where your plan, team data, connections and device information is stored.

Pre-Shared Key

Many VPN connections are secured using a Pre-Shared Key (PSK) or Shared Secret which is set on the VPN gateway during the configuration process. You need to enter the PSK in VPN Tracker in order to connect to your VPN.

If you are not the administrator of your VPN gateway, contact the admin for assistance. Tip: Admins can share pre-configured VPN connections using TeamCloud to avoid PSK confusion at enduser level.

Extended Authentication (XAUTH)

Most VPNs have a list of permitted VPN users - e.g. members of staff. Each VPN user has their own unique username and password which they need to enter in order to connect to the VPN. These are often the same credentials you use to sign in at the office. If you're not sure, get in touch with your admin who can advise you further.

After upgrading to macOS 15 Sequoia, you might notice that your Mac constantly changes its MAC address, affecting your ability to connect to your VPN. This behavior is due to macOS 15’s new privacy features, which can assign randomized MAC addresses for network connections. However, you can configure your network settings to always use a fixed MAC address, which can resolve issues with VPN connectivity, such as DHCP reservations failing due to MAC address changes.

How to Set a Fixed MAC Address in macOS 15 (Sequoia):

1. Open System Settings:
   • Click the Apple logo in the top-left corner of your screen.
   • Select System Settings from the dropdown menu.
2. Go to Wi-Fi Settings:
   • In the left sidebar, click Wi-Fi.
   • Select the Wi-Fi network you usually connect to for VPN access and click on "Details...".
3. Configure the MAC Address:
   • Look for the option labeled Private Wi-Fi Address.
   • Change this option to "Fixed" to use a fixed MAC address instead of a randomized one.
   In some cases, the Fixed Setting may still cause issues. If this is the case, change the setting to "Off"
   
   • Your network will now always connect using the same MAC address, helping maintain your VPN connection stability.
4. Re-establish VPN Tracker Connection:
   • Once you've set a fixed MAC address, ensure that your VPN’s DHCP reservation or configuration aligns with this MAC address.

This process will restore the VPN Tracker’s ability to connect reliably using a consistent MAC address, resolving issues caused by macOS 15 Sequoia’s default MAC address randomization feature.

‣Open System Preferences

‣Go to Security

‣Click "Allow"

• Private IP Addresses, and
• Public IP Addresses

• 192.168.0.x, and
• 192.168.1.x

1. Change your local network to a different range (Preferred)

   
   Possible Ranges are:
   
   • 10.250.250.x
   • 172.30.30.x
   • 192.168.250.x
   
   Advantage: Once you have made this change on your home network, you will never have conflicts in this network.
   Disadvantage: You will need to change the settings on your private network router once, this requires access and can take some time.
   What to do:
   
   • Login to your home router
   • Find the setup section with “DHCP” settings.
   • Change your router to a different IP adress (for example an address from one of the ranges listed above, for example 172.30.30.1)
   • Change the DHCP Server Settings to the same range of your router (If your router IP is 172.30.30.1, your range could be 172.30.30.10 to 172.30.30.253)
   
   After you have made these changes, there will be no more conflicts between your home and company network.

2. Force Traffic over VPN

   
   There may be situations where it's not possible to use the first option (for example if you're in a coffee shop or hotel) In this case you have the option to force the traffic over your VPN Network, this means your VPN Network (company network) will always win.
   Advantage: This setting is global, meaning no matter what network you are in you will always be able to connect.
   Disadvantage: Once you are connected to your company’s VPN, you can not access local service, like home router, local storages or printers.
   What to do:
   
   • Configure your VPN Tracker connection
   • Select the "Advanced" Tab at the top
   • In the "Traffic control" section, activate the Checkbox "Force traffic over the VPN if remote networks conflict with local networks"
   
   

Download VPN Tracker free

VPN Tracker automatically stores a backup of all your VPN connections on your Mac. If you have inadvertently deleted a connection, or wish to revert to an earlier copy of a connection, you can manually restore the backup copy.

1. Turn off Personal Safe syncing

You need to deactivate Personal Safe for the connections you're trying to restore from your backup, to prevent unwanted changes being synced:

• Open VPN Tracker 365
• From the menu bar, choose: VPN Tracker 365 > Preferences > Personal Safe
• Uncheck the connections you want to restore from your backup
• Quit VPN Tracker 365

2. Restore from your Backup

• Open Finder and choose "Go" > "Go to Folder…" from the menu bar
• Enter this path and press Return:
  /Library/Application Support/VPN Tracker 365
• Rename your "etc" folder to "etc-backup" – for safekeeping
• Go into the "backup" folder

Here you'll see a number of backup folders, all organized and named by date.

• Move the "etc-date" folder you want to restore up one level into the main "VPN Tracker 365" folder
• Rename the folder your just moved to just "etc" (deleting the date)
• Open VPN Tracker 365

All of your connections will now be restored to their backed-up state.

3. Re-activate Personal Safe

• Choose: VPN Tracker 365 > Preferences > Personal Safe from the menu bar
• Check your connections, to add them to Personal Safe

Download VPN Tracker free

IPsec VPN uses a different protocol (ESP) for the actual data transfer than for establishing the connection (IKE). Since the ESP protocol does not use network ports, NAT (Network Address Translation) routers may have difficulties handling it correctly. Only NAT routers that support "IPSec Passthrough" (sometimes also named "VPN Passthrough" or "ESP Passtrhough") and where this option is also enabled, can handle ESP data packets.

To work around this problem, two alternative tunneling methods exist:

• NAT-Traversal (old, RFC draft version)
• NAT-Traversal (new, RFC standard version)

Which of these methods will work with your connection depends on two properties:

1. Which of these methods allows traffic to pass through your local Internet router.
2. Which of these methods are supported by your VPN remote gateway.

To test for the first property, VPN Tracker will automatically establish three VPN test connections to a VPN gateway hosted by us whenever it detects a new router that has not been tested before. One connection uses plain ESP, the other two either NAT-T method mentioned above. It will remember the test results for this router and take them into account whenever you start a connection from the network location. The reason we are testing with our own gateway is simply that the test requires a gateway supporting all three methods, with a known configuration and a simply way to verify if traffic did arrive at that gateway.

The second property is not tested in advance, VPN Tracker will become aware of that information when it actually tries to connect to your VPN gateway. VPN Tracker will compare the methods your gateway supports with the stored test results. If there is a match, a method that your gateway supports and that was also working during the test, this method will be used. If there is no match, VPN Tracker will immediately stop and show an appropriate error in the log, explaining the situation.

If you suspect a NAT-Traversal issue or you think the previous test results may be wrong or outdated, simply re-run the test:

‣ Make sure NAT-Traversal (Advanced tab) is set to Automatic
‣ Go to "Tools" > "Test VPN Availability"
‣ Click "Test Again"
‣ Wait until the test has completed, then connect to your VPN

The test dialog also allows you to tell VPN Tracker to not test the current location and forget any previously created test results. This is rarely needed and also not recommended but there might be situation where the test results are wrong because access to our VPN gateway is not possible (e.g. it is blocked) and thus the test result are just bogus and say nothing about the true capabilities of your VPN gateway.

Such a setup is called “Host to Everywhere” in VPN Tracker. All non-local traffic will be sent through the VPN. For this setup to work, it must be properly configured in VPN Tracker and on the VPN gateway:

1. The Network Topology must be set to “Host to Everywhere” in VPN Tracker
2. The VPN gateway must accept an incoming VPN connection with a 0.0.0.0/0 (= everywhere) endpoint

Once these are configured, it should already be possible to establish the VPN connection. However, it is very likely that Internet access will not yet work. For Internet access to work, several more things need to be configured on the VPN gateway:

1. The VPN gateway must route VPN traffic not destined for its local networks out on the Internet
2. This traffic must be subject to Network Address Translation (NAT) in order for replies to reach the VPN gateway
3. In many cases, a suitable remote DNS setup is necessary for DNS resolution to continue to work

Note that not alll VPN gateways can be configured for Host to Everywhere connections. Most devices designed for small office or home networks (e.g. devices by NETGEAR or Linksys) are not capable of dealing with Host to Everywhere connections.

• Download VPN Tracker for Mac or iPhone
• Copy your VPN connection details from the AnyConnect app
• Connect and enter your username and password when asked

1. Start your VPN connection in VPN Tracker
2. Go to the Finder > Go To >Connect to Server
3. In the Server Address field, enter the name or IP address of the server you want to connect to
4. Click on the Connect button.

Create a VPN Shortcut:

Once you have decided which product to purchase, the next step is to proceed to our Online Store and place your order. We accept all major credit cards, PayPal and bank transfers or checks, depending on your country.

After your order has been processed you will receive a confirmation for your purchase. This will confirm the items purchased, and additional payment instructions if you're paying via bank transfer or check (in those cases you will also receive an additonal email confirming your payment when it has been processed.)

In the purchase confirmation email you will also receive additional information like the download links for your purchased apps.

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.

Purchasing through our online store is perfectly safe. All transferred information is encrypted via HTTPS - so it is secured against any potential threats.

If you have entered information or have started to apply settings in your application demo, those changes will remain unchanged - even after activating the software.

A couple of years ago, a team of security experts released a paper describing an attack that can break an IKEv1 Aggressive Mode Pre-Shared Key connection using an attack that would not equally have been possible with an IKEv1 Main Mode Pre-Shared Key connection, leading to the incorrect assumption that Aggressive Mode is inherently insecure. This claim, however, is not backed up by objective facts. What most people don't know, part of that attack was the ability to guess the Pre-Shared Key (PSK) using a brute force attack and such a brute force attack can only be successful if the PSK is weak. A PSK is also just a password and as with every password, choosing a weak password always leads to poor security. As long as your PSK is at least 14 characters long (the longer the better), consists out of lower case letters, upper case letters and digits, and was randomly generated, so it's impossible to somehow guess it, and as long as your Phase 1 hash algorithm is at least SHA1 (or better, we recommend SHA-256 if possible), there's absolutely no reason to consider IKEv1 Aggressive Mode with Pre-Shared Key as less secure than IKEv1 Main Mode with Pre-Shared Key. If you want to be even more secure, switch to certificate based authentication instead of PSK if possible as then the attack is not possible at all.

Technical background:

The Pre-Shared Key (PSK) is not a password used for encryption of any data, it's used for authentication, just when you log in to a website using a username and a password. During Phase 1, both sides must prove to each other to know the PSK. This cannot be done by just sending it to the other side, as if the other side didn't know it before, it will know it after receiving it. Instead both sides calculate a number (a hash digest) out of data they exchanged so far (data that will be different every time you start a new connection, which ensures the calculated value will be as well) and the PSK. Only this digest is send to other side. The other side can now verify that digest by performing the same calculations and comparing the result with the digest received. If both are equal, the sender must have used the same PSK in the calculation, which proves knowledge of the PSK. Then the receiver also calculates such a digest, using a slightly different formula as before, leading to an entirely different result, and sends it back in reply to also prove its knowledge.

The differences between Main Mode and Aggressive Mode is simply that in Main Mode the digest is exchanged encrypted because the session key exchange already negotiated a session encryption key when the digest is exchanged, whereas in Aggressive Mode it is exchanged unencrypted as part of the key exchange that will lead to a session key. By snooping the connection establishment of an Aggressive Mode connection, the attackers were able to get the digest as well as all values required to calculate that digest, except for the PSK itself. Please note that this alone doesn't mean the connection is broken already, it only means that the attackers now have enough data to start guessing the PSK using a brute force or dictionary attack. Only if the PSK is too weak to withstand those attacks and the attackers are able to correctly guess it, the connection will be broken. That's why a good, secure PSK is essential.

The same attack is in fact also possible with a Main Mode PSK connection, it just requires some extra work. For a Main Mode connection it's not enough to just snoop the traffic, the attackers would need to perform a so called Man-in-the-Middle (MitM) attack, allowing them to capture and manipulate all traffic exchanged. By performing a MitM attack, attackers can break the key exchange and thus will be able to decrypt all the exchanged packets. Doing so will not make it possible to break into your VPN, they still need to know the PSK for that, otherwise they cannot successfully authenticate to the other side and then Phase 1 will never complete, but that way they can get all the information required to start guessing on the PSK, just as in case of a an Aggressive Mode connection. And if an attacker is already able to snoop on your VPN traffic (which is required to attack Aggressive Mode), it's very likely that attacker is equally possible to perform a MitM attack and in that case using Main Mode will not offer you any additional protection.

A PSK out of 11 random alphanumeric characters offers an entropy of approx. 64 bits, that's 2^64 possible values. Modern high end graphics adapter (as of 2015) can calculate in the order of 1 billion SHA-256 hashes a second. On average one has to try 50% of all possible values to find a match, wich would be about 292 years. Yet if the attackers have an array of 100 such graphics adapters, it would "only" be around 3 years. If the PSK is 14 characters, the entropy is about 80 bits and you are already at 19,154,798 years. Now even having 10,000 graphics adapters would help a lot. Also one must consider the costs of such an attack, which is not so much the cost of buying all these graphics adapters, rather their power consumption when all these graphics adapters run at maximum current 24 hours a day and that for years, decades, or even centuries. The power costs will be billions of dollar and all that to just break one single PSK connection in the entire world. And whenever you change the PSK, an attacker must start all over, so if you change the PSK regularly, let's say once a year, an attacker has at most one year to find it; that's very ambitious, even for a weak PSK.