From: Christopher Larson (clarson@xxxxxxxxxxx)
Date: Tue Feb 06 2001 - 16:04:45 GMT-3
P.S. A change to an access-list under a crypto map constitutes a change to
the crypto map.
-----Original Message-----
From: Christopher Larson
Sent: Tuesday, February 06, 2001 2:04 PM
To: 'erickbe@yahoo.com'; Christopher Larson; 'Jason T. Rohm'; 'Brian
Hescock'
Cc: CCIELIST (E-mail)
Subject: RE: IPSec w/GRE or IPinIP Tunnels (Troubleshooting)
If your IPSEC SA did not time out during the change then this could be why
it worked. Try it with one ACL again, but before you test it clear isakmp sa
and clear ipsec sa.
I don't remember the exact commands to clear the SA's but it is something
along those lines. It is possible that the ipsec info does not go away
between your changes so SA's and policies are not renogiated. When making a
change to crypto maps or isakmp you should clear the SA's.
-----Original Message-----
From: Erick B. [mailto:erickbe@yahoo.com]
Sent: Tuesday, February 06, 2001 12:37 PM
To: Christopher Larson; 'Jason T. Rohm'; 'Brian Hescock'
Cc: CCIELIST (E-mail)
Subject: RE: IPSec w/GRE or IPinIP Tunnels (Troubleshooting)
I got it working with one ACL entry after awhile but
still am not clear. I had same exact config earlier
and it wasn't working. At that time, I changed my ACL
to permit the entire subnet range which was working. I
did not make any changes to my crypto commands, etc -
just the ACL.
I changed my ACL back to gre host with one entry and
it stopped working. Added a 2nd ACL to make them
mirrored and it worked again. After some testing and
verifying, I removed the ACL and put it back with just
one gre host entry and it still worked even with a
reload. show commands verify packets are encrypted,
etc...
Anyone else think this is flaky? I sure hope ACL's
don't give me trouble when it counts.
--- Christopher Larson <clarson@mtieast.com> wrote:
> One thing I noticed in your access-list defining the
> crypto map is that they
> are not "mirrored".
> You need to have the access-lists mirrored ie.
>
> 1605
>
> 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
>
> 3640
>
> access-list 106 permit gre host 10.254.253.1 host
> 10.254.254.2
> access-list 106 permit gre host 10.254.254.2 host
> 10.254.253.1
>
> -----Original Message-----
> From: Jason T. Rohm [mailto:jtrohm@athenet.net]
> Sent: Monday, February 05, 2001 8:38 PM
> To: 'Brian Hescock'
> Cc: CCIELIST (E-mail)
> Subject: RE: IPSec w/GRE or IPinIP Tunnels
> (Troubleshooting)
>
>
> Thanks, I'm running 12.1(1), so it shouldn't be a
> 11.2 bug... the router was
> wr erase'd prior to this config...
>
> I am curious about my access-list. I noticed that
> all the examples on
> Cisco's web page only show a single line access-list
> attached to the crypto
> map. I am I wrong to explicitly list both
> directions?
>
> -Jason
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> Brian Hescock
> Sent: Monday, February 05, 2001 7:16 PM
> To: Jason T. Rohm
> Cc: 'Kyle Galusha'; CCIELIST (E-mail)
> Subject: Re: IPSec w/GRE or IPinIP Tunnels
> (Troubleshooting)
>
>
> Jason,
> I ran into a similar problem the other day with
> some 11.2 code where
> having nat configured on the router (even though it
> wasn't being
> used) caused problems. One thing you might want to
> try is removing old
> configs from your router and also making sure you
> have at least
> 12.0. Worked fine after that.
>
> B.
>
> On Mon, 5 Feb 2001, Jason T. Rohm wrote:
>
> > 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:39 GMT-3