Buying factories in Siberia was the strategically correct decision for the company “Lift mi Am”. After the elevators began to travel not only up, but also down, the company went ... no flew up. The elevators began to be dismantled, like hot cakes from the table. The name was no longer true and a decision was made to rebrand. ( In fact, they were tortured by litigation with Moby ).
So, it is planned to take factories in Novosibirsk, Tomsk and Brno under the wing of LinkMiAp. It's time to think about how to connect this economy to the existing network.

So, today we are considering
1) Possible connection options, their pros and cons
2) Site-to-Site VPN based on GRE and IPSec
3) A big topic: a dynamic multipoint virtual network (DMVPN) in theory and practice.

In the traditional video, there is only a capacious squeeze from an article devoted to the operation and configuration of DMVPN.



When you want to connect several offices, you have a huge choice of methods and means. It all depends on your capabilities, abilities, desires and the availability of equipment.

Let's go in order.

A ) To build a physical channel with your own hands. Then it could be:

1. Ethernet is twisted pair. Up to 100 meters. Maximum in a building or between adjacent buildings. Speed ​​up to 1 Gbit / s (Strictly speaking, there is a standard 10GBASE-T, which allows transmitting data at the same distance at a speed of 10 Gbit / s).
2. WiFi. The distance depends on the implementation: it is possible to achieve operability up to 40 km using powerful directional antennas. On average, up to 5 km with direct visibility. Speed ​​depends on the standard used and the distance. It is necessary to register with Roskomnadzor, and at high radiation powers, and obtain permission to turn it on.
3. xDSL - two to four wires. The speed depends on the distance (theoretical maximum 250 Mbps, distance up to 6 km). Although there are rumors about the development of the standard 1GB / s on two wires.
   Or solutions like E1.
   

   This does not mean an Internet connection via xDSL, but namely a link: a modem modem. Yes, and such solutions exist . You can call it a bridge.
   

   
   
4. Radio Relay Lines. Distance to several tens of kilometers. Speed ​​up to 600 Mb / s. But this solution is already at the operator level, since it requires a lot of approvals and measures for planning, construction, commissioning.
5. Optical fiber. 1 Gb / s (10 and 100 Gb / s solutions can be unreasonably expensive). The distance depends on many factors: from several kilometers to hundreds. Coordination of cable laying is required, qualified personnel for construction and maintenance. For small companies, it makes sense only to connect the building not very far from the central hub. In general, of course, each case is individual and requires calculation.

In this case, everything is transparent for you - you use your own physical line, so you can pass anything through it without any restrictions.

B) The second option is to rent a channel from the provider. If you need a stable channel to another city, this is the most common and reliable option. The provider can provide you with the following services:

1. A real straight cable. For example, he can lend you one or two dark fibers from his optical beam. You are free to send everything that your soul wants into it. On the part of the provider this is not controlled in any way, it is not limited, it provides only support. For example, in the event of an accident, you do not have to look for a contractor and a welding machine, but a provider. And for the simple, he is responsible. If you do not agree on this by mutual agreement (read, offset), then perhaps the most expensive way.
2. L2VPN. You can also let anything into the channel, but in this case, your traffic will go through the active equipment of the provider, so it can be limited, for example, by speed.
   This term refers to several services of the second level at once:
   VLAN - in one form or another between the branches you are provided with VLAN.
   Pseudo cable ( PWE3 ) is a Point-to-Point service when you have a cable between two nodes. All frames transmitted by you are delivered to the remote point without changes. Similarly the opposite. This is possible because your frame arriving at the provider's router is encapsulated in a higher-level PDU , usually an MPLS packet.
   VPLS ( Virtual Private Network)) Is a simulation of a local network. In this case, the entire network of the provider will be like an abstract giant switchboard for you. Like the real one, it will store a table of MAC addresses and decide on where to send the received frame. This is also implemented by encapsulating the frame in the MPLS packet.
3. L3VPN. In this case, the provider's network is like a large router with several interfaces. That is, the joint will occur at the network level. You configure IP addresses on your routers on both sides, but routing in the provider's network is already a provider’s headache. You can either determine the IP addresses for the junction points or issue the provider - it depends on the implementation and on your agreement. It can function on the basis of GRE, IPSec or the same MPLS.

This service looks very simple from the point of view of the client - both in terms of configuration, and in terms of implementation - but complex - from the point of view of the operator.
We will deal with the implementation of L2 / L3 VPN based on MPLS, but much later.

B) Well, the last option: a tunnel through a public network. Suppose you have Internet access at both of your points. Often the cheapest way is to build a tunnel between these two points. To do this, you just need to have white (public) static addresses at all points (and sometimes enough on one) and the equipment on which to implement it. This solution has a number of shortcomings, which we will consider below, but nevertheless it is on it that we will stop today.

So, your will to choose which option to use based on your budget, appropriateness and your ability to convince management.
As part of this release, we need to connect 3 offices: in Novosibirsk, Tomsk and Brno. We agree that everywhere we will only use the Internet connection.

The hub and spoke node wiring diagram - in Russian speaking, the star: I



remind you that the general scheme of the LinkMiAp network now looks like this:



But we abstract from it, pushing only for essential things.

Since we undertook to implement option B, we will have to understand in detail the options.
Today, there are innumerable applications and protocols for organizing a VPN, but most of them are ways to connect hosts, not networks. We mean remote work. For example, this:



That is, this is a work scheme when one employee connects to a corporate network remotely (teleworker in Cisco terminology).

Frankly, this is of little interest to us, the question is more interesting how to connect entire networks.



Today we will consider the most common options:

• GRE
• IPSec (tunnel and transport modes)
• GRE over IPSec
• Vti
• DMVN

GRE

Generic Routing Encapsulation is a very simple tunneling protocol.
Dachshunds, tunneling . What kind of beast is this? Roughly speaking, this means that your initial data is taken along with service headers (usually IP, but it can also be Ethernet and ATM), packaged in a packet and transmitted over a public network, as if the car was traveling through a mountain through a tunnel. On the final node, the headers of the new package are removed, and your data in its original form continues its journey.
Not very clear, right? Let's look at an example with GRE.

For now, let's take an abstract topology:



Two routers are connected to the Internet through static white addresses. Each of them has private networks from the range 10.0.0.0/8.
Of course, these networks are not routed on the Internet. (The computer and laptop are drawn in the picture, but in practice we will configure the virtual interface Loopback0)
Our task is to clear the tunnel:



Thus, there is no Internet for PC1 when communicating with PC2 - they will both think that they are on the same local network.

The GRE tunnel is configured as follows:

interface Tunnel0
ip address 10.2.2.1 255.255.255.252

