Help setting up home router

Help setting up home router

[Gonçalo Luiz]

Hi,

I've been reading all the material I could get my hands on, but there
is a small detail I seem unable to get my head around. Let me show you
my setup first

1 linux PC (router) with two physical NICs: eth0 (inner facing) and
eth1 (outer facing)
many clients behind a switch to where eth0 connects to
three network namespaces in the router, whose veths bridge with eth0 in br0
one OpenVPN VPN running on the router, through which I'm sending some
traffic originating from a few source IPs. Let's call it tun0

what I want to do: apply traffic control to the outer facing,
controlling *all* the outgoing traffic. For simplicity let's assume I
want to apply the rules based solely on the source IP

my first instinct was to configure the qdiscs on eth1 egress. Seems to
me that this is the only way I can also apply the control to packets
originating in the router as they go straight away to the exit
interface (eth1).

The problem I'm facing is that the traffic that goes through tun0
presents itself to eth1, obviously, already compressed and without the
real source IP information (can come from any of the clients or
network namespaces on the router) and therefore I cannot infer what
class should assign to it. In practice, VPN turns all it's traffic
opaque and I cannot treat it differently depending on the client
originating it.

my second instinct was to shape tun0 ingress (through an IFB) along
with eth0 egress by redirecting both to an IFB and shapping it there.
Sadly this leaves traffic originating in the router itself out.

lastly I've tried to add an iptables mark to the packets that are
going through tun0 before they go through the compressing process but
it seems to be lost when they come out of the other side of it. If
they were not perhaps I could apply traffic control based on iptables
marks instead of source IPs if I marked all the packets as soon as
they land on the router or are originated in the router.

Any ideas? I fell this must be possible but am running out of ideas.

Thanks.

Gonçalo


Gonçalo Luiz

RE: Help setting up home router

[I-Strong, Russell J]

