[LARTC] qos inside ipsec tunnel

[LARTC] qos inside ipsec tunnel

[Marco Berizzi]

Hello everybody.
I would like to do some kind of shaping inside an
ipsec tunnel implemented by Openswan and linux
2.6.18.x with xfrm (no KLIPS): for example, to
limit outbound smtp traffic inside the tunnel.
Question: where should I attach the qdisc to? Eth0?
I'm asking this, because tcpdump only see the ESP
packet on the eth0 and not the 'clear' packet.

TIA

This is my simple network schema:

        ____ private lan A
       /
       |
       |eth1
   +---+----+
   |        |
   | 2.6.18 |
   |openswan| Ipsec gateway
   |        |
   +---+----+
       |eth0
       |
      I|
      P|i
      S|n
      E|t
      C|e
       |r
      T|n
      U|e
      N|t
      N|
      E|
      L|eth0
   +---+----+
   |        |
   | 2.6.18 |
   |openswan| Ipsec gateway
   |        |
   +---+----+
       |eth1
       |
       \____ private lan B



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

AW: [LARTC] qos inside ipsec tunnel

[Martin Bene]

Hi Marco,

> Hello everybody.
> I would like to do some kind of shaping inside an
> ipsec tunnel implemented by Openswan and linux
> 2.6.18.x with xfrm (no KLIPS): for example, to
> limit outbound smtp traffic inside the tunnel.
> Question: where should I attach the qdisc to? Eth0?
> I'm asking this, because tcpdump only see the ESP
> packet on the eth0 and not the 'clear' packet.

Heh  - just subscribed to LARC list because I'm working on a similar
problem. 

Yes, you'll have to attach your classes to eth0 device. However, by the
time qos gets to see the packets, they'll be encrypted, so you won't be
able to just use tc filter with u32 classifier to select on port 25.

What should work is to mark the packets in PREROUTING in the mangle
table and assign them to the classes you want based on the fwmark:

iptables -t mangle -A PREROUTING -d <private ip vpn remote side>/24 -p
tcp -m multiport --port 25 -j MARK --set-mark 102
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 102 fw
flowid 1:20

Hope this helps, Martin
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: AW: [LARTC] qos inside ipsec tunnel

[Mohan Sundaram]

Martin Bene wrote:
> Hi Marco,
> 
>> Hello everybody.
>> I would like to do some kind of shaping inside an
>> ipsec tunnel implemented by Openswan and linux
>> 2.6.18.x with xfrm (no KLIPS): for example, to
>> limit outbound smtp traffic inside the tunnel.
>> Question: where should I attach the qdisc to? Eth0?
>> I'm asking this, because tcpdump only see the ESP
>> packet on the eth0 and not the 'clear' packet.
> 
> Heh  - just subscribed to LARC list because I'm working on a similar
> problem. 
> 
> Yes, you'll have to attach your classes to eth0 device. However, by the
> time qos gets to see the packets, they'll be encrypted, so you won't be
> able to just use tc filter with u32 classifier to select on port 25.
> 
> What should work is to mark the packets in PREROUTING in the mangle
> table and assign them to the classes you want based on the fwmark:
> 
> iptables -t mangle -A PREROUTING -d <private ip vpn remote side>/24 -p
> tcp -m multiport --port 25 -j MARK --set-mark 102
> tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 102 fw
> flowid 1:20
> 
> Hope this helps, Martin
Has anyone tested this? Does the mark get carried across encapsulations 
or is the packet context a new one on encapsulation? I know that IPSec 
RFC says inner packet headers have to be copied to the outer header. 
Does that include the TOS byte too? Do not know what OpenSWAN does. If 
that were the case, assigning TOS prior to encapsulation and classifying 
by TOS at the device will work.

Mohan
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

AW: AW: [LARTC] qos inside ipsec tunnel

[Martin Bene]

Hi Mohan,

> > What should work is to mark the packets in PREROUTING in the mangle 
> > table and assign them to the classes you want based on the fwmark:

> Has anyone tested this? Does the mark get carried across 
> encapsulations or is the packet context a new one on 
> encapsulation? 

Yes, I have tested this. The fwmark is preserved/copied to the encrypted
packet. I've set up a test system using 4 virtual machines in a vmware
environment to give me two ipsec routers and a seperate client for each
:-)

> I know that IPSec RFC says inner packet 
> headers have to be copied to the outer header. 
> Does that include the TOS byte too? Do not know what OpenSWAN 
> does. If that were the case, assigning TOS prior to 
> encapsulation and classifying by TOS at the device will work.

Openswan shouldn't come into the picuture in this case: original poster
isn't using the openswan ipsec stack (klips), just the userspace tools,
so we're just dealing with the standard/in-kernel ipsec implementation.

I haven't tried setting/classifying by tos - I'm happy with the fwmark
method.

Bye, Martin
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: AW: [LARTC] qos inside ipsec tunnel

[John Serink]

Bring up a GRE tunnel inside the IPSec tunnel.
Then use tc to shape the BW on the tunnel,
Then use tc to shape the BW on the outgoing interface, eg ppp1.

Cheers,
John

--- Mohan Sundaram <mohan.tux@gmail.com> wrote:

> Martin Bene wrote:
> > Hi Marco,
> > 
> >> Hello everybody.
> >> I would like to do some kind of shaping inside an
> >> ipsec tunnel implemented by Openswan and linux
> >> 2.6.18.x with xfrm (no KLIPS): for example, to
> >> limit outbound smtp traffic inside the tunnel.
> >> Question: where should I attach the qdisc to? Eth0?
> >> I'm asking this, because tcpdump only see the ESP
> >> packet on the eth0 and not the 'clear' packet.
> > 
> > Heh  - just subscribed to LARC list because I'm working on a similar
> > problem. 
> > 
> > Yes, you'll have to attach your classes to eth0 device. However, by the
> > time qos gets to see the packets, they'll be encrypted, so you won't be
> > able to just use tc filter with u32 classifier to select on port 25.
> > 
> > What should work is to mark the packets in PREROUTING in the mangle
> > table and assign them to the classes you want based on the fwmark:
> > 
> > iptables -t mangle -A PREROUTING -d <private ip vpn remote side>/24 -p
> > tcp -m multiport --port 25 -j MARK --set-mark 102
> > tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 102 fw
> > flowid 1:20
> > 
> > Hope this helps, Martin
> Has anyone tested this? Does the mark get carried across encapsulations 
> or is the packet context a new one on encapsulation? I know that IPSec 
> RFC says inner packet headers have to be copied to the outer header. 
> Does that include the TOS byte too? Do not know what OpenSWAN does. If 
> that were the case, assigning TOS prior to encapsulation and classifying 
> by TOS at the device will work.
> 
> Mohan
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 



 
____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups 
(http://groups.yahoo.com)

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] qos inside ipsec tunnel

[Martin Bene]

Ji John,

> Bring up a GRE tunnel inside the IPSec tunnel.
> Then use tc to shape the BW on the tunnel,
> Then use tc to shape the BW on the outgoing interface, eg ppp1.

I don't see what advantage you get from the nested tunnel configuration
you propose - why not simply shape on ppp1 and be done with it?

Bye, Martin
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc