[Dr.WoW] [No.24] GRE-part 1

Latest reply: May 19, 2018 01:27:46 2323 3 1 0

To discuss GRE, we first have to shift our focus 20 years back into the past, and look at some of the events that happened during those times. At that time, the Internet had already begun to develop quickly, and increasing amounts of resources were being connected by the Internet, making contact between people faster and more convenient―certainly cause for celebration. However, the seemingly harmonious online world was also full of many causes for worry. Life is often like this―people's sources of happiness tend to be roughly the same, but their sources of misery vary greatly. After being connected to the Internet, private networks faced the following headaches:

l   There was no way for networks with private IP addresses to directly connect with each other through the Internet.

Not too much needs to be said about this point―all private networks use private addresses, while packets sent on the Internet must use public addresses. This is shown in Figure 1-1.

Figure 1-1 Private IP networks cannot connect directly through the Internet)

[Dr.WoW] [No.24] GRE-part 1-1334929-1 

l   Different types of networks (IPX, AppleTalk) cannot directly communicate with each other through the Internet.

This headache is caused by a head-ache inducing, but logical 'birth defect', this being that as IPX and IP are not the same type of Internet protocol, IP networks don't transmit IPX packets. This is shown in Figure 1-2.

Figure 1-2 Different types of networks (IPX, AppleTalk) cannot directly communicate with each other through the Internet

[Dr.WoW] [No.24] GRE-part 1-1334929-2 

There are many more similarly tear-inducing stories, and I won't go into detail about them, but basically these headaches coagulated and formed together into an enormous impetus that drove network engineers to wrack their brains in looking for a solution. Finally, in 1994, Generic Routing Encapsulation (GRE) (RFC 1701 and RFC 1702) came into being.

The creation of GRE ensures that the aforesaid headaches will no longer occur today. Now, I'm sure everyone is thinking: "What methods does GRE use exactly to solve all of these aforesaid difficulties? Actually, this is very easy to explain. GRE uses the "alter ego" technology popular today--if packets sent by private networks cannot be transmitted on the Internet for various reasons, why not give these packets "alter egos" that the Internet can recognize, and then transmit them on the Internet? This works because the Internet only recognizes the alter-ego, not the person behind it. The network term for this kind of alter-ego is "encapsulation."

1 GRE Encapsulation/Decapsulation

Any kind of network encapsulation technology's basic structural elements can be divided into three parts (passenger protocols, encapsulation protocols, and transport protocols), and GRE is no exception. Below, I'll use a comparison to the postal system to help us understand encapsulation technology.

l   Passenger protocols

Passenger protocols are the letters we write. These letters may be written in Chinese, English, French, etc., and the writer and reader themselves are responsible for the specific content of the letter.

l   Encapsulation protocols

Encapsulation protocols can be compared to different types of mail: mail can be sent using ordinary mail, registered mail or EMS. Different types of mail correspond to different encapsulation protocols.

l   Transport protocols

Transport protocols are a letter's method of transport; this could be by land, sea or air. Different methods of transportation correspond to different transport protocols.

Now that we've understood the above metaphor, we can take another look at which protocols are used in GRE, as shown in Figure 1-3.

Figure 1-3 GRE protocols

[Dr.WoW] [No.24] GRE-part 1-1334929-3 

The figure allows us to clearly see that the protocols that GRE can carry include IP protocols and IPX protocols, and that the transport protocol used by GRE is the IP protocol.

Now that we've learned about the basic concepts behind GRE, let us next look at the principles behind GRE encapsulation. In Figure 1-4, we've used the IP protocol as the passenger protocol, so that the end result of encapsulation is an IP packet encapsulating an IP packet.

Figure 1-4 GRE packet encapsulation

[Dr.WoW] [No.24] GRE-part 1-1334929-4

 

The GRE encapsulation process is made up of two steps. The first step is adding a GRE heading onto the front of the private network's original packet. The second step is adding a new IP heading in front of this GRE heading, with the IP address in the new IP heading being the public network address. The addition of the new IP heading means that this private network's packet, having been encapsulated layer by layer, can now be transmitted on the Internet.

