Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

VPN setup to syncro a NTP server

I had a 1720 working on a Ipsec environment.

I knew that for working well the certification of the key

i have to set the correct clock and calendar on my cisco.

The Ntp server could not send the packet to my 1720.

Is the Ipsec ? or may I have to configure an ACL for incoming connection from the NTP server

this is the config:

no scheduler allocate

ntp server

ntp server


Any suggestion?


Re: VPN setup to syncro a NTP server

NTP server is likely being blocked by the IPSEC access list. I wouldn’t think you’ll need to build an IPSEC tunnel for NTP, just allow it in an access list. Have Cisco’s tac look at your situation.

New Member

Re: VPN setup to syncro a NTP server

Okay, issue here is that you want to use NTP, because we all know those pesky certificates will fail when your router wakes up in 1993. Problem is, you can't build a crypto tunnel to your NTP source until the router gets correct time - catch 22.

Solutions are:

Use multiple authentication methods in your crypto policy, and use a pre-shared key to the crypto peer protecting your NTP server.

Define multiple NTP peers, some protected by IPSec which are "preferred", and some not protected that the router can use to get time in the wake-up process. (remember that you can use different source interfaces for different ntp peers)

If you are using Tunnel Endpoint Discovery, you can use the NTP protocol to create the a crypto tunnel to a monitoring site from a private IP address source on the remote router, and then use this encrypted tunnel from the central site to manage the remote router via telnet/ssh to the private IP address on the remote router. That way, as a fallback if crypto has failed you can still telnet/ssh to the public IP address of the remote router outside the crypto tunnel.