SGksDQoNCkkndmUgbmV2ZXIgdHJpZWQgdGhpcyB3aXRoIG9wZW52cG4sIGJ1dCB0aGVyZSBpcyBh
IC0tcGFzc3RvcyBvcHRpb24gd2hpY2ggc2V0cyB0aGUgVE9TIGZpZWxkIG9mIHRoZSB0dW5uZWwg
cGFja2V0IHRvIHdoYXQgdGhlIHBheWxvYWQncyBUT1MgaXMuIEkndmUgZG9uZSB0aGlzIHNvcnQg
b2YgdGhpbmcgYmVmb3JlIHdpdGggR1JFIHR1bm5lbHMuICBUaGV5IGhhdmUgYW4gaW5oZXJpdCBv
cHRpb24uDQoNClJ1c3NlbGwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxh
cnRjLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxhcnRjLW93bmVyQHZnZXIua2VybmVs
Lm9yZ10gT24gQmVoYWxmIE9mIEdvbsOnYWxvIEx1aXoNClNlbnQ6IFRodXJzZGF5LCA4IEphbnVh
cnkgMjAxNSA3OjQwIFBNDQpUbzogbGFydGNAdmdlci5rZXJuZWwub3JnDQpTdWJqZWN0OiBIZWxw
IHNldHRpbmcgdXAgaG9tZSByb3V0ZXINCg0KSGksDQoNCkkndmUgYmVlbiByZWFkaW5nIGFsbCB0
aGUgbWF0ZXJpYWwgSSBjb3VsZCBnZXQgbXkgaGFuZHMgb24sIGJ1dCB0aGVyZSBpcyBhIHNtYWxs
IGRldGFpbCBJIHNlZW0gdW5hYmxlIHRvIGdldCBteSBoZWFkIGFyb3VuZC4gTGV0IG1lIHNob3cg
eW91IG15IHNldHVwIGZpcnN0DQoNCjEgbGludXggUEMgKHJvdXRlcikgd2l0aCB0d28gcGh5c2lj
YWwgTklDczogZXRoMCAoaW5uZXIgZmFjaW5nKSBhbmQNCmV0aDEgKG91dGVyIGZhY2luZykNCm1h
bnkgY2xpZW50cyBiZWhpbmQgYSBzd2l0Y2ggdG8gd2hlcmUgZXRoMCBjb25uZWN0cyB0byB0aHJl
ZSBuZXR3b3JrIG5hbWVzcGFjZXMgaW4gdGhlIHJvdXRlciwgd2hvc2UgdmV0aHMgYnJpZGdlIHdp
dGggZXRoMCBpbiBicjAgb25lIE9wZW5WUE4gVlBOIHJ1bm5pbmcgb24gdGhlIHJvdXRlciwgdGhy
b3VnaCB3aGljaCBJJ20gc2VuZGluZyBzb21lIHRyYWZmaWMgb3JpZ2luYXRpbmcgZnJvbSBhIGZl
dyBzb3VyY2UgSVBzLiBMZXQncyBjYWxsIGl0IHR1bjANCg0Kd2hhdCBJIHdhbnQgdG8gZG86IGFw
cGx5IHRyYWZmaWMgY29udHJvbCB0byB0aGUgb3V0ZXIgZmFjaW5nLCBjb250cm9sbGluZyAqYWxs
KiB0aGUgb3V0Z29pbmcgdHJhZmZpYy4gRm9yIHNpbXBsaWNpdHkgbGV0J3MgYXNzdW1lIEkgd2Fu
dCB0byBhcHBseSB0aGUgcnVsZXMgYmFzZWQgc29sZWx5IG9uIHRoZSBzb3VyY2UgSVANCg0KbXkg
Zmlyc3QgaW5zdGluY3Qgd2FzIHRvIGNvbmZpZ3VyZSB0aGUgcWRpc2NzIG9uIGV0aDEgZWdyZXNz
LiBTZWVtcyB0byBtZSB0aGF0IHRoaXMgaXMgdGhlIG9ubHkgd2F5IEkgY2FuIGFsc28gYXBwbHkg
dGhlIGNvbnRyb2wgdG8gcGFja2V0cyBvcmlnaW5hdGluZyBpbiB0aGUgcm91dGVyIGFzIHRoZXkg
Z28gc3RyYWlnaHQgYXdheSB0byB0aGUgZXhpdCBpbnRlcmZhY2UgKGV0aDEpLg0KDQpUaGUgcHJv
YmxlbSBJJ20gZmFjaW5nIGlzIHRoYXQgdGhlIHRyYWZmaWMgdGhhdCBnb2VzIHRocm91Z2ggdHVu
MCBwcmVzZW50cyBpdHNlbGYgdG8gZXRoMSwgb2J2aW91c2x5LCBhbHJlYWR5IGNvbXByZXNzZWQg
YW5kIHdpdGhvdXQgdGhlIHJlYWwgc291cmNlIElQIGluZm9ybWF0aW9uIChjYW4gY29tZSBmcm9t
IGFueSBvZiB0aGUgY2xpZW50cyBvciBuZXR3b3JrIG5hbWVzcGFjZXMgb24gdGhlIHJvdXRlcikg
YW5kIHRoZXJlZm9yZSBJIGNhbm5vdCBpbmZlciB3aGF0IGNsYXNzIHNob3VsZCBhc3NpZ24gdG8g
aXQuIEluIHByYWN0aWNlLCBWUE4gdHVybnMgYWxsIGl0J3MgdHJhZmZpYyBvcGFxdWUgYW5kIEkg
Y2Fubm90IHRyZWF0IGl0IGRpZmZlcmVudGx5IGRlcGVuZGluZyBvbiB0aGUgY2xpZW50IG9yaWdp
bmF0aW5nIGl0Lg0KDQpteSBzZWNvbmQgaW5zdGluY3Qgd2FzIHRvIHNoYXBlIHR1bjAgaW5ncmVz
cyAodGhyb3VnaCBhbiBJRkIpIGFsb25nIHdpdGggZXRoMCBlZ3Jlc3MgYnkgcmVkaXJlY3Rpbmcg
Ym90aCB0byBhbiBJRkIgYW5kIHNoYXBwaW5nIGl0IHRoZXJlLg0KU2FkbHkgdGhpcyBsZWF2ZXMg
dHJhZmZpYyBvcmlnaW5hdGluZyBpbiB0aGUgcm91dGVyIGl0c2VsZiBvdXQuDQoNCmxhc3RseSBJ
J3ZlIHRyaWVkIHRvIGFkZCBhbiBpcHRhYmxlcyBtYXJrIHRvIHRoZSBwYWNrZXRzIHRoYXQgYXJl
IGdvaW5nIHRocm91Z2ggdHVuMCBiZWZvcmUgdGhleSBnbyB0aHJvdWdoIHRoZSBjb21wcmVzc2lu
ZyBwcm9jZXNzIGJ1dCBpdCBzZWVtcyB0byBiZSBsb3N0IHdoZW4gdGhleSBjb21lIG91dCBvZiB0
aGUgb3RoZXIgc2lkZSBvZiBpdC4gSWYgdGhleSB3ZXJlIG5vdCBwZXJoYXBzIEkgY291bGQgYXBw
bHkgdHJhZmZpYyBjb250cm9sIGJhc2VkIG9uIGlwdGFibGVzIG1hcmtzIGluc3RlYWQgb2Ygc291
cmNlIElQcyBpZiBJIG1hcmtlZCBhbGwgdGhlIHBhY2tldHMgYXMgc29vbiBhcyB0aGV5IGxhbmQg
b24gdGhlIHJvdXRlciBvciBhcmUgb3JpZ2luYXRlZCBpbiB0aGUgcm91dGVyLg0KDQpBbnkgaWRl
YXM/IEkgZmVsbCB0aGlzIG11c3QgYmUgcG9zc2libGUgYnV0IGFtIHJ1bm5pbmcgb3V0IG9mIGlk
ZWFzLg0KDQpUaGFua3MuDQoNCkdvbsOnYWxvDQoNCg0KR29uw6dhbG8gTHVpeg0KLS0NClRvIHVu
c3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsYXJ0
YyIgaW4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcg
TW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8t
aW5mby5odG1sDQo

Re: Help setting up home router

[Gonçalo Luiz]

Hi,

Thank you for your replies.

Russel's suggestion indeed works but is not quite what I'm aiming for.
While respecting the TOS header is often a good idea, what I really
need is to pivot the QoS decision in the source IP as some source IPs
will have very low priority despite the TOS header.

I can do this by shaping the tunnel ingress (by means of shaping an
IFB egress that mirrors it) along (i.e. on the same HTB qdisc) with
the bridge egress (also mirrored to the same IFB). The only thing I'm
missing is how throw into the (same IFB) mix the locally generated
packages.

A workaround would be to shape eth1 egress with a simple PRIO (work
connserving) assigning whatever comes out of br0 and the tunnel (i.e.
what has already been shaped into a given bit rate) lower priority
than everything else (i.e. the locally generated traffic) as usually
on a router whatever generates traffic has super priority (it's
usually remote admin work, ssh for example) and not services or user
traffic.

How does that sound ?

G.
Gonçalo Luiz


On 9 January 2015 at 01:05, Raul Dias <raul@dias.com.br> wrote:
> That's very close to what I had to do with TINC in a similar scenery.
>
> -rsd
>
> On 8 Jan 2015 20:12, "I-Strong, Russell J" <Russell.J.Strong@boeing.com>
> wrote:
>>
>> Hi,
>>
>> I've never tried this with openvpn, but there is a --passtos option which
>> sets the TOS field of the tunnel packet to what the payload's TOS is. I've
>> done this sort of thing before with GRE tunnels.  They have an inherit
>> option.
>>
>> Russell
>>
>> -----Original Message-----
>> From: lartc-owner@vger.kernel.org [mailto:lartc-owner@vger.kernel.org] On
>> Behalf Of Gonçalo Luiz
>> Sent: Thursday, 8 January 2015 7:40 PM
>> To: lartc@vger.kernel.org
>> Subject: Help setting up home router
>>
>> Hi,
>>
>> I've been reading all the material I could get my hands on, but there is a
>> small detail I seem unable to get my head around. Let me show you my setup
>> first
>>
>> 1 linux PC (router) with two physical NICs: eth0 (inner facing) and
>> eth1 (outer facing)
>> many clients behind a switch to where eth0 connects to three network
>> namespaces in the router, whose veths bridge with eth0 in br0 one OpenVPN
>> VPN running on the router, through which I'm sending some traffic
>> originating from a few source IPs. Let's call it tun0
>>
>> what I want to do: apply traffic control to the outer facing, controlling
>> *all* the outgoing traffic. For simplicity let's assume I want to apply the
>> rules based solely on the source IP
>>
>> my first instinct was to configure the qdiscs on eth1 egress. Seems to me
>> that this is the only way I can also apply the control to packets
>> originating in the router as they go straight away to the exit interface
>> (eth1).
>>
>> The problem I'm facing is that the traffic that goes through tun0 presents
>> itself to eth1, obviously, already compressed and without the real source IP
>> information (can come from any of the clients or network namespaces on the
>> router) and therefore I cannot infer what class should assign to it. In
>> practice, VPN turns all it's traffic opaque and I cannot treat it
>> differently depending on the client originating it.
>>
>> my second instinct was to shape tun0 ingress (through an IFB) along with
>> eth0 egress by redirecting both to an IFB and shapping it there.
>> Sadly this leaves traffic originating in the router itself out.
>>
>> lastly I've tried to add an iptables mark to the packets that are going
>> through tun0 before they go through the compressing process but it seems to
>> be lost when they come out of the other side of it. If they were not perhaps
>> I could apply traffic control based on iptables marks instead of source IPs
>> if I marked all the packets as soon as they land on the router or are
>> originated in the router.
>>
>> Any ideas? I fell this must be possible but am running out of ideas.
>>
>> Thanks.
>>
>> Gonçalo
>>
>>
>> Gonçalo Luiz
>> --
>> To unsubscribe from this list: send the line "unsubscribe lartc" in the
>> body of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html

