We'd love to hear about it! Click here to go to the product suggestion community
One of my clients has been trying to set up QoS properly for traffic handling/shaping based on firewall rules and traffic matching. This is so we can rate limit certain traffic to a specific traffic speed/cap based on destination so as not to exhaust the tiny pipe of 75Mbps.
There is an XG at both sides of the network, and we are trying to rate-limit traffic at one of the remote offices. The specific traffic we want to rate limit is over an IPSec point-to-point tunnel between the machines.
The rules were set up as follows in this ordering:
30Mbps - 50Mbps Shared
* Because of the different QoS priorities each of the starred items is its own separate traffic shaping policy
When we implemented these rules, however, we discovered that, in fact:
With regards to issue #2, this makes zero logical sense as to why traffic in the same VLAN that does NOT pass through the firewall (therefore, only the VLAN on the remote office side is going to itself), is breaking. Does anyone know if the QoS rules as defined (which we put ahead of all other rules - none of which have QoS rules - so we could 'test' and then 'disable' if the rules stopped working) would have contributed to intra-VLAN packet failures of this type?
As for #1, I can only attribute QoS filtration to this.
When all QoS rules were disabled, *everything* went back to normal functionality.
I can provide information and setup details here if necessary, though I'll have to sanitize it for my client's privacy.
Does anyone have any ideas what went wrong here?
Hi Thomas Ward Thank you for providing a detailed description of the issue.QoS should not block the traffic or communication when it's applied on the firewall rules. It seems to be strange behavior.The issue required a further investigation, I would request you to contact technical support and open a service request.Please PM us the service request number.
We spent a few hours on the phone with Sophos Support and managed to figure this one out. We *think* the application and web controls added on top of the QoS was interfering. Removing those and reactivating the rules (off/on) seemed to have fixed the issue for now.
In reply to Thomas Ward:
Hi Thomas Ward Thank you for sharing details, it will help other community members.