The OnDemand Tunnel agent starts automatically after users successfully authenticate to WorkPlace, if the community supports the OnDemand Tunnel agent.

The provisioned Connect Tunnel client requires you to activate it each time you want to begin a tunnel session. Tunnel sessions can remain active for many hours. Interrupting network connectivity for periods of more than a few seconds causes the tunnel session to end. Interruptions occur, for example, when a network cable is disconnected, a laptop is set to sleep, or the network link is so busy that it has high latencies and packet drop rates.

The following describes common failures that can prevent a Connect Tunnel client or OnDemand Tunnel agent connection from succeeding:

• Appliance is unreachable: In the Connect Tunnel login box, click Properties. In the Properties box, under Login group, click Change. If the appliance is reachable over the network, the Select or enter your login box will be populated with a list of available realms. If the appliance is not reachable, after a few moments you will see an error message that reads “The remote network connection has timed out.”
• Incorrect appliance address specified: In the Connect login box, click Properties. In the Properties box, ensure that the Host name or IP address of your VPN is correct. If a host name is entered instead of an IP address, ensure that the client can resolve the host name, and that the host name corresponds to the IP address of the appliance’s external interface.

• Appliance is not running: Ensure that the appliance is running.

• Invalid realm for user name: Ensure that a valid realm is configured for the user.

• Authentication failure: Ensure that the user has specified the correct authentication credentials.

• Client service failure: Retrieve the client log (ngsetup.log), and send the log file to SonicWall for analysis along with a description of the situation.

• Personal firewall is not permitting tunnel traffic: Ensure that the user’s firewall is configured to allow connections to the appliance’s FQDN or IP address.

When a tunnel is established, an icon representing that tunnel appears in the taskbar notification area. At this point the client computer has access to all configured resources the appliance can reach and for which the user is authorized. If the client cannot reach a resource, the following may explain the issue or offer a solution:

• Resource not defined: Ensure that the correct resource is defined in AMC.

• User not authorized to access resource: In AMC, review access control rules, and realm and community assignments, to ensure that the user is allowed to access the resource.

• Appliance routing cannot reach resource: Ensure that there isn’t a general networking problem between the appliance and back-end resources.

• Server software failure: Note the time of the failure, determine whether the network tunnel service is functioning properly, and gather further troubleshooting information if necessary.

Once connected, a Connect Tunnel or OnDemand Tunnel connection should remain active for many hours. However, the tunnel can end prematurely for several reasons. If a tunnel connection disconnects unexpectedly, the following may explain the issue or offer a solution:

• Tunnel that was left idle timed out: To conserve appliance resources, idle tunnels can disconnect after an extended period of time.

• Administrator stopped or restarted the network tunnel service: Normal configuration operations using AMC should not affect established tunnels; they continue to operate under the configuration that was in effect when they were established. However, configuration changes that affect basic appliance networking will cause existing tunnels to drop or hang, possibly requiring a disconnect at the client to recover.

• With the network tunnel service logs set to Info level or higher, the message, Reset Internal Interface and Addressing Information, appears in the log any time the network tunnel service is stopped; in addition, the message, Internal Interface eth0 Address n.n.n.n Netmask n.n.n.n BCastAddr n.n.n.n Subnet n.n.n.n (with appropriate IP addressing values), appears any time the service is started from a stopped condition. In the ngutil log, the text, The server is shutting down, identifies this situation.

• Internetwork carrying tunnel became unresponsive or unreliable: When traffic fills the available bandwidth on any hop between the client and the appliance, packets wait on queues in the end-point TCP stack or in intermediate routers. When queues fill, packets are dropped.

• The network tunnel service carries traffic over a TCP SSL connection. TCP is designed to accept network unreliability by delivering traffic only when it is in sequence, it can be verified, and it is available. TCP implementations can drop connections when ACK responses are not returned soon enough; this is true of the Windows TCP implementation. After the connection drops, the tunnel client’s normal behavior is to attempt to resume the connection transparently for 20 seconds. If congestion caused the drop, resumption is likely to fail, and the user sees the tunnel terminate.

• Cluster failover occurred, and client’s resumption failed: In a cluster configuration, when an active node fails over to the standby node, client connections are preserved by the client tunnel resumption mechanism. Clients will continue tunnel resumption attempts for 20 seconds, and then give up; if the failover is not complete within this time the tunnel connection is dropped. On orderly termination the client does not attempt resumption, so all tunnel connections are dropped.

• In addition, a new client connection initiated after failover, but during the period in which tunnel clients are attempting resumption, might be assigned an address that an existing client is trying to resume using. Several characteristics of address assignment make this case unlikely, but if it occurs the resuming client’s tunnel is dropped.

• Client service failure: Failure of the client service software can cause the tunnel to drop, and an error box to appear. Retrieve the client log, send the log file to SonicWall for analysis along with a description of the situation, and then restart the service.

• Server software failure: Failure of the appliance tunnel software generally causes a spontaneous reboot of the appliance, or possibly an indefinite hang.

• In the reboot case, a crash dump appears in a numbered directory in /var/log/dump; retrieve and analyze this information.

• If the appliance hangs without rebooting, the crash dump may have succeeded before the hang; reboot the appliance and check /var/log/dump for a new crash dump, and then retrieve and analyze this information. You may need to reproduce the circumstances that led to the crash.