Re: Help setting up home router

[Dave Taht]

On Fri, Jan 9, 2015 at 12:49 AM, Gonçalo Luiz <goncalo.luiz@gmail.com> wrote:
> Hi,
>
> Thank you for your replies.

My own answer is to try to *first* - offer fair and aqm'd service to
all traffic exiting and entering the external interface with something
like sqm-scripts + fq_codel. That fixes a lot.

After that you can try deprioritizing certain kinds of traffic, and
prioritizing a very few kinds of traffic.

>
> Russel's suggestion indeed works but is not quite what I'm aiming for.
> While respecting the TOS header is often a good idea, what I really
> need is to pivot the QoS decision in the source IP as some source IPs
> will have very low priority despite the TOS header.

The way sqm-scripts does it is to fw or TOS mark based on whatever you
want and then toss that into one of three prioritized bins (priority,
best effort, and background).

Dealing with vpn traffic is harder, unless you want to fit it into one
of those 3 bins. Recently I started work on finding better ways to FQ
vpn traffic, but it involves changes to the underlying daemons and
protocols.

>
> I can do this by shaping the tunnel ingress (by means of shaping an
> IFB egress that mirrors it) along (i.e. on the same HTB qdisc) with
> the bridge egress (also mirrored to the same IFB). The only thing I'm
> missing is how throw into the (same IFB) mix the locally generated
> packages.
>
> A workaround would be to shape eth1 egress with a simple PRIO (work
> connserving) assigning whatever comes out of br0 and the tunnel (i.e.
> what has already been shaped into a given bit rate) lower priority
> than everything else (i.e. the locally generated traffic) as usually
> on a router whatever generates traffic has super priority (it's
> usually remote admin work, ssh for example) and not services or user
> traffic.
>
> How does that sound ?
>
> G.
> Gonçalo Luiz
>
>
> On 9 January 2015 at 01:05, Raul Dias <raul@dias.com.br> wrote:
>> That's very close to what I had to do with TINC in a similar scenery.
>>
>> -rsd
>>
>> On 8 Jan 2015 20:12, "I-Strong, Russell J" <Russell.J.Strong@boeing.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I've never tried this with openvpn, but there is a --passtos option which
>>> sets the TOS field of the tunnel packet to what the payload's TOS is. I've
>>> done this sort of thing before with GRE tunnels.  They have an inherit
>>> option.
>>>
>>> Russell
>>>
>>> -----Original Message-----
>>> From: lartc-owner@vger.kernel.org [mailto:lartc-owner@vger.kernel.org] On
>>> Behalf Of Gonçalo Luiz
>>> Sent: Thursday, 8 January 2015 7:40 PM
>>> To: lartc@vger.kernel.org
>>> Subject: Help setting up home router
>>>
>>> Hi,
>>>
>>> I've been reading all the material I could get my hands on, but there is a
>>> small detail I seem unable to get my head around. Let me show you my setup
>>> first
>>>
>>> 1 linux PC (router) with two physical NICs: eth0 (inner facing) and
>>> eth1 (outer facing)
>>> many clients behind a switch to where eth0 connects to three network
>>> namespaces in the router, whose veths bridge with eth0 in br0 one OpenVPN
>>> VPN running on the router, through which I'm sending some traffic
>>> originating from a few source IPs. Let's call it tun0
>>>
>>> what I want to do: apply traffic control to the outer facing, controlling
>>> *all* the outgoing traffic. For simplicity let's assume I want to apply the
>>> rules based solely on the source IP
>>>
>>> my first instinct was to configure the qdiscs on eth1 egress. Seems to me
>>> that this is the only way I can also apply the control to packets
>>> originating in the router as they go straight away to the exit interface
>>> (eth1).
>>>
>>> The problem I'm facing is that the traffic that goes through tun0 presents
>>> itself to eth1, obviously, already compressed and without the real source IP
>>> information (can come from any of the clients or network namespaces on the
>>> router) and therefore I cannot infer what class should assign to it. In
>>> practice, VPN turns all it's traffic opaque and I cannot treat it
>>> differently depending on the client originating it.
>>>
>>> my second instinct was to shape tun0 ingress (through an IFB) along with
>>> eth0 egress by redirecting both to an IFB and shapping it there.
>>> Sadly this leaves traffic originating in the router itself out.
>>>
>>> lastly I've tried to add an iptables mark to the packets that are going
>>> through tun0 before they go through the compressing process but it seems to
>>> be lost when they come out of the other side of it. If they were not perhaps
>>> I could apply traffic control based on iptables marks instead of source IPs
>>> if I marked all the packets as soon as they land on the router or are
>>> originated in the router.
>>>
>>> Any ideas? I fell this must be possible but am running out of ideas.
>>>
>>> Thanks.
>>>
>>> Gonçalo
>>>
>>>
>>> Gonçalo Luiz
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe lartc" in the
>>> body of a message to majordomo@vger.kernel.org More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: Help setting up home router

