Hello all,
The company I work for uses Mikrotiks as both a central IPSEC VPN concentrator and on-site VPN endpoint for a geographically large timeclock network. The timeclocks all exists on their own unique subnets at the site and communicate directly with a central timeclock server. This works well and has worked well for many years.
Originally, the infrastructure was designed with a Cisco concentrator and Netgear Prosafe VPN firewalls. This worked reliably, but the concentrator hit EOL and the Netgears were old and difficult to administer efficiently. For these reasons, we moved to a full RouterOS solution.
We are experiencing an intermittent but regularly occurring problem where timeclocks will become inaccessible for between 4 and 8 hours. We monitor all clocks on their site unique IP address from our home office. All peers are configured for initial contact from the concentrator, not the endpoints. SA lifetime is set for 24 hours. We know that the tunnel is going down and not the timeclock itself as we are monitoring the timeclock locally on the Tik and logging when they are inaccessible. All Tiks are time synchronized using NTP and are set for the same timezone. Additionally, all Tiks are running ROS 5.25.
Any thoughts on why this may be occurring? It hasn’t been a huge issue, since the clocks are relatively intelligent about what to do when no network connection is available, but I would like to get closer to 100% uptime on all of our endpoint.
I’ve posted the pertinent areas of our IPSEC configuration below:
Concentrator
/ip ipsec policy
add comment="Property 23" dst-address=10.150.60.245/32 proposal=\
payroll sa-dst-address=71.87.*.* sa-src-address=24.158.*.* \
src-address=192.168.148.0/24 tunnel=yes
/ip ipsec peer
add address=71.87.*.*/32 comment="Property 23" dpd-interval=\
disable-dpd secret=****
/ip ipsec proposal
add auth-algorithms=md5 lifetime=1d name=payroll
Endpoint
/ip ipsec policy
add dst-address=192.168.148.0/24 proposal=payroll sa-dst-address=24.158.*.* \
sa-src-address=71.87.*.* src-address=10.150.60.245/32 tunnel=yes
/ip ipsec peer
add address=24.158.*.*/32 dpd-interval=disable-dpd dpd-maximum-failures=1 secret=\
**** send-initial-contact=no
/ip ipsec proposal
add auth-algorithms=md5 lifetime=1d name=payroll
We’re attempting to log everything IPSEC related, but when going back through the logs around the times of the apparent disconnects, we’re not see any indication of what could be happening.
Any help would be greatly appreciated! Thank you!