From: Andrew Short (ashort@xxxxxxxxxxxxxxx)
Date: Tue Feb 06 2001 - 00:56:25 GMT-3
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:37 GMT-3