On firewalls, encapsulation operations are achieved using a logical interface, this being the famous tunnel interface. From the word tunnel we can see that this logical interface is created for tunneling. Information about the source address and destination address for the new IP header is on the tunnel interface, and after a packet enters the tunnel interface, the firewall will encapsulate a GRE header and IP header onto the packet.

So how does a firewall deliver a packet to the tunnel interface? This is achieved via routing, and firewalls support two methods for this:

l   Static routing

This refers to firewalls on both ends of the GRE tunnel configuring static routing to and from each other's private network segments. The next hop is set to the IP address of the terminal's tunnel interface, which is the sending tunnel interface.

l   Dynamic routing

Configuring dynamic routing (such as OSPF) on firewalls on both ends of the GRE tunnel means broadcasting the addresses of their private network segments and tunnel interfaces, so that the two firewalls will learn routes to each other's private network segments. The next hop is the other firewall's tunnel interface's IP address, and the sending interface is the tunnel interface of the sending firewall.

Regardless of which kind of routing is used, the end goal is to generate routes for the corresponding private network segments on the firewalls' routing tables, and to use these routes to guide packets into the tunnel interface for encapsulation.

Figure 1-5 shows the process by which firewalls encapsulate, decapsulate, and forward private network packets.

Figure 1-5 GRE packet forwarding process

[Dr.WoW] [No.24] GRE-part 1-1334929-5 

When PC_A seeks to access PC_B through GRE tunneling, the packet forwarding process by FW_A and FW_B is as follows:

1.        After PC_A's original packets accessing PC_B enters FW_A, the routing table is first checked for a match.

2.         FW_A then sends the packet to the tunnel interface for GRE encapsulation based upon the results of the route check, where a GRE header and a new outer-layer IP header are added.

3.         FW_A then re-checks the routing table using the encapsulated packet's new IP header's destination address.

4.         FW__A sends the packet to FW_B based upon the results of the route check. In the above figure it is assumed that the next-hop address found by FW_A for FW_B is 1.1.1.2.

5.         After FW_B receives the packet, it must first determine whether or not this packet is a GRE packet.

How can this be deduced? We've seen that during the encapsulation process the encapsulated GRE packet has a new IP header. This new IP header includes a protocol segment, which marks the class of the inner layer's protocol. If this protocol segment's value is 47, this means that the packet is a GRE packet.

6.         If a packet received by FW_B is a GRE packet, then the packet will be sent to the tunnel interface for decapsulation, where the outer layer IP header and GRE header will be stripped away, restoring the original packet.

7.         FW_B will re-check the routing table based upon the destination address of the original packet, and will then send the packet to PC__B using the matching routing result.

This is the complete process for how firewalls carry out GRE encapsulation/decapsulation and forwarding for private network packets. Pretty simple, huh!?

2 Configuring Basic GRE Parameters

Above, we discussed the tunneling, encapsulation and decapsulation processes for private network packets from a theoretical perspective. But, I bet everyone is more interested in learning about how to configure GRE tunneling on firewalls, isn't that right? Below, we'll use Figure 1-6 to help explain configuration methods for GRE tunneling.

Figure 1-6 GRE VPN network organization

[Dr.WoW] [No.24] GRE-part 1-1334929-6 

Configuring GRE tunneling is very simple, and can be divided into two steps.

 1.   Configure the tunnel interface.

Configure FW_A's tunnel interface's encapsulation parameters.

[FW_A] interface Tunnel 1

[FW_A-Tunnel1] ip address 10.1.1.1 24

[FW_A-Tunnel1] tunnel-protocol gre

[FW_A-Tunnel1] source 1.1.1.1

[FW_A-Tunnel1] destination 2.2.2.2

[FW_A-Tunnel1] quit

Add FW_A's tunnel interface to a security zone. The tunnel interface can be added onto any one security zone; here we've added the tunnel interface to the DMZ zone.

[FW_A] firewall zone dmz

[FW_A-zone-dmz] add interface Tunnel 1

[FW_A-zone-dmz] quit

Configure FW_B's tunnel interface's encapsulation parameters.

[FW_B] interface Tunnel 1

[FW_B-Tunnel1] ip address 10.1.1.2 24

[FW_B-Tunnel1] tunnel-protocol gre

[FW_B-Tunnel1] source 2.2.2.2

[FW_B-Tunnel1] destination 1.1.1.1

[FW_B-Tunnel1] quit

Add FW_B's tunnel interface to a security zone. As with FW_A, we've added the tunnel interface to the DMZ zone.

[FW_B] firewall zone dmz

[FW_B-zone-dmz] add interface Tunnel 1

[FW_B-zone-dmz] quit

When configuring encapsulation parameters for the tunnel interfaces, we first set the tunnel interfaces' encapsulation type to GRE, and then designated the GRE tunnel's source and destination addresses. These steps seem very simple, but although few in number, they play a decisive role in allowing the tunnel interfaces to complete GRE packet encapsulation:

?       This first stipulated that the tunnel interfaces need to encapsulate GRE headers.

?       Next, this stipulated the source and destination addresses for the new IP header, which in fact are just the IP addresses for the public network interfaces for the firewalls on both ends of the GRE tunnel.

These two points are identical in theory to encapsulating GRE packets, and are relatively easy to understand. However, I'm thinking that everyone may now have the following thoughts about the properties of the tunnel interfaces themselves:

?   Is it necessary to configure IP addresses for the tunnel interfaces?

?       Are the IP addresses for the tunnel interfaces belonging to the firewalls on both ends of the tunnel related to one another?

?       Do the tunnel interfaces use public network IP addresses or private network IP addresses?

It is necessary to configure IP addresses for the tunnel interfaces. If IP addresses are not configured, it is impossible for the tunnel interfaces to be in an UP state. Secondly, in terms of the process of GRE encapsulation, the tunnel interfaces' IP addresses do not participate in packet encapsulation, so there is no relationship between the IP addresses for the tunnel interfaces belonging to the firewalls on each of the tunnel; each can be configured separately. Finally, since the tunnel interfaces do not participate in encapsulation, there is no need to use a public network address, and configuring a private network IP address is fine.

2.  Routing configuration―guiding packets in need of GRE encapsulation to the tunnel interface.

I've already mentioned above that firewalls support both static and dynamic routing, and either one of these two methods can be chosen.

Static routing

To configure static routing on FW_A, set the next-hop for the route to HQ's private network as the tunnel interface.

[FW_A] ip route-static 192.168.2.0 24 Tunnel 1

To configure static routing on FW_B, set the next-hop for the route to the branch organization's private network as the tunnel interface.

[FW_B] ip route-static 192.168.1.0 24 Tunnel 1

Dynamic routing

To configure OSPF on FW_A, broadcast the network segments for the branch organization's private network and the Tunnel interface in OSPF.

[FW_A] ospf 1

[FW_A-ospf-1] area 0

[FW_A-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255

[FW_A-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

To configure OSPF on FW_B, broadcast the network segments for HQ's private network and the tunnel interface in OSPF.

[FW_B] ospf 1

[FW_B-ospf-1] area 0

[FW_B-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255

[FW_B-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

After configuration is complete, FW_A and FW_B will learn the routes to each other's private network segments.

There is one point to be aware of: when using the OSPF dynamic routing method, if the public network interface corresponding to the GRE tunnel also uses OSPF to broadcast routes, we need to use a new OSPF process to broadcast the network segments for the private network and the tunnel interface, to avoid private network packets being directly forwarded through the public network interface rather than being forwarded through the GRE tunnel.

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Jun 25, 2015 04:21:46 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

wissal
MVE Created Apr 10, 2018 15:47:59 Helpful(0) Helpful(0)

useful document, thanks
  • x
  • convention:

Telecommunications%20engineer%2C%20currently%20senior%20project%20manager%20at%20an%20operator%2C%20partner%20of%20Huawei%2C%20in%20the%20radio%20access%20network%20department%2C%20for%2020%20years%20I%20managed%20several%20types%20of%20projects%2C%20for%20the%20different%20nodes%20of%20the%20network.
w1
Created May 19, 2018 01:27:46 Helpful(0) Helpful(0)

:) GOOD
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login