Since the tunnel is a virtual L3 interface through which we will have routing, it should be assigned an IP address that is selected according to your IP plan, probably from a private network.

As the source address, you can select both the IP address of the output interface
(white address provided by the provider) and its name (FE0 / 0 in our case):

tunnel source 100.0.0.1

Destination address - public address of the remote party:

tunnel destination 200.0.0.1

Finished view:

interface Tunnel0
ip address 10.2.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1

Immediately after this, the tunnel should rise:

R1 # sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes , BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1 / 255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
Tunnel protocol / transport GRE / IP

All basic information is reflected here. Pay attention to the size of the MTU - it is not 1500, as set for conventional physical interfaces. We will talk about the MTU parameter at the end of the article.

By default, GRE does not check the availability of the destination address and immediately sends the tunnel to Up. But you just need to add the keepalive X command to the tunnel interface , as the router starts sending kipalives and does not rise until there is an answer.

In our test circuit, as a local network, we simply configured Loopback interfaces - they are always in Up. They were given addresses with a mask / 32. In fact, they mean real subnets of your enterprise (well, as in the picture).

interface Loopback0
ip address 10.0.0.0 255.255.255.255

You should have two static routes on the router:

ip route 0.0.0.0 0.0.0.0 100.0.0.2
ip route 10.1.1.0 255.255.255.255 10.2.2.2

The first one says that the default gateway is the provider address 100.0.0.2:

R1 # traceroute 200.0.0.1
Type escape sequence to abort.
Tracing the route to 200.0.0.1
1 100.0.0.2 56 msec 48 msec 36 msec
2 200.0.0.1 64 msec * 60 msec

The second redirects packets addressed to the host with the address 10.1.1.0, to next-hop 10.2.2.2 - this is the tunnel address on the reverse side.

GRE tunnels are unidirectional, and a reverse tunnel is usually implied on the other side, although generally speaking this is not necessary. But in our case, when the Internet is in the middle, and the task is to organize a private network, there should be a symmetric setting on the reverse side:

nsk-obsea-gw1:

interface Tunnel0
ip address 10.2.2.2 255.255.255.252
tunnel source 200.0.0.1
tunnel destination 100.0.0.1

ip route 0.0.0.0 0.0.0.0 200.0.0.2
ip route 10.0.0.0 255.255.255.255 10.2.2.1

Try to run ping:

R1 # ping 10.1.1.0 source 10.0.0.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min / avg / max = 44/71/136 ms

R1 # tracer 10.1.1.0
Type escape sequence to abort.
Tracing the route to 10.1.1.0
1 10.2.2.2 68 msec * 80 msec

Sumptuously! But what happens behind the scenes?
And there, guys, amazing things:

When you start ping 10.1.1.0, what does the router do?
1) Generates an IP packet ::



2) Looks at the routing table

R1 # sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via “static”, distance 1, metric 0
Routing Descriptor Blocks:
* 10.2.2.2
Route metric is 0, traffic share count is 1

Next it looks recursively where the address is 10.2.2.2:

R1 # sh ip rou 10.2.2.2
Routing entry for 10.2.2.0/30
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

Taxss, Tunnel 0:

R1 # sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1 / 255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1

3) Understanding that this is a GRE tunnel, he adds the GRE



header to the packet: And on top is a new IP header. The source address will be the tunnel source address, and the destination address will be the tunnel destination.



4) The newly made package is sent to the wonderful world by default route:

R1 # sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0

5) Do not forget about the Ethernet header; when sending to the provider, it must also be formed.

Since the GRE tunnel is a level 3 virtual interface, it does not have its own MAC address (like Loopback, for example). Ultimately, the frame will leave the physical interface FastEthernet0 / 0:

R1 # sh ip route 100.0.0.2
Routing entry for 100.0.0.0/30
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0 / 0
Route metric is 0, traffic share count is 1

Accordingly, he will indicate his address as Source MAC

R1 # sh int
FastEthernet0 / 0 is up, line protocol is up
Hardware is Gt96k FE, address is c000.25a0.0000 (bia c000.25a0.0000)
Internet address is 100.0.0.1/30

Destination is traditionally taken from the ARP cache or obtained using the ARP request from the address 100.0.0.2:

R1 # show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 100.0.0.1 - c000.25a0.0000 ARPA FastEthernet0 / 0
Internet 100.0.0.2 71 c001.25a0.0000 ARPA FastEthernet0 / 0

6) And in this form, the new IP packet is transmitted to the Internet. And since each router does not split the packet, but makes a decision based on the first IP header, no one on the Internet will know that somewhere inside your private addresses 10.1.1.0 and 10.0.0.0 are hidden.



7) And finally abides to the destination.
Does R3 detect that the destination address belongs to itself, removes the IP header, and what does it find under it? GRE header.

He checks that he really has such a GRE tunnel, removes the GRE header, and then this is the most common IP packet that must be disposed of according to the entries in the routing table.

In this case, pass 0 to the Loopback interface for processing

R3 # sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1

These are such simple manipulations.
While the packet on the local network, it looks like this:

it is processed based on private addresses.
As soon as it enters the public network, GRE hangs an additional IP header on it:

and the packet is processed based on public addresses.

Here's what the packet looks like on the Internet:

1 - initial data
2 - first IP header (internal)
3 - GRE header (indicating that IP data is inside)
4 - new IP header (external, with tunnel addresses)

ICMP -messages may look like that upon a detailed examination .

Complete router configuration for GRE .

If you try to draw an analogy with the tangible world, then imagine a situation when you are driving from a village encapsulated in a car. You reach the river, and you need to cross to the other side and continue your journey to the city there.
At the river port, your car is encapsulated in a ferry and transported through surging waves to the other side, where your car is removed, and you continue to move. So this ferry was a GRE ferry.

Сделаем три ремарки:
Во-первых, интерфейсы Loopback и адреса с маской /32 мы выбрали просто для теста, фактически это вполне бы могли быть интерфейсы fa1/0.15 и fa0/1.16 с подсетями 172.16.15.0/24 и 172.16.16.0/24, например, или любые другие.
Во-вторых, мы тут всё ведём речи о публичных сетях и адресах, но на самом деле, конечно, это не имеет значения и туннели вполне можно поднимать даже внутри своей корпоративной сети, когда конечные сети и так имеют IP-связность без туннеля.
В-третьих, несмотря на то, что теоретически обратно трафик может возвращаться и не по туннелю, создать его необходимо, чтобы конечный узел могу успешно декапсулировать GRE-пакеты

Regular GRE is a vivid example of tunneling that is very easy to configure and relatively easy to juggle.
Obviously, you already guess what three big problems await us in this field?

