Limewire Pro running through a test ros 2.9.46 does not even show up as p2p traffic while operating and transferring files…
Any way to improve the detection or cause the p2p filters to work with the newer p2p software?
Even If I can’t stop it I can control it if it can be identified…
Thanks,
Scott
How are you currently Identifying it as p2p?
I did not mean to imply I was able to do it another way… I just realized it was speeding right through when testing some things with ros… I’m wondering how I might be able to deal with this stuff or if they (p2p networks) have finally won 
I know it is difficult because they don’t want to be identified - are the p2p filters going to be able to keep up and successfully identify the traffic…
I think I remember seeing some information somewhere about blocking the entire gnutella address space to cut off access to their servers but I’d rather not do that if possible.
Thanks,
Scott
Well i’ve been able to “tame” limewire with the built in p2p filter (2.9.46/rc4) are you sure you have the right chain selected in the firewall… its real simple essentially.
/
ip firewall filter
add chain=input p2p=all-p2p action=drop in-interface=(LAN)
also it helps to drop rouge tcp port ranges used by p2p
add chain=input port-range=1000-5000 protocol=tcp action=drop in-interface=(LAN)
If your aim is to throttle p2p and not kill it entirely just create a simple queue
/
queue simple
add name=p2p crap max-limit=128000/12800 (whatever you please really) p2p=all-p2p in-interface=(LAN)
In any event do a torch to see exactly what the traffic looks like …
Regards
Thanks for the info… I believe your solution works fine with the older limewire stuff but I just got hold of a limewire pro client and it works a bit differently. Seems to use random distributed ports and random other service ports to do its dirty work - none of the traffic generated by the limewire pro client showed up as p2p traffic in 2.9.46.
If it doesn’t get caught as p2p traffic in the ros “p2p detection criteria” then I wouldn’t really be able to use the settings you suggest to control that traffic. Again, I realize it works on the older stuff but I wanted to address if there was a way to handle the newer ways they are passing traffic.
I think in the end the only way to handle it would be to control/queue/prioritize everything you know about and throttle the rest. But that still leaves them using other service ports for their p2p service. They are playing dirty
I guess if I just wanted to block it all i could block all their IP space, but I have a feeling they have circumvented that problem too some how.
Thanks for your time -Scott
I’ve had so much trouble with P2P from one customer I’ve just throttled them down to a trickle during the day and allow them full bandwidth only during the night.
For the P2P filters in MikroTik to be useful they need to be kept up to date, after all we expect Anti-Virus companies to produce updates within hours of new viruses being detected. MikroTik need to be somewhat more pro-active in keeping ahead of the P2P game. I’m not expecting them to produce updates within hours, but once or twice a month should be an aim.
Imesh v7 is not working, I updated MT to 2.9.46.
also layer7 filter nor IPP2p does not work, I updated the protocols definitions and nothing.
Perhaps a script would work in this case?
Look for any highport connections (1025-65535) that are transferring at more than x amount and connected to more than x clients.
(I’d be looking for downloads over 1mb with 20+ connections to the same port)
Recheck these in 5 minutes time.
Limit or drop according to your preferences
Saves having to actually identify as p2p, and most p2p programs only set a port when they first startup?
If anyone sees a reason why this can’t be done, post now!
why not try this rule, apply to the greedy client’s ip only though!
this allow only 5 connection to an IP, Hope this help.
1 ;;; Limit connection to 5
chain=forward action=drop tcp-flags=syn src-address=192.168.1.119
protocol=tcp connection-limit=6,32
Both are good ideas but they are not perfect - I doubt any solution ever will be under the circumstances.
I came up with an idea after reading those two above… Origination tcp ports are generally random with destination ports usually defined as one of the standard service ports (telnet/smtp/http etc) Would blocking outbound access to non-standard ports cause a huge problem I’m not considering?
I also would still like to know if there is IP space from the gnutella networks command and control that could be blocked. I realize all the p2p stuff is distributed but the software has to check somewhere first to know whats out there - it doesn’t just scan randomly… It’s open source software I think, maybe I should take a peek inside
Scott
Yeah this just means they’ll always be getting bad connections to webpages and such. Windows standard is 50 concurrent tcp connections max.
Only if they want to use things like msn (file transfers, vidoe etc), games (any game that is online), streaming media and voip
It’s open source software I think, maybe I should take a peek inside >
Oh its easy enough for them to identify the traffic, just a lot harder to do on encrypted traffic in real-time… which is why people pay $10,000 and up (USD) for devices that can limit p2p traffic. These devices allow them to monitor and limit on the fly without adversely affecting speed.
If you knew where these programs originated their info fro once they became active it wouldn’t matter what type of traffic it was or if it were encrypted… would it?
Scott
Thats the inherent problem with p2p .. there’s no set location that it’s coming from but instead hundreds of peers.
Which is why I’m suggesting that it be a port based rule for clients you can control instead.