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

[sebvasseur]

the same problem happen sometimes and block all dns traffic during 1 or 2  hours (dns such 1.1.1.1 !!!)  reply from support :"If the DNS traffic is being blocked and classified as edonkey then I would advise you to remove the P2P category rule."  thanks but this is a workaround not a solution. MX 18.107.2   

[Iansays1]

This just happened on our MX 100, and lasted about 15 minutes, blocking or dropping almost all DNS traffic to 8.8.8.8 and 1.1.1.1, which, of course, brought most internet and email connectivity to a standstill. Looking back through the last few weeks logs, this has been happening sporadicially for the past 30 days, but nothing like the volume of traffic flagged this morning.

Source IP: <redacted>, Source Port: 51406, Destination IP: 8.8.8.8  « hide

Destination Port	53
Protocol	UDP
Block Type	DNS
NBAR ID	67
Classification	eDonkey
Layer 7 firewall rule	Deny

MX 18.107.2

[MarcAEC]

This is still not fixed?!?

[chakshu]

This is fixed in 18.107.6 and above.

[MarcAEC]

There's a bit of problem with this.  The firmware page shows the most recent Stable release as 18.107.2.  A newer version of 18.107 is buried in the Other available versions section at the end.  Stable patches used to be visible in the Stable section.  In fact, the organization of the tabs has been recognized as declining in stability from left to right (Stable > Stable RC, Beta).  The label Other available versions communicates "don't look here unless you know what you are doing".