Advisory: Support Portal Maintenance. Login is currently unavailable, more info available here.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos XG QoS Headaches

Hello.

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:

SRC DST What/Svc QoS Pri QoS Guarantee-Limit
LAN, 10.1.18.20 VPN, 10.1.2.200, 10.1.2.206, 10.1.2.25 Any 1

30Mbps - 50Mbps Shared

LAN, 10.1.6.0/23 VPN, 10.1.123.0/24 RDP 1
MGMT, Any Host VPN, 10.1.2.20 Any 2 10Mbps-40Mbps *
Any Zone, Any Host VPN, 10.1.2.20 tcp/7447 4 10Mbps-40Mbps *
Any Zone, Any Host VPN, Any Any 3 10Mbps-40Mbps *

VPN,MGMT,LAN
Any

WAN, Any Any 7 10Mbps-40Mbps *

* 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:

  1. Traffic between the two networks (local branch office and remote over the IPSec tunnel) failed to work for the QoS 3 rules - Windows systems remote-profile syncing across the VPN tunnel couldn't reach the profile shares server on the remote side with a timeout, and it broke Windows logons.
  2. Traffic within one of the *same* VLANs on the network appeared to cease flowing between systems on the same VLAN.

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?



This thread was automatically locked due to age.
Parents Reply Children
No Data