NTP server unreachable through ASA firewall

[Oliver Drew]

Hi all,

I've configured a DMZ switch to point to an NTP server on on the Inside, but I get a debug message on the switch that says:

NTP: <NTP server IP address> unreachable

I'm confident that the NTP server is configured properly, as there are more than a dozen other hosts using it, successfully. The difficulty here is that the NTP packets are having to flow from the DMZ to the Inside. I have a rule set on the firewall that permits the IP address of the switch to connect to the IP address of the NTP server as follows:

access-list intdmz1_acl extended permit udp host <IP address of switch> host <IP address of NTP server> eq ntp

I can see the hit counter on this rule incrementing.

The firewall can ping the NTP server, and the NTP server can ping the switch, so I think routing is OK.

Output from the DMZ switch:

switch#show ntp associations

      address         ref clock     st  when  poll reach  delay  offset    disp
~192.168.65.254   0.0.0.0          16     -    64    0     0.0    0.00  16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured

switch#show ntp status

Clock is unsynchronized, stratum 16, no reference clock

nominal freq is 119.2092 Hz, actual freq is 119.2092 Hz, precision is 2**17

reference time is 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)

clock offset is 0.0000 msec, root delay is 0.00 msec

root dispersion is 0.00 msec, peer dispersion is 0.00 msec

PRNLN-DMZ-SW01#sh run | inc ntp

ntp source Vlan138

ntp server 192.168.65.254

ukhvdc00vs01#sh run | inc ntp

ntp source Vlan65

ntp master 3

ntp update-calendar

ntp server 0.uk.pool.ntp.org

ntp server 1.uk.pool.ntp.org

PRNLN-DMZ-SW01#show ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 119.2092 Hz, actual freq is 119.2092 Hz, precision is 2**17
reference time is 00000000.00000000 (00:00:00.000 GMT Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec

Does the firewall rule need to permit more than UDP/123 for this to work perhaps?

NTPconfig on DMZ switch:

switch#sh run | inc ntp
ntp source Vlan138
ntp server <IP address of NTP server>

===================

NTP config on NTP server:

NTP_Server#sh run | inc ntp
ntp source Vlan65
ntp master 3
ntp update-calendar
ntp server 0.uk.pool.ntp.org
ntp server 1.uk.pool.ntp.org

Any guidance welcomed.

Thank you,

Olly

[Julio Carvajal]

Hello Oliver,

Do

packet-tracer input DMZ udp switch_ip 1026 NTP_IP 123

and provide us the output

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

[Oliver Drew]

Hi Julio,

Thank you for your repsonse.

I've done that, and I think I have an idea what the problem might be. There's a NAT rule that translates the private IP address of the NTP server to the firewall's public IP address, as it leaves the outside interface for access to the NTP servers on the internet.

Here's output:

ciscoasa# packet-tracer input intdmz1 udp DMZ_SWITCH_IP 1026 192.168.65.254$

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.0.0     255.255.0.0     inside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group intdmz1_acl in interface intdmz1
access-list intdmz1_acl extended permit udp host DMZ_SWITCH_IP host NTP_SERVER_IP eq ntp
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 access-list hide-nat
  match udp inside host NTP_SERVER_IP outside any eq 123
    dynamic translation to pool 1 (FIREWALL's_OUTSIDE_INTERFACE_IP [Interface PAT])
    translate_hits = 0, untranslate_hits = 0
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 71880216, packet dispatched to next module

Result:
input-interface: intdmz1
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow

Do I need to configure a NAT rule above the existing NAT rule that doesn't translate the NTP server's IP address, if the destination is the DMZ_SWITCH_IP or something like that?

Thanks

[cadet alain]

Hi,

Which OS version are you using on ASA ?

Regards

Alain

Don't forget to rate helpful posts.

[Oliver Drew]

Hi Alain,

It's running 8.2(4).

Thanks

Olly

[Julio Carvajal]

Hello Oliver,

In this case seems like there is no NAT between each other and packet is being allowed (The Host-Limit NAT does not count)

Let's do the following

cap capdmz interface dmz match udp host dmz_switch_IP host NTP_Inside_IP eq 123

cap capin interface inside match  udp host dmz_switch_IP host NTP_Inside_IP eq 123

cap asp type asp-drop all circular-buffer

Then try to connect to the NTP server and provide

show cap capin

show cap capdmz

show cap asp | include NTP_server_IP

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.com

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

[Oliver Drew]

Hi Julio,

Hi Julio,

For the purposes of this information:
DMZ switch IP = 5.6.7.8
NTP server IP = 10.1.1.1

Here's the output from the show commands:

ciscoasa# show capture NTPCAPTUREDMZ

11 packets captured

   1: 16:22:05.271500 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   2: 16:23:09.276185 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   3: 16:24:13.274033 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   4: 16:24:57.272813 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   5: 16:24:58.279480 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   6: 16:24:59.277817 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   7: 16:25:00.275971 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   8: 16:25:01.275559 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
   9: 16:25:02.272599 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
  10: 16:25:03.279129 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
  11: 16:25:04.277710 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
11 packets shown

----------------------------------------------------
ciscoasa# show capture NTPCAPTUREINSIDE

0 packet captured

0 packet shown

----------------------------------------------------

ciscoasa# show capture NTPASP | include 10.1.1.1
419: 16:24:13.274171 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
1820: 16:24:57.272904 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
1841: 16:24:58.279587 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
1876: 16:24:59.277909 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
1934: 16:25:00.276062 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2027: 16:25:01.275651 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2068: 16:25:02.272690 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2095: 16:25:03.279221 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2129: 16:25:04.277802 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2200: 16:25:05.275849 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2233: 16:25:06.274094 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2275: 16:25:07.273606 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2327: 16:25:08.280182 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2347: 16:25:09.277222 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2373: 16:25:10.275467 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2399: 16:25:11.273759 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48
2414: 16:25:12.273347 802.1Q vlan#138 P6 5.6.7.8.123 > 10.1.1.1.123:  udp 48

I'm guessing we should see some packets in the second capture, but we're not...

Does this help?

Thanks!
Olly

[Julio Carvajal]

Hello Oliver,

Great job with the captures You did it right!

It does help. Let me analize it:

1) On capture dmz we see the requests from the switch to the NTP server

2) On capture Inside no packets being shown (so they are getting stuck in the ASA)

3) On capture ASP (capture for packets being dropped) we see all of the packets, so all of them are being dropped.

Here are my questions:

packet-tracer input intdmz1 udp DMZ_SWITCH_IP 1026 192.168.65.254$

Here is the packet-tracer . the IP addresses are different than the capture

Cause I see here:

5.6.7.8.123 > 10.1.1.1.123

Can you do the packet-tracer with those IP addresses.

Also share the running configuration if possible (or send it privateley to my email address listed bellow)

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.com

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

[Oliver Drew]

Hi Julio, I have replied to your email address, but will post back here with relevant information to help anyone else that might find it useful.

Thanks

Olly

[Julio Carvajal]

Hello Oliver,

Just answered u

For more information about Core and Security Networking follow my website at http://laguiadelnetworking.com

Any question contact me at jcarvaja@laguiadelnetworking.com

Cheers,

Julio Carvajal Segura

[a.guillen]

HI Oliver

A question, from the original (Client) you can reach the NTP Server?,

Could you send us the result of the following command:

Ping to the NTP server

Traceroute to the NTP server

Let me know if you can reach it

[Salvador Antonio Quintanilla Mendoza]

any update about this??? I have the same issue with an asa5585...