Email and DNS Traffic Blocked as eDonkey Traffic

[MarcAEC]

The IT Help Desk received a report that multiple users at a site were unable to connect to an internal email server.  Upon investigating the event log, we found the MX decided to start blocking random traffic as NBAR ID 67, classification eDonkey based on the layer 7 rule to block eDonkey P2P traffic.  This appeared to ramp up Friday and continue through this week.  In addition to email traffic, I see it blocking DNS queries. 

Why would the MX think email and DNS traffic is P2P eDonkey traffic?  eDonkey is so old, it's quite possible 100% of the blocked traffic was false positives.

[ww]

Try run 16.16.5 fw if your not already using it

[MarcAEC]

The devices are on 16.16.5.  And there are 5 separate P2P layer 7 rules (BitTorrent, DC++, eDonkey, Gnutella, Kazaa), instead of a single "All peer to peer" rule due to the MX NBAR blocking Statistical Peer-to-peer traffic  incident.

[MarcAEC]

I ended up taking out the eDonkey layer 7 rule (so now down to 4).  I doubt that eDonkey is in use much these days, but not being able to contact the email server is a big deal.

[MarcAEC]

The latest Meraki eDonkey attack was blocking DNS forwards from spoke DNS servers to the hub DNS servers.  I had turned off eDonkey on the spoke templates, but hadn't changed the hub settings.  Now it's off at the hub as well. 

Interestingly, the templates have 5 L7 Peer-to-peer options.  A non-template MX has 29 options.  I wonder if the sites attached to the template have more than eDonkey disabled since I can't select the "All peer-to-peer (P2P)" option for them.

[TRBO_KCMO]

We have a sprinkle of 16.6.6 and 17.10. Just started popping up around September-ish. Still trying to determine if it's a false positive. We do not want SMB traffic if we can avoid it. Will probably fire up a packet capture