From: Jason T. Rohm (jtrohm@xxxxxxxxxxx)
Date: Tue Feb 06 2001 - 01:06:03 GMT-3
Andrew,
From: http://www.cisco.com/warp/public/cc/so/neso/vpn/vpne/vpne_an.htm
Appendix A: IPSec Negotiation (MM and QM)
To establish an IPSec connection, two types of sessions called security
associations must be established: an IKE SA and several IPSec SAs.
The IKE SA is bidirectional and is analogous to the control session in the
FTP protocol (port 21). It establishes/authenticates the identity of the
peers, negotiates the type of security parameters to be used and manages the
key material required for packet authentication and encryption. Its other
important role is to negotiate and establish the IPSec SAs (analogous to the
FTP data sessions (port 20)). The IPSec SAs are unidirectional and pass
encrypted/authenticated user data.
-Jason
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Andrew Short
Sent: Monday, February 05, 2001 9:56 PM
To: CCIE Study Group
Subject: Re: ANSWER+Follow-up Q.: IPSec w/GRE or IPinIP Tunnels
(Troubleshooting)
I thought it was the ISAKMP SA's that were unidirectional, with the IPSec
SA's being BI-Directional.
On Mon, 5 Feb 2001, Jason T. Rohm wrote:
> The answer is:
>
> I was messing things up by listing both directions in my access-list.
>
> The obvious question is... since IPSec SAs are unidirectional, why does
> Cisco ASSUME that you want to encrypt the data both ways?
>
> -Jason
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> NoOne Important
> Sent: Monday, February 05, 2001 8:53 PM
> To: jtrohm@athenet.net; kgalusha@cisco.com; globalfx@netropolis.net
> Cc: ccielab@groupstudy.com
> Subject: RE: IPSec w/GRE or IPinIP Tunnels (Troubleshooting)
>
>
> Transport IS the way to go.
> Anyway, just change your access-list to instead of host to host use the
> whole $%&* class C...tat probably will solve your problem.
> the debug said it's not an ipsec packet probably because your access list
> use host to host.
> Good luck!
>
>
>
>
>
> >From: "Jason T. Rohm" <jtrohm@athenet.net>
> >Reply-To: "Jason T. Rohm" <jtrohm@athenet.net>
> >To: "'Kyle Galusha'" <kgalusha@cisco.com>, "'Foltz'"
> ><globalfx@netropolis.net>
> >CC: "CCIELIST (E-mail)" <ccielab@groupstudy.com>
> >Subject: RE: IPSec w/GRE or IPinIP Tunnels (Troubleshooting)
> >Date: Mon, 5 Feb 2001 20:30:53 -0600
> >
> >I'm pretty sure transport is the way to go. (You are already creating a
> >tunnel with the GRE/IPinIP tunnel setup).
> >
> >I found this url after we started this converstation... it is pretty much
> >exactly what I am doing:
> >
> >http://www.cisco.com/warp/public/707/ipsec_gre.html
> >
> >-Jason
> >
> >-----Original Message-----
> >From: Kyle Galusha [mailto:kgalusha@cisco.com]
> >Sent: Monday, February 05, 2001 8:23 PM
> >To: Foltz; Jason T. Rohm
> >Subject: Re: IPSec w/GRE or IPinIP Tunnels (Troubleshooting)
> >
> >
> >Just to add some more thoughts...You can have GRE if you are routing over
> >the internet to another site. For example you may be running 10.x.x.x
> >address space at a central site and at a remote site with registered ip
> >addresses only on the outside of your of your routers. You would encrypt
> >everything between your site including you 10.x.x.x routing protocols in
> >the
> >GRE/IPSEC tunnel.
> >In your example I believe your access lists should be just source to
> >distination on one side and the mirror image access list on the other.
> >Another thing to check. Are you using transport mode on purpose. I
need
> >to doublecheck to see if tunnel isn't the way to go.
> >Kyle
> >
> >At 07:56 PM 2/5/2001 -0600, Foltz wrote:
> > >you need to change the access list 106 on both routers to be tcp, or ip
> > >instead of gre. The way you have it only gre encapsulated traffic will
be
> > >encrypted through the tunnel. if u change it from gre to tcp/ or ip
then
> > >trafffic to and from those hosts will be encrypted but no others will
be.
> > >Also, 11.3 has problem when u try to NAT and do IPSec at the same time,
i
> > >use 12.07T at work and have no problems doing NAT and IPSec.
> > >
> > >Richard Foltz, CCNP-Voice, CCNP, CCDP, MCSE+I, Network+, A+
> > >Attempt 2 @ Halifax 3/26-27
> > >
> > >
> > >----- Original Message -----
> > >From: "Jason T. Rohm" <jtrohm@athenet.net>
> > >To: "'Kyle Galusha'" <kgalusha@cisco.com>
> > >Cc: "CCIELIST (E-mail)" <ccielab@groupstudy.com>
> > >Sent: Monday, February 05, 2001 7:07 PM
> > >Subject: IPSec w/GRE or IPinIP Tunnels (Troubleshooting)
> > >
> > >
> > >> I am having some problems with my newly "IpSec'd" tunnel... Do you
have
> > >> experience working with these @#$% things?
> > >>
> > >> A "debug crypto ipsec" shows that *SOME* of my IPinIP/GRE (I've tried
> >it
> > >> both ways) packets are coming in w/o the IPSec wrapper. I have double
> > >> checked my crypto maps/access-lists for accuracy, but am having a
hard
> > >time
> > >> determining why only some of the data isn't getting encrypted (my
OSPF
> > >> packets are getting through just fine, but I can't ping or telnet).
> > >>
> > >> My lab is connected to the internet if you would like to take a look
> >for
> > >> yourself. Let me know if that would be helpful.
> > >>
> > >> Basic Layout:
> > >>
> > >> |-[3640B]--[other router]--[1605A]-|
> > >> ^- IPinIP or GRE Tunnel -^
> > >>
> > >> OSPF AS 50 runs on center router and connected interfaces of end
> >routers.
> > >> OSPF AS 10 runs only on end routers' outside interfaces and the
tunnel
> > >> interface.
> > >> No redistribution takes place between OSPF AS's.
> > >>
> > >> I show complete routing tables on both ends in OSPF AS 10.
> > >> I can ping from either tunnel interface to the other end.
> > >> I cannot ping the other end of the tunnel using the outside
interfaces
> >as
> > >> the source.
> > >>
> > >> debug crypto ipsec:
> > >>
> > >> Feb 5 18:52:33.867: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not
an
> > >> IPSEC packet.
> > >> (ip) dest_addr= 10.254.253.2, src_addr= 10.254.254.1, prot=
47
> > >> Feb 5 18:56:47.816: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not
an
> > >> IPSEC packet.
> > >> (ip) dest_addr= 10.254.253.2, src_addr= 10.254.254.1, prot=
47
> > >>
> > >> Code Summary:
> > >>
> > >> ****** 1605A ******
> > >> !
> > >> crypto isakmp policy 10
> > >> hash md5
> > >> authentication pre-share
> > >> group 2
> > >> crypto isakmp key MYCRYPTOKEY address 10.254.254.1
> > >> !
> > >> !
> > >> crypto ipsec transform-set ZERO_ONE esp-des esp-md5-hmac
> > >> mode transport
> > >> !
> > >> crypto map ZERO_ONE_MAP 10 ipsec-isakmp
> > >> set peer 10.254.254.1
> > >> set transform-set ZERO_ONE
> > >> set pfs group2
> > >> match address 106
> > >> !
> > >> interface Tunnel0
> > >> ip address 10.250.250.2 255.255.255.0
> > >> tunnel source 10.254.253.2
> > >> tunnel destination 10.254.254.1
> > >> crypto map ZERO_ONE_MAP
> > >> !
> > >> interface Ethernet0
> > >> ip address 10.254.253.2 255.255.255.0
> > >> crypto map ZERO_ONE_MAP
> > >> !
> > >> interface Ethernet1
> > >> ip address 10.1.10.1 255.255.255.0
> > >> !
> > >> router ospf 10
> > >> network 10.1.10.0 0.0.0.255 area 1
> > >> network 10.250.250.0 0.0.0.255 area 1
> > >> !
> > >> access-list 105 permit ipinip host 10.254.253.2 host 10.254.254.1
> > >> access-list 105 permit ipinip host 10.254.254.1 host 10.254.253.2
> > >> access-list 106 permit gre host 10.254.253.2 host 10.254.254.1
> > >> access-list 106 permit gre host 10.254.254.1 host 10.254.253.2
> > >> !
> > >>
> > >> ****** 3640B ******
> > >>
> > >> crypto isakmp policy 10
> > >> hash md5
> > >> authentication pre-share
> > >> group 2
> > >> crypto isakmp key MYCRYPTOKEY address 10.254.253.2
> > >> !
> > >> !
> > >> crypto ipsec transform-set ZERO_ONE esp-des esp-md5-hmac
> > >> mode transport
> > >> !
> > >> crypto map ZERO_ONE_MAP 10 ipsec-isakmp
> > >> set peer 10.254.253.2
> > >> set transform-set ZERO_ONE
> > >> set pfs group2
> > >> match address 106
> > >> !
> > >> interface Tunnel0
> > >> ip address 10.250.250.1 255.255.255.0
> > >> tunnel source 10.254.254.1
> > >> tunnel destination 10.254.253.2
> > >> crypto map ZERO_ONE_MAP
> > >> !
> > >> interface Ethernet0/0
> > >> ip address 10.0.10.36 255.255.255.0
> > >> !
> > >> interface Ethernet0/1
> > >> ip address 10.254.254.1 255.255.255.0
> > >> crypto map ZERO_ONE_MAP
> > >> !
> > >> router ospf 10
> > >> network 10.0.10.0 0.0.0.255 area 1
> > >> network 10.250.250.0 0.0.0.255 area 1
> > >> !
> > >> access-list 105 permit ipinip host 10.254.253.2 host 10.254.254.1
> > >> access-list 105 permit ipinip host 10.254.254.1 host 10.254.253.2
> > >> access-list 106 permit gre host 10.254.253.2 host 10.254.254.1
> > >> access-list 106 permit gre host 10.254.254.1 host 10.254.253.2
> > >> !
> > >>
> > >> ***** End Code ******
> > >>
> > >> Thank you,
> > >>
> > >> Jason T. Rohm
> > >> Sr. Network Engineer
> > >> Wire Technologies, Inc
> > >> jtrohm@wiretech-inc.com
> > >> (920) 766-5172
> > >>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:38 GMT-3