Tunnel
{«Come on and take a low ride with me girl \\ on the tunnel of love»} Dire Straits
Virtual Private Network
The term VPN identifies a Virtual Private Network. They allow the exchange of data among company offices spread over the territory and represent a service of greater interest for Business customers. It is said that the network is private as it allows private communications among company sites, in the same way as a physical private network (eg routing and addressing schemes are maintained) It is said that the network is virtual because the connections are virtual and not physical. The physical support network is public and not private, but resource management and security techniques are such as to "virtualize" it as if it were private. As an example, a university institute can activate a VPN to allow its students to consult from home publications for which they have subscribed; as long as the user has the VPN service activated, all his requests pass through the institution's servers, as if the connection were made locally, thus obtaining access to reserved subscription services; at the same time the user is also subjected to the policies of the manager who can for example encrypt or not the server-user connection or inhibit some protocols such as P2P or access to internet sites inserted in a black list.
Virtual Private Network.
vpn
There is a necessary condition within the same VPN addressing must be unique. A VPN can be implemented at any of the ISO / OSI levels, for example:
  1. Layer 1. Physical VPN, for example with a DDC (Digital Direct Circuit), the "old" dedicated lines.
  2. Layer 2. VPN data link, for example ATM PVC or the VLANs described in the previous chapter.
  3. Layer 3. VPN network like IPsec, tunneling,.. .
  4. Layer 4. Transport-level VPN like TLS.
At present, the term VPN is generally referred to as a layer 3 network infrastructure. We can identify two modes of data transport:
  1. Overlay: the public network offered by the ISP offers only transport functions and the routing information is exchanged only among company sites.
    In this case the topology (logical and physical) is composed of point-to-point links defined by the customer (customer). If we consider these point-to-point links we can identify a "superimposed" network (lett. Overlay) to the physical network.
  2. Peer-to-peer: the public network offered by the ISP also exchanges routing information with the company sites.
    In this case the logical topology is defined by the customer, the physical topology that realizes the logical topology, is decided by the provider according to specific traffic engineering criteria in its network.
On Peer-to-Peer VPN, where routing takes place on a layer composed of both entities residing in the company and entities residing in the ISP, we will return to this later talking about MPLS (see section mpls starting from page mpls ). In this first part we will devote ourselves to the VPN overlays that are generally implemented on the public internet network. In this case the communications security must be realized ent-to-end, as one cannot trust in a secure transport network; for this reason the reference model envisages the creation of secure tunnels between the VPN end-points.
Tunnel
The term tunneling refers to a techniques set for which a protocol is encapsulated in a protocol of the same level or higher level to realize particular configurations. The security of the communication is obtained through the encryption of the data that are inserted inside the tunnel and the authentication of the end-points. The data packets are modified upon sending by adding a header that will allow you to go through the tunnel; subsequently, when they reach the destination, at the end of the tunnel, the header will be removed returning the original package. Often the terms "tunnel" and "VPN" are used interchangeably, but it is not a correct approach. Protocols defining tunnels:
Protocols defining VPN:
In this text we will address:
RouterOS provides different types of tunnels and VPNs: PPTP, L2TP, PPPoE, EoIP, SSTP, OpenVPN, etc. The types that can be used are visible in the list of virtual interfaces (see figure vpn-list ).
List of available virtual interfaces.
vpn-list
Chapter 8 of the book "Theory, laboratories and exercises for Mikrotik RouterOS" is dedicated to the main VPN protocols (see https://amzn.to/2Qm4S0L ), so the common protocols like PPTP and PPPoE will be omitted in the following sections. to investigate more complex protocols such as IPsec and MPLS. For an analysis on which VPN use in your network infrastructure it is recommended to refer to the talk of Andis Arins at the MUM Europe of Ljubljana of March 25, 2016: http://bit.ly/2Qjloi1 .
IP addresses on point-to-point networks
In general, to connect 2 devices we will use IP with a minimum of subnet /30, where there will be 2 usable hosts, for example:
Network address
Usable addresses
Broadcast address
172.16.1.0/30
172.16.1.1-172.16.1.2
172.16.1.3
In Mikrotik, these needs can be met using the IP /32 subnet or the single IP: it is an IP address addressing system for two directly connected devices. Since it uses only 2 IP addresses, there is no transmission address, but the network IP must be set manually with a remote IP address. The most obvious example is the implementation of a PPTP VPN. In the Secret tab of the PPTP server the local and remote address parameters use IP /32:
After the PPTP tunnel is created, a new IP address will be displayed on both sides of the router with subnet /32. Comparing the server side and the client side of the VPN we note the different position of the IP address:
In addition to the VPN service, point-to-point addressing can be applied manually to the installation of 2 directly connected devices. This method is widely used by ISPs with the goal of an efficient use of the public IP. For example, an ISP could assign the IP address 222.152.211.0/30 to the client. The ISP will use an IP taken from the subnet /30 interval as a gateway, so the client will have only one address that can be installed on the device. However, with the concept of point-to-point addressing, the IP 222.152.211.0/30 will be completely available to the client and this provides the client with two IP addresses. How could the ISP do not "waste" IP addresses? Here is the solution.
Point-to-point topology with /32 addressing.
Addresses to be set in the two routers in IP > Addresses :
Point-to-point addressing.
Static route to be set on R1 towards router R2. This route has the point-to-point address as gateway:
For the R2 router we use the description on page loopback about the loopback interface. In this case the IP address is installed on the fictitious bridge interface, ie the bridge was created without any bridge port assigned. At this point proceed in the configuration as usual, the only changes concern the NAT settings and the default gateway that must take into account the exit address from the router:
NAT configuration of the R2 router
NAT settings are made so that the client can access the internet. According to the above, internet access is made through the public IP, not through the point-to-point IP, so the address must be forced, ie it must be 222.152.211.1, when the client packet leaves the router:
R2 default gateway configuration
To obtain this "forcing" we use the Pref-Source property, studied on page pref-src , so that when the packet exits the router it is used as IP 222.152.211.1.
IP-in-IP
ipip The IP-in-IP tunneling implementation, also briefly referred to as IPIP, on MikroTik RouterOS complies with RFC 2003; many routers, including Cisco and Linux, support this protocol. The IPIP tunnel is a simple protocol that encapsulates IP packets in a tunnel between two routers. The IPIP tunnel interface appears as an interface below the list of interfaces but it is not possible to insert the IPIP interface as a port in a bridge. The protocol adds the following possibilities to a network infrastructure:
IP-in-IP encapsulation.
IP_in_IP_Encapsulation
To encapsulate an IP packet in another IP packet (see figure IP_in_IP_Encapsulation ), an external header is added with the SourceIP, the entry point of the tunnel and the destination, the exit point of the tunnel. While doing this, the internal packet is not modified (except the TTL field, which is decremented). The Do not Fragment and Type Of Service fields are copied to the external package. If the packet size is larger than the path MTU then the packet is fragmented during encapsulation because the external header must be included. Upon arrival at destination the package will be reassembled.
GRE vs IPIP
The encapsulation of generic routing (GRE) and IP-in-IP (IPIP) are two rather similar tunneling mechanisms that are often confused. IP-in-IP encapsulation is exactly what it seems: one IP packet encapsulated within another (see figure ipip_encapsulation ). The external header protocol field is set to 4 for IPv4 or 41 for IPv6.
IPIP encapsulation.
ipip_encapsulation
The GRE (defined in RFC 2784 and updated by RFC 2890) goes one step further than IP-in-IP, adding an additional header inside and outside the IP headers (see figure gre_encapsulation ).
GRE encapsulation.
gre_encapsulation
This addition allows the GRE protocol to:
On the other hand these features have an additional cost of overhead; in cases where GRE functionality is not required, IPIP is a good choice.
Lab
Three routers and two PCs are required for this laboratory.
IPIP tunnel
The objective of this laboratory is to realize the infrastructure of figure ipip2 starting from that of figure ipip .
IPIP tunnel.
ipip
  1. Connect the routers as shown in fig ipip .
  2. We configure the R1, R2 and R3 routers for basic connectivity:
    {R1}
    /system identity set name=R1
     /ip address
     add address=10.10.10.30/24 interface=ether1
     
    {R2}
    /system identity set name=R2
     /interface bridge add name=bridge1
     /interface bridge port add interface=ether1  bridge=bridge1
     /interface bridge port add interface=ether2  bridge=bridge1
     /ip address
     add address=10.10.10.30/24 interface=bridge1
     
    {R3}
    /system identity set name=R3
     /ip address
     add address=10.10.10.31/24 interface=ether1
     
  3. We check the connection from router R1 to R3:
    [admin@R1] > /ping 10.10.10.31
       SEQ HOST                                     SIZE TTL TIME  STATUS
         0 10.10.10.31                                56  64 18ms
         1 10.10.10.31                                56  64 2ms
         2 10.10.10.31                                56  64 2ms
         3 10.10.10.31                                56  64 6ms
         4 10.10.10.31                                56  64 2ms
         sent=5 received=5 packet-loss=0
  4. We create the tunnel by acting on the routers R1 and R3:
    {R1}
    /interface ipip add name=ipip local-address=10.10.10.30 \
        remote-address=10.10.10.31
    /ip address add address=192.168.200.1/30 interface=ipip
    {R3}
    /interface ipip add name=ipip local-address=10.10.10.31 \
        remote-address=10.10.10.30
    /ip address add address=192.168.200.2/30 interface=ipip
  5. We check the connection from router R3 to R1 but using the ip addresses of the tunnel :
    [admin@R3] > /ping 192.168.200.1
      SEQ HOST                                     SIZE TTL TIME  STATUS
        0 192.168.200.1                              56  64 9ms
        1 192.168.200.1                              56  64 3ms
        2 192.168.200.1                              56  64 4ms
        sent=3 received=3 packet-loss=0
  6. We modify the infrastructure by connecting the two PCs as in figure ipip2 .
    Tunnel IPIP con routing.
    ipip2
  7. We modify the configuration of R1 and R3 for basic connectivity:
    {R1}
    /ip address
    add address=192.168.1.1/24 interface=ether2
    /ip pool
    add name=dhcp_pool0 ranges=192.168.1.2-192.168.1.254
    /ip dhcp-server
    add address-pool=dhcp_pool0 disabled=no interface=ether2 name=dhcp1
    /ip dhcp-server network
    add address=192.168.1.0/24 gateway=192.168.1.1
    {R3}
    /ip address
    add address=192.168.2.1/24 interface=ether2
    /ip pool
    add name=dhcp_pool0 ranges=192.168.2.2-192.168.2.254
    /ip dhcp-server
    add address-pool=dhcp_pool0 disabled=no interface=ether2 name=dhcp1
    /ip dhcp-server network
    add address=192.168.2.0/24 gateway=192.168.2.1
  8. We check that the PC-1 has obtained a valid ip address and is able to communicate with R1:
    PC-1> ping 192.168.1.1
    84 bytes from 192.168.1.1 icmp_seq=1 ttl=64 time=2.637 ms
    84 bytes from 192.168.1.1 icmp_seq=2 ttl=64 time=0.503 ms
    84 bytes from 192.168.1.1 icmp_seq=3 ttl=64 time=0.418 ms
    84 bytes from 192.168.1.1 icmp_seq=4 ttl=64 time=0.360 ms
    84 bytes from 192.168.1.1 icmp_seq=5 ttl=64 time=0.401 ms
  9. We check that the PC-2 has obtained a valid ip address and is able to communicate with R3:
    PC-2> ping 192.168.2.1
    84 bytes from 192.168.2.1 icmp_seq=1 ttl=64 time=2.416 ms
    84 bytes from 192.168.2.1 icmp_seq=2 ttl=64 time=0.417 ms
    84 bytes from 192.168.2.1 icmp_seq=3 ttl=64 time=2.128 ms
    84 bytes from 192.168.2.1 icmp_seq=4 ttl=64 time=0.401 ms
    84 bytes from 192.168.2.1 icmp_seq=5 ttl=64 time=0.354 ms
  10. Check if the PC-1 can reach PC-2:
    PC-1> ping 192.168.2.1
    *192.168.1.1 (ICMP type:3, code:0, Destination network unreachable)
    *192.168.1.1 (ICMP type:3, code:0, Destination network unreachable)
    *192.168.1.1 (ICMP type:3, code:0, Destination network unreachable)
    *192.168.1.1 (ICMP type:3, code:0, Destination network unreachable)
    *192.168.1.1 (ICMP type:3, code:0, Destination network unreachable)
  11. As expected, PC-1 does not reach PC-2.
  12. On R1 and R3 we add the necessary static routes that use the IPIP tunnel:
    {R1}
    /ip route add dst-address=192.168.2.0/24 gateway=192.168.200.2
    {R3}
    /ip route add dst-address=192.168.1.0/24 gateway=192.168.200.1
  13. Check if the PC-1 can reach PC-2:
    PC-1> ping 192.168.2.1
    84 bytes from 192.168.2.1 icmp_seq=1 ttl=63 time=5.415 ms
    84 bytes from 192.168.2.1 icmp_seq=2 ttl=63 time=1.472 ms
    84 bytes from 192.168.2.1 icmp_seq=3 ttl=63 time=0.936 ms
    84 bytes from 192.168.2.1 icmp_seq=4 ttl=63 time=2.320 ms
    84 bytes from 192.168.2.1 icmp_seq=5 ttl=63 time=1.165 ms
  14. As expected, communication is now successful .
  15. Note that the connection is made through the IPIP tunnel and PC-1 has no knowledge of the internal infrastructure,
    for example of R2:
    PC-1> ping 10.10.10.100
    10.10.10.100 icmp_seq=1 timeout
    10.10.10.100 icmp_seq=2 timeout
    10.10.10.100 icmp_seq=3 timeout
    10.10.10.100 icmp_seq=5 timeout
EoIP
eoip
How the protocol works
Ethernet over IP (EoIP) is a MikroTik RouterOS protocol that creates an ethernet tunnel between two routers over an IP connection. The EoIP tunnel can be created over IPIP tunnels, PPTP tunnels or any other connection capable to carry the IP protocol. When the bridging function is enabled, all ethernet traffic is part of a bridge in the same way as a physical Ethernet interface and a cable between the two routers (with bridging enabled). In fact, the EoIP protocol encapsulates the Ethernet frames in GRE packets (IP protocol number 47) and sends them to the remote side of the EoIP tunnel.
Lab
Three routers and two PCs are required for this laboratory.
Tunnel EoIP
The objective of this laboratory is to realize the infrastructure of figure eoip-lab with a dhcp server between the two external routers.
Tunnel EoIP.
eoip-lab
  1. Connect the routers as shown in fig eoip-lab .
  2. We configure the R1, R2 and R3 routers for basic connectivity :
    {R1}
    /system identity set name=R1
     /ip address
     add address=10.10.10.30/24 interface=ether1
     
    {R2}
    /system identity set name=R2
     /interface bridge add name=bridge1
     /interface bridge port add interface=ether1  bridge=bridge1
     /interface bridge port add interface=ether2  bridge=bridge1
     /ip address
     add address=10.10.10.30/24 interface=bridge1
     
    {R3}
    /system identity set name=R3
     /ip address
     add address=10.10.10.31/24 interface=ether1
     
  3. We check the connection from router R1 to R3:
    [admin@R1] > /ping 10.10.10.31
       SEQ HOST                                     SIZE TTL TIME  STATUS
         0 10.10.10.31                                56  64 18ms
         1 10.10.10.31                                56  64 2ms
         2 10.10.10.31                                56  64 2ms
         3 10.10.10.31                                56  64 6ms
         4 10.10.10.31                                56  64 2ms
         sent=5 received=5 packet-loss=0
  4. We create the tunnel operating on routers R1 and R3:
    {R1}
    /interface eoip add name=eoip local-address=10.10.10.30 \
       remote-address=10.10.10.31 tunnel-id=0
    {R3}
    /interface eoip add name=eoip local-address=10.10.10.31 \
       remote-address=10.10.10.30 tunnel-id=0
  5. Still on R1 and R3 we create a bridge and insert ether2 and the endpoint of the EoIP tunnel among the ports:
    {R1}
    /interface bridge add name=bridge1
    /interface bridge port add interface=ether2  bridge=bridge1
    /interface bridge port add interface=eoip  bridge=bridge1
    /ip address
    add address=192.168.200.1/24 interface=bridge1
    {R3}
    /interface bridge add name=bridge1
    /interface bridge port add interface=ether2  bridge=bridge1
    /interface bridge port add interface=eoip  bridge=bridge1
    /ip address
    add address=192.168.200.2/24 interface=bridge1
  6. On the R1 router we create a DHCP server that provides the ip addresses to our two LANs:
    {R1}
    /ip pool
    add name=dhcp_pool0 ranges=192.168.200.100-192.168.200.200
    /ip dhcp-server
    add address-pool=dhcp_pool0 disabled=no interface=bridge1 name=dhcp1
    /ip dhcp-server network
    add address=192.168.200.0/24 gateway=192.168.200.1
  7. We check that the PC-1 and PC-2 have obtained a valid ip address and are able to communicate with each other:
    PC-1> show ip
      NAME        : PC-1
      IP/MASK     : 192.168.200.198/24

       PC-2> show ip
      NAME        : PC-2
      IP/MASK     : 192.168.200.197/24

      PC-1> ping 192.168.200.197
      84 bytes from 192.168.200.197 icmp_seq=1 ttl=64 time=2.266 ms
      84 bytes from 192.168.200.197 icmp_seq=2 ttl=64 time=4.836 ms
      84 bytes from 192.168.200.197 icmp_seq=3 ttl=64 time=1.444 ms
      84 bytes from 192.168.200.197 icmp_seq=4 ttl=64 time=1.636 ms
      84 bytes from 192.168.200.197 icmp_seq=5 ttl=64 time=1.546 ms
IPsec
ipsec
How the protocol works
IPsec (IP SECurity) is a family of IETF protocols aimed at making the communications that use IP protocol more secure. It rests directly on the IP protocol at the ISO / OSI 3 level; it can be implemented directly through specific hardware, or via software: in the case of hardware implementations, it will be completely transparent to the machine, applications and operating system, while in the case of software implementation, the operating system must be modified. IPsec was first developed within the IPv6 standard and later incorporated into IPv4. The main protocols that make up IPsec are described in the following RFCs:
The issues that affect IPv4 and that IPsec tries to overcome are:
IPsec uses the following communication strategies:
To obtain these three results, it adopts the following protocols:
IPsec does not define the specific security algorithm (encryption, ...) to be used but provides a way to indicate which algorithm is chosen, allowing the use of the algorithms most suited to the needs of the moment. For example, integrity is normally controlled using the MD5 or SHA algorithm, while encryption is often done using DES.
We must distinguish two modes of operation of IPsec:
  1. the case in which IPsec is used between two hosts that are the traffic extreme points, called transport mode. In this case L4 datagrams are encapsulated.
  2. all other cases (router-router, computer-router etc.) where at least one of the two extremes is not the final destination of the traffic (Gateway), called tunnel mode; in this case the
    gateway sends and receives traffic to and from the final recipient using the usual IP protocol. In this case the entire L3 packet is encapsulated.
The most significant logical difference between the two modes is that in the second case in the packet carried by IPsec there must be both an indication of the gateway and of the final non-IPsec recipient, while in the first case the latter is not necessary. All communications between the two hosts connected by an IPsec tunnel and identified by their IPv4 address must pass via IPsec: therefore if a host receives a non-IPsec IPv4 packet with an IP address of an IPsec partner, it must discard it. It should be noted that each tunnel is unidirectional, so to communicate the two hosts must establish two tunnels, one for each direction. The IPsec initialization procedure is called IKE (Internet Key Exchange), we will discuss some details of which later. Once the procedure has been successfully completed, two Security Association (SA) are created, which are the collection of all the parameters that characterize the two IPsec tunnels that connect the two hosts; in practice, the SA uniquely identifies the tunnels. At this point, finally, host A, using the appropriate SA, transforms the original package into an IPsec package and sends it to B. B, also having the two SAs, can transform the IPsec package in the original package. Then, similarly, B can respond to A. After the initial phase of tunnel creation (IKE), IPsec finally begins to exchange data between the two hosts. For this operation two protocols are available: Authentication Header (AH) and Encapsulating Security Payload (ESP). It should be noted that AH does not offer confidentiality, ie the data, the payload, are not encrypted, while ESP allows the data to be encrypted. On the other hand, AH also guarantees the integrity of the packet IP Header (with the exception of some parts that can be changed as discussed below), while ESP guarantees the integrity only of the payload of the IP packet. Putting together the two transmission modes (Tunnel and Transport) with the two IPsec Protocols (AH and ESP), we obtain the four main types of data packets created and transported by IPsec. Since the initialization phase is slow and complicated, we therefore have that an IPsec tunnel is created and remains active for a certain period of time, whether there is traffic or not. When the time expires, if there is no traffic the tunnel is closed or the SAs are regenerated. We have said that each SA can be associated with different security features and that it takes two SAs to have complete protection of a two-way channel, to manage this you use two local IPsec databases that store the necessary information:
How IPsec works - dispatch
ipsec-send
How IPsec works - reception with AH
ipsec-receive-ah
IPsec on RouterOS
First of all it should be noted that in RouterOS to activate IPsec process there must be traffic that corresponds to an IPsec criterion. What should I configure?
By referring to the phases of IPsec communication we can summarize the RouterOS commands in the following groups:
Hint. To enable the specific log for IPsec use the command: \\ /system logging add topics=ipsec
Now we are ready to set up a simple site-to-site IPsec VPN. For the two configurations that follow refer to the infrastructure in figure ipsec-site-to-site .
Simple site-to-site IPsec VPN
ipsec-site-to-site
Tunnel mode
/system identity set name=R1
#  Define peer (Phase 1)
/ip ipsec peer
   add address=2.2.2.2/32
   dh-group=modp2048
   dpd-interval=10s
   dpd-maximum-failures=3
   encalgorithm=aes-256
   hash-algorithm=sha512
   secret=superSecret
# Define policy (Phase 2)
/ip ipsec policy
   add dst-address=10.2.2.0/24
   sa-dst-address=2.2.2.2
   sa-src-address=1.1.1.1
   src-address=10.1.1.0/24
   tunnel=yes
# IPsec tunnel traffic
# don't be into NAT
/ip firewall nat
   add action=accept chain=srcnat
   dst-address=10.2.2.0/24
/system identity set name=R2
# Define peer (Phase 1)
/ip ipsec peer
   add address=1.1.1.1/32
   dh-group=modp2048
   dpdinterval=10s
   dpd-maximum-failures=3
   encalgorithm=aes-256
   hash-algorithm=sha512
   secret=superSecret
# Define policy (Phase 2)
/ip ipsec policy
   add dst-address=10.1.1.0/24
   sa-dst-address=1.1.1.1
   sa-src-address=2.2.2.2 s
   rc-address=10.2.2.0/24
   tunnel=yes
# IPsec tunnel traffic
# don't be into NAT
/ip firewall nat
   add action=accept chain=srcnat
   dst-address=10.1.1.0/24
Transport mode
/system identity set name=R1
# Configurazione IPsec
/ip ipsec peer
   add address=2.2.2.2/32
   dh-group=modp2048
   dpdinterval=10s
   dpd-maximum-failures=3
   enc-algorithm=aes256
   hash-algorithm=sha512
   secret=superSecret
/ip ipsec policy
   add dst-address=2.2.2.2/32
   protocol=gre
   src-address=1.1.1.1/32
# Tunnel GRE per il traffico
/interface gre
   add clamp-tcp-mss=no
   dont-fragment=inherit
   keepalive=10s,3 mtu=1400
   name=gre-tunnel1
   remote-address=2.2.2.2
# routing
/ip address
   add address=10.255.0.1/24
   interface=gre-tunnel1
/ip route
   add distance=1
   dst-address=10.2.2.0/24
   gateway=10.255.0.2
/system identity set name=R2
#  IPsec setup
/ip ipsec peer
   add address=1.1.1.1/32
   dh-group=modp2048
   dpdinterval=10s
   dpd-maximum-failures=3
   enc-algorithm=aes256
   hash-algorithm=sha512
   secret=superSecret
/ip ipsec policy
   add dst-address=1.1.1.1/32
   protocol=gre
   src-address=2.2.2.2/32
# Tunnel GRE ready fro traffic
/interface gre
   add clamp-tcp-mss=no
   dont-fragment=inherit
   keepalive=10s,3 mtu=1400
   name=gre-tunnel1
   remote-address=1.1.1.1
# routing
/ip address
   add address=10.255.0.2/24
   interface=gre-tunnel1
/ip route
   add distance=1
   dst-address=10.1.1.0/24
   gateway=10.255.0.1
IPsec/XAuth
At MUM 2018 in Berlin, Tomas Kirnak gave an interesting talk on the IPsec / XAuth protocol often called "Cisco IPsec". The talk slides are available at the link http://bit.ly/2RlSeEg while a detailed description of the protocol is available at the link http://bit.ly/2RmuWOD . VPNs are often used by network administrators to remotely manage customer networks, other times there are requests from some user who has to work from remote locations or from companies that need access to manage some equipment. In summary we can say that often the required configuration is client-to-site with the client located behind a NAT network. There are many options that can be used to offer the customer these opportunities:
The choice of IPsec / Xauth mode-config is very interesting because it:
As a first step it is necessary to prepare the configuration that will subsequently be sent to the clients. Most of the configuration is automatically deduced from what is set in the peer and in its profile. By setting peer configuration generate-policy=port-strict the IPsec policies are automatically generated.
IPsec/XAuth - configuration to send to clients
IPsec/XAuth - Peer profile
IPsec/XAuth - Peer - General
IPsec/XAuth - Peer - Advanced
Definiamo come cifrare il traffico:
IPsec/XAuth - Policy proposal
Aggiungiamo un utente:
IPsec/XAuth - adding a user
Below i is the resulting final configuration for the router that will accept the connection and provide the configuration to the clients:
/system identity set name=R1

# Setup XAuth in mode-config
/ip pool
add name=vpn-admins ranges=10.10.10.10-10.10.10.20

/ ip ipsec mode-config
    add address-pool=vpn-admins name=vpn-admins
    split-include=10.4.11.0/24,192.168.0.0/24 static-dns=1.2.3.4
    system-dns=no

# Define peer
/ip ipsec peer profile
    add dpd-interval=10s dpd-maximum-failures=3
    enc-algorithm=aes-256,3des
    hash-algorithm=sha512 name=vpn-admins

/ip ipsec peer
    add address=0.0.0.0/0 auth-method=pre-shared-key-xauth
    generate-policy=port-strict mode-config=vpn-admins passive=yes
    secret=thisIsSuperSecret

# Adding user
/ip ipsec user
    add name=username password=password

# Define how to crypt traffic
/ip ipsec proposal
    set [ find default=yes ] auth-algorithms=sha256
    enc-algorithms=aes-128-cbc pfs-group=modp2048
Now all that remains to do is to configure the client. In this case we show the client configuration for OSX, for other clients like Microsoft Windows or Android see the document http://bit.ly/2C9S2xn . To configure the Apple OSX VPN client:
  1. Go to System Preferences > Network
  2. Press on the + symbol at the bottom left
  3. Create a Cisco IPsec VPN and assign the name you prefer
  4. Enter the following parameters
    1. address: (indicate the IP of the IPsec VPN server)
    2. user: username
    3. pass: password
  5. Click on advanced and as a pre-shared key use thisIsSuperSecret.
MPLS
How the protocol works
mpls The idea behind the MPLS protocol (Multi Protocol Label Switching ) is to forward packets based on a label instead of the destination IP address. This approach produces faster searches in the forwarding table since the label can be used as an index instead of the longest prefix matching and also allows a more refined control of the traffic. The idea behind the MPLS protocol (Multi Protocol Label Switching) is to forward packets based on a label (label) instead of the destination IP address. This approach produces faster searches in the forwarding table since the label can be used as an index instead of the longest prefix matching and also allows a more refined control of the traffic. The MPLS protocol was created in response to the problems that the network was encountering in its development in the early 1990s. Among these we have the complexity of routing, the use of different technologies that are difficult to integrate like IP and ATM and scalability problems. MPLS solves these problems in a simple and effective way: it places itself between the data of the second level protocol and those of the third level protocol, adding its own header, which contains a label in which all the necessary information for routing are defined of the package. In this way the data of the third level protocol are transparent to the routers of the network; thanks to MPLS I can therefore use the same router to pass different protocol packets, even if it is typically used with IP type packets. MPLS completely separates the control component (communication between nodes and update routing tables) and the component that realizes the actual routing of the packets based on the routing tables, called forwarding component. The heart of an MPLS network is formed by a set of routers capable of routing packets solely through the content of the MPLS labels. These routers are called LSRs (Label Switch Routers), which form together an area called the MPLS backbone as exemplified in figure mpls-dominio .
Multi Protocol Label Switching (MPLS) domain.
mpls-dominio
However, the packets start from the users' routers without MPLS header, but only with the protocol data of the third level. We will have special routers located at the border of the MPLS backbone that add the MPLS label based on the data of the third level and route the packet to the backbone. On the other hand, normal LSRs usually do not use the third level protocol header. The path followed by a packet through multiple LSRs is called LSP (Label Switched Path ).
MPLS packet.
mpls-label
Now a bit of routing theory: in a connectionless network, like the IP network, the path followed by a packet between the source and the destination is determined by the composition of elementary and independent routing operations performed by the routers that are traversed from the package. Each router chooses the next router to which re-launch the packet. This choice is performed by examining the header of the packet and accessing a updated routing table by using a routing protocol. This is the Router Information Base (RIB) table introduced on page rib . The choice of the next-hop operated by a router can be modeled as the concatenation of two distinct functions:
  1. the subdivision of the set of packages to be re-launched in a series of distinct subsets, called FEC (Forwarding Equivalent Class );
  2. the association of a FEC to a specific next-hop.
According to this model, the packets belonging to the same FEC will be relayed by a router to the same nexthop. In particular, in an IP network, a router will classify two packets, which carry two different destination addresses A and B, as belonging to the same FEC if in the routing table of the router there is an X prefix for which this prefix represents the greatest correspondence length (longest match ) for both addresses A and B. In this view, each router executes, independently of the others, its packet classification in FEC and therefore two packets that are classified as belonging to the same FEC in a router can belong to different FECs in another router. The MPLS protocol acts differently: as defined in RFC 3031 the MPLS protocol assigns a FEC to a package once and for all, at the time when the package enters an MPLS network. The FEC assigned to the package is encoded in a label , of short and fixed length, transported in the header of the package 6 itself. When the router through which the packet has entered an MPLS network raises the packet, the packet itself assigns to the packet the value of the label that will be used by the next router to carry out the switching. When a packet enters a router, the label is used as an index for direct access to a table that will contain the value of the next-hop and the value of the new label. The old label is replaced with the new one and the package is sent back to the next router. It should be emphasized that once a packet has been assigned a label, the packet is switched by examining the label exclusively without taking into account the value of the other fields of the IP header.
Label Switching Router (LSR) and label definition mode
In the previous section the concept of FEC has been defined as a set of IP packets that must be treated by a router in the same way, for example that must be re-launched towards the same next-hop and belonging to the same class of service. In MPLS every FEC is assigned a label that will be used by the routers to perform the packet switching function. A router that supports the MPLS technique is called the Label Switching Router (LSR) and the type of switching is generally referred to as label switching. An MPLS network domain is thus formed by a set of LSRs connected directly to each other. The incoming traffic to an MPLS domain can come either from networks external to the domain, such as for example local user networks, or from traditional IP routers belonging to IP network sections that do not support MPLS technology as illustrated in figure mpls-dominio . An LSR that connects an MPLS domain with other nodes that are outside the domain is called Edge LSR, while an LSR that is connected only to other LSRs is called Core LSR. A label is therefore a fixed-length identifier that is used to identify a FEC. A label has local validity, this means that the association between FEC and a specific value of a label is valid only on one section of the network, the same FEC can therefore be identified by different labels on different sections of the network.
LSP tunnel
A Label Switched Path can be used to create tunnels within IP networks. If an IP tunnel is made using an MPLS LSP then the LSP is called the LSP Tunnel. There are two types of tunnel LSPs:
  1. hop-by-hop routed LSP tunnels are implemented by
    hop by hop routed LSP, these tunnels follow the paths indicated by the routing protocols within the MPLS domain and are indicated with the term Uniform Model LSP;
  2. explicit routed LSP tunnels are implemented by explicitly routed LSP, therefore, the paths followed by these LSPs in the MPLS domain may be different than those indicated by the routing protocol and decided on the basis of considerations and alternative strategies, these tunnels are indicated with the term Pipe Model LSP.
For the purposes of this text our introduction to the MPLS protocol stops here. For those wishing to learn more, we recommend the excellent dispensation produced by Marco Listanti of the INFOCOM Department of the "La Sapienza" University of Rome available at the link http://bit.ly/2F0SrFl . An interesting talk was presented at the MUM 2009 in Prague entitled "MikroTik RouterOS Introduction to MPLS" which included the MPLS protocol with Mikrotik products. The slides are available at the link http://bit.ly/2GRW1Eq .
VPLS (Virtual Private LAN Service)
Those familiar with the services that Service Providers offer on their IP + MPLS networks will know that one of the most interesting of these is the VPLS (Virtual Private LAN Service) service, which is a Multipoint-to-Multipoint service that allows emulation of LAN Ethernet on an IP + MPLS network. From a logical point of view, the VPLS service can be seen as a service that allows emulating Ethernet switches. For example, connecting N geographically dispersed routers with a VPLS service is equivalent to connecting the routers locally to an Ethernet switch with straight-through cables. The CE (Customer Edge), that is the customer's devices that interface with the CE Service Provider network,, can be any device that generates tagged and/or untagged Ethernet frames (Ethernet or Host routers or switches), and the connection among the CE and the ISP network routers (PE router) can be in any technology (ex. Ethernet back-to-back, Ethernet over SONET / SDH using GFP encapsulation, Ethernet over ATM using AAL5 (RFC 2684), etc. ). The service model is very similar to the classic L3VPN service on IP + MPLS networks, with the substantial difference that between L3VPN sites IP packets are transported and the ISP network participates in inter-site routing, while between VPLS sites Ethernet frames are exchanged (tagged or untagged). This theoretically allows the exchange of Level 3 packages that are not IP, although this is actually no longer considered an important advantage of VPLS, since all applications are based on the TCP/IP architecture. From a physical point of view, the operating model is similar to that of the L3VPN, with some substantial differences. For each client, the virtual L2 instances called VSI (Virtual Switch Interface) are created on the PEs where the sites are certified. Each VSI can be seen as a set of two elements: a MAC table (usually referred to as VFI, Virtual Forwarding Instance), and a set of physical or logical Ethernet interfaces that form a broadcast domain (usually referred to as a Bridge Domain). The CE access interfaces on the PE (attachment circuit) are associated with the appropriate VSI via configuration. The VSIs must emulate all the ethernet switch functions:
For each VPLS, a complete pseudowire mesh is created between the PEs where the VPLS sites are attested; a pseudowire emulates a point-to-point connection within which it is possible to carry any Level 2 frames, in this case Ethernet frames. The reason why you need a complete pseudowire mesh is related to the transport of BUM traffic, ie to Broadcast, Unknown-Unicast and Multicast traffic.
Architecture for performance testing.
vpn-test
But MPLS and VPLS are also interesting for small architectures as they are very efficient. If we consider the architecture of figure vpn-test using RB1000 RouterBoard as hardware then the table table:tunnel-performance that collects the performance tests highlights the winning protocols.
64 byte pps
512 byte pps
Bridge
414.000
359.000
MPLS
410.000
358.000
VPLS
332.500
301.000
Routing
236.000
229.700
EoIP
190.000
183.900
Performance test.
table:tunnel-performance
MPLS and VPLS using Mikrotik RouterOS
Remember that in order for the MPLS menu to be present, the MPLS package must be installed and active as shown in fig mpls-package .
MPLS package.
mpls-package
Lab
For this laboratory, two routers with a wireless interface and two PCs are required.
VPLS tunnel
The objective of this laboratory is to realize the infrastructure of figure mpls-tunnel using MPLS. This approach has the following advantages:
VPLS tunnel using a radio bridge.
mpls-tunnel
For educational convenience this laboratory is available in two versions: through the graphical interface of WinBox or through the terminal commands.
{Using WinBox}
  1. Set up the radio link as usual with a WDS bridge.
  2. As a first step, enable LDP (Label Distribution Protocols) on both routers using the menu MPLS > MPLS > LDP Interface > LDP Setting :
  3. Using the MPLS > MPLS > LDP Interfaces menu, add the interface to be used for VPLS connections. The transport address can be empty.
  4. After a few seconds check the status of the LDP connectivity in MPLS > MPLS > LDP Neighbor :
    D=Dynamic, O=Operational
  5. Add a new VPLS interface using the MPLS > VPLS > VPLS menu.
    The address to indicate in the remote peer field is the ip address of the other end of the radio link:
  6. After a few seconds, check how the status of the LDP connectivity was changed in MPLS > MPLS > LDP Neighbor menu:
    D=Dynamic, O=Operational, T = Transport, V=VPLS Active
  7. Create a bridge interface and add the vpls and ether1 interface to the ports.
  8. Check for proper operation by pinging between clients .
{Using terminal commands}
  1. We load the configurations on the AP router and then on the router station:
    {AP}
    /system identity set name=AP

    # Configuration of the wireless access point (AP)
    /interface wireless
    set wlan1 disabled=no ssid=MPLS frequency=5180 band=5ghz mode=bridge

    # Configuration of IP address
    /ip address
    add address=172.16.0.1/30 interface=wlan1

    # Enable LDP
    /mpls ldp
    set enabled=yes lsr-id=172.16.0.1 transport-address=172.16.0.1
    /mpls ldp interface
    add interface=wlan1

    # Setup VPLS tunnel
    /interface vpls
    add name=vpls1 remote-peer=172.16.0.2 vpls-id=1:1 disabled=no

    # Add bridge and ports
    /interface bridge add name=bridge1
    /interface bridge port
    add bridge=bridge1 interface=ether1
    add bridge=bridge1 interface=vpls1
    {station}
    /system identity set name=station

    # Configuration of the wireless access point (station)
    /interface wireless
    set wlan1 disabled=no ssid=MPLS band=5ghz mode=station

    # Configuration of IP address
    /ip address
    add address=172.16.0.2/30 interface=wlan1

    # Enable LDP
    /mpls ldp
    set enabled=yes lsr-id=172.16.0.2 transport-address=172.16.0.2
    /mpls ldp interface
    add interface=wlan1

    # Setup VPLS tunnel
    /interface vpls
    add name=vpls1 remote-peer=172.16.0.1 vpls-id=1:1 disabled=no

    # Add bridge and ports
    /interface bridge add name=bridge1
    /interface bridge port
    add bridge=bridge1 interface=ether1
    add bridge=bridge1 interface=vpls1
  2. Check the correct working:
    [admin@AP] /mpls ldp neighbor> print
    Flags: X - disabled, D - dynamic, O - operational,
           T - sending-targeted-hello, V - vpls
     #      TRANSPORT    LOCAL-TRANSPORT PEER           ADDRESSES
     0 DOTV 172.16.0.2   172.16.0.1      172.16.0.2:0   172.16.0.2

    [admin@AP] /mpls forwarding-table print
    Flags: L - ldp, V - vpls, T - traffic-eng
     #   IN-LABEL        OUT-LABELS      DESTINATION    INTERFACE
     0   expl-null
     1 V 18                              vpls1
  3. Check that the VPLS tunnel is correctly established:
    [admin@AP] /interface vpls> monitor vpls1 once
           remote-label: 17
            local-label: 18
          remote-status:
      transport-nexthop: 172.16.0.2
         imposed-labels: 17
  4. Check for proper operation by pinging between clients.
If you want to go deeper into the topic always the excellent Tomas Kirnak at MUM 2013 gave a talk entitled "MPLS for ISPs - PPPoE over VPLS MPLS, VPLS, PPPoE" whose slides are available at link http://bit.ly/2VrgCCB .