Windows Server Time

Unanswered Question
Sep 28th, 2008

Hi, Our Web Servers are placed in DMZ and when i try to update time synchronization then it shows me error. Seems something is getting blocked. Has NTP required to be add in the default inspection. Please suggest. Thanks.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Burts Sun, 09/28/2008 - 04:41

Richard

I believe that there is not enough information here for us to really understand and provide answers about your issue. What device is providing the DMZ functionality (PIX, ASA, router, something else)? What access policies are in place for the DMZ? How are your web servers configured to get time? By default Windows servers run the Windows time service which implements a simplified version of NTP.

With normal access policies on a DMZ if the Windows server sends a request for time to some appropriate time source on the outside, since the request originated from inside the DMZ then responses should be allowed. If the time information is included in transmission originated from devices on the outside then you would need to configure access rules to permit this. If the request for time is sent from the server in the DMZ to some appropriate time source on the inside network then you would need to configure access rules to permit this traffic.

If you can clarify these aspects then perhaps we can provide better answers.

HTH

Rick

ray_stone Sun, 09/28/2008 - 05:31

We are using ASA 5505. Application Servers are placed on DMZ and DB Servers are on Inside. The all App Server are mapped with Static Public IP and time is getting synchronized in App Server but not in DB Servers. We can access internet from DB and App Servers. Please Advice and let me know if you want anything else. Thanks

cisco24x7 Sun, 09/28/2008 - 10:06

When you run "tcpdump" or "capture" on the

ASA "outside" interface, do you see NTP traffics

leaving the outside interface and come back,

like this:

[email protected]-labgw]# tcpdump -i eth1 -nnn port 123

tcpdump: listening on eth1

18:02:19.558611 192.168.148.201.123 > 192.168.89.240.123: v4 client strat 0 poll 4 prec -6 (DF)

18:02:19.558928 192.168.89.240.123 > 192.168.148.201.123: v4 server strat 2 poll 4 prec -18 (DF)

18:02:19.559093 192.168.148.201.123 > 192.168.89.240.123: v4 client strat 0 poll 4 prec -6 (DF)

18:02:19.559353 192.168.89.240.123 > 192.168.148.201.123: v4 server strat 2 poll 4 prec -18 (DF)

18:02:19.559473 192.168.148.201.123 > 192.168.89.240.123: v4 client strat 0 poll 4 prec -6 (DF)

18:02:19.559729 192.168.89.240.123 > 192.168.148.201.123: v4 server strat 2 poll 4 prec -18 (DF)

18:02:19.559869 192.168.148.201.123 > 192.168.89.240.123: v4 client strat 0 poll 4 prec -6 (DF)

18:02:19.560115 192.168.89.240.123 > 192.168.148.201.123: v4 server strat 2 poll 4 prec -18 (DF)

8 packets received by filter

0 packets dropped by kernel

[[email protected]-labgw]#

Actions

This Discussion