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
  • Has there been any update for this?  I recently installed splunk and am seeing luckily for me this was my first google result to describe why google is sending my https udp packets!!  Is there a way to set up an exception to allow this traffic?
  • Has there been any update for this?  I recently installed splunk and am seeing luckily for me this was my first google result to describe why google is sending my https udp packets!!  Is there a way to set up an exception to allow this traffic?


    Hi, for now you may have to disable UDP flood protection.

    ^^
           
    Barry
  • Hi,

    I have noticed this the past few months and it's been driving me crazy, but I have found a workaround as in nearly a year this hasn't been addressed by anyone else as far as I can tell.

    I created a new network definition, called it HTTPS (UDP) for want of anything better, type:UDP, Source:1:65535, Destination:443, then added this as an exception for UDP Flooding detection. I thought this was at least better than completely disabling detection.

    I also have an exception for outbound from my internal network that also disables all flooding detection, as this was causing issues with a few games I was playing. Perhaps I may revisit this setting at another time.

    For now, Google's YouTube and YouTube Gaming streams work without a hitch at full 1080p60
  • Great research from previous posters, thanks for creating a reference for this issue.

    I took a slightly difference approach as opening up all UDP from any source and port going to 443 and disabling all flood detection was not acceptable here.

    I noticed all of these IPS blocks were coming from the 74.125.x.x range and host lookups verified that these were all 1e100.net hosts from Google.

    A quick ARIN search validates that Google has been allocated the entire 74.125 class B network.

    Therefore, I created an IPS exception that disables the IPS/Portscan and TCP/UDP/ICMP flood detection for the 74.125 range only.

    (edited to include more detailed screenshot)

  • Hi, we are having the same issue here. 
    Before disabling UDP flood detection: couldn't this be fixed somehow different?

    [code]2016:09:26-11:15:33 vpn ulogd[5341]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="ppp0" srcip="172.217.22.35" dstip="OUR-WAN" proto="17" length="1378" tos="0x00" prec="0x00" ttl="56" srcport="443" dstport="39729"[/code]

  • Thanks for posting that, David!

    For my clients, I configure the same subnet as Brent (74.125.0.0/16) with a Service of UDP443:1-65535, but I only except UDP Flood protection, not the other capabilities.  It looks like I'll need to add 172.217.0.0/16 to that Exception.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob, thanks for the answer :)

    I actually went through the IPS logs and identified (via NSLOOKUP) the IP ranges of Google and some other big companies I would expect to not be sending UDP flood.

    After adding those as exceptions (just UDP flood detection) my daily log of IPS shrinked from ~20-30MB to ~1-2MB 

Reply
  • Hi Bob, thanks for the answer :)

    I actually went through the IPS logs and identified (via NSLOOKUP) the IP ranges of Google and some other big companies I would expect to not be sending UDP flood.

    After adding those as exceptions (just UDP flood detection) my daily log of IPS shrinked from ~20-30MB to ~1-2MB 

Children
No Data