Re: [Shorewall-users] Traffic shaping with Shorewall and OpenVPN.

[Mchael B. <mic...@gm...>]

On 12-03-23 11:55 AM, Brian J. Murrell wrote:
> On 12-03-23 02:11 PM, Ryan on the Beach wrote:
>>
>>
>> Hello,
>> I've been using Shorewall for a long time and really like it.  I recently set up TOS using some of the online documentation and some guides online.  It works great.  However I've run into a new configuration which I'm not sure how to handle and was hoping some other users could give me some recommendations.
>> In my other configs I have on an outside and inside interface.  So defining the rules were fairly straight forward.  However in my latest setup I am trying to wrap my brain around using traffic shaping when there are two external interfaces.  One is obviously the external interface and the other is a tun0 which is the routed OpenVPN interface.  I just don't know how I should define the interfaces in tcinterfaces, especially since one is really just a virtual interface.  My main reason for wanting traffic shaping is because I have VOIP traffic traversing my OpenVPN tunnel along with other traffic and I wanted to make sure there is always enough bandwidth for the voice traffic.
>> I am hoping some other users have traffic shaping set up in the same way and can shed some light on how they handle having a two external interfaces, one real and one tunnel.
>
> It's actually more complicated than just two external interfaces.  The
> problem is that you want to be able to convey the "importance" (i.e.
> priority) of the voip packets that have been taken off of the VPN and
> wrapped into openvpn's udp packets at the next layer.
>
> That's not currently possible, AFAIK.  Such a thing is possible with
> IPsec AFAIU.
>
> Of course you could just tell the "real network" layer that all openvpn
> traffic has a high (i.e. voip) priority but if somebody starts doing
> some kind of bulk transfer through the VPN you've basically given that
> bulk the same high priority as voip and voided the priority of the voip
> traffic.  Furthermore you end up putting the lower priority traffic on
> the real network behind all openvpn traffic, even if it's bulk.
>
> b.

I guess one workaround could be to establish 2 OpenVPN connections with 
different QoS properties and redirect bulk and voice traffic to one or 
another accordingly.

Michael.