VPN PPTP Clients and IPSEC tunneling between sites

First, thank you very much for your answer.

I don't think that the situation you described is the one i'm in right now. I have a vpdn group 1 configured. here is the config :

vpdn group 1 accept dialin pptp vpdn group 1 ppp authentication mschap vpdn group 1 ppp encryption mppe 128 required vpdn group 1 client configuration address local pptp-pool vpdn group 1 client configuration dns HANDEL CHOPIN vpdn group 1 client configuration wins HANDEL CHOPIN vpdn group 1 client authentication aaa RADIUS vpdn group 1 pptp echo 60 vpdn username cisco password ******** vpdn enable outside

and the IPs at the remote sites and the one given to my VPN clients are not overlapping.

What do you mean by : It won't always be the -best- way though...

In article , ZChuck wrote: :We are currently using CISCO Pix 515 Firewall running OS 6.3(1) and VPN

That version has several known security problems. You are entitled to a free upgrade to PIX 6.3(4)110. Please search cisco's site for PIX Security Advisory for more information.

:functionnality is configured to accept PPTP clients that authenticate :thru MS-CHAP using 3DES encryption 128bit required.

:My question is : Is it possible to add an IPSEC tunnel (branch office) :with 3DES encryption and SHA authentication without changing the way :current VPN clients connect to the device?

Probably Yes, but there is one particular configuration in which the answer is No.

-If- you happened not to have configured a vpn group password, and so are "falling back" to an "isakmp key" statement for the password, and -if- the IP address range required for that isakmp key overlaps the IP address range needed for the branch office (e.g., it happens to have a dynamic IP address from one of the ISPs that the PPTP clients use), and -if- the new office's firewall is not able to handle Cisco's proprietary EzVPN negotiations -- if all of these conditions are true, then you would have to change the way the PPTP clients connect, in that you would have to configure a vpn group password instead of falling back to the "isakmp key".

The change would be transparent to the users -- but it -is- a change to "the way current VPN clients connect".

If any of the conditions listed does -not- hold, then there is a way to configure the PIX to accept the new connection without changing the internal details of how the PPTP clients connect. It won't always be the -best- way though...

:I thought of buy

In article , ZChuck wrote: :vpdn username cisco password ********

:What do you mean by : :>It won't always be the -best- way though...

If no vpdn password --> password is taken from isakmp key .

isakmp key has a network and netmask.

If the PPTP -public- user IP addresses (the one the link gets from the ISP) does not overlap with the -public- IP addresses of the remote sites, then you could have different isakmp key statements that specified different public IP ranges (one for PPTP, one for the site-to-site VPN), and there would not be a password conflict.

If, though, the public IPs of the PPTP users overlapped the public IPs of the remote sites, then you couldn't distinguish them in the isakmp key statement, and you would need to do one of: a) use the same password for everything; or b) reconfigure the PPTP part to supply a vpdn password; or c) use EzVPN from the remote office.

If you were in that situation and you didn't want the same password for everything, and you couldn't use EzVPN (e.g., because the remote office device isn't a Cisco box), then you would be forced into (b), a reconfiguration of the PPTP setup.

If you -were- forced into reconfiguring the PPTP setup, changing over from falling-back on the isakmp key, to having a proper vpdn password, then the users would never notice... but it -would- be a reconfiguration of the PPTP side which would be in violation of the premise of your original posting that no PPTP reconfiguration should be allowed.

The part about not being the -best- way comes in if you -are- able to distinguish the sites by IP range -and- you are falling back on isakmp for the PPTP instead of using a vpdn password statement. In that combination of circumstances, you would end up with two isakmp key statements, one of which was used for its normal purpose of site-to-site VPN, and the other of which was used in the fallback mode to compensate for the missing vpdn password. This wouldn't require a PPTP reconfiguration, but in my opinion it would not be the best configuration: I would say that a better configuration in the situation would be to accept the minor (user-transparent) addition of the vpdn password and only have the isakmp key needed for the remote office site-to-site VPN.

Anyhow, you *do* have a vpdn password statement, so the chain of events doesn't apply to you: you can add the site-to-site without worrying about the PPTP config.

The information that you posted originally left open the possibility of this tenuous chain of configuration needs.

The moral of this is: post the relevant parts of your configuration when you ask a question -- it saves the respondants such as me from having to list out long series of constraints that probably don't apply... but we can't just say "Go ahead" because you just -might- have configured in the one way that it wouldn't have worked. And in turn, if I don't end up listing long series of constraints, then besides my being able to provide shorter answers, I'm less likely to end up confusing you with arcanities!