Hi all,
Is there a best practice for limiting ipsec tunnels? Managing the LAN and VoIP traffic was effective until ipsec tunnel was established. VoIP traffic is now dropping calls.
I tried marking traffic with a mangle rule and simple queue but seems ineffective.
Bandwidth management of VPN traffic is similar to management of non-VPN traffic, with a significant difference - you must not drop the transport (encrypted) packets, because the sequence numbers play an important role in authenticity check and if the gaps would be too large, valid packets would get rejected. So all the Tx bandwidth control must take place on the payload packets being sent before they get encapsulated into the VPN transport ones, and all the Rx bandwidth control must take place on the decapsulated payload.
Like with non-VPN traffic, in the download direction, you can control the bandwidth only indirectly, by controlling (slowing down) delivery of the received packets to the LAN side. Doing so only has an effect for flow types where the recipient provides a feedback to the sender (all TCP connections and some UDP ones where the application protocol carried by the UDP transport provides such feedback); for other flows, such as plain RTP for VoIP calls, no throttling in the download direction makes any sense as the sender will keep sending using the same bandwidth no matter what happens at your end, and there is no point in dropping packets which have already made it to you via the uplink as the download bandwidth on the uplink has already been consumed. An additional issue, which is not specific for VPN traffic, is how to classify the download traffic and choose which UDP flows are bandwidth-controllable and which are not, given that the DSCP field rarely survives transport via public internet (not only that ISP’s equipment ignores it, which is quite logical, but more often than not it rewrites it). So it doesn’t help you much that the transport packets inherit DSCP from the payload ones and vice versa even in tunnel mode.
So on departure, you use the same parent queue with a common bandwidth limit, matching the uplink’s upload bandwidh, for plaintext packets which will get encapsulated into VPN and for plaintext packets which will be sent directly through the same uplink, but you don’t place the VPN transport packets into any queue (as they are created from the payload ones which already have been throttled by a queue). Within the parent queue, set child queues with the max-limit etc. values as appropriate, and send plaintext packets which will later be sent via VPN to queues according to your chosen policy. In download direction, the same approach is necessary.
The above means that you cannot use interface queues as parents - you have to use the global parent.