GRE over IPSEC Tunnel up Down not coming up (once applied IPsec tunnel protection)

[Vinodh KC]

Hi All,

I have tried the GRE-IPSEC tunnel in GNS3 first i have created

crypto-map

and everything working fine without any issues.

With the same set-up, i have tried with ipsec profie and removed crypto .once i applied the tunnel protection the GRE tunnel is showing up down 

Need your help on this .Below are the configuration 

===================================================================

1) Before applying IPSEC profile in Tunnel interface.

R1#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  administratively down down
FastEthernet1/0            unassigned      YES NVRAM  administratively down down
FastEthernet1/1            192.168.12.1    YES NVRAM  up                    up
SSLVPN-VIF0                unassigned      NO  unset  up                    up
Loopback0                  192.15.38.104   YES manual up                    up
Loopback1                  unassigned      YES NVRAM  up                    up
Tunnel1                    192.168.13.1    YES NVRAM  up                    up
R1#




IP-EIGRP neighbors for process 13
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.13.3            Tu1               13 00:02:29 1315  5000  0  35
R1#




============================================================

R2#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  administratively down down
FastEthernet1/0            unassigned      YES NVRAM  up                    up
FastEthernet1/1            192.168.23.3    YES NVRAM  up                    up
SSLVPN-VIF0                unassigned      NO  unset  up                    up
Loopback0                  192.35.38.103   YES manual up                    up
Loopback1                  unassigned      YES NVRAM  administratively down down
Tunnel1                    192.168.13.3    YES NVRAM  up                    up
R2#

R2#sh ip ei ne
IP-EIGRP neighbors for process 13
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.13.1            Tu1               13 00:01:54  116  1362  0  35
R2#

==========================================================

IPSEC CONFIGURATION:

R1#sh run | sec crypto
crypto isakmp policy 10
 authentication pre-share
crypto isakmp key vino address 192.168.23.3
crypto ipsec transform-set tset esp-3des esp-md5-hmac
crypto ipsec profile IPSEC-PROFILE
 set transform-set tset
R1#




R2#sh run | sec crypto
crypto isakmp policy 10
 authentication pre-share
crypto isakmp key vino address 192.168.12.1
crypto ipsec transform-set tset esp-3des esp-md5-hmac
crypto ipsec profile IPSEC-PROFILE
 set transform-set tset
R2#

==============================================

2)After applying the tunnel protection in tunnel eigrp peer as well tunnel protocol shows down

R2#sh run int tunnel 1
Building configuration...

Current configuration : 228 bytes
!
interface Tunnel1
 ip address 192.168.13.3 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 keepalive 10 3
 tunnel source FastEthernet1/1
 tunnel destination 192.168.12.                                                                                                           tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROFILE
end

R2#




R1#sh run int tunnel 1
Building configuration...

Current configuration : 228 bytes
!
interface Tunnel1
 ip address 192.168.13.1 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 keepalive 10 3
 tunnel source FastEthernet1/1
 tunnel destination 192.168.23.3
 tunnel mode ipsec ipv4   ===>After applying only the ipsec tuunel formed but no encryption                      tunnel protection ipsec profile IPSEC-PROFILE
end

R1#




R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.12.1    192.168.23.3    QM_IDLE           1006 ACTIVE

IPv6 Crypto ISAKMP SA

But no encryption /decryption

R1#sh crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel1
Uptime: 00:02:15
Session status: UP-ACTIVE
Peer: 192.168.23.3 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 192.168.23.3
      Desc: (none)
  IKE SA: local 192.168.12.1/500 remote 192.168.23.3/500 Active
          Capabilities:(none) connid:1006 lifetime:23:57:43
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 4381706/3464
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4381706/3464

R1#

++++++++++++++++++++++++++++++++++++++++++++++++++++++++

R1#

R1#sh int description
Interface                      Status         Protocol Description
Fa0/0                          admin down     down
Fa1/0                          admin down     down     TESTING IPSEC R2
Fa1/1                          up             up       ****  connect to ISP****
SS0                            up             up
Lo0                            up             up
Lo1                            up             up
Tu1                            up             down
R1#




R2#sh run int tunnel 1
Building configuration...

