xg210 lan interface stops responding for a few seconds every 4 hours

Hi guys, I hope everyone is doing well.

I am experiencing a curious problem with my XG 210. The LAN interface (Port1) simply stops responding for about 30s. The curious thing is that this occurs religiously every 4 hours.

- I have already changed interface speed and operating mode settings

 - I already reviewed syslog and other logs and nothing was found

- I have already monitored the Switch and noticed that the interface is not disconnected

- I already switched Switch, cable etc (Although of course it is not a hardware problem)

It's been a week since I updated to version 18.0.4 MR-4, but the problem started to happen since January 21, 2021 and the appliance was still in version 17.5.12 MR-12. Has anyone had this problem?



Hello guys. Some update of the problem. - set up a Lan ip on port3 and set it in the Lan zone and realized that for port 3 the failure does not occur - today I made a TCPDump capture and found it strange at the time of failure these ARP requests on ports 1,3,5 on the firewall's own IP. I didn't find anything else that could help to identify the reason for the failure on port1. 8:32:49.393842 Port1, IN: IP 192.168.1.9.53 > 192.168.1.1.9376: 30355 1/0/0 A 13.66.138.102 (64) 08:32:49.495601 Port1, IN: IP 192.168.1.3 > 192.168.1.1: ICMP echo request, id 37946, seq 59902, length 9 08:32:49.495615 Port1, OUT: IP 192.168.1.1 > 192.168.1.3: ICMP echo reply, id 37946, seq 59902, length 9 08:32:49.589204 Port1, IN: ARP, Request who-has 192.168.1.1 (7c:5a:1c:xx:xx:xx) tell 192.168.3.34, length 46 08:32:49.589214 Port1, OUT: ARP, Reply 192.168.1.1 is-at 7c:5a:1c:4a:82:38, length 28 08:32:49.619697 Port1, OUT: IP 192.168.1.1.38727 > 192.168.1.9.53: 27895+ A? chat.cdn.whatsapp.net. (39) 08:32:49.632652 Port3, IN: ARP, Request who-has 192.168.1.1 tell 192.168.1.1, length 46 08:32:49.632653 Port1, IN: ARP, Request who-has 192.168.1.1 tell 192.168.1.1, length 46 08:32:49.632655 Port5, IN: ARP, Request who-has 192.168.1.1 tell 192.168.1.1, length 46 08:32:49.776296 Port5, IN: ARP, Request who-has 192.168.1.9 tell 192.168.1.1, length 46 08:32:49.776299 Port3, IN: ARP, Request who-has 192.168.1.9 tell 192.168.1.1, length 46 08:32:49.776300 Port1, IN: ARP, Request who-has 192.168.1.9 tell 192.168.1.1, length 46 08:32:50.016317 Port5, IN: ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 46 08:32:50.016319 Port3, IN: ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 46 08:32:50.016321 Port1, IN: ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 46 On Sunday I will change everything to port3, including any rules that may exist and see if this will work or if the problem will follow.
[edited by: Cristiano Monteiro at 12:27 PM (GMT -8) on 25 Feb 2021]
  • Hi ,

    Thank you for reaching out to the Community! 

    When this issue occurs, run the traceroute command from the workstation to google.com and take a packet capture on the firewall. 

    Could you show us the output of the "ifconfig" command for Port1? 

    Thanks,

     

     
    Harsh Patel (H_Patel)

    Community Support Engineer | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' button.

  • Thanks for the answer

    I don't think tracert is going to help much. I leave a ping running from my machine towards the IP of XG's Lan and I notice that the ping always loses packets at the same times: 04:18 am, 08:18 am, 12:18 pm, 04:18 pm 08:18 pm, 12:18 am.

    The impression I have is as if there is a routine in XG that reloads the firewall rules or simply reloads the network interface.

    I have an open case in Brazil's support, but it hasn't helped me much.

    Port1     Link encap:Ethernet  HWaddr 7C:5A:1C:4A:82:38
              inet addr:192.168.1.1  Bcast:192.168.255.255  Mask:255.255.0.0
              inet6 addr: fe80::7e5a:1cff:fe4a:8238/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:108831544 errors:0 dropped:0 overruns:0 frame:0
              TX packets:145308612 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:40844307424 (38.0 GiB)  TX bytes:136560654162 (127.1 GiB)

  • Hi ,

    Running traceroute and packet capture simultaneously would help identify where the traffic stops and for what reason.

    Try to turn off firewall acceleration by running the following command from the console and see if that helps. 

    console>system firewall-acceleration disable

    Thanks,

     

     
    Harsh Patel (H_Patel)

    Community Support Engineer | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' button.

  • Hi H_Patel, good morning

    I disabled firewall acceleration but unfortunately the problem still persists.

    Below the tracert at the time of Lan's failure the first jump (in this case the XG) is not reached.

    Rastreando a rota para dns.google [8.8.8.8]
    com no máximo 30 saltos:

      1     *        *        *     Esgotado o tempo limite do pedido.
      2     *        *        *     Esgotado o tempo limite do pedido.
      3     *        *        *     Esgotado o tempo limite do pedido.
      4     *        *        *     Esgotado o tempo limite do pedido.
      5     *        *       11 ms  172.24.0.81
      6    11 ms    10 ms    10 ms  172.24.0.38
      7     9 ms    10 ms    13 ms  72.14.213.32
      8    12 ms    11 ms    20 ms  108.170.251.65

    Resposta de 192.168.1.1: bytes=32 tempo=2ms TTL=64
    Resposta de 192.168.1.1: bytes=32 tempo=2ms TTL=64
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Esgotado o tempo limite do pedido.
    Resposta de 192.168.1.1: bytes=32 tempo=2ms TTL=64
    Resposta de 192.168.1.1: bytes=32 tempo=3ms TTL=64

    The wan interfaces work normally, because I accessed the XG by the Wan address and pinged the internal network, but also without an answer.

     

    The hard thing is that nothing appears in the syslog or network logs. it seems that there is some type of scheduling that restarts some service every 4 hours, but I have not found where this is configured.

    Best regards.

  • Do you have STAS? 

    __________________________________________________________________________________________________________________

  • Could you share a screenshot of the STAS config in XG webadmin?

    __________________________________________________________________________________________________________________

  • Assuming 192.168.1.1 as Port1 interface IP address.

    Request to collect tcpdump and drop-packet-capture at the time of instance.

    Open two SSH sessions > 4. Device Console

    To collect tcpdump: console> tcpdump 'host 192.168.1.1 and proto ICMP

    To collect drop-packet: console> drop-packet-capture 'host 192.168.1.1 and proto ICMP


    It could be an issue with the internal network as well. To confirm that, is it possible to connect a laptop/desktop directly with Port1 interface in non-working hours to take an observation?

    Yash Kothari
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question, use the 'Verify Answer' link.
  • Thanks for the answer.

    Internal network I believe it is not. I already changed the lan interface of the XG switch including cables. But during the problem I can't access the appliance through the lan, but I can access it through the Wan from another firewall.