netdev - Shaping ingress and egress VPN traffic with OpenVPN or KLIPS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1328911022.3310.143.camel@denise.theartistscloset.com>
Date:	Fri, 10 Feb 2012 16:57:02 -0500
From:	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>
To:	netdev@...r.kernel.org
Subject: Shaping ingress and egress VPN traffic with OpenVPN or KLIPS

I've just emailed some questions about doing traffic shaping with IPSec
but I also have question when using OpenVPN since it uses a separate
interface, i.e., the tun interfaces. I suppose this would also be true
of systems still using KLIPS with ipsec interfaces like the Endian
firewalls.

Once again, with egress traffic, do we simply use a CONNMARK? Is that
preserved in the OpenVPN or KLIPS encapsulated packet?

For ingress traffic, I would think I would simply redirect traffic on
the tun or ipsec interfaces to the same ifb interface as the physical
interface uses for shaping.  However, since the original OpenVPN or ESP
traffic is also coming in on that interface, how do we properly shape
the traffic? Do we create a separate queue for the original traffic and
allocate it bandwidth equal to the sum of all the queues for the traffic
it might handle? Will it work to pass traffic to two separate ifb
interfaces, one for traffic coming in off of ipsec+ or tun+ and the
other for traffic coming in on the physical interface?

Thanks - John

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html