Current configuration : 228 bytes
!
interface Tunnel1
 ip address 192.168.13.3 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 keepalive 10 3
 tunnel source FastEthernet1/1
 tunnel destination 192.168.12.1                                                                                                                     tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROFILE
end

R2#




R2#sh int description
Interface                      Status         Protocol Description
Fa0/0                          admin down     down
Fa1/0                          up             up
Fa1/1                          up             up       *** TO ISP ****
SS0                            up             up
Lo0                            up             up
Lo1                            admin down     down
Tu1                            up             down
R2#







R2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.168.12.1    192.168.23.3    QM_IDLE           1006 ACTIVE

IPv6 Crypto ISAKMP SA

R2#

R2#sh crypto session de
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel1
Uptime: 00:02:39
Session status: UP-ACTIVE
Peer: 192.168.12.1 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 192.168.12.1
      Desc: (none)
  IKE SA: local 192.168.23.3/500 remote 192.168.12.1/500 Active
          Capabilities:(none) connid:1006 lifetime:23:57:20
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 4506558/3440
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4506558/3440

R2#




=========================================================

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I haven't analyzed your config, but I did want to mention, using protection creates a IPSec VTI tunnel, i.e. GRE is no longer used.  BTW, I have running VTI tunnels, i.e. they do work.  Also BTW, I don't believe keepalive will work correctly with VTI tunnels, try removing it.

[Richard Burts · Accepted solution]

Joseph makes an interesting point about GRE keepalive and tunnel protection. When you configure tunnel mode

ipsec ipv4

and tunnel protection then the function of determining whether the tunnel should be up or down is based on the state of the crypto negotiation. GRE keepalive might get in the way of this.

I also agree with Joseph that the feature does work - and work quite well. I have configured many tunnels with tunnel protection and it has worked very well.

HTH

Rick

[BhushanPatil45238]

Thanks, it was due to keep alive only,after removing keep alive tunnel came up!!

[SamuraiEx]

Hello, had the exact same issue on my GNS3 lab - and I did remove the keepalive and it came up. THank you!

[Vinodh KC]

Hi Joseph Doherty ,

Thanks for your update.

Let me remove the keep alive and check & i will share you my complete configuration as soon as possible.

When i came across the Cisco document 

1)IPSEC Tunnel mode means the source IP would be the

Tunnel IP

2)IPSEC Transport means the source IP would be the

Physical IP

Please correct me  If i am wrong.

i have tested same through GNS3-wire shark .However i am seeing for Tunnel mode /Transport mode (IP header) for both  source  IP is my physical interface only. 

[Richard Burts · Accepted solution]

Unfortunately your understanding about the address used for source address is not correct. The address used as the source address for the IPSec packet will always be some address on the device and not the tunnel IP.

HTH

Rick

[Vinodh KC]

Hi Rick,

Thanks 

DOC says ,IPSEC Tunnel mode => First Header will have the

tunnel ip

on  top of the original IP header. 

 Transport header will have the

Physical ip

will be the first header 

Can you please clarify me ..

[Richard Burts]

I am not sure which doc you are referring to or exactly what it says. But I can tell you for sure that the IP address used in the IP header of an IPSec packet will not be the tunnel address. Perhaps one way to explain it is that the source address should be the peering address and the peering address can not be the tunnel address. Remember that the devices must negotiate ISAKMP using the peer address and the tunnel IP address is not reachable until the negotiation is successfully completed. If you try to negotiate to the tunnel address and the tunnel address is not yet up then the negotiation fails.

HTH

Rick

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Basically, IPSec can support its own tunneling and so when used with another tunneling encapsulation mode, you can have redundant addressing (within the transmitted packet), when doing

p2p

between the peering IPs.  The tunnel/transport modes control whether the extra IPSec tunnel addressing is done.  For such

p2p

you don't need the duplication, although I think it's the default.

For example, when doing

site-to-site GRE/IPSec

you don't need two sets of IPs.  It's a little more efficient to turn off the second set with transport mode.

[Vinodh KC]

Hi Jose,

As per your answer ,in

P2P

we couldn't get the result as per the attached DOC

If i have HUB and spoke (IPSEC/DMVPN) as per the above document will get the IP header in wireshark?

