From: Daniel Lopes <lopsch@lopsch.com>
To: netfilter@lists.netfilter.org
Subject: Re: QoS and IPSec...
Date: Wed, 27 Jul 2005 13:59:41 +0200 [thread overview]
Message-ID: <42E7772D.3070302@lopsch.com> (raw)
In-Reply-To: <42E716EA.9010703@riverviewtech.net>
Grant Taylor schrieb:
>> What about this (only for one side ;) ):
>> Suppose we are on LAN A:
>> In the table mangle chain PREROUTING mark all packets coming in over
>> the LAN device and destined for 172.30.13.0/24 and sourced from
>> 172.30.12.0/24 for example with 1.
>> Then IPSec handles the packets.
>> In table mangle chain POSTROUTING mark all packets with AH/ESP
>> outgoing over the internet device and destined for the routable IP of
>> LAN B with 1. Don't know if they are marked twice with 1 but that's no
>> problem. So we can be sure all IPSec packets are marked with 1.
>> Then you can apply the filters in the schedulers for the appropriate
>> marks on the appropriate device in this case the internet device.
>> So we can prioritize outgoing packets.
>> Incoming should also be prioritized. So both directions get their
>> priorities.
>> So in table mangle chain PREROUTING mark all AH/ESP packets coming in
>> over the internet device and sourced from the routable IP of LAN B
>> with 1.
>> Then IPSec handles the packets.
>> In table mangle chain POSTROUTING mark all packets destinded for
>> 172.30.12.0/24 and sourced from 172.30.12.0/24 and going out over the
>> LAN device with 1.
>> Then apply the filters for the marks in the schedulers of the LAN device.
>> This way IPSec should be prioritized in both directions on one router.
>> If it works you can do it with canged addresses on the other one.
>> Don't know if it really works, because it's now 3am and I'm a bit
>> confused and IPSec is already complex standalone ;).
>> But afaik every net device gets schedulers no matter if physical or
>> virtual so it normally should be no problem.
>
>
> Daniel (and others) thank you for the reply. However I think you have
> (re)touched on the QoS / Prioritization of IPSec (IP/ESP) traffic verses
> regular internet bound traffic. I am after how to prioritize just the
> subset of the traffic from Lan A (or B) that is destined to the other
> side. More specifically I will be having SSH (interactive sessions
> only) / Telnet, Terminal Services (RDP), VNC (RFB), ICMP, SMB/CIFS, FTP
> / SCP (bulk data transfer), RSYNC, LPD, etc traffic from one LAN
> destined to the other LAN through a VPN that has a finite amount of
> bandwidth (128 kbps DSL (768/128)) which will spend a good deal of time
> saturated with all of the traffic going through it. Thus I want to
> prioritize that interactive services, i.e. SSH / Telnet, RDP, VNC, and
> ICMP, send their traffic through the VPN *BEFORE* any of the bulk data
> transfer services thus hopefully yielding what will appear to be a
> fairly responsive circuit. Seeing as how all of this traffic is going
> to be encapsulated with in the IPSec VPN and thus becoming IP/ESP
> traffic I can not just prioritize the IP/ESP traffic on the egress of
> the external interface of the router. Naturally I will prioritize like
> you have suggested to make sure that VPN traffic will have priority over
> general web traffic on the external interface of the router. However as
> I understand it there is no ""egressing interface for the traffic that
> will be encapsulated *BEFORE* it does become encapsulated thus putting
> all afore mentioned VPN traffic in one priority level.
>
> Here is a brief description of how I want to prioritize the traffic that
> will be leaving any of the LANs. There will be more LANs down the road,
> each of which will (for now) have equal priority with each other. I
> will be denoting Priority Groups (PgN) as well as sub groups (sN). All
> VPN traffic from one LAN to another will be a Priority Group 1 with all
> other traffic from the sending LAN being a Priority Group 2 or lower.
> The only possible exception to this will be ICMP and similar traffic.
>
> Pg1s1: ICMP destined to other LANs (IP/ESP)
> Pg1s2: SSH / Telnet / RDP / RFB destined to other LANs (IP/ESP)
> Pg1s3: LPD / SMB / CIFS destined to other LANs (IP/ESP)
> Pg1s4: FTP / RSYNC / SCP destined to other LANs (IP/ESP)
> Pg1s5: (unused as of yet) destined to other LANs (IP/ESP)
>
> Pg2s1: ICMP destined to the world at large.
> Pg2s2: SSH / Telnet / RDP / RFB destined to the world at large.
> Pg2s3: LPD / SMB / CIFS destined to the world at large.
> Pg2s4: FTP / RSYNC / SCP destined to the world at large.
> Pg2s5: (unused as of yet) destined to the world at large.
>
> I want any traffic that is in Priority Group 1 (IPSec VPN traffic) to be
> sent out the internet connection first. I also want Priority Group 1s
> traffic to be prioritized based on the sub group priority. However as
> IP/ESP traffic is encapsulated and can thus not be prioritized on egress
> of the external interface it has to be prioritized before it is
> encapsulated. Here in lies the problem. Where / how do I prioritize
> this traffic to the appropriate sub group priority.
>
>
>
> Grant. . . .
>
>
OK as I said I don't know if the marks on packets are still there after
encapsulation. If so there is no problem. Trial and error ;). If not I
think the best solution is the IMQ device to do intermediate shaping
before encapsulation. Wasn't there a discussion on the LARTC mailing
list on how it works?
next prev parent reply other threads:[~2005-07-27 11:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-27 0:29 [LARTC] QoS and IPSec Grant Taylor
2005-07-27 0:29 ` Grant Taylor
2005-07-27 1:09 ` Daniel Lopes
2005-07-27 5:08 ` Grant Taylor
2005-07-27 11:59 ` Daniel Lopes [this message]
2005-07-27 4:17 ` [LARTC] " Andreas Unterkircher
2005-07-27 4:53 ` Vinod Chandran
2005-07-27 4:55 ` [LARTC] " Vinod Chandran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42E7772D.3070302@lopsch.com \
--to=lopsch@lopsch.com \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.