Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 7440 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NTP not being responded to

Greg Oliver

Hi,

 

I am running:

SFOS 17.0.6 MR-6

but just backed down from:
 
SFOS 17.0.8 MR-8
 
to test this out as I cannot remember this ever happening.
 
This weekend I just noticed it as I put a new IP phone for work on my network.  The phone authenticates to a remote netowrk and has certificate checking built in (Cisco 8851).  The time/date is incorrect on it, so the certificate dates are not in order, but the phone cannot get NTP set straight.  My laptop is another device that cannot successfully set NTP, although I have several devices who set NTP properly every single attempt.  The firewall has no rules blocking 123 and if I look at the logviewer, the router does not appear to be blocking them either, but I never get responses.  If I take the Sophos out and use the provider's router, I have zeroi issues.
 
192.168.100.113 is my laptop and 192.168.100203 is the phone..
 
10:29:36.795617 Port4, IN: IP 192.168.100.203.123 > 66.228.59.187.123: NTPv3, Client, length 48
10:29:37.295754 Port4, IN: IP 192.168.100.203.123 > 172.98.193.44.123: NTPv3, Client, length 48
10:29:37.375870 Port4, IN: IP 192.168.100.203.123 > 69.89.207.199.123: NTPv3, Client, length 48
10:29:37.916001 Port4, IN: IP 192.168.100.203.123 > 108.61.56.35.123: NTPv3, Client, length 48
 
10:30:58.843858 Port4, IN: IP 192.168.100.113.123 > 17.253.2.253.123: NTPv4, Client, length 48
10:30:59.046868 Port4, IN: IP 192.168.100.113.123 > 17.253.24.125.123: NTPv4, Client, length 48
10:30:59.246885 Port4, IN: IP 192.168.100.113.123 > 17.253.6.125.123: NTPv4, Client, length 48
10:30:59.446711 Port4, IN: IP 192.168.100.113.123 > 17.253.2.125.123: NTPv4, Client, length 48
10:30:59.644085 Port4, IN: IP 192.168.100.113.123 > 17.253.24.253.123: NTPv4, Client, length 48
10:31:00.029138 Port4, IN: IP 192.168.100.150.57147 > 64.6.144.6.123: NTPv4, Client, length 48
10:31:00.059401 Port4, OUT: IP 64.6.144.6.123 > 192.168.100.150.57147: NTPv4, Server, length 48
10:31:00.845343 Port4, IN: IP 192.168.100.113.123 > 17.253.2.253.123: NTPv4, Client, length 48
10:31:01.043974 Port4, IN: IP 192.168.100.113.123 > 17.253.24.125.123: NTPv4, Client, length 48
10:31:01.214974 Port4, IN: IP 192.168.1.5.44139 > 192.168.101.254.123: NTPv3, Client, length 48
10:31:01.243413 Port4, IN: IP 192.168.100.113.123 > 17.253.6.125.123: NTPv4, Client, length 48
10:31:01.444044 Port4, IN: IP 192.168.100.113.123 > 17.253.2.125.123: NTPv4, Client, length 48
10:31:01.643924 Port4, IN: IP 192.168.100.113.123 > 17.253.24.253.123: NTPv4, Client, length 48
10:31:02.846628 Port4, IN: IP 192.168.100.113.123 > 17.253.2.253.123: NTPv4, Client, length 48
10:31:03.046660 Port4, IN: IP 192.168.100.113.123 > 17.253.24.125.123: NTPv4, Client, length 48
10:31:03.246659 Port4, IN: IP 192.168.100.113.123 > 17.253.6.125.123: NTPv4, Client, length 48
10:31:03.446606 Port4, IN: IP 192.168.100.113.123 > 17.253.2.125.123: NTPv4, Client, length 48
10:31:03.646648 Port4, IN: IP 192.168.100.113.123 > 17.253.24.253.123: NTPv4, Client, length 48
10:31:04.844051 Port4, IN: IP 192.168.100.113.123 > 17.253.2.253.123: NTPv4, Client, length 48
10:31:05.044035 Port4, IN: IP 192.168.100.113.123 > 17.253.24.125.123: NTPv4, Client, length 48
10:31:05.243863 Port4, IN: IP 192.168.100.113.123 > 17.253.6.125.123: NTPv4, Client, length 48
10:31:05.444038 Port4, IN: IP 192.168.100.113.123 > 17.253.2.125.123: NTPv4, Client, length 48
 