Like Tunnel mode

source ip tunnel ip

Transport mode

Source ip physical

My understand completely wrong ?.Need your help understand what below attached diagram says

==============================================

What is a new IP header ? in Tunnel mode

What is original IP header ? in Transport mode  

Please find the attachment here also 

[Vinodh KC]

Source Physical IP     : 192.168.12.1 
Destnation Physical IP : 192.168.23.3

Tunnel Source IP      : 192.168.13.1
Tunnel Destination IP :  192.168.13.3

Tunnel mode with esp:
++++++++++++++++++++

crypto ipsec transform-set ge3vpn esp-3des esp-sha-hmac 

When i am using the i could see below Frame in wireshark

[Protocols in Frame: eth:ip:esp]

complete packet encapsulated including tunnel ip only could see

physical ip's

Here i have attache the diagram which i referred for the tunnel mode & transport mode.

As per the diagram for tunnel mode with esp, it shows NEW IP header will add in top of the original header.

original header tunnel ip or physical ip ?

Could you please guide me if my understanding is wrong that would help me to correct myself.

Transport with AH header

+++++++++++++++++++++++

crypto ipsec transform-set ge3vpn esp-3des esp-sha-hmac 

When i am using the i could see below Frame in wireshark

This header as correct as per the DOC
 

[Protocols in Frame: eth:ip:ah:ip:gre:ipgre]

[Vinodh KC]

Hi Jose

Thank u so much..

You are right once i removed the keep alive conf and the tunnel started to work...no idea how its working?

why

IPSEC profile

with keep alive its not working ? same keep alive configure with

IPSEC crypto map

it's working.

I have one more question here, In

ipsec profile

how the interesting traffic took automatically ? no interesting traffic has been defined myself .

Is this the advantage of creating a

ipsec profile

instead of old tech

(crypto map)

?

R1#sh crypto map
Crypto Map "Tunnel1-head-0" 65536 ipsec-isakmp
        Profile name: vino
        Security association lifetime: 4608000 kilobytes/3600 seconds
        Responder-Only (Y/N): N
        PFS (Y/N): N
        Transform sets={
                ge3vpn:  { esp-3des esp-sha-hmac  } ,
        }

Crypto Map "Tunnel1-head-0" 65537 ipsec-isakmp
        Map is a PROFILE INSTANCE.
        Peer = 192.168.23.3
        Extended IP access list
            access-list  permit gre host 192.168.12.1 host 192.168.23.3
        Current peer: 192.168.23.3
        Security association lifetime: 4608000 kilobytes/3600 seconds
        Responder-Only (Y/N): N
        PFS (Y/N): N
        Transform sets={
                ge3vpn:  { esp-3des esp-sha-hmac  } ,
        }
        Interfaces using crypto map Tunnel1-head-0:
                Tunnel1


R1#

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I did come across some Cisco documentation that helps explain why the keepalive doesn't work with VTI tunnels (I've also bumpted into it keeping the tunnel down, and I recall [?], or not taking the tunnel down when it should).  Keepalives need to be reflected, and with VTI, I believe they get sent either via the tunnel or via the interface but are not reflected or correctly processed on the other side.  I.e. something like tunnel<>interface or interface<>tunnel, whichever, basically the two sides don't correctly match for keepalive generation and reflection.

With a GRE tunnel, including GRE/IPSec, I believe they are processed correctly.  I.e. tunnel<>tunnel or interface<>interface.

As Rick noted, the VTI tunnel will go down if connectivity is lost.  The problem with GRE tunnels, some will stay up even with no end-to-end connectivity.  For the latter, keepalive insures you can detect lost of end-to-end connectivity.

Of course, with either, if your run a dynamic routing protocol across the tunnel, it will detect the lost of the end-to-end connection.

Yes, with VTI you don't have to define interesting traffic (and its less encapsulation overhead too).

With IPSec you need to use cyrpto maps (at least you no longer need to define the crypto statement on both the physical interface and the tunnel interface).

The reason for the difference, with VTI you have an encrypted tunnel, interesting traffic is whatever you direct into the tunnel.

With GRE/IPSec you're encrypting selected GRE traffic on the physical interface, the tunnel, itself, isn't encrypted.