09-28-2008 02:48 AM - edited 03-11-2019 06:50 AM
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.
09-28-2008 04:41 AM
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
09-28-2008 05:31 AM
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
09-28-2008 10:06 AM
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:
Expert@CP-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
[Expert@CP-labgw]#
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide