Gre over ipsec

 

Let's test gre over ipsec. The test topology is as follows:

 

 

R2 serves as the internet, R1 and R3 serve as the company's headquarters and branches respectively, and the loopback port is used as the following test network segment R1 lo10 ip: 192.168.1.1/24 lo11 192.168.2.1/24 lo12 192.168.3.1/24

R3 lo10 ip: 172.16.1.3/24 lo11 172.16.2.3/24 lo13 172.16.3.3/24

First of all, why does the gre over ipsec Technology emerge? Although the ipsec VPN of lan-to-lan can solve the problem that the company headquarters can communicate with its branches, it is a fatal defect, that is, ipsec itself does not support encrypted multicast, and all our dynamic routing protocols must use multicast. Therefore, the ipsec VPN of the lan-to-lan is that our dynamic routing protocol will not be used, when the company is large, there will certainly be more network segments, and the ipsec VPN of the lan-to-lan cannot meet the requirements. At this time, we have another protocol gre, it supports the dynamic routing protocol, but it does not support the encryption function. However, ipsec does not support the dynamic routing protocol, but supports the encryption function, the combination of the two gave birth to the gre over ipsec Technology. I don't know if you have ever wondered why you don't need to use ipsec over gre.

For the basic IP Address Configuration, we will not talk about it here. We start IKE's first-stage policy. Here we use AH for testing to see the actual encapsulation results of data packets.

R1 (config) # crypto isakmp policy 1

R1 (config-isakmp) # authentication pre-share

R1 (config-isakmp) # encryption 3des

R1 (config-isakmp) # hash md5

R1 (config-isakmp) # group 2

The first phase of IKE configuration is complete. Next, we will configure the second phase of IKE policy,

 

R1 (config) # crypto ipsec transform-set cisco ah-md5-hmac

R1 (cfg-crypto-trans) # mode tunnel

The pre-shared key is selected for verification. Then we configure the key,

R1 (config) # crypto isakmp key 0 cisco address 23.1.1.3 255.255.255.0

Next we will do map,

R1 (config) # crypto map cisco 1 ipsec-isakmp

R1 (config-crypto-map) # set peer 23.1.1.3

R1 (config-crypto-map) # set transform-set cisco

R1 (config-crypto-map) # match address 100

100 refers to the number of traffic that the acl is interested in,

R1 (config) #$100 permit ip 192.168.0.0 0.0.255.255 172.16.0.0 0.0.255.255

Call this map under the interface

R1 (config-if) # crypto map cisco

Make the same configuration in R3

R3 (config) # crypto isakmp policy 1

R3 (config-isakmp) # authentication pre

R3 (config-isakmp) # encryption 3des

R3 (config-isakmp) # hash md5

R3 (config-isakmp) # group 2

R3 (config) # crypto ipsec transform-set cisco ah-md5-hmac

R3 (cfg-crypto-trans) # mode tunnel

R3 (config) # crypto isakmp key 0 cisco address 12.1.1.1

R3 (config) #$100 permit ip 172.16.0.0 0.0.255.255 192.168.0.0 0.255.255

 

R3 (config) # crypto map cisco 1 ipsec-isakmp

R3 (config-crypto-map) # set peer 12.1.1.1

R3 (config-crypto-map) # set transform-set cisco

R3 (config-crypto-map) # match address 100

 

R3 (config-if) # crypto map cisco

Test the basic ipsec VPN. At this time, our gre has not been configured,

R1 # ping 172.16.1.3 source 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds:

Packet sent with a source address of 192.168.1.1

.!!!! We can see that our test result is successful.

We need to capture packets to see

 

We can see that IKE uses nine packages, six in the first phase and three in the second phase. This is the same as what we saw in the previous article, to see the actual ipsec encapsulation, open an icmp packet to check the effect,

 

The Encapsulation Format is the same as our theory: icmp | internal ip | AH | external IP address. This is the benefit of choosing AH. If you select ESP, the subsequent data is encrypted, so we cannot see the actual Encapsulation Format when we capture the package. Finally, I will put this package on the attachment. If you are interested, please check it out, the basic ipsec VPN test is complete. Next we will test gre over ipsec,

R1 (config) # int tunnel 0

R1 (config-if) # tunnel source 12.1.1.1

R1 (config-if) # tunnel destination 23.1.1.3

R1 (config-if) # ip add 100.100.100.1 255.255.0

The gre tunnel configuration is quite simple. I can't explain it much here, but now we want to rewrite the traffic we are interested in. Why ??

 

R1 (config) # access-list 100 permit gre host 12.1.1.1 host 23.1.1.3 think about the traffic you are interested in?

 

R3 (config) # int tunnel 0

R3 (config-if) # tunnel source 23.1.1.3

R3 (config-if) # tunnel destination 12.1.1.1

R3 (config-if) # ip add 100.100.100.3 255.255.255.0

 

R3 (config) # access-list 100 permit gre host 23.1.1.3 host 12.1.1.1

Next we will run ospf on R1 and R3.

R1 (config) # router OS 1

R1 (config-router) # router-id 1.1.1.1

R1 (config-router) # net 100.100.100.0 0.0.255 a 0

R1 (config-router) # net 192.168.1.0 0.0.255 a 0

R1 (config-router) # net 192.168.2.0 0.0.255 a 0

R1 (config-router) # net 192.168.3.0 0.0.255 a 0

R3 (config) # router ospf 1

 

R3 (config-router) # router-id 3.3.3.3

R3 (config-router) # net 100.100.100.0 0.0.255 a 0

R3 (config-router) # net 172.16.1.0 0.0.255 a 0

R3 (config-router) # net 172.16.2.0 0.0.255 a 0

R3 (config-router) # net 172.16.3.0 0.0.255 a 0

* Mar 1 01:07:01. 431: % OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Tunnel0 from LOADING to FULL, Loading Done can see their neighbor relationship

 

R1 # sh ip rou ospf

172.16.0.0/32 is subnetted, 3 subnets

O 172.16.3.3 [110/11112] via 100.100.100.3, 00:02:10, Tunnel0

O 172.16.2.3 [110/11112] via 100.100.100.3, 00:02:10, Tunnel0

O 172.16.1.3 [110/11112] via 100.100.100.3, 00:02:10, Tunnel0

We can see that R1 learned the lookback port address of R3 from Tunnel0. Similarly, we can see it in R3,

R3 # sh ip rou OS

192.168.1.0/32 is subnetted, 1 subnets

O 192.168.1.1 [110/11112] via 100.100.100.1, 00:03:40, Tunnel0

192.168.2.0/32 is subnetted, 1 subnets

O 192.168.2.1 [110/11112] via 100.100.100.1, 00:03:40, Tunnel0

192.168.3.0/32 is subnetted, 1 subnets

O 192.168.3.1 [110/11112] via 100.100.100.1, 00:03:40, Tunnel0

We can ping the test results. R1 # ping 172.16.1.3 source 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.3, timeout is 2 seconds:

Packet sent with a source address of 192.168.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 188/213/244 MS

We can see that the test result is normal. To see the actual encapsulation effect, we can capture the package,

 

The Data encapsulation format is the same as we predicted: icmp | internal ip | gre | external ip | AH | external ip address. I will upload the package to the attachment. If you are interested, see it.

Finally, a question is raised. If map is called in tunnel0 and no physical interface is called, what will happen. Next time, we will test DMVPN and EZVPN.

This article is from the "hua" blog