Troubleshooting SSL VPN Configuration 109novdocx (en) 16 April 2010A.19 SSL VPN Full Tunnel ConnectionDisconnects on VMwarePossible Cause: An SSL VPN full tunnel connection might disconnect because of no keepaliveresponse if the Novell Access Manager setup is on a host-only network, on a VMware interface ofthe client.Explanation: After full tunnel is enabled, a new route entry is added to the client routing table toroute the keepalive packet to the SSL VPN server through the default gateway. Because the SSLVPN gateway is on a host-only network on a VMware, the keepalive packet might not reach the SSLVPN server through the default gateway.Action:1 Add a virtual address to the SSL VPN gateway.For example, if the primary address is 200.200.200.140, add 200.200.200.141.2 Disconnect the physical network from the client to make sure that there is no default gateway tothe Internet.3 Manually add a default route.For example, route add 0.0.0.0 mask 0.0.0.0 200.200.200.141 metric 5.A.20 Clustering Issues Section A.20.1, “Bringing Up the Server If a Cluster Member Is Down,” on page 109 Section A.20.2, “Bringing Up a Binary If It Is Down,” on page 109 Section A.20.3, “Debugging a Cluster If Session Sharing Doesn’t Properly Happen,” onpage 110A.20.1 Bringing Up the Server If a Cluster Member Is DownAction: Check the Administration Console for the component that is down in the cluster member. Ifthe component is openvpn, stunnel, or sockd, restart SSL VPN by using the following command:/etc/init.d/novell-sslvpn restartYou can check for the status by using the following command:/etc/init.d/novell-sslvpn statusA.20.2 Bringing Up a Binary If It Is DownAction: If the openvpn, stunnel, or sockd binaries are not running:1 Stop the server by using the following command:/etc/init.d/novell-sslvpn stop2 Use the ps command to check whether the openvpn, stunnel, and sockd binaries are stillrunning.If the binaries are running, kill the processes and start the server.