GRE tunnel protocol comes down when IPSec comes up

[n_parshina]

Hi. I have not been able to solve an issue with the following configuration:

Cisco 1760 w/IOS 12.4(16) at remote end, 3845 w/IOS 12.3(14)T7 at headquarters. Both physically connected to Internet. A GRE tunnel is created between them and given IP addresses. GRE is up and traffic through it flows. When IPSec is brought up to encapsulate the GRE tunnel, the line protocol drops and nothing helps.

Tried changing IPSec parameters (btw, the crypto maps work, they say they're up and active), routing.. just doesn't help.

The configs are as follows:

Remote:

crypto isakmp policy 50

encr 3des

hash md5

authentication pre-share

lifetime 14400

crypto isakmp key UKM-RKO-904711 address x.x.x.x

!

!

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac

!

crypto map MAP 10 ipsec-isakmp

set peer x.x.x.x

set transform-set 3DES

match address 105

ip access-list extended 105

permit gre host y.y.y.y host x.x.x.x

interface Tunnel1

ip address 10.1.9.38 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip route-cache flow

keepalive 15 3

tunnel source y.y.y.y

tunnel destination x.x.x.x

tunnel key 5763542

tunnel checksum

interface BVI1

ip address y.y.y.y 255.255.255.252

crypto map MAP

Remote#sh ip int br

Interface IP-Address OK? Method Status Protocol

Tunnel1 10.1.9.38 YES NVRAM up down

HQ:

crypto isakmp policy 40

encr 3des

hash md5

authentication pre-share

lifetime 14400

crypto isakmp key UKM-RKO-904711 address y.y.y.y

crypto ipsec transform-set 3DES esp-3des esp-md5-hmac

crypto map GRE-CM 68 ipsec-isakmp

set peer y.y.y.y

set transform-set 3DES

match address 156

Extended IP access list 156

permit gre host x.x.x.x host y.y.y.y

interface Tunnel904

ip address 10.1.9.37 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip route-cache flow

keepalive 15 3

tunnel source x.x.x.x

tunnel destination y.y.y.y

tunnel key 5763542

tunnel checksum

interface GigabitEthernet0/0

ip address x.x.x.x 255.255.255.192

ip nat outside

ip virtual-reassembly

no ip route-cache

no snmp trap link-status

no cdp enable

crypto map GRE-CM

HQ#sh ip int br

Tunnel904 10.1.9.37 YES manual up down

When I apply the crypto maps to interfaces, tunnels drop... any ideas?

[andrew.prince]

Try using loopback interfaces, then configure the loopbacks as the source and destinations of the tunnel interfaces.

HTH>

[cisco24x7]

Why do you have to use loopback interface? His

configuration looks correct.

If you use loopback interfaces, you have

to make the loopback interface reachable from

both sides. You are wasting more public

address space and accomplish nothing.

I ran into a IOS bug where in the ACL you have

to allow IP instead of GRE. Your

configuration looks correct. That's what

I would do next.

[andrew.prince]

Why do you have to use loopback interface? - Do not HAVE to, it was a suggestion. I like loopbacks = as they are ALWAYS up. They are NOT dependant of any interfaces, or circuits.

If you use loopback interfaces, you have

to make the loopback interface reachable from

both sides. You are wasting more public

address space and accomplish nothing - Errm no actually, if you have NOT planned your IP addressing scheme then yes you can waste IP's, but if you have planned you will not have to waste any IP addresses. As loopback interfaces allow specific /32 IP addresses. So you could assign a /24 and use it ONLY for loopback interfaces, so you can have 254 in the network. Last time I checked the 10/8 allows 18 million IP addresses.

[cisco24x7]

For almost all situations, you want the GRE

end-point to be the same as the IPSec end-point.

That way, the configuration is much easier.

[n_parshina]

Using loopback interfaces here is impossible and impractical - the remote end does not have any available IP addresses for that, and the connections on physical interfaces remain stable.

I checked, double checked and triple checked everything: the line protocol on the gre tunnel goes down as soon as crypto maps are brought up. I still do not understand what's the connections, even debugs show me nothing.

As cisco24x7 suggested, I tried changing the ACLs to allow IP insted of GRE, or both IP and GRE. Unfortunately, that did not help either.

Any other thoughts?

[Jason Gervia]

Hello,

Without your complete configuration from both side, it's hard to tell what exactly is going on.

Try turning off the keepalives on both sides. There have been known issues with keepalives and IPSEC. This will bring the gre tunnel up, and then you can verify whether connectivity over ipsec is working or not (ie it's just a keepalive issue) or if there is an actual total ipsec issue you have to deal with.

--J

[cisco24x7]

His configuration looks correct. I just tested

his configuration on a VXR7204 running IOS

12.2(46) and Cisco 3640 running IOS version

12.3(8)T and it works fine.

Look like this is an IOS bug.

My 2c.

[n_parshina]

Problem resolved.

I see it as a software bug...

First I removed the keepalives, as jagervia suggested. That brought the line protocol up on the tunnel, but no traffic would pass through it....

The solution was to change the transform sets from esp-md5-hmac esp-3des to ah-md5-hmac esp-3des ...

After that, all started working.

Interesting fact is that things like sh crypto session kept telling me that IPSec is up and active even with the ESP transform set.. All things seemed to work without errors, except, in fact, nothing did.

p.s.: gentlemen, it's "her" configuration, not "his"..