Troubleshooting VPN client connections

3rd Party Compatibility Notes

Hints / Suggestions

Answers in this category:
I am planning a site-to-site tunnel between two NetMAX VPN servers. What do I need to know?
How do I configure VPN Client Communications?
What Ethernet cards are compatible with the VPN Client?
Is it possible to block access to certain IP addresses and/or protocols over the VPN connection?
Why is my VPN Server performance slow?
What log files are created by the VPN server?
Where are the VPN-specific configuration files or prototypes?
Why is the server creating firewall rules by itself?
What Common console messages are related to VPN?
How do I configure the SafeNet SoftPK VPN client to connect to the NetMAX VPN Server?
How can I get the latest version of the SafeNet IRE client?
What are the different types of connections possible?
What new entries get added to /etc/crontab for VPN subsystems to function?
How do I get my VPN client to work from behind a NAT?

Answers in this category:
I'm having problems accessing the remote LAN through a VPN client connection. What's wrong?
When the client connects, Phase 1 completes, but Phase 2 is unsuccessful?

Ask the administrator of the server to verify this, or if you are the
administrator, follow these steps:

Access the NetMAX interface. Access "Home|Network|VPN|Options" Ensure that "VPN Enabled" is selected for all interfaces accepting connection requests.

If you are troubleshooting a Road Warrior connection:

        Ensure that "Road Warrior Included" is selected for all
        interfaces accepting connection requests, and that the          
        appropriate "Network" has "Road Warrior Access Enabled"
        selected.

If you are troubleshooting a Road Warrior connection:

        Access "Home|Users|Users".
        Click the pencil icon on the row of the user who is having
        difficulty making a connection .
        Click the "Password" tab.
        Ensure that "Enable Road Warrior Access" is selected.
        Note the "identity" of the user and reenter the "Passphrase" in
        the "New Passphrase" and "Confirmation" Boxes.
        Store and commit changes.
        Ensure that the user having difficulties has configured the client
        software with the proper identity, passphrase and connection settings.
        ( Please refer to the NetMAX VPN Suite User manual for configuration of
        Safenet / Soft-PK, Windows 2000, or NetMAX VPN Connecting as Road
        Warrior, or the included documentation for other products.)

If you are troubleshooting a non-Road Warrior connection:

        Review the settings for "Local Configuration" and "Remote Peer" on the
        NetMAX server/s, using the worksheet supplied with the VPN manual as a
        guide.
        Ensure that the user having difficulties has configured the client
        software with the proper connection settings.
        ( Please refer to the NetMAX VPN Suite User manual for configuration of
          Safenet / Soft-PK, Windows 2000, or NetMAX VPN, or the included
          documentation for other products.)

If you are still having difficulties after reviewing the configuration, determine if a firewall or other network access restriction is in place that would prevent the user from accessing the desired network.
Take action to remedy any such problems.

If you are STILL having difficulties, please contact NetMAX technical support.

address-suppressed

Please review the client software's Phase 2 settings, using the VPN Manual for NetMAX VPN clients, SafeNet Soft-PK, or Windows 2000, or the documentation provided with other VPN Clients.

For products other than those specifically supported by the NetMAX VPN Suite, check http://www.netmax.com/fom/fom.cgi?file=337 to ensure that the client software meets the requirements for communication with a NetMAX VPN server.

Answers in this category:
Can other Windows IPSec compliant VPN clients be used?
Is the NetMAX VPN Server Suite interoperable with Cisco PIX Secure Firewall?
Is the NetMAX VPN Server Suite interoperable with Checkpoint FW-1?
What programs are known to conflict with the NetMAX IRE client?
Why does Windows 2000 MTU settings cause problems with NetMAX VPN gateway communications?
Can the native IPSEC component in Windows 2000/XP connect as a VPN Road Warrior?

Please note that the document referred to by the link above is in PDF format.

Viewing PDF documents requires a PDF viewer, such as Adobe Acrobat Reader.
address-suppressed

Microsoft®'s NetMeeting
JGAA's War FTP Daemon
Windows(tm) 2000

It is possible that the NetMAX IRE SafeNet/Soft-PK VPN client will not work on Windows ME.

Most conflicts involve the method in which the NetMAX IRE client takes control of the tcpstack (winsock).

Some of these conflicts have been addressed in later versions of SafeNet's VPN Client. This client can now be purchased directly from SafeNet.
address-suppressed

Most encapsulated protocols will have an MTU that is smaller than 1500 because additional bytes must be added to each packet. IPSEC requires an MTU of 1480. When a NetMAX VPN Server Suite gateway and a Windows 2000 machine begin an IP conversation, MTU discovery should allow the Windows 2000 machine to lower it's MTU setting to the one offered by the NetMAX in the MTU Discovery negotiation.

Since the Windows 2000 machine is set to not perform this MTU negotiation, it will continue to send packets that are 1500 bytes. If the Windows 2000 machine sends a packet larger than 1480 bytes, the NetMAX will be unable to accept the packet and will report this with an ICMP message asking the Windows 2000 machine to fragment packets larger than 1480 bytes. Windows 2000 ignores these ICMP messages.

This problem can be worked around by enabling MTU discovery on your Windows 2000 machines by making a registry entry:

Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, create a DWORD value with the name "EnablePMTUDiscovery", and the value of "1".

Modifying your registry is considered advanced configuration for Windows 2000 users and can cause serious problems if done incorrectly. We will not be able to support this. This article is for information purposes only, and we can not recommend your modifying the default behavior of Windows 2000.
address-suppressed

The native IPSEC component in Windows 2000/XP only supports certificates for Road Warrior connections when using Microsoft's proprietary L2TP VPN protocol, which NetMAX does not support. This makes it unusable as a Road Warrior VPN client with NetMAX 4.x.

The Windows 2000/XP IPSEC component can support making a VPN connection to a NetMAX VPN Server Suite using Main Mode. Instructions are in the VPN Server Suite documentation.

If you would like to make a Road Warrior connection to a NetMAX VPN Server Suite using Windows 2000/XP, you will need a third party VPN client, such as SafeNET's SoftRemote.
address-suppressed

Answers in this category:
Why has telnet been disabled in the NetMAX VPN Server Suite?
How do I configure SSH for remote administration and shell logins?
Are there new VPN-specific entries in /proc?
Can I manually control the VPN Subsystem (Start, Stop, Restart) from the command-line?

1. Access the NetMAX interface (via web browser)
2. Access "Home|Users|Users"
3. Click the pencil icon in the row for the user to be permitted remote shell access.
4. Select "Unix Shell Login Enabled."
5. Store and commit changes.

You may have noticed that there are some entries under the /proc directory that
are not present in other NetMAX products.

Here are the VPN-specific entries and a brief explanation of each:

/proc/net/ipsec_eroute

Displays information about current VPN routes.

Example:

  99.1.1.1/32 -> 10.0.0.0/8 => tun0x3d10b014@99.1.2.1
  99.1.1.1/32 -> 99.1.2.1/32 => tun0xb6449669@99.1.2.1

"99.1.1.1/32 -> 10.0.0.0/8" means there is a connection
from a host 99.1.1.1 to a network 10.0.0.0.

It is known that "99.1.1.1" is a host because it is immediately
followed by a "/32" (The subnet mask which identifies a single host)

It is known that 10.0.0.0 is a network because it is not immediately
followed by a "/32"

"tun0x3d10b014@99.1.2.1" signifies that we are creating a tunnel with 99.1.2.1
as the gateway.

For additional details on interpreting the "0x3d10b014" part,
type 'man ipsec_spi' from the UNIX command line.


/proc/net/ipsec_klipsdebug

Specifies current debugging features and level for IPSEC communications.

Example:

  debug_tunnel=00000000.
  debug_netlink=00000000.
  debug_xform=00000000.
  debug_eroute=00000000.
  debug_spi=00000000.
  debug_radij=00000000.
  debug_esp=00000000.
  debug_ah=00000000.
  debug_rcv=00000000.
  debug_pfkey=00000000.

For additional information on interpreting this output,
type man ipsec_klipsdebug from the UNIX command line.


/proc/net/ipsec_spi

Contains detailed information about current security associations and
their configuration. Tells which hosts are involved in the connection,
how they are communicating, key lifetimes and more.

Example:

  tun0x8a649b6f@99.1.2.1 IPIP: dir=out 99.1.1.1 -> 99.1.2.1
  life(c,s,h)=add(206523,0,0)
  esp0x835890e@99.1.2.1 ESP_3DES_HMAC_SHA1: dir=out ooowin=16 seq=2 alen=160
  aklen=20 eklen=24
  life(c,s,h)=bytes(256,0,0)add(206452,0,0)use(206465,0,0)packets(2,0,0) idle=63
  esp0x8a649b6f@99.1.2.1 ESP_3DES_HMAC_SHA1: dir=out ooowin=16 alen=160
  aklen=20 eklen=24 life(c,s,h)=add(206523,0,0)
  tun0xdbf0ae23@99.1.1.1 IPIP: dir=in 99.1.2.1 -> 99.1.1.1
  life(c,s,h)=add(206523,0,0)

For additional details on interpreting this output,
type 'man ipsec_spi' from the UNIX command line.


/proc/net/ipsec_spigrp

Displays information about groups of security associations.
Similar to ipsec_spi.

Example:

  tun0x59905deb@192.245.33.149 esp0x59905deb@192.245.33.149
  tun0x5e400cfd@24.131.112.149 esp0x5e400cfd@24.131.112.149

For additional details on interpreting this output,
type 'man ipsec_spigrp' from the UNIX command line.


/proc/net/ipsec_spinew

Contains the next Security Parameters Index that will be used to negotiate
security associations.

This value will change every time it is accessed, to ensure unique
identification of new security associations.

Example:

0x1014


/proc/net/ipsec_tncfg

Displays information about which VPN "virtual" interfaces are associated
with which "real" interface.

Example:

  ipsec0 -> eth0 mtu=1480 -> 1500

In this example, the "virtual" interface ipsec0 is associated with the "real"
interface eth0. The "virtual" interface has been configured to have an mtu
value of 1480, while the "real" interface has an mtu of 1500.

For additional details on interpreting this output,
type 'man ipsec_tncfg' from the UNIX command line.


/proc/net/ipsec_version

Contains the current version of the IPSEC kernel patches running.

Example:

  FreeS/WAN version: 1.3

Applies to: NetMAX VPN Server Suite version 3.1 - 4.0x

We recommend that you control the VPN system through the NetMAX interface.  You may use the following information at your own risk.

The following scripts are present to control the VPN subsystem:

/usr/netmax/etc/rc.d/isakmpd.sh

Controls the operation of the Internet Key Exchange daemon.

This is the mechanism responsible for transporting and interpretting
authentication data.

Available commands are:

/usr/netmax/etc/rc.d/isakmpd.sh stop
  Stops the authentication mechanism

/usr/netmax/etc/rc.d/isakmpd.sh start
  Starts the authentication mechanism

/usr/netmax/etc/rc.d/isakmpd.sh restart
  Restarts the authentication mechanism


/etc/rc.d/init.d/ipsec

Controls the configuration of the "virtual" network interfaces
responsible for IPSEC communication.

This is the mechanism responsible for transporting and interpretting
encrypted communications across a VPN tunnel.

Available commands are:

/etc/rc.d/init.d/ipsec stop
  Disables IPSEC communication and "brings down" virtual interfaces.

/etc/rc.d/init.d/ipsec start
  Enables IPSEC communication and "brings up" virtual interfaces.

/etc/rc.d/init.d/ipsec restart
  Restarts IPSEC communication and "brings down" virtual interfaces,
  then brings them back up.

Does each NetMAX server have a static IP on the untrusted network through which the tunnel will be created, or does one or both have a dynamc IP?

        You will need to know this information to determine whether you will be
        creating a Road Warrior connection, or a non-Road Warrior connection.

If both servers have static IP addresses, what are they?

If one or both servers have dynamically assigned IP addresses, what is the identity that will be used to create the tunnel?

        The identity is in the form of "username@domainname" - where "username"
        is a user on the NetMAX receiving connections, and domainname is the
        primary domain of the NetMAX receiving connections.

Are there any network access restrictions (firewalls) in place on the NetMAX receiving connections?

        Firewalls can complicate the behavior and configuration of VPN tunnels.
        The presence of a firewall may require that the administrator of the
        NetMAX receiving connections specifically allow communications from the 
        NetMAX initiating connections, or that NAT be enabled for VPN
        communications.

Which network interface is designated as the "external" interface on each server?

Will the NetMAX server receiving connections allow VPN communication with hosts in it's own internal network/s, only the server itself, or both?

If the NetMAX server receiving connections will provide VPN communications with hosts in it's own internal network/s, what are the network IP and subnet mask for each internal network?

After you answer these questions, follow the steps in the manual for setting up your NetMAX VPN servers.

• ISAKMP (Phase 1) communication on UDPO port 500
• ISAKMP main mode configuration (for static IP connections)
• IPSEC (Phase 2) quick mode configuration
• Preshard secrets (passphrase)
• 3DES encryption
• SHA-1 or MD5 authentication
• Key exchange using Diffie-Hellman Group 2, 1024 bits
• Key lifetime of 540 seconds
• IPSEC key lifetime of 300 seconds
• ISAKMP aggressive mode configuration (for Road Warrior connections)

If you have an ethernet card that is having trouble with the SafeNet/Soft PK client, please send an email containing the make and model of the card to support@netmax.com for review.

address-suppressed

• Outdated hardware
• Improperly configured network settings
• Low bandwidth (oversaturated switches/routers, slow internet connection, etc...)
• System bottlenecks (Slow harddrive, High Resolution X Sessions, etc..)

• /var/log/messages
• /var/log/console.log
• /var/log/secure.*
• /var/log/auth.log

• /etc/isakmpd/isakmpd.conf
• /etc/ipsec.conf
• /usr/netmax/etc/vpnlogsurfer.conf

In order to facilitate VPN communications, NetMAX VPN Suite automatically
creates a few necessary firewall rules upon receiving a connection request.

When a connection is initiated, the NetMAX VPN server checks to see if
the connection is from a known client, or if this will be a Road Warrior
connection.

The server then checks in the appropriate configuration files to determine
if NAT should be enabled for the type of connection it is receiving.

If NAT is enabled for the connection being requested, the server
automatically creates the appropriate masquerading rule.

If NAT is not enabled for the connection being requested, the server
automatically creates the appropriate forward / accept rule for
the connection.

These rules are created because the default policy of the firewall is
to DENY communications. This policy ensures maximum security.

Consequently, specific exceptions need to be made to accomodate VPN
communications.

isakmpd: write (3, ...) failed: Device not configured

This message is indicative of the way isakmpd talks to the Linux kernel. This message is normal, may appear in your console messages on a regular basis, and is no cause for alarm.
address-suppressed

Multiple Network Interfaces Windows 2000 Configuration

To ensure connectivity of the NetMAX SafeNet/Soft-PK VPN client to a NetMAX VPN server, follow the following troubleshooting guidelines:

• Delete any non-working connections you have created and reconfigure them according to the manual. Keep in mind that it is very important to follow the manual EXACTLY as presented when setting up the client. The order of the steps is very important.
• In the dialog presented on the VPN server manual on page 67, ensure that Enable Replay Detection is NOT checked under Security Policy for each connection. This is an error not documented in the errata supplement of the VPN server manual.
• Make sure that the value for the Remote Network (page 73 of the manual, or item 10 on the configuration worksheet) represents the network address for a subnet, not an individual host. A network address is the first address in an IP range.(e.g. 192.168.2.0 given a netmask of 255.255.255.0)
• Verify that the value supplied for the Road Warrior Identity (item 8 on the worksheet and described on page 67 of the manual) matches what is assigned to the NetMAX server (page 29 of the VPN manual).
• Re-enter the pre-shared key (passphrase) for each connection.
• The NetMAX SafeNet VPN client is not compatible at this time with:

- Windows ME

- America Online (AOL)

Multiple network interfaces on NetMAX VPN client computer.

If you cannot connect your SafeNet VPN client to your NetMAX VPN server after trying the above guidelines the problem may be your computers' interfaces.

The SafeNet/Soft-PK VPN client cannot function properly if your Windows machine has more than one network interface (adapter). A network interface is considered any hardware which connects your computer to any kind of network.This includes all modems and all Network Interface Cards (An IR communications port will not cause any problems with the SafeNet VPN client.)

The problem and reason: Unable to connect VPN session remotely when the destination IP address of the server is the same network address of office LAN. User is able to connect to LAN through NIC card when connected locally. When the user takes his notebook outside the office and attempts to connect remotely to the same server's IP address on his local LAN- secure sessions are not possible. The user is also using fixed addresses on the NIC card. Cause: When the user is connecting remotely the notebook PC still thinks the server is local due to the address on the NIC card.

Resolution:There are two ways to work around this routing issue.

1. If the notebook has a PCMCIA card, remove the card when connecting remotely. This will remove the local address from the machine.
2. If the notebook does not have a removable PCMCIA card, then the user must configure hardware profiles. Hardware profiles are described in your Windows help.

An example for, creating a Dial-up only profile:

1. Open the System Properties dialog box.
2. Click the name of the profile you want to base the new hardware profile on, and then click Copy.
3. In To, type a name for the new hardware profile you want to create. Dial-Up.
4. Re-start Windows.
5. During boot-up, you are prompted to choose the hardware profile in which to start Windows. Select Dial-Up.
6. Open the System Properties dialog box at the Device Manager tab.
7. Click the plus sign next to the Network adapters.
8. Select properties for the NIC card that is present.
9. Under Device usage, select Disable this device from this hardware profile. Disabling the network card for the dial-up profile will essentially remove the NIC card from the machine and therefore the LAN network address.
10. Re-start window. Select Dial-up adapter profile when outside the office and Select Original configuration when inside the office.
11. Under Security Policy Editor, Change the connection for the secure connection to use the PPP adapter. Select My Identity- Internet Interface-PPP Adapter. This secure connection will only be active when a PPP session is established.

If you have more than one network interface in your windows machine you may choose one of these options:

1. You can create a hardware profile that has all except one network interface disabled.

Having two profiles enables you to switch between the VPN profile, with only one network interface enabled, and the default profile, with all network interfaces enabled. This way you will not have to reinstall your network interfaces when you wish to use more than one.

This option is recommended if you have an integrated network interface and use another for the VPN connection. For example if you have an integrated NIC and use a modem for the VPN connection.

2. You can physically remove all but one interface from your computer. This option is more feasible if you are using a computer that only uses a modem to connect and does not have an internal network. For example a laptop used on business trips.

Windows 2000 configuration.

In order for the SafeNet VPN client to work in Windows 2000 these guidelines must be followed.

1. The high encryption package must be installed.
• To do so click the Start button and select Windows Update.
• In the Windows Update browser click on product updates.
• Browse to and select for download the high encryption package.
• Click on download, read and accept any license agreements.
• Click yes to reboot your computer.
2. Any IPsec devices must be removed.
• Any IPsec devices that windows provides or other VPN software provides must be removed in order for the SafeNet client to properly install and run.
3. Network interfaces other than your internet connection interface must be removed from the system or another hardware profile must be created with other interfaces removed.
• In other words if your Windows 2000 system has a modem and a NIC and you use the NIC to connect to the internet the modem must be removed from the system or the hardware profile. For more information on this please see Mutiple network interfaces.
4. Other VPN software must not be running.
• If you have other VPN software installed on your Windows 2000 system it should be removed.
• It is possible to leave other VPN software installed, however all of it's components must not be running when the SafeNet client is installed or is run.
5. Do not install Safenet VPN adapter which provides support for L2TP and Virtual Adapter functionality.
• In the installation you are told not to install this feature. However you will still be asked if you would like to install this feature. DO NOT INSTALL IT!
• Choosing to install this will keep the SafeNet VPN client from working.

