RE: traffic queueing and ipsec vpn

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux