Copy DSCP value to ESP header for BOVPN
I would like to prioritize traffic over a BOVPN using DSCP. Packets can be assigned a DSCP value at the BOVPN-Allow policy level, however when those packets get re-encapsulated in an ESP header and sent out the external interface, no DSCP value is assigned (or rather it is set to 0). Is there a way to copy the DSCP value to the outer ESP header when sending packets over a VPN?
Here's documentation explaining how this works in Fortinet and Meraki equipment.
https://docs.fortinet.com/document/fortigate/7.0.0/administration-guide/28065/configure-dscp-for-ipsec-tunnels
https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/QoS_over_a_Site-to-site_VPN
0
Sign In to comment.
Comments
Is it enough to enable TOS for Ipsec?
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/global_vpn_settings_about_c.html
VPN -> VPN settings
Looks promising, I'll do some testing and find out.
This documentation implies that the Enable TOS for IPSec setting should do what I'm wanting but it doesn't seem to be working. All traffic exiting the external interface destined for the remote VPN endpoint has a DSCP value of CS0.
Initially I had the BOVPN-Allow.out policy configured to Assign a DSCP value. Thinking that maybe the Firebox couldn't both assign a DSCP value at the BOVPN policy level and copy that value to the ESP header, I disabled DSCP assignment at the BOVPN policy and marked the packets downstream at the switch. That would ensure that packets are marked when they enter the Firebox. Even then the marking was not preserved when encapsulating in an ESP header.
Note that the Firebox I'm testing is a M300 running v12.5.9.
Seems you are right. I just tested it on a bovpn with fireware 12.7.2
Tcpdump on ESP at the outgoing interface shows default tos 0x0
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
I have enabled QoS and set the dscp value to other than 0 on a test policy.
Is this a bug?
Perhaps? I had already opened a case inquiring about this functionality before you pointed out the Enable ToS for IPSec option. Waiting to hear back from support currently, I'll see what they have to say.
Odd, if i test with a virtual bovpn interface and capture ESP packets on the fysical outgoing interface the DSCP value is set.
Differentiated Services Field: 0x30 (DSCP: AF12, ECN: Not-ECT)
0011 00.. = Differentiated Services Codepoint: Assured Forwarding 12 (12)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
This is on a T20 running 12.7.2. The other test was on a M370.
On the T20, is the remote endpoint a Firebox? (i.e. is the Remote Endpoint Type for the BOVPN virtual interface set to Firebox?)
The documentation states...
"From the Remote Endpoint Type drop-down list, select either Firebox or Cloud VPN or Third-Party Gateway.
To connect to another Firebox, or to a third-party endpoint that supports GRE over IPSec, select Firebox.
To connect to a cloud VPN gateway such as Microsoft Azure, Amazon AWS, or another third-party endpoint that supports wildcard traffic selectors, select Cloud VPN or Third-Party Gateway. When you select this option, GRE is not used."
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/bovpn_vif_config_c.html
Just wondering of GRE encapsulation could be a factor here.
My bovpn remote end is set to Firebox, so yes, the tunnel are using GRE.
@pacificadmin
It´s not related to the GRE incapsulation. I just changed one of my virtual bovpn tunnels to a non firebox type removing the GRE option and the ESP packets is marked with the DSCP value, i have assigned on the firewall policy.
Good to know. My test setup is M300 (local) to T55 (remote). I removed the gateway/tunnel BOVPN configured between these endpoints and added a BOVPN virtual interface based tunnel. Like you, I'm now seeing ESP packets out the external interface on the M300 correctly marked with DSCP CS7.
So this seems to work with a virtual interface but not the traditional gateway/tunnel setup.
FYI, tech support has confirmed this to be a bug.