Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: netfilter@lists.netfilter.org
Subject: Re: QoS and IPSec...
Date: Wed, 27 Jul 2005 00:08:58 -0500	[thread overview]
Message-ID: <42E716EA.9010703@riverviewtech.net> (raw)
In-Reply-To: <42E6DEDA.40200@lopsch.com>

> 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. . . .


  reply	other threads:[~2005-07-27  5:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-27  0:29 QoS and IPSec Grant Taylor
2005-07-27  1:09 ` Daniel Lopes
2005-07-27  5:08   ` Grant Taylor [this message]
2005-07-27 11:59     ` Daniel Lopes
2005-07-27  4:53 ` 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=42E716EA.9010703@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox