Shulou(Shulou.com)06/01 Report--

Analysis of GRE OVER IPSEC process

First, the background.

IPsec is a very mainstream branch interconnection protocol nowadays, and its powerful encryption and verification functions ensure the security of private network data during Internet transmission. However, in the face of the current diversified access requirements, Ipsec × × can not meet the complex requirements of customers for the exchange of visits between private network segments. In the actual environment, the organization that separates the two places requires that the routing neighbor relationship between private networks be established through × × × tunnel, but Ipsec × × × itself does not have the ability to transmit routes, so GRE over IPSEC technology arises at the historic moment.

Second, basic principles

We know that according to the security requirements of the packet, the traditional IPsec usually uses two protocols to encapsulate the packet: AH and ESP. AH mainly uses the authentication mechanism, combined with the corresponding summary algorithm to calculate that the authentication field is filled into the data packet, and the receiver analyzes the legitimacy and integrity of the message by comparing the relevant information in the verification field, but AH itself does not have the function of secure encryption, which leads to the fact that in addition to its own authentication function, ESP,ESP will encrypt the packet first and then add the ESP header and tail. To protect the confidentiality of the data

In addition to AH and ESP, there is another key protocol, IKE, which is mainly used for key exchange and is often used to establish SA in × ×. IKE itself is based on the UDP500 port and has the possibility of traversing NAT. The exchange mode of IKE is divided into main mode and aagresive mode. The two modes take different measures according to the IP address between gateways. Main mode is mainly suitable for cases where the IP addresses at both ends of the line are fixed. Six negotiation messages are taken during negotiation, and the ID information of the peer identity is encrypted before sending in the authentication phase. In aggressive mode, the ID information is sent in clear text when the first and second messages are sent. So the main mode is more secure. Aggressive mode is suitable for situations where the IP addresses of both parties are not fixed (such as pppoe dialing, DHCP acquisition, IPCP negotiation address, etc.). Sending 3 messages during negotiation is faster and supports nat traversal.

Third, topological structure

Fourth, topology requirements:

This experimental environment is an environment with NAT equipment. RT3 (branch office) and RT1 (headquarters) set up GRE OVER IPSEC,SW1 to simulate the equipment of public network operators through the public network, and dynamically assign IP addresses to RT2.

Fifth, topological analysis:

1. There are NAT devices on the boundary of the branch office in this environment. RT3 must consider the problem of NAT when establishing × × × with RT1, so you must enable NAT traversal when establishing IKE; do not allow × × interesting traffic to enter the NAT engine of RT2 on RT2, otherwise an error will occur in the establishment of × × IKE; in the × × environment of NAT traversal, in addition to the above cases where a single NAT gateway device exists, there are also the following situations:

In this topology, RT2 acts as both a × × × gateway and a NAT gateway. By default, NAT is given priority in the router before matching the interesting data flow. If this is an H3C device, you need to take measures of tunnel separation to ensure the normal passage of the interested traffic, that is, when selecting the interested data flow through the acl, you need to deny the interested data traffic in the rule in the access control. And then add a rule to permit the traffic that needs to be forwarded by NAT, which can not only ensure the normal access of NAT traffic to the public network, but also make the interested traffic pass normally.

2GRE defines the source address and destination address when establishing a tunnel, but in the GRE OVER IPSEC message, GRE encapsulates the interior of IPsec, so the tunnel traffic established by the entire GRE is encrypted by IPSEC, so when defining the interested traffic, it is necessary to define the source and destination interface of the tunnel interface as the source and destination of the interesting flow.

3. When the dynamic routing protocol is run in the GRE tunnel, the published route is the tunnel tunnel address and the private network routing address. When the loopback interface is established with × ×, the loopback interface cannot be published to this routing protocol, otherwise up/down will occur on the tunnel interface.

4. The public network equipment does not need to have a route to the loopback interface between the two places, which can be analyzed by GRE OVER IPSEC packet encapsulation.

5 the difference between GRE OVER IPSEC and IPSEC OVER GRE: first, one can tell by name that the former is GRE encapsulated in IPSEC message, while the latter is IPSEC message encapsulated in GRE; secondly, the data traffic encrypted by the latter is an individual private network segment defined separately, while the traffic encrypted by the former is the entire GRE tunnel, as long as the private network data published through the routing protocol running through the GRE tunnel will be encrypted

Third, because GRE OVER IPSEC is outside the IPSEC header, according to the IP address between border gateways, we can flexibly use the two modes of IPSEC tunnel: transport and tunnel mode, and because the packet encapsulation of transport mode is simpler, it is less than tunnel mode in terms of traffic processing and software resource consumption.

Second, topology configuration:

RT1:

IPsec configuration

Ike local-name center

Ike peer zwc

Exchange-mode aggressive

Pre-shared-key simple 123

Id-type name

Remote-name banch

Nat traversal

Ipsec proposal 1

Ipsec policy-template zwc 1

Ike-peer zwc

Proposal 1

Ipsec policy zwc1 1 isakmp template zwc

Interface GigabitEthernet0/0/0

Port link-mode route

Ip address 200.1.1.2 255.255.255.0

Ipsec policy zwc1

GRE configuration:

Interface Tunnel0

Ip address 10.1.1.1 255.255.255.0

Source LoopBack0

Destination 3.3.3.3

Routing configuration:

Ospf 100

Area 0.0.0.0

Network 10.1.1.0 0.0.0.255

Network 172.16.1.1 0.0.0.0

#

Ip route-static 0.0.0.0 0.0.0.0 200.1.1.1

Address configuration:

Interface LoopBack0

Ip address 1.1.1.1 255.255.255.255 / / loopback interface address

#

Interface LoopBack1

Ip address 172.16.1.1 255.255.255.255 / / Intranet address

RT3 configuration:

IPsec configuration

Ike local-name banch

Ike peer zwc

Exchange-mode aggressive

Pre-shared-key simple 123

Id-type name

Remote-name center

Remote-address 200.1.1.2

Nat traversal / / ike negotiation can be established normally if you do not type this command, but the tunnel port cannot up

#

Ipsec proposal 1

Acl number 3000

Rule 0 permit gre source 3.3.3.3 0 destination 1.1.1.1 0 / / tunnel traffic at both ends

Ipsec policy zwc 1 isakmp

Security acl 3000

Ike-peer zwc

Proposal 1

Ipsec policy zwc 1 isakmp

Security acl 3000

Ike-peer zwc

Proposal 1

GRE configuration:

Interface Tunnel1

Ip address 10.1.1.2 255.255.255.0

Source LoopBack0

Destination 1.1.1.1

Routing configuration:

Ospf 100

Area 0.0.0.0

Network 10.1.1.0 0.0.0.255

Network 192.168.3.1 0.0.0.0

#

Ip route-static 0.0.0.0 0.0.0.0 23.1.1.2

RT2 configuration:

Acl number 2000

The traffic defined by rule 0 permit source 23.1.1.0 0.0.0.255 / / does not need to take into account split tunneling

Interface GigabitEthernet0/0/0

Port link-mode route

Nat outbound 2000 / / NAT configuration

Ip address dhcp-alloc

Interface GigabitEthernet0/0/1

Port link-mode route

Ip address 23.1.1.2 255.255.255.0

Ip route-static 0.0.0.0 0.0.0.0 100.1.1.1

View the NAT conversion record:

[RT2] display nat session

There are currently 1 NAT session:

Protocol GlobalAddr Port InsideAddr Port DestAddr Port

UDP 100.1.1.2 12291 23.1.1.3 500 200.1.1.2 500

Status:11 TTL:00:04:00 Left:00:03:52 × ×:--

During the establishment of SA negotiation phase, IKE initiates a session using the UDP500 port. Here you can see that the NAT gateway has translated the source address and source port of the ipsec packet from 500 to 12291, 23.1.1.3-> 100.1.1.2. Because the traversal function of NAT is enabled, the parameters negotiated by IKE when establishing SA are no longer IP address information, but identifier information, and ike local-name.

View the ike SA status of RT1:

Disp

Display ike sa

Total phase-1 SAs: 1

Connection-id peer flag phase doi

38 100.1.1.2 RD 1 IPSEC

39 100.1.1.2 RD 2 IPSEC

Flag meaning

RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO-TIMEOUT

View the IPSec SA status of RT1:

Display ipsec sa

= =

Interface: GigabitEthernet0/0/0

Path MTU: 1500

= =

-

IPsec policy name: "zwc1"

Sequence number: 1

Mode: template

-

Connection id: 21

Encapsulation mode: tunnel

Perfect forward secrecy:

Tunnel:

Local address: 200.1.1.2

Remote address: 100.1.1.2

Flow:

Sour addr: 1.1.1.1/255.255.255.255 port: 0 protocol: GRE

Dest addr: 3.3.3.3/255.255.255.255 port: 0 protocol: GRE

[inbound ESP SAs]

Spi: 3981374185 (0xed4ef2e9)

Proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5

Sa duration (kilobytes/sec): 1843200 Universe 3600

Sa remaining duration (kilobytes/sec): 1843195Accord 2950

Max received sequence-number: 52

Anti-replay check enable: Y

Anti-replay window size: 32

Udp encapsulation used for nat traversal: Y

[outbound ESP SAs]

Spi: 2812594908 (0xa7a4cadc)

Proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5

Sa duration (kilobytes/sec): 1843200 Universe 3600

Sa remaining duration (kilobytes/sec): 1843195Accord 2950

Max received sequence-number: 53

Udp encapsulation used for nat traversal: Y

View the ospf status of RT1:

Display ospf peer

OSPF Process 100 with Router ID 172.16.1.1

Neighbor Brief Information

Area: 0.0.0.0

Router ID Address Pri Dead-Time Interface State

192.168.3.1 10.1.1.2 1 39 Tun0 Full/-

Check the learning status of private network routing:

Display ip routing-table

Routing Tables: Public

Destinations: 10 Routes: 10

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 Static 60 0 200.1.1.1 GE0/0/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 Direct 0 0 10.1.1.1 Tun0

10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

172.16.1.1/32 Direct 0 0 127.0.0.1 InLoop0

192.168.3.1/32 OSPF 10 1562 10.1.1.2 Tun0

200.1.1.0/24 Direct 00 200.1.1.2 GE0/0/0

200.1.1.2/32 Direct 00 127.0.0.1 InLoop0

As you can see, the private network route 192.168.3.1 RT3 32 has been learned through ospf

Here, SW1 simulates a public network device. Enable DHCP to assign addresses on SW1, and configure interface IP. There is no need to add any routes. Only a default route for external access to the public network is needed on RT2, and there is no need to define any route to the private network × × network segment on RT3.

Note: see the attachment for the topology diagram

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.