|Client does not
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.
|Client connects, but
cannot access a
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.
|Client connects, but
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 connects, but
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.
problems||Tunnel problems typically show up at the client first. Many possible problems can be
identified only by an administrator in AMC or, sometimes, at an SSH console or the
system serial console. For more information, see General Networking Issues.|
|Network tunnel service
is not running|
At the serial console or in an SSH session, type:
If the network tunnel service is configured and running, client virtual address range
information will appear. Otherwise, nothing will appear except another shell prompt.
The following items can help you determine why the network tunnel service is not
License invalid or expired: If your appliance license is invalid, AMC displays a license warning at the top- right corner of every AMC page after login. You may need to contact SonicWall to resolve licensing issues.
Stopped in AMC or from console prompt: In the Network Tunnel Service area of the AMC Services page, you can stop the network tunnel service indefinitely, and you can view information that indicates whether the service has been stopped.
Service unconfigured, or incorrectly configured: The network tunnel service must be configured with virtual addresses and related information for assignment to clients. If tunnel service configuration is incomplete, the service will not run.
Server software failure: A failure of a userspace network tunnel service component will generally cause the failed component to restart. There may be helpful information in the log or in a corefile in
/var/log/core. Serious failure of a kernel component will likely result in a crash dump.
Cluster issues: Clustered appliances must be able to communicate over their cluster interfaces. If they cannot communicate reliably, both nodes in the pair may attempt to provide service, resulting in failures, or both nodes may be on standby, so that neither is providing service.