azpete
asked on
Sonicwall Site to Site VPN ( 28,800 second Lifetime default)
I have a two offices connected by a Site to Site SonicWall TZ 300's ( great products)
I have setup many VPN tunnels before and I think I simply followed the VPN wizard this time to set them up and all seemed well.
We have approx 5 users at the remote office that login to a Windows Database Server ( they use remote desktop) at the main office and about once a day they report the "computers" slow or stop "talking" to the Server for a minute or so.
this was Frustrating to the users and I finally started looking deeply for an answer.
I looked at the Server logs for errors that matched the time of these problems and at the Cable connection logs, and everything I could think of but nothing seemed to match UNTIL I LOOKED AT THE SonicWall LOGS and found that every 8 hours ( 28,800 seconds) the VPN tunnel re-estatblished the Security ( SA - Lifetime) and it is SET to do that default ! ( I shook my head both in shame and incredulity at that) According to SonicWall's Help page
QUOTE: ........every time the VPN tunnel renegotiates, users accessing remote resources are disconnected. Therefore, the default SA Life Time of 28,800 seconds (8 hours) is recommended.
I contacted Support and received the following answer
QUOTE You can enter "9999....." until the box for the lifetime can take it. That should be the "forever" configuration for the VPN policy. This has to be done on both ends.
I just wanted to run this by our Experts to see what I am missing here....I realize that security is needed but if the "Lifetime" is not timed to when USERS are not going to be affected, it seems like this might be a problem for lots of folks...
Just looking for comments and opinions
THANKS
I have setup many VPN tunnels before and I think I simply followed the VPN wizard this time to set them up and all seemed well.
We have approx 5 users at the remote office that login to a Windows Database Server ( they use remote desktop) at the main office and about once a day they report the "computers" slow or stop "talking" to the Server for a minute or so.
this was Frustrating to the users and I finally started looking deeply for an answer.
I looked at the Server logs for errors that matched the time of these problems and at the Cable connection logs, and everything I could think of but nothing seemed to match UNTIL I LOOKED AT THE SonicWall LOGS and found that every 8 hours ( 28,800 seconds) the VPN tunnel re-estatblished the Security ( SA - Lifetime) and it is SET to do that default ! ( I shook my head both in shame and incredulity at that) According to SonicWall's Help page
QUOTE: ........every time the VPN tunnel renegotiates, users accessing remote resources are disconnected. Therefore, the default SA Life Time of 28,800 seconds (8 hours) is recommended.
I contacted Support and received the following answer
QUOTE You can enter "9999....." until the box for the lifetime can take it. That should be the "forever" configuration for the VPN policy. This has to be done on both ends.
I just wanted to run this by our Experts to see what I am missing here....I realize that security is needed but if the "Lifetime" is not timed to when USERS are not going to be affected, it seems like this might be a problem for lots of folks...
Just looking for comments and opinions
THANKS
John
I think that must be unique to Sonic Wall. We have the same kind of variable in Cisco, Juniper and NCP and it does not cause the systems to reset.
It would be better if the SW would detect the inactive time and then renegotiate the VPN but it doesn't.
If you set the 9999... then the only time it gets renegotiated is if the line drops from either end then it will.
If a minute or 2 of down/slow time is too much for the users then you'll have to set the 9999999 lifetime.
I have 2 NSA2400's and would love it if i could set it so it would renegotiate the link at certain times link a calendar for it
If you set the 9999... then the only time it gets renegotiated is if the line drops from either end then it will.
If a minute or 2 of down/slow time is too much for the users then you'll have to set the 9999999 lifetime.
I have 2 NSA2400's and would love it if i could set it so it would renegotiate the link at certain times link a calendar for it
I haven't gotten in a 300 yet but on all the older models 28800 is the default and is fine. I would check that the KeepAlive is enabled and that the KeepAlive address is the local IP address of the opposite SonicWall. I keep my tunnels up 24/7 and they have really never dropped or as far as I know "renegotiated".
I have several TZ300's installed using the 28800 setting and it has not been a problem. As long as you have keep alives set on Advanced, it will automatically regnotiate the tunnel anytime it drops. If you choose to set it to 999999 it should not be an issue, since keep alives will force regnotiation if needed.
I don't know Sonicwalls but I know a little bit about firewalls and vpns.
SA's usually don't cause the symptoms you are describing. SA renegotiation takes milliseconds to complete and not noticeable to users. Most likely, when the users come in the morning, the VPN tunnel is already down due to inactivity over night and 8 hour SA timer. When users initiate the rdp connection to your DB server, VPN tunnel comes up and SA timer starts ticking. Do your users work more than 8 hours in a row? I don't think so.
(In Cisco world, SA renegotiation could also be forced by reaching the max amount of allowed traffic through the tunnel. I gave a brief look at the sonicwall config but haven't seen that setting.)
Now, slow and stop "talking" are two different issues. Slow most likely points to traffic congestion and stop could actually mean a lot of things. But before going deeper, I would go back to the users and ask them which one it is, when during the day it happens and what are they doing at that moment.
SA's usually don't cause the symptoms you are describing. SA renegotiation takes milliseconds to complete and not noticeable to users. Most likely, when the users come in the morning, the VPN tunnel is already down due to inactivity over night and 8 hour SA timer. When users initiate the rdp connection to your DB server, VPN tunnel comes up and SA timer starts ticking. Do your users work more than 8 hours in a row? I don't think so.
(In Cisco world, SA renegotiation could also be forced by reaching the max amount of allowed traffic through the tunnel. I gave a brief look at the sonicwall config but haven't seen that setting.)
Now, slow and stop "talking" are two different issues. Slow most likely points to traffic congestion and stop could actually mean a lot of things. But before going deeper, I would go back to the users and ask them which one it is, when during the day it happens and what are they doing at that moment.
Hi There,
Refer the below link:
https://community.spiceworks.com/topic/764490-what-is-security-association-lifetime-cisco-site-to-site-vpn
A new security association is negotiated before the lifetime threshold of the existing security association is reached, to ensure that a new security association is ready for use when the old one expires. The new security association is negotiated either 30 seconds before the seconds lifetime expires or when the volume of traffic through the tunnel reaches 256 kilobytes less than the kilobytes lifetime (whichever occurs first).
Refer the below link:
https://community.spiceworks.com/topic/764490-what-is-security-association-lifetime-cisco-site-to-site-vpn
A new security association is negotiated before the lifetime threshold of the existing security association is reached, to ensure that a new security association is ready for use when the old one expires. The new security association is negotiated either 30 seconds before the seconds lifetime expires or when the volume of traffic through the tunnel reaches 256 kilobytes less than the kilobytes lifetime (whichever occurs first).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
As it turns out the 8 hr Default ( 28,800 seconds) was exactly the problem. SonicWall support emailed me and confirmed. ( 8 hours plus /overtime is normal here in our business) . The interesting timing is we have 4 stores and one Central office, so the TIMING of the tunnels were really random because the countdown starts when the unit was first powered up or when it was last rebooted, and of course in a multi-city system they are not started or restarted by one person at exactly the same time. I made the change to all 9's and all if fine .
Hi there,
Glad to know the issue is fixed..
Have Sonicwal tech managed to give a valid reason for this anomalous behavior of SA's specific to their device.
Do post a relevant KB if obtained so that we could all learn.
Glad to know the issue is fixed..
Have Sonicwal tech managed to give a valid reason for this anomalous behavior of SA's specific to their device.
Do post a relevant KB if obtained so that we could all learn.