From: Jason T. Rohm (jtrohm@xxxxxxxxxxx)
Date: Mon Feb 05 2001 - 23:30:53 GMT-3
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