Shaping of traffic inside VPN tunnel?

[dhatz]

What's the current situation wrt shaping traffic inside an IPsec tunnel? Are there any limitations one should be aware of ?

I was under the impression that IPsec had some limitations (due to the way IPsec traffic is passed in the FreeBSD kernel) but I noticed this old message by Ermal:

Re: Traffic Shaping and IPSEC
« Reply #3 on: November 19, 2009, 11:04:36 am »

Actually on 1.2.3 you can shape inside the tunnel but i am not sure if the rules allow this to be setuped.
On 2.0 it is surely possible.

http://forum.pfsense.org/index.php/topic,19985.msg106174.html#msg106174

TIA.

[dhatz]

It seems that traffic shaping within an IPsec VPN is doable under OpenBSD, but I couldn't find any references on it for FreeBSD and enc(4) doesn't seem to be included in pfSense's interfaces.inc as an ALTQ-capable interface (function is_altq_capable()), whereas ovpns/c, pppoe, ng etc are.

Am I missing something here?

[MLIT]

It can kind of apply traffic shaping to items in the tunnel. You aren't creating queues for the tunnel for itself, but you are creating the queues on the physical interfaces in your PFsense box.

For instance:

We have a main office and a branch office. There is an IPsec VPN between the two offices. VoIP traffic and data transfers between our servers both use the same IPsec VPN. With PFsense, I can easily assign VoIP traffic to one queue (It is all to/from a certain network) and all other IPsec traffic to another queue. The shaping is done on the WAN or on the LAN interface.

[cmb]

@dhatz:

It seems that traffic shaping within an IPsec VPN is doable under OpenBSD, but I couldn't find any references on it for FreeBSD and enc(4) doesn't seem to be included in pfSense's interfaces.inc as an ALTQ-capable interface (function is_altq_capable()), whereas ovpns/c, pppoe, ng etc are.

Am I missing something here?

enc is never an assigned interface hence it's not needed there. You can shape within IPsec, it gets a bit complicated because part of your shaping has to accommodate the fact it's ESP traffic on WAN.

[dhatz]

@cmb:

it gets a bit complicated because part of your shaping has to accommodate the fact it's ESP traffic on WAN.

Ah, I see …

I wonder if it would be possible to copy the ToS byte from the original IP header to the new ESP header (or perhaps it's being done already?) In Cisco it's done by default, it's called the “ToS Byte Preservation” feature.

Edit: Based on a quick Google search, there seems to be a system tunable net.inet.ipsec.ah_cleartos that is set by default, but I don't see a corresponding ESP tunable.