RE: [LARTC] traffic queueing and ipsec vpn
hi alexis, please do -- i'd like to see just how far off i am :-) i've been just playing arounfd with racoon instead of freeswan -- totally different animal ... cheers charles On Sat, 2004-09-04 at 16:39, Alexis wrote: > Thanks again, this is _really_ enough info, ill do a lab and test this, I > think this is the best way to realize how this work. > > Best regards. > > > > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En > nombre de [EMAIL PROTECTED] > Enviado el: Sábado, 04 de Septiembre de 2004 5:15 > Para: LARTC list > Asunto: RE: [LARTC] traffic queueing and ipsec vpn > > hi alexis, > > its been a while since i did this modification to the kptd. > > the diagram assumes that this a linux box doing a vpn tunnel(s). lets assume > that eth0 is facing the lan and eth1 is facing the internet and that eth1 > has one or more ipsec interfaces. > > a packet from the lan comes in on eth0 and is destined to lan via an ipsec > tunnel. i *believe* that before the routing decision is made, the ipsec > process changes the interface to the appropriate ipsecX interface name. > > the packet, as it is not destined for this local machine, pass thru FORWARD, > POSTROUTING, and then EGRESS. ipsec encrypts the packet and the new esp > packet is repassed thru POSTROUTING and EGRESS and is dequeued to the > hardware. > > if i am not mistaken, meta data from the unencrypted packet is preserved, > that is, that you may mark the packet in POSTROUTING and then use that mark > to make an QOS EGRESS decision on the ESP packet. i'll have to check this > again, but i don't have a bunch of time at the moment. > > now, assume an esp packet arrives on eth1 addressed to this box because it > is at the end of the tunnel. the esp packet passes PREROUTING, INGRESS, and > passes INPUT as it addressed for this machine. after INPUT, ipsec decrypts > the packet and it is passed thru PREROUTING, INGRESS, FORWARD (as it is > destined now for a machine on the lan), POSTROUTING, EGRESS and dequeued to > the hardware. > > cheers > > chalres > > > On Fri, 2004-09-03 at 22:16, Alexis wrote: > > Thank you very much for the quick answer. > > > > Let me ask you a question about it so I can save time, analyzing this > > ascii I can see after qos ingress and before input routing a statement > > that says "if dst ip via ipsec put on ipsecX interface" > > > > Ok, this is my basic schema > > > > LAN > |ethX| linuxbox |ethZ| > IPSEC VPN > > > > This means, all the LAN traffic that reaches the linuxbox is forwarded > > from ethX to ethZ and then via ipsec reaches its destination. > > > > > > As ive never configured an ipsec vpn using linux yet (only used cisco > > and > > nortel) my question is. > > > > "if dst ip via ipsec put on ipsecX interface" < this means that ill > > have an ipsecX interface and I need to set the queues in this > > interface? Or I need to set up my queues on ethZ? > > > > Thanks in advance. > > > > Ps: ill configure ipsec vpn using kernel 2.6 > > > > > > > > -Mensaje original- > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > En nombre de [EMAIL PROTECTED] Enviado el: Viernes, 03 de > > Septiembre de 2004 16:32 > > Para: Alexis; LARTC list > > Asunto: Re: [LARTC] traffic queueing and ipsec vpn > > > > hi alexis, > > > > i -- THINK -- that this is how it happens. > > > > cheers > > > > charles > > > > > > On Fri, 2004-09-03 at 20:12, Alexis wrote: > > > Hi all, ive been reading lartc howto, im new about traffic > > > shaping/police. > > > > > > As far as red (chapter 9 complete) i saw that first the packet > > > passes at the ingress qdisc, then it passes to the ip stack if the > > > packet is directed to the box or its forwarded (is my case), then it > > > falls to the egress classifier/s. > > > > > > Now, i understand if i have an ipsec vpn at the outside interface, > > > the egress classifiers will act before the packet leave the kernel > > > and enter to the vpn tunnel, is this correct? > > > > > > Here's my situation , i have a "headquarter" box that is a database > > > (to call it with a name) and then a lot of branches that send > > > queries to this database and based on the results, the branches send > > > packets to other branches trough some established IPSEC tunnels. So,
RE: [LARTC] traffic queueing and ipsec vpn
hi alexis, its been a while since i did this modification to the kptd. the diagram assumes that this a linux box doing a vpn tunnel(s). lets assume that eth0 is facing the lan and eth1 is facing the internet and that eth1 has one or more ipsec interfaces. a packet from the lan comes in on eth0 and is destined to lan via an ipsec tunnel. i *believe* that before the routing decision is made, the ipsec process changes the interface to the appropriate ipsecX interface name. the packet, as it is not destined for this local machine, pass thru FORWARD, POSTROUTING, and then EGRESS. ipsec encrypts the packet and the new esp packet is repassed thru POSTROUTING and EGRESS and is dequeued to the hardware. if i am not mistaken, meta data from the unencrypted packet is preserved, that is, that you may mark the packet in POSTROUTING and then use that mark to make an QOS EGRESS decision on the ESP packet. i'll have to check this again, but i don't have a bunch of time at the moment. now, assume an esp packet arrives on eth1 addressed to this box because it is at the end of the tunnel. the esp packet passes PREROUTING, INGRESS, and passes INPUT as it addressed for this machine. after INPUT, ipsec decrypts the packet and it is passed thru PREROUTING, INGRESS, FORWARD (as it is destined now for a machine on the lan), POSTROUTING, EGRESS and dequeued to the hardware. cheers chalres On Fri, 2004-09-03 at 22:16, Alexis wrote: > Thank you very much for the quick answer. > > Let me ask you a question about it so I can save time, analyzing this ascii > I can see after qos ingress and before input routing a statement that says > "if dst ip via ipsec put on ipsecX interface" > > Ok, this is my basic schema > > LAN > |ethX| linuxbox |ethZ| > IPSEC VPN > > This means, all the LAN traffic that reaches the linuxbox is forwarded from > ethX to ethZ and then via ipsec reaches its destination. > > > As ive never configured an ipsec vpn using linux yet (only used cisco and > nortel) my question is. > > "if dst ip via ipsec put on ipsecX interface" < this means that ill have an > ipsecX interface and I need to set the queues in this interface? Or I need > to set up my queues on ethZ? > > Thanks in advance. > > Ps: ill configure ipsec vpn using kernel 2.6 > > > > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En > nombre de [EMAIL PROTECTED] > Enviado el: Viernes, 03 de Septiembre de 2004 16:32 > Para: Alexis; LARTC list > Asunto: Re: [LARTC] traffic queueing and ipsec vpn > > hi alexis, > > i -- THINK -- that this is how it happens. > > cheers > > charles > > > On Fri, 2004-09-03 at 20:12, Alexis wrote: > > Hi all, ive been reading lartc howto, im new about traffic > > shaping/police. > > > > As far as red (chapter 9 complete) i saw that first the packet passes > > at the ingress qdisc, then it passes to the ip stack if the packet is > > directed to the box or its forwarded (is my case), then it falls to > > the egress classifier/s. > > > > Now, i understand if i have an ipsec vpn at the outside interface, the > > egress classifiers will act before the packet leave the kernel and > > enter to the vpn tunnel, is this correct? > > > > Here's my situation , i have a "headquarter" box that is a database > > (to call it with a name) and then a lot of branches that send queries > > to this database and based on the results, the branches send packets > > to other branches trough some established IPSEC tunnels. So, hq is the > > route database, and the branches send voice traffic to other branches. > > > > Now i have to set traffic shaping and manage the bandwith for > > senialization and for voice flows (rtp flows). So i need to be shure > > that i can classify the packets at the outside interface before them > > enters to the vpn tunnel. > > > > is this correct? > > > > > > Thanks in advance. > > > > > > -- > > Alexis ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] traffic queueing and ipsec vpn
hi alexis, i -- THINK -- that this is how it happens. cheers charles On Fri, 2004-09-03 at 20:12, Alexis wrote: > Hi all, ive been reading lartc howto, im new about traffic > shaping/police. > > As far as red (chapter 9 complete) i saw that first the packet passes > at the ingress qdisc, then it passes to the ip stack if the packet is > directed to the box or its forwarded (is my case), then it falls to > the egress classifier/s. > > Now, i understand if i have an ipsec vpn at the outside interface, the > egress classifiers will act before the packet leave the kernel and > enter to the vpn tunnel, is this correct? > > Here's my situation , i have a "headquarter" box that is a database > (to call it with a name) and then a lot of branches that send queries > to this database and based on the results, the branches send packets > to other branches trough some established IPSEC tunnels. So, hq is the > route database, and the branches send voice traffic to other branches. > > Now i have to set traffic shaping and manage the bandwith for > senialization and for voice flows (rtp flows). So i need to be shure > that i can classify the packets at the outside interface before them > enters to the vpn tunnel. > > is this correct? > > > Thanks in advance. > > > -- > Alexis Title: Welcome on docum.org Kernel Packet Traveling Diagram Network---+--- | +--+ +---+---++-+-+ |IPCHAINS || IPTABLES | | INPUT || PREROUTING| +---+---+| +---+---+ | || | conntrack | | || +---+---+ | || |mangle | | <- MARK WRITE|| +---+---+ | || | IMQ | | || +---+---+ | || | nat | | <- DEST REWRITE || +---+---+ | DNAT or REDIRECT or DE-MASQUERADE |+-+-+ +--+ | +---+---+ | QOS | |INGRESS| +---+---+ | || +---+---+ | if dst ip via ipsec | | put on ipsecX interface | +---+---+ | packet is for +---+---+ packet is for this machine | INPUT | another address+--+ROUTING+--+| |+ PDBB | || +---+ |+---+---+ || IPTABLES| || INPUT | || +-+-+ | || | mangle | | || +-+-+ | || | filter | | || +-+-+ |to iptables prerouting |+---+---+^|||||||+---+ yes +--+ || esp packet |---| decrypt | |+---+ +--+ || || no || +---++---+---+ +---+---+ +---+---+ | Local | |IPCHAINS | |IPTABLES | |Process| |FORWARD| |FORWARD| +---+---+ +---+---+ | +-+-+ | | | | | mangle | | <- MARK WRITE+---+---+ | | +-+-+ | |OUTPUT | | | | filter | | |ROUTING| | | +-+-+ | +---+---+ | +---+---+ | +---+ +---+---+ ||IPTABLES |
[LARTC] traffic queueing and ipsec vpn
Hi all, ive been reading lartc howto, im new about traffic shaping/police. As far as red (chapter 9 complete) i saw that first the packet passes at the ingress qdisc, then it passes to the ip stack if the packet is directed to the box or its forwarded (is my case), then it falls to the egress classifier/s. Now, i understand if i have an ipsec vpn at the outside interface, the egress classifiers will act before the packet leave the kernel and enter to the vpn tunnel, is this correct? Here's my situation , i have a "headquarter" box that is a database (to call it with a name) and then a lot of branches that send queries to this database and based on the results, the branches send packets to other branches trough some established IPSEC tunnels. So, hq is the route database, and the branches send voice traffic to other branches. Now i have to set traffic shaping and manage the bandwith for senialization and for voice flows (rtp flows). So i need to be shure that i can classify the packets at the outside interface before them enters to the vpn tunnel. is this correct? Thanks in advance. -- Alexis
