Minimum requirements for IPSec over L2TP - PIX.

Moreover is it possible to split the de-encapsulation process by two and let the PIX decrypt the IPsec and forward the

Yes. This is something simular to a configuration we have at a hospital I work at part time. "split the de-encapsulation " is called split tunneling. it allows you to split web traffic off the tunnel. Do a search on cisco or google for split tunnel and you should get more than enough info to see if this fits your solution.

Yes the PIX is an end point device for tunnel and user VPN. Our pix had

3 interfaces-- DMZ-Outside-Inside and 3640 routed traffic accross vlans and to and from the pix. We put an ACL on the 3640 interface that faced the PIX and this was used to secure vpn traffic to specific hosts that the tunnels needed to connect to.

The 1812-k9 supports ipsec as part of its IOS. The "K9" i believe means it has crypto support as part of the IOS.

Steve

AM wrote:

that can manage IPsec over L2TP (not the

investigating on it, it's a PIX515 with

encr./decry. module and they suggest at least a

that kind of tunnel. Do you have any idea

the PIX decrypt the IPsec and forward the

decryption/de-encapsulation.

Thanks Steve,

but I was talking about a tunnel within another tunnel (IPsec over L2TP) and the provider said it would be better that just one device unwraps packet from the 1st tunnel (that is L2TP) and decrypts the packets for the 2nd tunnel (IPsec). I asked for a solution where one device unwraps the 1st tunnel and then forward the IPsec packets to another device that decrypt those IPsec packets.

Alex.

In article , snipped-for-privacy@am.am (AM) writes: | We're buying a service from a provider and they said we need to have a device that can manage IPsec over L2TP (not the | opposite). PIX should not be able to manage that kind of encapsulation (I'm investigating on it, it's a PIX515 with | finesse 7.0.2) and I'm looking for the cheapest solution to build the tunnel. | | They say the minimum requirements are 12.4, 128 MB RAM, 32 MB Flash and encr./decry. module and they suggest at least a | 1812-K9 router. | | Cisco published one of the first documents about the topic in November 2000. | So I think that even a rather old hardware (OK not all old devices) can manage that kind of tunnel. Do you have any idea | if I can use hardware like 1720 series or 870 series or a 3640 router?

I do it on a 3660 with 12.1(5)T and a 4700 with 12.2(34a). Note that the ability to associate a dialer with an L2TP tunnel probably requires "service internal" and (IIRC) did not exist prior to 12.1T.

| Moreover is it possible to split the de-encapsulation process by two and let the PIX decrypt the IPsec and forward the | L2TP packets to another device that will de-encapsulate them?

For IPSec over L2TP you could have one box de-capsulate and the next decrypt. Your way of saying it sounds more like L2TP over IPSec...

The neat thing about IPSec over L2TP is that the PPP connection in the L2TP tunnel can establish static IP addresses making the IPSec configuration simpler, i.e., no dynamic crypto maps even if your real IP address is dynamic. It's almost like encrypting a dedicated serial link, and your access lists can match (virtually) all traffic.

Dan Lanciani ddl@danlan.*com

Sorry Dan,

I meant IPsec over L2TP so the sentence above sounds

"...let another device unwrap the L2TP tunnel and forward IPsec packets to the PIX..."

this way sounds more like IPSec over L2TP...

How much CPU time does the unwrapping process take? Is it reliable to act the unwrapping process on a old device with no encapsulation/decapsulation accelerator card? As far as I know L2TP doesn't give any kind of encryption, but I'd like to have more information from you who know better this topic. Is there any article document about that?

Thank you very much,

Alex

In article , snipped-for-privacy@am.am (AM) writes: | Dan Lanciani wrote: | | > For IPSec over L2TP you could have one box de-capsulate and the next | > decrypt. Your way of saying it sounds more like L2TP over IPSec... | | Sorry Dan, | | I meant IPsec over L2TP so the sentence above sounds | | "...let another device unwrap the L2TP tunnel and forward IPsec packets to the PIX..." | | this way sounds more like IPSec over L2TP... | | How much CPU time does the unwrapping process take?

I don't know, but I suspect the worst effect would be if it forced packets to take a process-switched path where otherwise they would not. The actual work of adding or removing the L2TP/UDP headers is trivial-- certainly nothing compared to software encryption.

|Is it reliable to act the unwrapping process on a old device with no | encapsulation/decapsulation accelerator card?

I'm not familiar with such cards, but I'm not sure of the advantage of using a separate "old" device to do the encapsulation if a similar old device could do both. I would think that in general the more devices you use the more points of failure...

|As far as I know L2TP doesn't give any kind of encryption, but I'd like | to have more information from you who know better this topic.

In theory you can use MPPE with L2TP just as you would with PPTP. In practice I find that it quickly gets out of sync even with L2TP configured to drop out-of-sequence packets.

Dan Lanciani ddl@danlan.*com