05-13-2002 01:07 AM - edited 02-21-2020 11:44 AM
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 131.188.34.75
ntp server 193.204.114.1
end
Any suggestion?
05-20-2002 05:50 AM
NTP server is likely being blocked by the IPSEC access list. I wouldnt think youll need to build an IPSEC tunnel for NTP, just allow it in an access list. Have Ciscos tac look at your situation.
05-30-2002 09:14 PM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: