Email and DNS Traffic Blocked as eDonkey Traffic

MarcAEC
Building a reputation

Email and DNS Traffic Blocked as eDonkey Traffic

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.

10 Replies 10
ww
Kind of a big deal
Kind of a big deal

Try run 16.16.5 fw if your not already using it

MarcAEC
Building a reputation

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
Building a reputation

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
Building a reputation

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
Getting noticed

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
Conversationalist

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
Just browsing

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 Port53
ProtocolUDP
Block TypeDNS
NBAR ID67
ClassificationeDonkey
Layer 7 firewall ruleDeny

 

 

MX 18.107.2

MarcAEC
Building a reputation

This is still not fixed?!?

This is fixed in 18.107.6 and above.

MarcAEC
Building a reputation

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".

Get notified when there are additional replies to this discussion.