Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

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

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#

 

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

  • WAN Routing and Switching
2 ACCEPTED SOLUTIONS

Accepted Solutions
Hall of Fame Super Silver

Joseph makes an interesting

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

Hall of Fame Super Silver

Unfortunately your

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

11 REPLIES
Super Bronze

DisclaimerThe Author of this

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.

Hall of Fame Super Silver

Joseph makes an interesting

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

New Member

Hi Joseph Doherty ,Thanks for

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. 

 

 

 

 

Hall of Fame Super Silver

Unfortunately your

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

New Member

Hi Rick, Thanks DOC says

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 ..

Hall of Fame Super Silver

I am not sure which doc you

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

Super Bronze

DisclaimerThe Author of this

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.

New Member

Hi Jose, As per your answer

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 

New Member

Source Physical IP     : 192

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]


  

1351
Views
10
Helpful
11
Replies
This widget could not be displayed.