Depending on the vendor your company uses, the location from which you’re trying to establish a
VPN connection, and other factors, a user could come up with a hundred different possible issues
with authenticating to a VPN. Here are some areas to look at first regarding the stability of a VPN
connection.
One of the first things to do when troubleshooting a VPN session timeout or lockout issues is to determine the user’s location. It’s important because if a user can always connect while he or she is at home, but can never connect on an open Wi-Fi connection at the local coffee house, that should enable isolation of the issue quickly. This is one of the simplest forms of VPN troubleshooting, but can save a lot of time during the process.
Another way to start determining the root cause of the VPN issue is to ask the user to connect to the VPN both on the WLAN and the wired LAN. The majority of VPN connections these days are connected wirelessly. In the past, I’ve noticed certain vendor agents are less tolerant of network loss due to the poor strength of a Wi-Fi connection, which could result in VPN stability issues. If a user is able to connect via the wired LAN without any issues, but has an issue periodically with the WLAN, start troubleshooting the agent logs and the origin of the logon attempts with an eye toward wireless-related issues.
There’s also the issue of timeout periods for users. I’ve seen many default values around timeouts, such as idle connections after 10 minutes, and a max session at 60 minutes with a reminder of five minutes before timeout. This might not suit all users, so these values could be reworked to fit the needs of the company and user population. This could be an issue where the defaults are too low for what the user needs the session for; this is especially true in SSL VPNs.
When using IPSec, verify the connection settings of your phase 1 and phase 2 rekey policies. The phase 1 policy will be able to go down without an issue and rekey, but if your phase 1 and phase 2 timers go down at the same time, there’s the potential for a timeout or longer connection time.
Read the rest of my article for searchsecurity.techtarget.com here.
One of the first things to do when troubleshooting a VPN session timeout or lockout issues is to determine the user’s location. It’s important because if a user can always connect while he or she is at home, but can never connect on an open Wi-Fi connection at the local coffee house, that should enable isolation of the issue quickly. This is one of the simplest forms of VPN troubleshooting, but can save a lot of time during the process.
Another way to start determining the root cause of the VPN issue is to ask the user to connect to the VPN both on the WLAN and the wired LAN. The majority of VPN connections these days are connected wirelessly. In the past, I’ve noticed certain vendor agents are less tolerant of network loss due to the poor strength of a Wi-Fi connection, which could result in VPN stability issues. If a user is able to connect via the wired LAN without any issues, but has an issue periodically with the WLAN, start troubleshooting the agent logs and the origin of the logon attempts with an eye toward wireless-related issues.
There’s also the issue of timeout periods for users. I’ve seen many default values around timeouts, such as idle connections after 10 minutes, and a max session at 60 minutes with a reminder of five minutes before timeout. This might not suit all users, so these values could be reworked to fit the needs of the company and user population. This could be an issue where the defaults are too low for what the user needs the session for; this is especially true in SSL VPNs.
When using IPSec, verify the connection settings of your phase 1 and phase 2 rekey policies. The phase 1 policy will be able to go down without an issue and rekey, but if your phase 1 and phase 2 timers go down at the same time, there’s the potential for a timeout or longer connection time.
Read the rest of my article for searchsecurity.techtarget.com here.