Is there a way to limit the sessions on bittorrent with Palo Alto ?
You can only enable a session limiter based on a service, but not on an application i think?
Anyone has some suggestions ?
Goal-> Limit bittorrent traffic. Users must be still able to download via bittorrent but the experience should be limited.
Is the end goal to limit the bandwidth consumed by bittorrent traffic? Session based limits of BT peer connections wouldn't give you as much control over the consumption of bandwidth since a few peers could have high throughput available and it wouldn't scale if you had a sudden increase in BT users.
I would probably look at a QoS policy to limit the max rate of BT traffic. You can apply the QoS profile to a rule specific to BT traffic and even apply it to specific users if you wanted to.
If you are hard set on session limits, I would create a separate service for your BT allow rule that included >1024 and then apply a DoS policy to that service. It should only match on the rule it's used in. I'd name it BT-Ports or something similar so it was obvious why it was created separately.
We apply QoS on peer-to-peer traffic to limit its use. Encrypted bittorrent traffic will show up as unknown-tcp and unknown-udp, so you might want to also limit those. Keep in mind that other completely unrelated applications could also show up as unknown-tcp and unknown-udp, so don't put the bandwidth limit too low. Actually, you could simply lower its priority.
I totally forgot about this community and now i can see the answers what i find fantastic!
I configured qos for bittorrent.
- 40 student buildings
- about 2000 hosts
- througput of 950Mbps during the evening as download
Best practice should be to configure qos policies based on source network as in network A= building A with a bittorrent limiter of 'y' Mbps.
Now, is this value 'y' session based or ip based ? Will the 'y' be divided up to the amount of hosts ?
I'm new to Palo Alto, and was researching limiting BitTorrent traffic and came across this post. But to try and answer the (dated) question, I believe you are going to be limiting on total defined bandwidth on your traffic class, in this case say class x=950Mbps where x= the class you set for bittorrent. Everything else is a match in your qos rule on what you want to limit to that bandwidth, like application, source ip, zone, etc.
For example, a single host could establish one or more sessions and theoretically receive BitTorrent traffic at speeds up to 950Mbps. Alternatively, if you have 50 users they will compete for bandwidth once the 950Mbps cap is reached, which would then queue packets according to your QoS policy.
In my case, I would be inclined to create two policies. One for "untrusted-bittorent" that defines a source of any, zones of any, application of bittorrent, and set a max cap of about 50Kbps and apply it campus wide. We find slowing it down is more effective than blocking it, because people are more likely to work around the block than the slow speeds. Then another rule for "trusted-bittorrent" allowing our users who have requested the application for legitimate reasons (pretty rare request, but does happen). Ticket process flags users to belong to a AD group, qos user-rule queries said AD group for matches, in turn allowing BitTorrent at a much higher data cap, ~950Mbps.
Does Bittorrent actually have a viable use-case in your enviroment? In most situations, this would be traffic that you could block outright without any issues, if not then you would want to put a pretty heavy QoS profile on it since you don't have much bandwidth to begin with.
Bittorrent by it's very nature will have a large amount of sessions associated with it, there really isn't any way around that seeing as its how it's designed to function.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!