https://www.netmax.com/order/support/support.cgi

If you have a VPN license number registered, you'll be able to click on VIEW PRODUCTS, click on the product ID (NOT THE USER ID) next to the VPN Product, and download the current version of the SafeNet IRE client.

This is not an upgrade, but is the full program of the latest version. This is where we will be posting the latest versions as they come out so you will always be able to download the most current version from this area.

The first version released on CD with the VPN Server Suite was version 5.1.1 Build 2.

Update: NetMAX no longer has an OEM partnership with IRE/SafeNet and is no longer offering their VPN client software with its VPN Server Suite or seperately. We are also unable to offer further upgrades. If you wish to purchase the current version of the software, now called SoftRemote, please visit SafeNet's web site at www.safenet-inc.com.

Issues addressed in 5.1.3 Build 4:

Changing a policy selection from "secure" to "block" defaults to "IP Address".

Description: If a policy entry has IP Range or IP subnet as the ID Type set to secure, changing this to Block changes the ID Type to IP Address. Changing back to Secure leaves the entry at IP Address.

Changing policy entry from Block to Secure changes ID type.

Description: If a policy entry has IP Range or IP subnet as the ID Type set to Block, changing this to Secure changes the ID Type to Domain Name. Changing back to Block changes the entry to IP Address.

Connection Monitor data is incorrect when Secure Other Connections SA is established.

Description: When the Other Connections entry is set to Secure and an SA is established on that connection, the data presented for that SA in Connection Monitor is incorrect.

Soft-PK does not work with the Windows Me (Millennium Edition) Dial-up Adaptor.

Description: Hardware profile (Dial-Up only). Connect to the ISP, SPDedit shows the correct ISP address assigned to the PPP adapter, but no secure sessions are even attempted. "Winipcfg" shows the ISP's ip address assigned to the PPP adapter; but "ipconfig" shows the ISP's ip address assigned to Ethernet adapter 1, and Ethernet adapter 0 has no ip address.

L2TP adapter reports Error 10049 when attempting to add default route to LNS.

Description: When L2TP connection configured to use default gateway on remote network, the default route is not added. See message below. Interface added: 172.23.11.21/255.255.0.0 on L2TP "SafeNet_VPN". 08:08:13.622 Error sending to interface address: 10049.

Elements of distinguished name were limited to 50 characters.

Description: When entering the value for each element of the peer's distinguished name (e.g. Name=, Department=, etc.), the entry field was limited to 50 characters. This was found to be too short for some customers. Each field has been increased to 256 characters.

Adding default route to L2TP LNS fails when client is using DHCP.

Description: Adding default route to L2TP LNS fails when client is using DHCP. This makes L2TP useless if the "use remote default gateway" option is checked for the dial-up / l2tp connection. In the log viewer you see the message "unable to determine default gateway". Also when you first open the log viewer, the "interface added ..." line has an IP address but not a subnet mask.

Retrieved CA cert with SCEP properties should overwrite existing CA cert with no SCEP properties.

IPSEC sessions do not initiate over L2TP connection on WinMe.

Description: Client configuration is FIXED IP address on NIC with L2TP over Ethernet. L2TP interface gets added and route gets added when IREIKE dated 11/10/00 (NT 10049 fix) is used. IPSEC traffic does not initiate over the L2TP adapter.

L2TP interface lost logged in viewlog even though interface is still present.