Not sure what to do here..  Should I roll back to something earlier than 17.06?
 
TiA,
 
Greg


This thread was automatically locked due to age.
Parents
  • 0

    Hi Greg,

    That is odd, could you check if you could create the firewall rule for your NTP connection with no Policy applied and check if that would help. We have released 17.1 GA so you may downgrade to MR-6 > take backup and then upgrade to 17.1 GA so you may have a firmware to fall back if this does not work.

  • 0 in reply to Aditya Patel

    Hi Aditya,

     

    I just upgraded and the issue is the same unfortunately.  I am more of a "figure it out" versus roll back person, but I did roll back to the previous MR yesterday just to see if that was it, and it was not.

     

    I am running 17.1 now, but do not understand your request - by no policy applied, I assume you mean "Accept Drop or Reject".  I do not know how to not pick one of those.  I can disable the rule (I created) completely, but I am unsure what yiou ask.

     

    It is definitely strange - like I said, I have several hosts that NTP goes straight out, and these 2 (that I know of) that never get it..

     

    Here is my laptop from Sophos' XG point of view running a simple `ntpdate' command ::

     

    11:58:05.100874 Port4.100, IN:  In 98:22:ef:dc:c6:9f ethertype IPv4 (0x0800), length 92: (tos 0x0, ttl 64, id 34052, offset 0, flags [DF], proto UDP (17), length 76)
        192.168.100.113.123 > 17.253.24.253.123: NTPv4, length 48
        Client, Leap indicator: clock unsynchronized (192), Stratum 0, poll 3s, precision -6
        Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3738416285.222238615 (2018/06/19 11:58:05)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3738416285.222238615 (2018/06/19 11:58:05)
        0x0000:  4500 004c 8504 4000 4011 6589 c0a8 6471  E..L..@.@.e...dq
        0x0010:  11fd 18fd 007b 007b 0038 59c4 e300 03fa  .....{.{.8Y.....
        0x0020:  0001 0000 0001 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 ded3 b49d 38e4 a15d            ........8..]
    11:58:06.298460 Port4, IN:  In 98:22:ef:dc:c6:9f ethertype Unknown (0x0064), length 96: 
        0x0000:  0000 0800 4500 004c 102b 4000 4011 ece2  ....E..L.+@.@...
        0x0010:  c0a8 6471 11fd 067d 007b 007b 0038 4513  ..dq...}.{.{.8E.
        0x0020:  e300 03fa 0001 0000 0001 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000 0000 ded3 b49e 6c25 954c  ............l%.L

    It never receives a response...

    And a system that always works - Linux just like my laptop (actually same version)..  I cannot see a difference, and you can see they are on the same VLAN..
    12:03:18.690420 Port4.100, IN:  In 70:71:bc:87:aa:bb ethertype IPv4 (0x0800), length 92: (tos 0x0, ttl 64, id 21049, offset 0, flags [DF], proto UDP (17), length 76)
        192.168.100.150.47847 > 154.16.245.246.123: NTPv4, length 48
        Client, Leap indicator:  (0), Stratum 0, poll 10s, precision 32
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3922789542.133315876 (2024/04/22 10:45:42)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3922789542.133315876 (2024/04/22 10:45:42)
        0x0000:  4500 004c 5239 4000 4011 3322 c0a8 6496  E..LR9@.@.3"..d.
        0x0010:  9a10 f5f6 bae7 007b 0038 53d0 2300 0a20  .......{.8S.#...
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 e9d1 04a6 2220 fd4c            ........"..L
    12:03:18.726480 Port4.100, OUT: Out 00:ec:ac:cf:00:43 ethertype IPv4 (0x0800), length 92: (tos 0x0, ttl 46, id 59380, offset 0, flags [DF], proto UDP (17), length 76)
        154.16.245.246.123 > 192.168.100.150.47847: NTPv4, length 48
        Server, Leap indicator:  (0), Stratum 2, poll 10s, precision -23
        Root Delay: 0.044036, Root dispersion: 0.027877, Reference-ID: 152.2.253.126
          Reference Timestamp:  3738416539.436323016 (2018/06/19 12:02:19)
          Originator Timestamp: 3922789542.133315876 (2024/04/22 10:45:42)
          Receive Timestamp:    3738416598.964726924 (2018/06/19 12:03:18)
          Transmit Timestamp:   3738416598.964757204 (2018/06/19 12:03:18)
            Originator - Receive Timestamp:  -184372943.168588981
            Originator - Transmit Timestamp: -184372943.168558657
        0x0000:  4500 004c e7f4 4000 2e11 af66 9a10 f5f6  E..L..@....f....
        0x0010:  c0a8 6496 007b bae7 0038 057d 2402 0ae9  ..d..{...8.}$...
        0x0020:  0000 0b46 0000 0723 9802 fd7e ded3 b59b  ...F...#...~....
        0x0030:  6fb2 dd59 e9d1 04a6 2220 fd4c ded3 b5d6  o..Y...."..L....
        0x0040:  f6f8 57ab ded3 b5d6 f6fa 542d            ..W.......T-
    12:03:18.726497 Port4, OUT: Out 00:ec:ac:cf:00:43 ethertype Unknown (0x0064), length 96: 
        0x0000:  0000 0800 4500 004c e7f4 4000 2e11 af66  ....E..L..@....f
        0x0010:  9a10 f5f6 c0a8 6496 007b bae7 0038 057d  ......d..{...8.}
        0x0020:  2402 0ae9 0000 0b46 0000 0723 9802 fd7e  $......F...#...~
        0x0030:  ded3 b59b 6fb2 dd59 e9d1 04a6 2220 fd4c  ....o..Y...."..L
        0x0040:  ded3 b5d6 f6f8 57ab ded3 b5d6 f6fa 542d  ......W.......T-
     
  • 0 in reply to Greg Oliver

    Hi,

    can you connect to external sites from the two failing devices? How are you authenticating your IP address in XG? Does your rule allow any device out?

    Ian

  • 0 in reply to Greg Oliver

    Ok, so a little more digging.

    Using `ntpdate' on 192.168.100.150 results in the same behavior.  So, XG has to be looking in the packets for 123 and deciding somewhere.  The gsd-datetime aop (Gnome 3) seems to work OK, but ntpdate does not get to come back in for some reason.  I know these damn Cisco phones run Java, but am unsure of the underlying OS - I assume their usual NX-OS, so assume their own NTP implementation, but not sure - just know this Sophos XG is not letting it happen.  I can put it in a tunnel (VPN) behind the XG, and ntp passes just fine as well.

     

    Not sure where to go from here since all of the rules are compiled and not open sourced..

     

    -Greg

Reply
  • 0 in reply to Greg Oliver

    Ok, so a little more digging.

    Using `ntpdate' on 192.168.100.150 results in the same behavior.  So, XG has to be looking in the packets for 123 and deciding somewhere.  The gsd-datetime aop (Gnome 3) seems to work OK, but ntpdate does not get to come back in for some reason.  I know these damn Cisco phones run Java, but am unsure of the underlying OS - I assume their usual NX-OS, so assume their own NTP implementation, but not sure - just know this Sophos XG is not letting it happen.  I can put it in a tunnel (VPN) behind the XG, and ntp passes just fine as well.

     

    Not sure where to go from here since all of the rules are compiled and not open sourced..

     

    -Greg

Children
No Data