How to keep NTP traffic internal

[HQuest]

Hello all.

Is there any way I can configure my ASA to keep internal all NTP traffic from a certain subnet? There are embedded devices and appliances on this network where NTP configurations are not available and the NTP servers are randomly chosen via the NTP pool or to whichever NTP server the vendor decided to hard-coded. Last I saw I had over 50 different IP addresses of public NTP servers, so making a list of them would be too cumbersome to maintain.

While the below does not work, it sort of gives an idea of what I am trying to achieve:

nat (Inside-VLANx,Outside) source static Inside-VLANx Inside-VLANx destination static any NTP-Server service udp-123-ntp udp-123-ntp net-to-net no-proxy-arp

Any suggestions?

[Marvin Rhoads]

If you want to restrict it to internal NTP server(s) only then why not just put an access list on the interface and block all ntp requests (and permit everything else or at least the things you want to allow)?

Your example NAT statement will exempt the traffic from NAT but not restrict it in any way.

[HQuest]

Marvin,

I would still like the devices I cannot change NTP servers to talk to a real NTP server. By putting in an ACL, servers with hardcoded entries would not get their clocks synchronized.

The other option I tried was to force any DNS request to *.ntp.org to point at my internal NTP. While this had a positive effect on some devices, others still had hardcoded IP addresses or hostnames outside the *.ntp.org domain. And then there is the management piece of the DNS: this is a network wide change vs a one single subnet - unless I turn on a dedicated DNS box just for that.

Thanks for your thoughts though.

[Marvin Rhoads]

Ah OK - I think I understand your goal with the use of NAT now. Basically keep letting everybody with hard coded ntp server addresses keep using them but convery them into an ntp server of your choosing at the ASA. 

The NAT should work in that case. The only thing odd about it that I noticed was the "net-to-net" which is normally only used in NAT 46 use cases.

What happens when you check the logic using packet-tracer?

[HQuest]

Apart of me finding out that using the internal object "any" makes the rule not even be accepted as valid by the ASA, but creating an object named "World" as network 0/0 allows the rule to be added, it still does not work.

asa(config)# nat (Inside-VLANx,Outside) source static Inside-VLANx Inside-VLANx destination static any NTP-Server service udp-123-ntp udp-123-ntp net-to-net no-proxy-arp

ERROR: any doesn't match an existing object or object-group

asa(config)# object network World
asa(config-network-object)# subnet 0.0.0.0 0.0.0.0

asa(config-network-object)# exit

asa(config)# nat (Inside-VLANx,Outside) source static Inside-VLANx Inside-VLANx destination static World NTP-Server service udp-123-ntp udp-123-ntp net-to-net no-proxy-arp

asa(config)# _

Packet tracer says traffic was allowed, but I cannot get a response back from the NTP server - doesn't matter if NTP server is on the same or on a different subnet.

It does not show up on the regular ASA logs:

asa# capture ntp real-time match udp any any eq ntp

Warning: using this option with a slow console connection may
result in an excessive amount of non-displayed packets
due to performance limitations.

Use ctrl-c to terminate real-time capture

(a few minutes later: Control+c)
0 packets shown.
0 packets not shown due to performance limitations.

Removing the net-to-net from the NAT rule makes no difference.

Looking at an asp-drop -type capture:

asa# sh capture
capture ntp type asp-drop all [Stopped - 0 bytes]
match udp any any eq ntp
asa# capture ntp real-time

Warning: using this option with a slow console connection may
result in an excessive amount of non-displayed packets
due to performance limitations.

Use ctrl-c to terminate real-time capture

1: 18:41:44.244668 192.168.X.XX.123 > 80.92.126.65.123: udp 48 Drop-reason: (acl-drop) Flow is denied by configured rule
2: 18:41:44.444249 192.168.X.XX.123 > 103.242.68.69.123: udp 48 Drop-reason: (acl-drop) Flow is denied by configured rule

, which is not exactly true:

access-list Inside-VLANx_access_in extended permit udp 192.168.X.0 255.255.255.0 object World eq ntp

but matches what I see on the client:

user@unix:~# tcpdump -ni eth0 'port 123' &

[1] 34422

user@unix:~# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

user@unix:~# ntpdate pool.ntp.org

18:41:44.244668 IP 192.168.X.XX.123 > 80.92.126.65.123: NTPv4, Client, length 48

18:41:44.444249 IP 192.168.X.XX.123 > 103.242.68.69.123: NTPv4, Client, length 48
14 Sep 18:44:46 ntpdate[33645]: no server suitable for synchronization found

Any further suggestions?

[HQuest · Accepted solution]

I learned a few new things with this issue.

1. I was trying to achieve what is called "NAT divert". Seems this is pretty wide used and known - now that I know its correct name.

2. The any keyword cannot be really used all the time, so the need for a World object was spot on.

3. My ACL was close but got no cigar. For the NAT divert to work, I had to use keyword interface, and it had to be of type dynamic, not static, which by the end of the day, makes proper sense:

nat (Inside-VLANx,Outside) source dynamic any interface destination static World NTP-Server service udp-123-ntp udp-123-ntp

4. With the rule added, the ASA began redirecting traffic as expected, with a side effect: it began to proxy-arp every empty IP address for this segment. To circumvent that (and fix Cisco ISE's IP address check during initialization time - hint, hint!), a system option command to the rescue:

sysopt noproxyarp Inside-VLANx

So there we have it. Hope this saves others some time in the future.

[Flavio Miranda]

Nice job Alexandre! 

 Congratualtions on your job by find out a solucion and, more then that, sharing what you learned!

 Keep going on this!