Description: This problem only seems to occur against the Springtide L2TP gateway. Interface lost message is immediately logged after interface added even though the interface is there. ifaces, ifacelist and winipcfg show the address present. If Use DGW is checked as soon as interface is logged as being lost then route is removed. If L2TP over dial-up is being performed, then view log continuously logs interface added messages for bogus addresses (i.e. 0.0.0.38/0.0.0.0 on LAN, 129.97.174.204/0.0.0.0 on LAN even though I am using a hardware profile with Ethernet card disabled.).

Blue screen when attempting a new connection after an L2TP session.

Description: After a successful L2TP session an attempt to create an L2TP session results in Break Due to KeBugCheckEx (Unhandled kernel mode exception) Error A (IRQL_NOT_LESS_OR_EQUAL).

Dialup networking fails to respond if you disconnect an active L2TP session on WinNT and the system hangs on shut down.

Description: Dialup networking fails to respond if you disconnect an active L2TP session on WinNT and the system hangs on shut down.

IREIKE.EXE crash on Win95 o or Win95a.

Description: When ireike starts during boot up on Win95o or Win95A, it crashes due to missing functions in RAS. This could be avoided with an upgraded to DUN1.3.

CERTIFICATEISSUER entry corrupted on policy save.

Description: When saving a policy, all connections using certificates, whose My Identity page has not yet been visited, have their CERTIFICATEISSUER entry corrupted in the Registry.
address-suppressed

• Gateway - to - Gateway
• Gateway - to - Network
• Network - to - Network
• Road Warrior Client - to - Gateway
• Road Warrior Client - to - Network

The following entries are added to /etc/crontab in the NetMAX VPN Suite:

0       1       *       *       *       root    /usr/netmax/etc/rc.d/isakmpd.sh stop && /etc/rc.d/init.d/ipsec restart && /usr/netmax/etc/rc.d/isakmpd.sh start
# Check for connections that have expired.
*/6       *       *       *       *       root    /usr/netmax/bin/vpncleanup.pl

The first line restarts the VPN subsystems once a day at 1:00 a.m.

The other line checks for VPN connections that have expired and
cleans up the necessary firewall rules and network routes associated
with the expired connections.

General Howto for getting a VPN client to work from behind a NAT

This article describes one implementation of getting a VPN client to work behind a NAT gateway.
This is a source of confusion and frustration for a lot of folks, and we hope that this article will help get you moving forward.
Be forewarned, however, this article delves into some pretty arcane technical stuff that you may not understand.
Your mileage may vary.

Assumptions:

1. The router or machine which is acting as the Internet gateway for the VPN client either natively supports "VPN/IPSEC passthrough" or can be configured to pass VPN traffic through port forwarding.
2. The person following this procedure has a NetMAX-compatible VPN client installed on a system behind a NAT gateway.

If the gateway has native support for IPSEC passthrough, things just might work without making any changes at all.
However,some routers will require you to specify the host to which the VPN traffic should be passed.
If this is the case with yours, simply follow the manufacturer instructions and tell the router the proper host to redirect such traffic.
If, however, your gateway does not have native support for IPSEC passthrough, you can accomplish the same thing using traffic filtering and redirection.
The first step is to set up traffic rerouting to send UDP traffic destined for the external IP address of the NAT gateway on port 500 to the internal machine.
In NetMAX, this is accomplished under HOME|Network|Routing|Reroute.
Included below are the guidelines for creating the necessary rules on the external interface of the firewall.
They are set up for a NetMAX, but can easily be adapted for most firewalls.

    Direction:   Input
    Action:      Allow
    Source:      Any
      Protocol:    UDP
      Port:        500
    Destination: IP of this NetMAX
      Protocol:    UDP
      Port: 500

    Direction:   Output
    Action:      Allow
    Source:      IP of this NetMAX
      Protocol:    UDP
      Port:        500
    Destination: Any
      Protocol:    UDP
      Port: 500

    Direction:   Forward
    Action:      Allow
    Source:      Any
      Protocol:    ESP
    Destination: Any
      Protocol:    ESP