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: lartc-admin@xxxxxxxxxxxxxxx [mailto:lartc-admin@xxxxxxxxxxxxxxx] En > nombre de lartc@xxxxxxxxxxxxxxxxxxx > Enviado el: Sábado, 04 de Septiembre de 2004 5:15 > Para: LARTC list > Asunto: RE: 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: lartc-admin@xxxxxxxxxxxxxxx [mailto:lartc-admin@xxxxxxxxxxxxxxx] > > En nombre de lartc@xxxxxxxxxxxxxxxxxxx Enviado el: Viernes, 03 de > > Septiembre de 2004 16:32 > > Para: Alexis; LARTC list > > Asunto: Re: 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 / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