• Security. Data encapsulated in GRE is nonetheless transmitted in clear text.
• The complexity of scaling. If you have 5-7 branches, it still seems possible to maintain such a number of tunnels, and if there are 50 of them? Moreover, traffic tunneling is often performed on the CPU, especially on the lower and middle ranges, so this is an extra load on the processor.
• All branches will interact with each other through the central node, although they could directly.

IPsec

The first problem voiced above is designed to solve encryption.

Currently, the following technologies are mainly used to organize an encrypted VPN channel: IPSec (IP Security), OpenVPN and PPTP (Point-to-Point Tunneling Protocol).

The undisputed leader, of course, is IPSec, and we'll talk about him.

First you need to understand that IPSec is not a protocol, it is a standard that includes as many as three protocols, each with its own functions:

1. ESP (Encapsulating Security Payload) directly encrypts data, and can also provide source authentication and data integrity verification
2. AH (Authentication Header) is responsible for authenticating the source and checking data integrity
3. IKE (Internet Key Exchange protocol – протокол обмена ключами) используется для формирования IPSec SA (Security Association, об этом чуть ниже), проще говоря, согласования работы участников защищенного соединения. Используя этот протокол, участники договариваются, какой алгоритм шифрования будет использоваться, по какому алгоритму будет производиться (и будет ли вообще) проверка целостности, как аутентифицировать друг друга

Before moving on, let's deal with the term SA - Security Association. An SA is generally a set of secure connection parameters (for example, an encryption algorithm, an encryption key) that can be used by both sides of the connection. Each connection has an associated SA.
Now, in order, how to create a secure connection in IPSec:

• To begin with, participants need to agree on which algorithms / protection mechanisms they will use for their secure connection, so IKE comes in. The process consists of two phases:
  
  • Фаза первая: участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения (тоже защищенного), предназначенного только для обмена информацией о желаемых/поддерживаемых алгоритмах шифрования и прочих деталях будущего IPSec-туннеля. Параметры этого мини-туннеля (правильно он называется ISAKMP Tunnel) определяются политикой ISAKMP, в режим редактирования которой мы можем попасть из конфигурационного режима командой crypto isakmp policy номер_политики. Если стороны пришли к соглашению, устанавливается ISAKMP туннель (его наличие можно посмотреть командой show crypto isakmp sa), по которому уже проходит вторая фаза IKE.
  • Фаза вторая: уже доверяющие друг другу участники договариваются о том, как строить основной туннель для данных. Они по очереди предлагают друг другу варианты, указанные в команде crypto ipsec transform-set, и, если приходят к согласию, поднимают основной туннель. Нужно сказать, что, после его установления, вспомогательный ISAKMP туннель никуда не пропадает – он используется для обновления SA основного. Дело в том, что ключи, выбираемые для шифрования информации в IPSec-туннеле, имеют некоторое “время жизни” (может выражаться как в количестве байт, так и в секундах – что первое достигнет порогового значения), по истечение которого должны быть заменены. Это как пароль, который вы меняете раз в час (по умолчанию lifetime IPSec SA составляет 4608000 килобайт/3600 секунд).
  
  
• Участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию, т.е., подпадающие под указанный в crypto map аксесс-лист.
• Периодически, в соответствии с настроенным lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и устанавливают новые SA.

Строго говоря, в этом процессе есть нулевой шаг: некий трафик должен попасть в соответствие аксесс-листу в крипто мапе. Только после этого будет происходить все остальное.

Now a little about the transform set and how ESP differs from AH. How our data going through the tunnel will be encrypted is determined by the crypto ipsec transform-set command network_name , followed by the name of the protocol that will be used (ESP or AH) + the algorithm by which the protocol will work. For example, the crypto ipsec transform-set SET1 esp-aes command will let the router know that the transform set with the name “SET1”, if applied, will only work on the ESP protocol with AES encryption. Well, if everything is more or less clear with ESP, it's up to him to encrypt (ensure confidentiality ), then what is AH and why is it needed at all? AH provides authenticationdata, that is, it gives confidence that this data came precisely from the one with whom we established communication, and were not changed along the way. If you do not go into details, it works like this: in each packet between the IP header and the transport layer header, an AH header is inserted, in which there is:

• information according to which the recipient can understand which SA the packet belongs to (i.e., including, according to which algorithm he should consider the hash for comparison - MD5 or SHA)
• the so-called ICV (Integrity Check Value), which is a hash from a packet (in fact, not the whole packet, but fields that are unchanged during the travel), which allows the recipient to make sure that this packet did not change along the way by calculating the hash from that same information and comparing the result with the value of this field.

IPSec can operate in two modes: tunnel and transport.

IPsec Tunnel Mode

In this mode, your original IP packet is taken, fully encrypted, along with the IP header, IPSec overhead information and a new IP header are added:

* the picture is not accurate and shows only the essence, in fact there are more headers, as well as trailers at the end .

This is the default mode.

Let's figure it out again during the setup.

On the local side:

First, the general policy for phase 1 is to establish the first, auxiliary tunnel: the type of encryption (default DES) and authentication. Authentication can be done on the basis of certificates, but we will consider a simple example with a preliminary key:

crypto isakmp policy 1
encr aes
authentication pre-share

Often several such policies are set up with various combinations of encryption, hash and DH group.
When creating isakmp sa, the party that initiates the connection sends all locally configured isakmp policies.
The receiving party scans in turn, in order of priority, their locally configured policies. The first policy for which a match is found will be used.

Specify a pre-shared key for neighbor authentication 200.0.0.1

crypto isakmp key CISCO address 200.0.0.1

Next, we specify the parameters for processing traffic. AES encryption algorithm using ESP header and authentication algorithm.

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac

In fact, we specify a set of protocols at once, as you see, it is called transform-set. When an IPSec session is established, routers exchange these sets. They must match.

To simplify the troubleshoot, the names for the transform-set are usually given according to the protocols used.

Now create an encryption card:

crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 101

This is where the IPSec neighbor address is determined, with which the tunnel will then be installed - 200.0.0.1. A set of protocols and ACLs are immediately attached, which determines which traffic will be encrypted and transmitted through the tunnel.

In our case, it looks like this:

access-list 101 permit ip host 10.0.0.0 host 10.1.1.0

Be careful when setting the ACL. It determines the parameters of not only outgoing traffic, but also incoming traffic (in contrast to ACLs for NAT, for example).
That is, if packets come not from 10.1.1.0, but from 10.2.2.2, it will not be processed and decrypted.

That is, if we generate traffic from the host with the address 10.0.0.0 to 10.1.1.0, then it and only it will be encrypted and sent to the IPSec tunnel. Any other will go the easy way.

Note that encryption occurs almost in the last turn, after routing.
And this, by the way, is a very important point. The route to the public address of the banquet (200.0.0.1) is not enough for you. We need a route to 10.1.1.0 even if it is defaulted. Otherwise, the packet will be discarded in accordance with normal routing rules.
No matter how strange it may seem, the traffic to your local network should be “turned off”, for example, to the Internet. At the same time, private packets that are about to be sent to the provider and discarded there are encrypted at the last moment, receiving public addresses.
By the way, there is a table with the order of operations performed on traffic.

The last step is to attach the encryption card to the interface. Until you do this, the mechanism will not work.

interface FastEthernet0 / 0
crypto map MAP1

On the reverse side you need to make a symmetric setting.
So just apply the following configuration on R3:

crypto isakmp policy 1
encr aes
authentication pre-share
crypto isakmp key CISCO address 100.0.0.1
!
!
crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
!
crypto map MAP1 10 ipsec-isakmp
set peer 100.0.0.1
set transform-set AES128-SHA
match address 101

interface FastEthernet0 / 1
crypto map MAP1

access-list 101 permit ip host 10.1.1.0 host 10.0.0.0

That's all.

But no matter how much you watch after show crypto session or show crypto isakmp sa , you will see only Down . The tunnel does not rise in any way.
Counters show crypto ipsec sa . Also zeros.

R1 # sh crypto session
Crypto session current status

Interface: FastEthernet0 / 0
Session status: DOWN
Peer: 200.0.0.1 port 500
IPSEC FLOW: permit ip host 10.0.0.0 host 10.1.1.0
Active SAs: 0, origin: crypto map

R1 # sh crypto isakmp sa
dst src state conn-id slot status

The fact is that you need to put traffic into it. In the literal sense, for example like this:

R1 # ping 10.1.1.0 source 10.0.0.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.0
. !!!
Success rate is 80 percent (4/5), round-trip min / avg / max = 60/94/160 ms

And once you have done this, you will succeed:

R1 # sh crypto session
Crypto session current status

Interface: FastEthernet0 / 0
Session status: UP-ACTIVE
Peer: 200.0.0.1 port 500
IKE SA: local 100.0.0.1/500 remote 200.0.0.1/500 Active
IPSEC FLOW: permit ip host 10.0 .0.0 host 10.1.1.0
Active SAs: 2, origin: crypto map

R1 # sh crypto isakmp sa
dst src state conn-id slot status
200.0.0.1 100.0.0.1 QM_IDLE 1 0 ACTIVE

Complete router configuration .

======================
Task number 1

Initial configuration: "IPsec"
R1 router is in the central office.
The R3 router is a router in one of the branches.
R4 is added to the circuit - the second branch.

Task:
1. Configure an IPsec tunnel using crypto-map between R4 and R1:
- Data protection policies are the same as for the tunnel between R3 and R1.
2. Add the appropriate settings so that R3 and R4 can also exchange data:
- Data between branches for R3 and R4 should be transmitted through the central router R1.

Details of the task on the site
================ =====

What happened

1) We started ping to the address 10.1.1.0 from the address 10.0.0.0.

2) According to the routing table, the packet must be transmitted to the public network in the form in which it is.

3) But the router sees that it falls on its ACL 101 and sends the packet to IPSec.

4) IPSec, working in tunnel mode (the default mode), first packs the source packet into the IPSec PDU, encrypting everything and everything along the way, and then equips it with a new IP header. As a destination address, the router prescribes the address of its IPSec neighbor - 200.0.0.1.

In the screenshot below you can see the encapsulation:



It was an exchange of ICMP messages. All source data is encrypted, including the old IP, the new IP header is based on the IPSec configuration.

5) At the final node, the router sees that the destination address belongs to it, removes the IP header and sees the IPSec header, it sends this protocol to the protocol for processing. The latter is decrypted, all service information is deleted, and the original packet travels further.

Why did we run such a weird Ping? In it, we indicated the sender address explicitly.

If we try to start Ping 10.1.1.0, it won’t fail, because the router automatically substitutes the address of the physical interface as the sender: 100.0.0.1, which does not fall into our ACL, and therefore the packet tries to go to the gateway of last resort.

What is the biggest problem we have here? Bingo! Dynamic routing It is impossible to implement it in such conditions - all IGPs require a direct L2 link between neighbors, which IPSec does not provide. Therefore, in this implementation, traffic is sent to the tunnel based on the ACL and the encryption card, not the routing table.
Plus, we have a problem with multicast, because we set specific subnets in the ACL.

Complete router configuration .

======================
Problem number 2

Configuration: "IPsec"

Note:
The problem can be solved, both theoretically and practically.
If you try the task in practice, carefully observe the conditions of the task.

Conditions of the problem:
Router R1 is located in the central office and 3 branches will be connected to it (routers R1, R2, R3 are sufficient for this task. R3 - as one of the branches). Branch offices use routers with different capabilities, and you must use different IPsec policies. There are 3 different policies in total.
On the R3 router, in addition to the tunnel to the central office, there are also several tunnels with partners. Therefore, various policies have also been created here.
Traffic is transmitted only from branches to the central office, there are no communications between branches.

From the R3 branch, R1 central office generates data that initiates the VPN tunnel.
Question: What data protection policy will routers use to build a tunnel between themselves?

Task details onsite
======================

It was a tunnel mode, colleagues. We move on to the next exhibit.

IPSec Transport Mode

It is much different from the tunnel, but the most important is the encapsulation method.

Here is the IPSec packet in tunnel mode.


And this is the IPSec packet in transport mode:



That is, tunnel encrypts the original packet completely and adds a new IP header. Transport encrypts everything above the IP level, and the IP header leaves it unchanged.

Roughly speaking, you use the tunnel mode in order to connect two private networks through a public one, while ensuring encryption (Something like a secure GRE). Transport is relevant when IP connectivity is already achieved, but traffic between nodes must be encrypted.
A good example of the use of transport mode can be a server-client scheme. For example, the work of a client bank. The server is already available, but traffic must be encrypted.

But we are not about that. We still need to connect networks.

======================
Task No. 3

Scheme: “the final scheme of the task 7.1”
Device configurations: on the project website

Description of the problem:
Data between R1 and R4 is not transmitted.

Task:
Find the error and fix the configuration so that the tunnel between R1 and R4 is established and traffic is transmitted between R1 and R4.

Details of the task on the site
======================

GRE over IPSec

Beginners often get confused here ( it happened to the author ): GRE over IPSec or IPSec over GRE. What is the difference where applied. You can’t stop there.
The usual mode that we consider here and which is used in the vast majority of cases is GRE over IPSec, that is, GRE data is encapsulated by ESP or AH headers



. IPSec over GRE means, on the contrary, IPSec data will be encrypted inside, and GRE / IP They will not be encrypted:



This option is possible, for example, if you are encrypting on a separate device before tunneling.



Why such plowing is needed is not very clear, therefore GRE over IPSec is usually used.

Let us return to our old scheme and implement exactly this option on it.



Of course, at the same time, we again have the tunnel interface (configured as usual GRE):

interface Tunnel0
ip address 10.2.2.1 255.255.255.252
tunnel source 100.0.0.1
tunnel destination 200.0.0.1

And then you direct the necessary traffic to it with a static route.

ip route 10.1.1.0 255.255.255.255 10.2.2.2

What does this change in the IPSec configuration?
In principle, even if you do not change anything, everything will already work, but this is not our way.
Firstly, since the tunnel already exists (GRE), there is no need to make it also using IPSec - you can put it in transport mode, thereby saving 20 bytes on the extra IP header:

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport

* Note, change, this is necessary on both sides, otherwise the IPSec neighborhood will not be established.

Secondly, all traffic between the branches should be encrypted, that is, the one that goes through the tunnel, accordingly, there is no need to register all networks in the ACL, we’ll be trickier:

access-list 101 permit gre host 100.0.0.1 host 200.0.0.1

The condition is met if traffic with a GRE header and corresponding addresses has arrived on the port.

What will happen in this situation?
1) A packet with a destination address of 10.1.1.0 arrives at the router, which determines from its table that the packet must be transmitted to next-hop 10.2.2.2

R1 # sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via “static”, distance 1, metric 0
Routing Descriptor Blocks:
* 10.2.2.2
Route metric is 0, traffic share count is 1

2) This is a tunnel interface with a destination address of 200.0.0.1. The packet is packaged with a GRE header and a new IP header.

R1 # sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1 / 255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
Tunnel protocol / transport GRE / IP

3) The network 200.0.0.1 is known through the address 100.0.0.2

R1 # sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0

And the subnet 100.0.0.0/30 is connected to the FE0 / 0 interface

R1 # sh ip route 100.0.0.0
Routing entry for 100.0.0.0/30, 1 known subnets
Attached (1 connections)

C 100.0.0.0 is directly connected, FastEthernet0 / 0

And it uses an encryption card with an ACL.
Traffic, of course, falls under it (it has a GRE header and the necessary IP addresses), so everything that is inside the external IP header will be encrypted.

Such a scheme of work allows you to properly implement dynamic routing protocols, as well as transmit multicast traffic, leaving the possibility of encryption. Bullies will no longer be able to steal secret recipes for making elevators.

======================
Task No. 5

Scheme: "GRE_over_IPSec"

Configuration: on the project website

Description of the problem:
After setting GRE over IPSec between R1 and R3, everything works fine , traffic between R1 and R3 (from 10.0.0.0 to 10.1.1.0) is transmitted.
However, after a few days, when the administrator wanted to see the status of the VPN, it turned out that there were no SAs installed on the routers at all.
Accordingly, traffic between R1 and R3 is not encrypted.

Task:
It is necessary to check the settings, correct the configuration and make the traffic encrypted (traffic between the loopback interfaces 10.0.0.0 and 10.1.1.0).

Details of the task on the site
======================

Complete configuration of routers for IPSec .

You can make another addition here: technically, you can exclude the four-byte GRE header from the packet, indicating on both sides that the IPIP tunnel operating mode:

interface Tunnel0
tunnel mode ipip

We must really remember that in this case only IP data can be encapsulated, not any, as in the case of GRE.

======================
Task No. 4

Scheme: "GRE_over_IPSec"

Configuration: "GRE_over_IPSec"

Task:
Change the initial GRE over IPSec configuration and configure GRE over IPsec without using crypto -map.

Details of the task on the site
======================

IPSec VTI

The last example of Site-to-Site VPN using IPSec, which, in fact, is recommended by tsiska - VTI (Virtual Tunnel Interface)

IPSec configuration differs in that we no longer need to manually create a crypto-map (and, accordingly, an ACL), instead we create an IPSec profile

crypto isakmp policy 1
authentication pre-share

crypto isakmp key DMVPNpass address 0.0.0.0 0.0.0.0

crypto ipsec transform-setVTI-TS esp-aes
mode transport

crypto ipsec profile VTI-P
set transform-set VTI-TS

And it, in turn, must be bound to the tunnel interface.

interface Tunnel0
tunnel protection ipsec profile DMVPN-P

The difference from the previously used Crypto map is that now there is no need to create an ACL - all traffic that enters the tunnel is encrypted (encryption cards are nevertheless still created, but already automatically).

This turned out to be the usual Tunnel Protection without VTI. Also widely used.
The tunnel mode ipsec ipv4 command indicates the use of VTI.
The difference from regular GRE in encapsulation methods is that 4 bytes are saved in VTI by excluding the GRE header.

Short Description
Complete Router Configuration for IPSec VTI .

DMVPN

The apotheosis of today's release is DMVPN (Dymamic Multipoint VPN). Until now, we have been talking about universal vendor-independent things. Unfortunately, DMVPN is a purely tsiskovy thing and has no adequate analogs yet (correct if I am mistaken).

In the previous parts we solved the problem with the security of the transmitted data - now we encrypt it - and with IGP - using GRE over IPSec we use dynamic routing protocols.
The last problem that remains is scalability.
It’s good when you have such a grid:



Two tunnels on each node and that’s it.
Add one more node:



And one more:



Already much more tunnels are needed to get a fully connected topology. Typical m * (m-1) / 2 complexity problem.
If you do not use Full-Mesh, but turn to the Hub-and-Spoke topology with one central point, another problem arises - traffic between any branches will pass through the central node.

DMVPN solves both problems.
The essence is this: the central point of the Hub (or several) is selected. It will be the server to which clients (Spoke) will connect and receive all the necessary information. In this case:

1) The data will be encrypted by IPSec
2) Clients can transfer traffic directly to each other bypassing the central node
3) Only at the central node a static public IP address is required. Remote nodes can have a dynamic address and even be behind NAT using addresses from private ranges ( NAT Traversal Technology) But at the same time, limitations arise regarding dynamic tunnels.

This is all the focus of the power of GRE and IPSec, flavored with NHRP and IGP.

Theory and Practice of DMVPN

Abstracting from our old network, we will only consider Moscow, the Internet, which will be emulated by the Balagan-Telecom router, and the actual branches in Novosibirsk, Tomsk and Brno:



New IP-plan:
Subnets dedicated to connecting to the Internet of the branches:



