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.

Reply
  • 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.

Children
  • 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

  • 0 in reply to rfcat_vk

    Yes, my main rule is a masquerade out the WAN for all Zones..  I have no internet issues, just this weird one..

     

    -Greg

     

    Also, I just posted that using the ntpdate command results in failures, but using another app does not.   Seems very strange - packet captures posted..

     

  • 0 in reply to Greg Oliver

    Well, I usually do not like to give up on products, but this is too much for me.  The 17.1-GA release was killing all of my DHCP clients that had static leases (most of mt house) while I was unknowing (and out of town the last 3 days) after the upgrade.  It also does not have pcaps for the rejected packets (although the main tcpdump was on and I can find them there, it would not stay enabled in logviewer).

     

    It seems Sophos is using us "free" home users as their free testing (which is absolutely fine), but the basics need to obviously be tested.  It is quite unnerving when the Sophos firewall blocks the Sophos DHCP server on the same piece of gear !

     

    Thanks for all the fish :)

     

    -Greg

     

    BTW:  It is always a bad idea to use a firewall that has built-in rules that cannot be disabled or viewed.

  • 0 in reply to Greg Oliver

    Hi,

    XG does not block DHCP but you need to add features to DHCP via the cli. You will need a more knowledgeable person than I for that.

    Please provide a copy of your firewall rule for us to review.

    Ian

  • 0 in reply to rfcat_vk

    In the past, I have posted about a wonky switch that was putting the same packet onto the PVID that it was on the trunked port.  That outbound port on the switch was connected to my XG Router, and it saww duplicate packets on 2 interfaces (which was bad switch firmware, so it dropped them due to rule_id=0

    Tuesday night, I was getting calls from home about devices not getting internet access.  I use DHCP static mappings for most of our stuff so it is easy to investigate issues with devices (or block access somewhere, etc).  I do not know why - I was being denied DHCP as well when I got home.  I rolled back to the previous release I noted earlier in this thread and all started working again, except NTP was still broken.

    My job ships me the phones for remote workers to my house prior to them going to the workers so I can provision them prior.  Since they are all the same model (we just switched our SBC the phones connect to), and NTP does not work here except for the select few, I had to switch software :)

    I really like the product, so I might switch back after I get these phones out.

    -Greg