Hi Rene,
Thank you for your excellent explanation!!! Can you add IKEv2 configuration? That will be great to learn since it was out in 2005.
Dear Rene,
Thanks for your nice article as always.
I am little bit confused about your two article âEncrypted GRE Tunnel with IPSECâ and GRE over IPSEC . What is the basic/ main difference between two ?? Pls help me to understand it clearly .Thanks
Br/zaman
Hello Mohammad.
What exactly is meant by each of the two phrases depends on the context. Encrypted GRE Tunnel with IPSec refers to the encryption of the information sent over a GRE tunnel using the functionalities of IPSec. GRE over IPSec is not that specific and it depends on what the person speaking really means.
IPSec used in combination with GRE can function in two ways, either in tunnel mode, or transport mode.
Tunnel mode, which is the default, which is also what Rene has configured in the lesson, the whole GRE packet is encapsulated and encrypted within the IPSec packet.
Transport mode on the other hand, involves the encapsulation of only the GRE payload. The GRE header in this case is not encrypted.
Take a look at this post by Rene for more details.
I hope this has been helpful!
Laz
Hi Rene,
Can you give me an example about how to configure both ipsec AH only and ipsec AH combined with ESP ( in wireshark I can see both AH & ESP ) just like you describe in IPsec (Internet Protocol Security) lessons ??
and I need another example about how to use virtual tunnel interfaces instead of the crypto map ??
Hi Hussein,
The only thing you have to change is the transform set:
R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET ?
ah-md5-hmac AH-HMAC-MD5 transform
ah-sha-hmac AH-HMAC-SHA transform
ah-sha256-hmac AH-HMAC-SHA256 transform
ah-sha384-hmac AH-HMAC-SHA384 transform
ah-sha512-hmac AH-HMAC-SHA512 transform
comp-lzs IP Compression using the LZS compression algorithm
esp-3des ESP transform using 3DES(EDE) cipher (168 bits)
esp-aes ESP transform using AES cipher
esp-des ESP transform using DES cipher (56 bits)
esp-gcm ESP transform using GCM cipher
esp-gmac ESP transform using GMAC cipher
esp-md5-hmac ESP transform using HMAC-MD5 auth
esp-null ESP transform w/o cipher
esp-seal ESP transform using SEAL cipher (160 bits)
esp-sha-hmac ESP transform using HMAC-SHA auth
esp-sha256-hmac ESP transform using HMAC-SHA256 auth
esp-sha384-hmac ESP transform using HMAC-SHA384 auth
esp-sha512-hmac ESP transform using HMAC-SHA512 auth
For example, if you want to use AH:
R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET ah-sha-hmac
or ESP:
R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac
or ESP+AH:
R1(config)#crypto ipsec transform-set MY_TRANSFORM_SET esp-sha-hmac ah-sha-hmac esp-aes
If you want to test this, change the transform-set and then clear the current SA:
R1#clear crypto sa
You can verify if you are using ESP/AH by looking at the SA. For example, hereâs ESP:
R1#show crypto ipsec sa | begin inbound esp
inbound esp sas:
spi: 0x52BDAEFA(1388162810)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 5, flow_id: SW:5, sibling_flags 80004040, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4241877/3557)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x7D2533B3(2099590067)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 6, flow_id: SW:6, sibling_flags 80004040, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4241877/3557)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
Above you see that it only shows inbound/outbound ESP, nothing at AH.
Hereâs AH:
R1#show crypto ipsec sa | begin inbound ah
inbound ah sas:
spi: 0xC412FE1D(3289579037)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
conn id: 7, flow_id: SW:7, sibling_flags 80004050, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4189277/3584)
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound pcp sas:
outbound esp sas:
outbound ah sas:
spi: 0xBF33F950(3207854416)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
conn id: 8, flow_id: SW:8, sibling_flags 80004050, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4189277/3584)
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound pcp sas:
Above you only see inbound/outbound ESP, no AH.
Here is AH+ESP:
R1#show crypto ipsec sa | begin inbound
inbound esp sas:
spi: 0xD68D5E92(3599589010)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 9, flow_id: SW:9, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4298169/3577)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
spi: 0x58397E06(1480162822)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
conn id: 9, flow_id: SW:9, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4298169/3577)
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound pcp sas:
outbound esp sas:
spi: 0x2CA509F3(749013491)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 10, flow_id: SW:10, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4298169/3577)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
spi: 0x110A4D8E(285887886)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
conn id: 10, flow_id: SW:10, sibling_flags 80004070, crypto map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4298169/3577)
replay detection support: Y
Status: ACTIVE(ACTIVE)
Here is a quick example for a virtual tunnel interface. Iâll turn this one into a lesson later:
Here are the configs of the routers.
R1:
hostname R1
!
ip cef
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key MY_PASSWORD address 10.10.10.2
!
crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
set transform-set MY_TRANSFORM_SET
!
interface Tunnel0
ip address 12.12.12.1 255.255.255.0
tunnel source 10.10.10.1
tunnel mode ipsec ipv4
tunnel destination 10.10.10.2
tunnel protection ipsec profile IPSEC_PROFILE
!
interface GigabitEthernet0/1
ip address 192.168.1.254 255.255.255.0
!
interface GigabitEthernet0/2
ip address 10.10.10.1 255.255.255.0
!
ip route 192.168.2.0 255.255.255.0 Tunnel0
!
end
And R2:
hostname R2
!
ip cef
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key MY_PASSWORD address 10.10.10.1
!
crypto ipsec transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac
mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
set transform-set MY_TRANSFORM_SET
!
interface Tunnel0
ip address 12.12.12.2 255.255.255.0
tunnel source 10.10.10.2
tunnel mode ipsec ipv4
tunnel destination 10.10.10.1
tunnel protection ipsec profile IPSEC_PROFILE
!
interface GigabitEthernet0/1
ip address 192.168.2.254 255.255.255.0
!
interface GigabitEthernet0/2
ip address 10.10.10.2 255.255.255.0
!
ip route 192.168.1.0 255.255.255.0 Tunnel0
!
end
The main difference is that we donât use a crypto-map anymore. We still have a crypto isakmp policy and a transform set. What is new is that we have a crypto ipsec profile that refers to our transform-set. We also use a tunnel interface where we refer to our IPSec profile and where Ipsec is enabled.
The tunnel interface now shows IPSEC/IP:
R1#show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 12.12.12.1/24
MTU 17878 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel linestate evaluation up
Tunnel source 10.10.10.1, destination 10.10.10.2
Tunnel protocol/transport IPSEC/IP
We can verify that it works:
R1#show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 10.10.10.2 port 500
Session ID: 0
IKEv1 SA: local 10.10.10.1/500 remote 10.10.10.2/500 Active
Session ID: 0
IKEv1 SA: local 10.10.10.1/500 remote 10.10.10.2/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 6, origin: crypto map
Hope this helps!
Rene
1 Like
Thanks Rene, that help indeed.
I now have a complete example with dynamic VTI and static VTI here:
I am labbing the above and I have a question⌠concerning the âaccess-list 100 permit gre any anyâ command. When I have this command in there, I see encaps and decaps in the âshow crypto ipsec saâ command. However, if I change the âany anyâ to both of the LAN subnets, I no longer see encaps and decaps. I am using GNS3 with an IOS for a 3660 router. Is this a bug? Or am I doing something wrong?
Hi John,
Think of the source and destination addresses of the GRE tunnel. Those are not the IP addresses of your LANs but the IP addresses of the routers that establish the GRE tunnel. For the routers in my lesson that would be:
HQ:
permit gre host 192.168.12 host 192.168.23.3
Branch:
permit gre host 192.168.23.3 host 192.168.12.1
Hope this helps!
Rene
2 Likes
Hi Renee,
Just review of some static route Information. You used:
HQ(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2
does not the 255.255.255.255 mean that every octet is a network?
I guess this static route is setup different than the basic one? meaning its normally:
Network your trying to reach. Then its the subnet mask and then the next hop address.
It threw me off that 192.168.23.2 was an actual host instead of a network like 192.168.23.0.
I am use to seeing it like the following:
ip route 192.168.23.0 255.255.255.0 192.168.12.2
I am rusty on some of this stuff and its just probably something I donât remember clearly but was hoping you could give me a brief summary. My guess is that the 255.255.255.255 means treat it specifically as a address in other words if we did not use the /32 then we could not add the specific IP address. I just wanted to conformation of my thoughts or the correction of them to be more in line with the meaning.
Hello Brian
When you use the ip route command, what you are telling the router is âin order to get to this network, use this next hop IP.â Now the contents of the command is a network address and a subnet mask. So, if you enter the command
ip route 192.168.23.0 255.255.255.0 192.168.12.2
then what you are saying is that if you get a packet with a destination IP address in the range 192.168.23.1 to 192.168.23.254, send it to 192.168.12.2.
If you change the subnet mask, what youâre doing is essentially modifying the range within which the destination address must fall in order to be routed to the specific next hop address. So if the above command instead was
ip route 192.168.23.0 255.255.255.240 192.168.12.2
then what you are saying is that if you get a packet with a destination IP address in the range 192.168.23.1 to 192.168.23.14, send it to 192.168.12.2.
Now if you use a subnet mask of 255.255.255.255 such as was the case in Reneâs command, then you are just restricting the range to a single IP, or a host address which is equally valid. In the example in this lesson, it makes sense to do so because the goal is for the two branch routers to be able to reach each otherâs tunnel source interfaces that correspond to those specific IP addresses. The operation would have worked equally well had he used 255.255.255.0 as the subnet mask.
If you look at the resulting routing table, you should see such static routes as destinations with a /32 prefix, indicating they are indeed hosts.
I hope this has been helpful!
Laz
1 Like
Maybe a little silly question, but - since GRE Tunnel with IPsec configuration goes right after the general IKE/IPSEc theory article, do we need to configure GRE to run encrypted tunnel between two sites? Otherwise why do we need GRE for that at all? Instead of just configuring Ipsec site-to-site tunnel?
And the other silly one - seems crypto map ties up all the encryption scheme, source and destination and shared password, etc, together. Except the isakmp policy for ike phase 1, seems to be . The policy seems is not getting tied up with anything anywhere. Is it just one global policy per router, applied to all the crypto-maps or where does it intersect with the rest of tunnel configuration?
Hello Vadim
About your first question, itâs important to understand what each entity is and does. GRE is a tunneling protocol. It encapsulates packets and allows them to run over another network. So you can run your internal private IP addresses between two sites that connect to each other over the Internet. A GRE tunnel is not encrypted or secured in any way.
IPSec is a secure network protocol suite that authenticates and encrypts packets. It is a method of encryption and authentication and does not include any tunneling mechanisms. It cannot and will not function on its own. It requires a tunneling protocol to function. So IPSec can be coupled with GRE to create an encrypted tunnel.
So to answer your question:
Not really, you can use another tunneling protocol. IN the IKE/IPSec lesson, it is the IKE that establishes the tunnel and IPsec that secures/encrypts it. It really comes down to which technology provides you with what you really need/want.
Concerning your second question, the ISAKMP policies function as follows:
Each configuration supports a maximum of 20 ISAKMP policies, each with a different set of values. Assign a unique priority to each policy you create. The lower the priority number, the higher the priority.
When ISAKMP negotiations begin, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer tries to find a match. The remote peer checks all of the peerâs policies against each of its configured policies in priority order (highest priority first) until it discovers a match.
A match exists when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer policy specifies a lifetime less than or equal to the lifetime in the policy the initiator sent. If the lifetimes are not identical, the security appliance uses the shorter lifetime. If no acceptable match exists, ISAKMP refuses negotiation and the SA is not established.
This was taken from the following Cisco documentation:
I hope this has been helpful!
Laz
Thanks, Lazaros, so ISAKMP policies are indeed not tied to any other configuration (contrary to IPSec portion that are literally point-to-point). There is just a list and it is parsed through by remote peer until it finds the one policy that is the same as configured on it. If none found, negotiation fails. Understood.
Now, as to the second question/explanation, after some digging and chewing, I think Id beg to differ. I got confused because after chapter explaining general IKE/IPsec theory there immediately follows the chapter with configuration of GRE with IPSec. With no chapter providing configuration for just IKE/IPSec. That is a little weird and looks like IPsec tunnels are configured with GRE. But now I see its not the case, simply we jump into additional application of IPsec without addressing configuration of pure IPSec.
Where I beg to differ is your statement that âNot really, you can use another tunneling protocolâ. First, we donât. GRE CAN be used with IPsec, and some other tunneling protocols CAN be used but neither is necessary. IPsec does not need ANY other tunneling protocols. Second, IPsec (and IKE or their combination) IS a tunneling protocol. Tunnel here is defined by a set of parameters included into SA but in the end what is important is that it encapsulates the original data into additional layer, which is particularly obvious in âtunnelingâ mode with new IP slapped on the packet (so same as in GRE private IP traffic can pass through public network) but even in âtransportâ mode the original data not just encrypted but encapsulated, which Id say would be definition of a âtunnelâ. And thats how seems IPsec commonly referred to - âIPSec tunnelâ. It does not even need IKE to form. While at the same time IKE creates its own âtunnelâ, not related to IPsec tunnel, though in this case the term âtunnelâ probably is less obvious, though still it is âtunnelingâ , or encapsulating, data that are used for other services (thats IPsec), even if thats only passwords. To further support what Im saying IKE and IPsec âtunnelsâ may and usually have different lifetimes, so either can expire and disappear while another one is still up. Until I see some definition of a âtunnelâ which defies above I say:
- The IPsec IS a tunnel protocol which does not rely on any other tunnel protocol.
- IPsec often is combined with another tunnel protocol - IKE, for ease of management. Or may not.
- IPSec may be used to further encapsulate (and tunnel) another tunnel protocol (like GRE, or mplsâŚ) to add security to them. It also may NEED them in some cases as for example its seems not capable of handling multicasts by itself, so need GRE to do that.
- IKE is a tunnel protocol that is used to pass information needed to establish a lighter, quicker and more flexible secure tunnels like IPSec. It is not used to pass real data itself as involved mechanisms to establish secure tunnel, namely Diffie-Hellman, are quite intensive and slow, but more convenient (and actually more secure) for delivering for instance shared passwords between two peers than say over the phone.
Just want to note here as well, that I enjoy reading materials provided by Rene, find them quite better than most other on Internet and consider them of great help. But nothing is perfect and in this case it seems a glitch of a sort, with the whole piece of the standard VPN configuration missing. And pretty much answering my own questions sometimes seems a little counterproductive 
- I would hope for more accurate and detailed answers. Also, would be really nice to have IKEv2 configuration presented as it is quite more complicated while ikev1 is really a legacy features these days.
Thanks
1 Like
Does the crypto isakmp policy number have to match with the the crypto map number. In this example, they are both 10. If they donât, how are the parameters of the crypto policy linked to the crypto map?
Hello Thierno
ISAKMP policies are not tied directly to the crypto map so the numbers donât have to be the same. ISAKMP policies function as follows:
Each configuration supports a maximum of 20 ISAKMP policies, each with a different set of values. Assign a unique priority to each policy you create. The lower the priority number, the higher the priority.
When ISAKMP negotiations begin, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer tries to find a match. The remote peer checks all of the peerâs policies against each of its configured policies in priority order (highest priority first) until it discovers a match.
A match exists when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer policy specifies a lifetime less than or equal to the lifetime in the policy the initiator sent. If the lifetimes are not identical, the security appliance uses the shorter lifetime. If no acceptable match exists, ISAKMP refuses negotiation and the SA is not established.
This was taken from the following Cisco documentation:
I hope this has been helpful!
Laz
Hi Everyone,
Does anyone have a working configuration of either GRE over IPSec using Loopbacks OR IPSec using Loopbacks?
It would be much appreciated.
Regards,
Shay Kotian
Hello Vibhum
You can find some good case studies and examples at this Cisco documentation. It includes an example where a loopback interface is used as a source IP address for a point to point GRE tunnel.
I hope this has been helpful!
Laz
Hi All! Iâm little bit confused, iâm configuring a routed based vpn, GRE tunnel for a ASA and a Router with both Ipsec in my test enviroment. Do a still need a interesting traffic ACL and do i also need to exempt traffic from noNat or Overload, this is needed for a policy based vpn configuration (Anyconnect or site to site)?