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

Google & "UDP flood" action

Hello

So to get straight to the point, I'm running Sophos UTM (FW Ver.: 9.203-3, Virtual) Home License and, as the thread title shows, browser-based Google products are affected by the IPS and some of its traffic are being tagged by the IPS as "UDP flood" firewall rule 60013, which is to Drop UDP_FLOOD attempts

As a result, some Google products will be capped at 2mbps download speeds. Strangely enough, it only happens to one wired client and not any virtualised clients nor wireless clients (so this means neither the LG Smart TV running YouTube nor the Android smartphone running Google Maps experience this issue.) When this plays out:

  • YouTube will load videos at 2mbps, causing buffer to 1080p videos and less often to 720p videos; and
  • Google Maps will load its chunks of map and image data slowly


Now, I can definitely turn off UDP flood protection, but that leaves a gigantic gap on my network. It's probably not the best practice when the UTM is responsible as the gateway between the Internet and my network at home. You now understand why this is probably something I would consider to avoid. I had disabled it for a minute and it definitely increased the loading speeds to what my ISP provides, which is 30x more than what it was throttling me to. As of right now, it's enabled.

Has anyone else experienced this issue? Has anyone found a fix for this? This started happening probably around the time where the OpenSSL Heartbleed vulnerability was discovered, if not a month or two before it.

UPDATE: Alright, so here's what's getting hit by IPS so that we all have that general idea...

IP of Google is the source IP. 
WAN IP is the destination.
Action is UDP Flood
Source Port: 443
Destination Port: Some random port on the 50000~60000s. 

Last time I checked, 443 isn't exactly UDP for the nature of what's being transported and a corporation like Google would keep atop for any such UDP floods to prevent it from happening.

Second Update
:
Please don't tell me this is too difficult. It has to be some simple explanation.
2014:07:14-16:40:20 core ulogd[4786]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="[Source MAC]" dstmac="[Destination MAC]" srcip="206.111.13.173" dstip="[My WAN IP]" proto="17" length="1228" tos="0x00" prec="0x00" ttl="57" srcport="443" dstport="55971"


Thanks


This thread was automatically locked due to age.
Parents
  • Hi All,

    Just to update, Google introduced QUIC protocol that communicates on UDP port 443. The protocol comes into picture while using Google Chrome as the web browser; incognito browsing on chrome will not use QUIC. The suggestion by Bob and Brent has to be considered when AntiDoS is configured.

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • Hi everyone,

    today I stumbled about this thread, cause I've viewed our IPS logs, as we got a new SG310 I turned on IPS.


    I recognized the suggested answer here, but had no luck. As there are a lot of these Google networks. So I decided to simply allow all of the QUIC traffic by creating an exception by service.

    But, this does not work - and I don't know why.
    I still get blocked entries like this:
    2016:11:03-19:21:21 gate-1 ulogd[5385]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth2" srcmac="00:xx:xx:xx:xx:xx" dstmac="00:xx:xx:xx:xx:xx" srcip="172.217.22.78" dstip="xx.xx.xx.xx" proto="17" length="113" tos="0x00" prec="0x00" ttl="60" srcport="443" dstport="62099"
    Has anyone an idea why the rule is not working?

    Thanks

  • Great way to post an issue - you anticipated the first question and answered it already!

    srcport="443" => Just clone that Service, change the name of the new one to, for example, "QUIC Responses," exchange the contents of Source and Destination and add the Service to your Exception.

    Note that this new service was the one I recommended earlier in the thread.  I've not seen a situation that requires an Exception for QUIC requests, but it probably doesn't hurt anything for you to leave it in place.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Great way to post an issue - you anticipated the first question and answered it already!

    srcport="443" => Just clone that Service, change the name of the new one to, for example, "QUIC Responses," exchange the contents of Source and Destination and add the Service to your Exception.

    Note that this new service was the one I recommended earlier in the thread.  I've not seen a situation that requires an Exception for QUIC requests, but it probably doesn't hurt anything for you to leave it in place.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children