RE: IPsec & VPN Discussion

From: Robert Thompson (rthompson@xxxxxxxxxxxxx)
Date: Thu Feb 10 2000 - 02:48:13 GMT-3


   

I have done only a little with VPNs & IPSec, so this is

> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> John Garrett
> Sent: Thursday, 10 February 2000 2:14
> To: - *ccielab@groupstudy.com
> Subject: IPsec & VPN Discussion
>
>
> Sorry pbosio. I can configure routers but email is a bitch! ;-)
> ---------------------- Forwarded by John Garrett/IS/US/BAYER on 02/09/2000
> 10:12 AM ---------------------------
>
>
> John Garrett
> 02/09/2000 10:10 AM
> To: "DDA.RFC-822=pbosio@comtech.com.au/P=BAYER/A=TELEMAIL/C=US"@X400
> cc:
>
> Subject: IPsec & VPN Discussion
>
> I am starting to play with VPNs, and I have some questions for the group.
> Hopefully these help you and me:
>
> If all we have to configure are routers, then a VPN is nothing
> more than an
> encrypted transport(pipe) between two addresses. Is this correct?
>
Yes, although it does not even have to be encrypted. In its simplest form
a VPN could be just a GRE tunnel between sites carrying non-routable
packets (i.e. IP packets with private addresses). This is the
simplest form of VPN and is good for trying out basic concepts without
getting stuck on weird reasons crypto maps don't work.

> I found that I had to upgrade my router to an IPsec compliant
> version to do
> anything with the crypto command. Does crypto=IPSec=VPN?
>
I'm not sure if there is another crypto command set that uses
the crypto keyword (e.g. 3DES - haven't loaded it so don't know).
If it isn't in the IOS feature set on the router, then yeah,
you can't see the command.

You can have VPNs using different crypto solutions than IPSec. IPSec
is nice and easy to do though, I have only been using it so far.

> All the documentation refers to "applying the crypto maps to
> interfaces" Is it
> significant which interfaces (or types of interfaces) that the
> crypto maps are
> applied to? For example, if R1 and R2 each have an eth and a
> ser, and are
> connected back-to-back ser, would I put my crypto map on the eths
> or the sers?
>
Like everything else it is vital which interfaces the crypto
maps (or pretty much anything else) are on.

In this case you'd apply them to the serial interfaces to allow the
two ethernets to have a VPN with each other.

> Assume there are other routers in the ser "cloud" above. Does
> the encryption
> cause them any greif? Other than ports 50.51, and udp500, are there other
> ports that will block connections?
>
The only problem should be if a router is blocking your encrypted
traffic due to an improper filter. Sorry, don't have a list of the
ports handy at the time of typeing this.

> Finally, the most important, is there another way to provide a
> point to point
> secure connection without IPsec? Can you apply something to a
> tunnel interface
> to call it a VPN?
>
If I make a tunnel I can call it a VPN. There are other ways to encrypt
data, but I'm not familiar with them so I won't try and describe
what I haven't done.

> Can I define a routing neighbor and pass routing info over the
> VPN? If so,
> does this then couse the same routign type problems that tunnels cause?
>
Yes.

> Recursive route syndrome? Will my VPN see its best orute to
> endpoint through
> VPN?
>
Since the VPN routes are normally not duplicated across the cloud this
shouldn't happen if you are carefull. e.g. Your router has a default
route to *everywhere* (the cloud) and also routes arriving across the VPN
for the other VPN sites, but not default routes from the VPN sites
(and no routes from them back into the cloud). Pretty much the same as
tunnels with most of the same traps IMHO.

---------------------------------
Robert Thompson, CCIE #4500, MCSE
Business Integration Solutions
44 Ellingworth Pde, Box Hill 3128
Australia
Office +61 3 9899 5111
FAX +61 3 9899 7671
Mobile 0407 368 154
Mailto:rthompson@busint.com.au
http://www.busint.com.au
---------------------------------



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:22:53 GMT-3