LAN:



For for tunnel interfaces, take the internal network:



And we will also assign Loopback addresses for them:



The idea is that there will be one single dynamic tunnel on the central node, which we will configure at the very beginning, but when adding new remote points, we don’t need it here s changes - neither add new tunnel interfaces nor reconfigure an existing one.
In fact, when adding new nodes, you only need to configure them.
Protocol Launches EverywhereNHRP - NBMA Next Hop resolution Protocol.
It allows you to dynamically learn the addresses of remote points that you want to connect to the main one.
It is based on the ability to implement multipoint VPN. The hub (central node) here acts as a server (NHS - Next-Hop Server), and all the remote nodes will be clients (NHC - Next-Hop Client).
That sounds complicated. It’s also impossible to explain on fingers. You only need to configure once and see how the packets run.

Hub configuration:

interface Tunnel0
ip address 172.16.254.1 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source FastEthernet0 / 1.6
tunnel mode gre multipoint

In order:
ip address 172.16.254.1 255.255.255.0 - IP address from the desired range.
ip nhrp map multicast dynamic - Dynamically examine NHRP data from clients. Since we have many clients and they can be with dynamic addresses, it is impossible to set the explicit correspondence of internal and external addresses on the hub.
ip nhrp network-id 1 - Define Network ID - just an identifier that does not have to be the same on all DMVPN nodes (similar to OSPF Router-ID).
tunnel source FastEthernet0 / 1.6 - legacy GRE - binding to the physical interface.
tunnel mode gre multipoint- The tunnel at the central node will terminate all the tunnels from the remote points. That is, it will be a point-to-MultiPoint.

Branch Configuration:

interface Tunnel0
ip address 172.16.254.2 255.255.255.0
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip nhrp registration no-unique
tunnel source FastEthernet0 / 0
tunnel mode gre multipoint

In order:
ip address 172.16.254.2 255.255.255.0 - IP address from the desired range.
ip nhrp map 172.16.254.1 198.51.100.2 - The static ratio of the internal and external addresses of the hub.
ip nhrp map multicast 198.51.100.2 multicast traffic should receive the hub.

Без этой команды у вас будут довольно интересные симптомы проблемы.
Вот вы запустили OSPF, пиринг поднимается, хаб и филиалы переходят в состояние Full, обменялись маршрутами, и вы уже радуетесь, что всё отлично, и тут бац – пинг пропадает, пиринг падает, но только с одной стороны, мол истёк dead-timer.

*Mar 1 01:51:20.331: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired
msk-arbat-gw1#
*Mar 1 01:51:25.435: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from LOADING to FULL, Loading Done

Что за фигня?
Смотрим дебаг, смотрим дампы

*Mar 1 01:53:44.915: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:44.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:44.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:53:54.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:53:54.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:53:54.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:53:54.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:53:54.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1
msk-arbat-gw1#
*Mar 1 01:54:04.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1
*Mar 1 01:54:04.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33
*Mar 1 01:54:04.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17
*Mar 1 01:54:04.935: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129
*Mar 1 01:54:04.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1


На 5 OSPF Hello от хаба только один Hello от филиала.
Как вы уже поняли, маршрутизатор просто не может сообразить куда посылать мультикастовые сообщения на адрес 224.0.0.5, хаб их не получает и дёргает OSPF-сессию.

ip nhrp network-id 1 - Network ID. It does not have to match the same on the hub.
ip nhrp nhs 172.16.254.1 - Statically configured NHRP server address - the hub. That is why in the center we need a static public address. Clients send a registration request to the hub 172.16.254.1. This request contains the configured local address of the tunnel interface, as well as its public address (the case when the client is behind NAT is not yet considered).
The hub enters the received information into its NHRP address mapping table. It distributes the same table upon request to any Spoke router.

ip nhrp registration no-unique - if the address in the branches is issued dynamically, this command is required.
tunnel source FastEthernet0 / 0- binding to the physical interface.
tunnel mode gre multipoint - we indicate that the type of tunnel is mGRE - this will allow you to create dynamically tunnels not only to the hub, but also to other branches.

Our situation is simple - without NAT - and we can now check the status of the tunnels.

msk-arbat-gw1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.254.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 198.51.100.2 (FastEthernet0/1.6), destination UNKNOWN
Tunnel protocol/transport multi-GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled

msk-arbat-gw1#ping 172.16.254.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.254.2, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/213/284 ms

msk-arbat-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
msk-arbat-gw1#sh ip nhrp
172.16.254.2/32 via 172.16.254.2, Tunnel0 created 00:09:48, expire 01:50:11
Type: dynamic, Flags: authoritative unique registered
NBMA address: 198.51.101.2

nsk-obsea-gw1#sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

OSPF

That is, connectivity is already provided, but the branches cannot work yet - routing is not configured.

Here, for each protocol, subtleties pop up.
Let's look at the OSPF configuration process, for example.

Since we have a broadcast L2 network on tunnel interfaces, we explicitly indicate the type of Broadcast network on tunnel interfaces on all nodes:

ip ospf network broadcast

In addition, DR should be selected in such a network. It is logical that they become a hub. We prohibit all Spoke routers from participating in DR elections:

ip ospf priority 0

Well and, of course, we define the announced networks.

router ospf 1
network 172.16.0.0 0.0.255.255 area 0

Networks announced:

msk-arbat-gw1 # sh ip route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks
C 172.16.2.128/30 is directly connected, FastEthernet0 / 1.8
C 172.16.255.1/32 is directly connected, Loopback0
C 172.16.254.0/24 is directly connected, Tunnel0
C 172.16.2.32/30 is directly connected, FastEthernet0 / 1.7
C 172.16.2.16/30 is directly connected, FastEthernet0 / 1.5
C 172.16. 2.0 / 30 is directly connected, FastEthernet0 / 1.4
O 172.16.255.128/32 [110/11112] via 172.16.254.2, 00:05:14, Tunnel0
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected , FastEthernet0 / 1.6
S * 0.0.0.0/0 [1/0] via 198.51.100.1

Ping passes

msk-arbat-gw1 # ping 172.16.255.128

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.128, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min / avg / max = 60/70/80 ms

This is what packets transmitted over the Internet look like:

* Dump from nsk-obsea-gw1 fa0 / 0

Checking how we get ping from one branch to another:

nsk-obsea-gw1#ping 172.16.255.132

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.132, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/231/492 ms

nsk-obsea-gw1#traceroute 172.16.255.132

Type escape sequence to abort.
Tracing the route to 172.16.255.132

1 172.16.254.3 240 msec * 172 msec

nsk-obsea-gw1#sh ip nhrp br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

As you can see, the packets do not go to the hub, but go directly directly to the router of another branch via the Internet. But reality is a little more complicated.

What is happening at this moment?
1) Send a ping to the address of the Loopback interface in Tomsk
2) According to the routing table, the next hop

nsk-obsea-gw1 # sh ip route 172.16.255.132
Routing entry for 172.16.255.132/32
Known via "ospf 1", distance 110, metric 11112, type intra area
Last update from 172.16.254.3 on Tunnel0, 00:18:47 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:18:47 ago, via Tunnel0
Route metric is 11112, traffic share count is 1

This is an address from a network directly connected to Tunnel 0

nsk-obsea-gw1 # sh ip route 172.16.254.3
Routing entry for 172.16.254.0/24
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

3) According to the interface settings, NHRP is used here. We look at the correspondence table received from the hub

nsk-obsea-gw1 # sh ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

As you can see, the address 172.16.254.3 nhrp is unknown .
Therefore, the ICMP packet is sent to the statically configured hub - 198.51.100.2:

msk-arbat-gw1, fa0 / 1:


And the hub immediately redirects the request to the desired address:

msk-arbat-gw1, fa0 / 1:


4) At the same time, the router a client in Novosibirsk sends an NHRP request, they say who is hiding the address 172.16.254.3:

msk-arbat-gw1, fa0 / 1:


5) The hub has this knowledge:

msk-arbat-gw1 # sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

And sends this information in the NHRP response:

msk-arbat-gw1, fa0 / 1:


The Hub does not meet two spokes in the conversation anymore.

6) An ICMP request came to Tomsk:

tmsk-lenina-gw1, fa0 / 0:


Despite the fact that the source IP address is the hub address in the external header, the initial address of the Novosibirsk router appears inside:

7) Tomsk also does not know anything about the address 172.16.254.2 that sent the ICMP request.

tmsk-lenina-gw1 (config-if) #do sh ip nh br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0

Therefore, he also sends an ICMP response to the hub:
tmsk-lenina-gw1, fa0 / 0:


8) Following him, he is interested in the public address of the sender:

tmsk-lenina-gw1, fa0 / 0:


9) Well, the hub, of course, responsible:

tmsk-lenina-gw1, fa0 / 0:


10) Now on all nodes the current NHRP information is:

msk-arbat-gw1 (config-if) #do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

nsk-obsea-gw1 (config-if) #do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

tmsk-lenina-gw1 (config-if) #do sh ip nh br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0

As you can see, the distribution does not happen automatically, but on demand, and only clients are the initiators, because in fact, they only know where to go (the hub does not know anything about the clients initially)

11) He will send the next ICMP request in a new way:

nsk-obsea-gw1 # sh ip route 172.16.255.132
Routing entry for 172.16.255.132/32
Known via "ospf 1", distance 110, metric 11112, type intra area
Last update from 172.16.254.3 on Tunnel0, 00:20:24 ago
Routing Descriptor Blocks:
* 172.16.254.3, from 172.16.255.132, 00:20:24 ago, via Tunnel0
Route metric is 11112, traffic share count is 1

Subnet 172.16.254.0 connected to Tunnel 0

nsk-obsea-gw1 # sh ip route 172.16.254.3
Routing entry for 172.16.254.0/24
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

12) We repeat a little, but ... Tunnel 0 interface is mGRE and according to the NHRP table all traffic for which the next hop is 172.16.254.3 should be encapsulated in GRE and the external IP header with the destination address 198.51.102.2 (As the source address will be physical interface address selected - 198.51.101.2):

nsk-obsea-gw1 (config-if) #do sh ip nhr br
Target Via NBMA Mode Intfc Claimed
172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0
172.16.254.3/32 172.16.254.3 198.51.102.2 dynamic Tu0

tmsk-lenina-gw1, fa0 / 0:


13) Well, then the packet with the recipient address 198.51.102.2 is sent according to the routing table:

Gateway of last resort is 198.51.101.1 to network 0.0.0.0

It is important to understand here that despite the fact that communication between branches is bypassing the central node, the hub however has a vital auxiliary function and will not work without it: it provides clients with an NHRP table and also announces all routes - branches distribute the route information is not directly to each other, but through the hub.

Current configuration of nodes:

msk-arbat-gw1
interface Tunnel0
ip address 172.16.254.1 255.255.255.0
no ip redirects
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip ospf network broadcast
ip ospf priority 10
tunnel source FastEthernet0/1.6
tunnel mode gre multipoint

nsk-obsea-gw1
interface Tunnel0
ip address 172.16.254.2 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint

tmsk-leneina-gw1
interface Tunnel0
ip address 172.16.254.3 255.255.255.0
no ip redirects
ip nhrp map 172.16.254.1 198.51.100.2
ip nhrp map multicast 198.51.100.2
ip nhrp network-id 1
ip nhrp nhs 172.16.254.1
ip ospf network broadcast
ip ospf priority 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end

At the moment, the following problems have been solved:
1) Connectivity. Branches are connected and available.
2) Routing. Through mGRE tunnels IGP started successfully.
3) Scalability. When adding a new spoke-router, only he is configured and there is no need to go into the configuration of existing nodes.
4) Unloaded the hub - only official traffic is transmitted through it.

It remains to resolve the security issue.

IPsec

This is solved as before - encryption.
If for Site-to-Site VPN we could still use a pre-shared key, because we rigidly set the IPSec peer address, then in the case of DMVPN we need flexibility, and in advance we do not know the addresses of neighbors.
In this regard, the use of certificates is recommended. There is a good article on xgu on the certificate authority center on cisco.

But for simplicity, we will still take the pre-shared key configuration.

crypto isakmp policy 1
authentication pre-share

It will differ from the Tunnel Protection and VTI discussed above using the template address:

crypto isakmp key DMVPNpass address 0.0.0.0 0.0.0.0

The danger here is that you can set up an IPSec session with the hub, knowing the key, any device.

Here you can safely use the transport mode:

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac
mode transport

crypto ipsec profile DMVPN-P
set transform-set AES128-SHA

Next, the created profile is applied to the tunnel interface. The setting on all nodes is the same.

interface Tunnel0
tunnel protection ipsec profile DMVPN-P

Now packets transmitted over the Internet will be encrypted:
msk-arbat-gw1, fa0 / 1:


Just don’t try to put tunnel mode ipsec ipv4 :)

IPSec tunnels and encryption cards will be created dynamically for data transfer sessions between branches and will be permanent for Hub channels -Spoke.

NAT-Traversal

Here we will not go into the principles of NAT-T operation. I’ll just give you the bottom line: IPSec can build a tunnel through NAT using an additional UDP header. This allows you to build a VPN even on those sites where you do not have a public address.
There is no need to activate and configure this functionality in a special way - it works by default.
We complicate the scheme by adding another router to Brno.



Let's say this is a provider piece of iron that performs nating. That is, in fact, on the router in the branch we will have a dynamic address from the private range on the physical interface. Pure GRE cannot build a VPN under such conditions, IPSec can, but is difficult to configure. mGRE in conjunction with IPSec can be easy!

Let's see what the NHRP table looks like in this case:

msk-arbat-gw1 # show ip nhrp brief
Target Via NBMA Mode Intfc Claimed
172.16.254.4/32 172.16.254.4 10.0.0.2 dynamic Tu0

That is, he still studied the private address allocated by the provider.
It should be noted that in the routing table there should be a route to this private address issued by the provider in the branch, even if defaulted.

We have activated IPSec on the tunnel interface, therefore there must be encryption cards:

msk-arbat-gw1#show crypto map
Crypto Map «Tunnel0-head-0» 65537 ipsec-isakmp
Map is a PROFILE INSTANCE.
Peer = 198.51.103.2
Extended IP access list
access-list permit gre host 198.51.100.2 host 10.0.0.2
Current peer: 198.51.103.2
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
AES128-SHA,
}
Interfaces using crypto map Tunnel0-head-0:
Tunnel0

Thus, an encrypted tunnel is built between 198.51.100.2 and 198.51.103.2, then the data that is still encrypted due to NAT-T in the tunnel goes to 10.0.0.2. And then you already know.

Explanatory detailed article on NHRP .

======================
Task number 6

Initial configuration: "DMVPN"

Scenario:
DMVPN network was fully operational, everything worked correctly.
But after rebooting the msk-arbat-gw1 hub, a strange behavior started.

Task:
1. Check the network performance.
2. Reboot the hub
3. After the reboot, check the network again
4. Fix the problem:
4.1. (minimum) Make the network operational again
4.2. Make the network recover automatically after the hub reappears.

Details of the task on the site
======================

TShoot IPSec

In the end, I want to say a few words about how to solve problems with IPSec. The procedure is far from trivial.
Debugging plays a huge role in Troubleshoot VPNs. The method of looking closely at the config is less reliable - it is easy to miss a small error.
An extremely valuable tool in IPSec Troubleshoot is sh crypto ipsec sa . No, the matter is not even in the binary “rose - did not rise”, but in the counters, primarily encaps-decaps . You can start continuous ping and watch which of the counters grows. Most problems can be localized in this way.
Counters do not grow at all? See where the crypto map is applied and whether everything is in order with the ACL.
Growing error ? Something is wrong with coordination, see debug.
Encaps growing but no decaps ? Go ahead to explore the opposite side of the tunnel, everything is fine here.

MTU

Finally, we discuss one insidious moment - the size of the MTU. In the life of every system / network administrator, the moment comes when the symptoms of the problem are as follows: Yandex opens, ping works, but no other site is accessible and Outlook does not connect.

The devil is in the amount of MTU and the presence of additional headers.

MTU - Maximum Transmission Unit. This is the maximum data block size that can be transmitted through the interface. This concept is at the intersection of L2 and L3 and its interpretation may vary for different vendors.

For example, the typical MTU size for the physical L3 interface is 1500. That is, roughly speaking, an IP packet of 1500 bytes will be processed, and 1501 will be dropped or fragmented. Packet fragmentation is often prohibited, and therefore large packets are discarded.

If you use tunneling, the packet size increases due to additional headers (GRE, IPSec, etc.)
For example, for GRE: 24 bytes (GRE, New IP).
For GRE over IPSec: 56 and more bytes (depends on the mode of operation and type of encryption)
For PPPoE: 36 (PPP, PPPoE, Ethernet)

The tunnel interface itself has a standard MTU 1514 and passes such packets, but the provider on the physical interface has MTU = 1500, and on it the packet will be discarded:

R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

R1#sh int fa0/1
FastEthernet0/1 is administratively down, line protocol is down
Hardware is Gt96k FE, address is c000.19ac.0001 (bia c000.19ac.0001)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

That is, you must consider not only your settings, but also the settings of all intermediate nodes.
Often you do not have the ability to influence MTU along the way.
Therefore, you can reduce the MTU, on the local side, use the Path MTU Discovery mechanism, or even configure the MSS - Maximum Segment Size (applies already to TCP).
Read more about MTU problems here and here.

For all kinds of tunnels, this is a very typical problem.

Why does ping and Yandex work?
ICMP Request and Relpy packets range in size from 32 to 64 bytes, ya.ru returns very little information, which fits into the allowable size of 1500 along with all the headers.

PSUnfortunately, the following uninteresting topics remained unaffected:

Completely flown past the topic of remote access for employees.
In addition, the topic of FlexVPN is very relevant now. This is a new round of VPN technology. But it uses IKE version 2 and is currently supported, as usual only by cisco equipment.
We would really like to pay attention to these and those and here are those topics, but it is impossible to put everything in the framework of one article.

Release Materials

IP plan
Device configuration GRE , IPSec , GRE over IPSec , VTI , DMVPN )

useful links

The IPSec
www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html
www.tcpipguide.com/free/t_IPSecModesTransportandTunnel.htm

the DMVPN
www.anticisco.ru/blogs/?tag=dmvpn
xgu.ru/wiki/ % D0% 9D% D0% B0% D1% 81% D1% 82% D1% 80% D0% BE% D0% B9% D0% BA% D0% B0_DMVPN_% D0% BD% D0% B0_% D0% BC% D0 % B0% D1% 80% D1% 88% D1% 80% D1% 83% D1% 82% D0% B8% D0% B7% D0% B0% D1% 82% D0% BE% D1% 80% D0% B0 % D1% 85_Cisco

NHRP.
habrahabr.ru/post/84738
blog.ine.com/tag/nhrp
FlexVPN.
www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/15-2mt/sec-intro-ikev2-flex.html
habrahabr.ru/post/160555
alexandremspmoraes.wordpress.com/2012/ 06/28 / hello-world-simple-lan-to-lan-flex-vpn-configuration
alexandremspmoraes.wordpress.com/2012/07/02/flex-vpn-sample-lan-to-lan-configuration-with-dynamic-routing The

article was prepared for you by eucariot and thegluck

Thank you, Natasha, for the brainwork tasks .

For comments and help, thanks to JDima .

The cycle “Networks for the smallest” has its own website: linkmeup.ru , where you can find all issues neatly folded and ready for thoughtful reading.

And as a moment of self-promotion: last week there was a zero issue of the podcast for signalers.