Does anyone know how to decrease the time between LSVPN Satellite connection attempts?
If one of our satellites drops off (e.g. reboot/power outage/etc), after it comes back up it will take up to an hour to connect to it's nominated Gateway. Also, if the Gateway is rebooted (e.g. after hours mainteance) it takes up to an hour before all of the satellites re-connect.
Currently the 'Configuration refresh' internal is set to 2 hours for the Gateway.
I'm unclear if this configuration option affects the actual reconnection times - I imagine it would act as a 'worst case' scenario where the Satellite would be forced to reconnect to attempt to refresh config?
I'm hoping there's a method of setting the LSVPN Satellite "re-connect timer" down to about 5 minutes or so, as currently it's very painful when there's a reboot. Remoting in to manually click 'Reconnect to Gateway' is not a feasuible option, as the Satellite's are installed in branch offices with non-technically-literate people and the Management interfaces are not available via WAN.
IPSec tunnels seem to reconnect much quicker. I was considering having an IPSec tunnel from each of the ~50 Satellites back to a central point to maintain a management interface, so I can manually click "Reconnect to Gateway" - but then why even both using LSVPN, if we have IPSec tunnels to all devices?
Edit - been through 2 TAC cases so far with no solid answers to any of the above
are your endpoints actively generating traffic to your central site ?
have you set up a tunnel monitoring profile with wait recover or failover?
Thanks for your reply
Yes, there are automated systems on-site sending data back to a central hub (cameras, etc).
So I would expect LAN devices to be generating traffic destined for the LSVPN Gateway as soon as the firewall was online
Additionally, when I reboot the hub firewall I have MultiPing running to establish when the branches come back online. This application is generating ping traffic across all know links, but it still takes roughty an hour for them all to come back online. It's always different firewalls in different orders, and they seem to come back in a roughly linear pattern over the hour - but it's always roughly an hour for them all to come back.
Also, I was under the impression that LSVPN was not established when 'interesting traffic' was encountered (ala Cisco) but rather as a function of the 'satd' daemon? I'm hoping to find out if we can manipulate this daemon to attempt re-establishment more quickly.
I thought of a tunnel monitor, but TAC advised that was only useful in the event we had redundant paths. The tunnel monitor could be used as a trigger to activate a redundanct/secondary path - but it would not prompt a Satellite to attempt reconnection of a failed tunnel. If you have experience that suggests the opposite then I'd be happy to try this method
I have big problems with LSVPN as well.
After replacing the Root CA, some gateways fail to connect to gateways, because the gateway or satellite has an old certificate cached.
When the first tunnel goes down, only tries to "reconnect" to the primary gateway happens, no failover to the secondary gateway.
AFter manually clicking on reconnect to gateway (secondary) the gateway is displayed as "user disconnected".
Yesterday somehow there was a connection to the secondary gateway when testing failover, but no routes were distributed.
In my opinion LSVPN is bananaware when these fundamental things aren't working properly.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!