Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 12736 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

2 minute delay with XG firewalls passing traffic from new user devices....

James Jackson

Hi All,

 

I have a ticket open with Sophos support for this but thought maybe the community can chip in too.

 

We have XG430s on our edge at our core and MPLS WAN links to our 8 sites and Cisco switches at our sites. Everything is working well.

Running SFOS 17.0.1 MR-1

 

However, when a new device connects to our network, either wired or wifi, it experiences a 2 minute delay before accessing the internet. I have a tcpdump showing the XG receives the packets and thinks that it has passed them on, but the wireshark capture from my ISP shows no activity for just over 2 minutes, and then there is activity.

 

I am using a class of device with a very simple XG rule applied to it - no IPS or scanning or malware detection or user lookup or ANYTHING AT ALL!

 

Once the device is known to the firewall it behaves fine. 

If I take the device off the network for a couple days (I am yet to determine precisely this time range) the next time it's on the network it gets the 2 minute delay again.

 

So I've just sent Support the ISP wireshark capture and they have responded saying they want to do some testing and believe mss values are something to do with it. I don't know if I believe mss values are anything to do with this at all.

I can only think it's something within the firewall.

 

Any thoughts/comments welcome



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

    Hi,

     

    maybe its related to the "Learning Stage" in STAS:

    https://community.sophos.com/kb/en-us/123156

     

    Drop timeout in Learning Mode

     

    Cheers

  • 0 in reply to LuCar Toni

    This sounds very likely to be the culprit, even though "match known users" isn't on for the rule I would bet STAS still takes effect.

     

    I have added an exclusion network for testing and will try tomorrow. Will also mention this to the support guys.

     

    Will update with any results.

    Thanks. 

  • 0 in reply to James Jackson

    Hi James,

    If you have STAS enabled, this sounds like your issue. I have the same issue, even on traffic between VLANs that use the XG as the gateway. You can SSH into the advance shell and type in drppkt | grep 'Identity' and you will most likely see the traffic you are talking about being dropped. I have our XG's learning mode down to 1 sec, have excluded the inter-vlan subnets in STAS, no user matching in the firewall rule, and we still see dropped packets. I believe support recommends no lower than 40 seconds or the XG may not learn the user. I have a case with Sophos as well but they are telling me it is not a bug, but a feature request, which I don't understand. It seems like a bug to me if you exclude a network but the XG still looks at the traffic for an identity. The "Feature Request" is being tracked as NC-26440. If yours turns out to be the same issue, I would ask for it to be escalated to product management. Maybe if enough of us have the issue, they will fix it.

    Thanks,

    Mike

Reply
  • 0 in reply to James Jackson

    Hi James,

    If you have STAS enabled, this sounds like your issue. I have the same issue, even on traffic between VLANs that use the XG as the gateway. You can SSH into the advance shell and type in drppkt | grep 'Identity' and you will most likely see the traffic you are talking about being dropped. I have our XG's learning mode down to 1 sec, have excluded the inter-vlan subnets in STAS, no user matching in the firewall rule, and we still see dropped packets. I believe support recommends no lower than 40 seconds or the XG may not learn the user. I have a case with Sophos as well but they are telling me it is not a bug, but a feature request, which I don't understand. It seems like a bug to me if you exclude a network but the XG still looks at the traffic for an identity. The "Feature Request" is being tracked as NC-26440. If yours turns out to be the same issue, I would ask for it to be escalated to product management. Maybe if enough of us have the issue, they will fix it.

    Thanks,

    Mike

Children
  • 0 in reply to MichaelBolton

    Hi Mike,

    I went to console but I get an error when I type drppkt, and can see no other similar commands. Where is this advanced shell you mentioned please?

     

    If it does turn out to be STAS, which I think it probs will, I would agree that it's a bug and push for it to be escalated to product management. Purely by not ticking "match known users" should disable lookups for that policy, let alone excluding networks...

  • 0 in reply to James Jackson

    Hi James,

    Once you SSH into the firewall, select option 5 "Device Management", then option 3 "Advance Shell", and type in drppkt | grep 'Identity'. Put a new device on the network and you should see the dropped traffic.

     

    I completely agree with you. If I don't check "match know users" the firewall should never check it. It is crazy to me that they call this a feature request and not a bug.

     

    Mike

  • 0 in reply to MichaelBolton

    Hi Michael,

     

    Thanks for the directions. I tried this and nothing appeared as I was testing with the device, yet the device still had the 2 minute delay.

     

    I will try on Monday with 2 devices and with STAS on or off for the whole firewall.

  • 0 in reply to James Jackson

    Right, progress!

     

    Today I changed the STAS timeout from 120 seconds to 45 seconds, then I did a connectivity test with a fresh device.

     

    Amazingly it didn't connect for 45 seconds but then after that traffic began to flow.

     

    So I've left STAS at 45 seconds and related my results to Sophos support and asked them to prioritise fixing the bug. It's 100% incorrect STAS lookups.

     

    If anyone else needs help with this I am happy to quote my experience.