[Andy Furniss]

Gonçalo Luiz wrote:
> Hi,
>
> I've been reading all the material I could get my hands on, but
> there is a small detail I seem unable to get my head around. Let me
> show you my setup first
>
> 1 linux PC (router) with two physical NICs: eth0 (inner facing) and
> eth1 (outer facing) many clients behind a switch to where eth0
> connects to three network namespaces in the router, whose veths
> bridge with eth0 in br0 one OpenVPN VPN running on the router,
> through which I'm sending some traffic originating from a few source
> IPs. Let's call it tun0
>
> what I want to do: apply traffic control to the outer facing,
> controlling *all* the outgoing traffic. For simplicity let's assume
> I want to apply the rules based solely on the source IP
>
> my first instinct was to configure the qdiscs on eth1 egress. Seems
> to me that this is the only way I can also apply the control to
> packets originating in the router as they go straight away to the
> exit interface (eth1).
>
> The problem I'm facing is that the traffic that goes through tun0
> presents itself to eth1, obviously, already compressed and without
> the real source IP information (can come from any of the clients or
> network namespaces on the router) and therefore I cannot infer what
> class should assign to it. In practice, VPN turns all it's traffic
> opaque and I cannot treat it differently depending on the client
> originating it.
>
> my second instinct was to shape tun0 ingress (through an IFB) along
> with eth0 egress by redirecting both to an IFB and shapping it
> there. Sadly this leaves traffic originating in the router itself
> out.
>
> lastly I've tried to add an iptables mark to the packets that are
> going through tun0 before they go through the compressing process
> but it seems to be lost when they come out of the other side of it.
> If they were not perhaps I could apply traffic control based on
> iptables marks instead of source IPs if I marked all the packets as
> soon as they land on the router or are originated in the router.
>
> Any ideas? I fell this must be possible but am running out of ideas.

Untested and probably not thought through very well!

Maybe you can redirect to the same ifb from tun0 and eth1 use iptables
marks to distinguish what came in eth0 (rules/mark in forward) and local
(rules/mark in output) then redirect to the same ifb from tun0 and eth1.

Some thoughts/hints.

Good that this is egress.

If you want to add a filter to an egress IF you need some qdisc on it so
add prio.

You need to avoid doubly catching tun0 traffic so mark everything you
need to shape and on eth1 just redirect marked traffic (this assumes you
can find a way to make all tun0 traffic on eth1 not be marked but still
mark local in output hmm - I am not sure about tuns and how/where tunnel
traffic is seen by netfilter).

To do this work in full 32bit hex (iptables) for the marks and use u32
to match the marks on filters so you can use masks. This way you could
arrange for say the top bit to be set on everything marked so you could
filter just on that bit for the redirect on eth1. For the filters on ifb
qdisc you can then exclude that bit.

Some testing/trial and error needed :-)