[strongSwan] Traffic shaping and IPsec

Heiko Wundram modelnine at modelnine.org
Tue Nov 3 15:56:17 CET 2015


Hey all,

I'm currently somewhat stumped by the interaction of egress traffic 
shaping with built-in Linux tc and IPsec tunnels (IKEv2, NAT-T) set up 
by strongSwan. As my web search(es) turned up no real hints, I'd be 
grateful for any information on how the packet flow actually works (it 
doesn't seem to work the way I understand it), so that I might adapt by 
tc rules accordingly.

Anyway, what I'm doing: I'm MARKing packets in the mangle POSTROUTING 
chain of the firewall on the corresponding host, setting up marks which 
are then used by generic tc filter rules to group packets in one of 
several buckets of an htb qdisc assigned to the default route interface 
(where the IPsec packets leave the host, too). On leaving the host, the 
packets are transformed with ipsec and ipcomp XFRM policies set up by 
strongSwan (those work), and from what I understood, the fwmark is 
preserved across this transformation (is it?). The packets are then 
grouped in one of the buckets (and they seem to be grouped, as I'm 
seeing a proper distribution of packets in the corresponding buckets), 
and from cursory view the bandwidth allocated to the bucket seems to be 
reached/filled (and htb says it is), but on the remote end, I'm seeing 
only a portion of the throughput inbound that the bucket on the outbound 
interface says it is sending at - it's somewhere between half and three 
quarters of the throughput assigned to the bucket.

 From what I understood, the ip_xfrm takes place before the packets are 
queued to the interface and the tc infrastructure is applied, so that 
basically the egress tc should see only the encapsulated packets (which 
is why I'm not using u32 marks but fwmarks to classify), but it seems 
that some/all(?) packets destined for the remote network are seen twice, 
and as such the bandwidth is halved(?).

Is this a known phenomenon, and/or what am I misunderstanding? Thanks 
for any hints!

-- 
--- Heiko.


More information about the Users mailing list