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
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
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, MartinHas 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
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
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)
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