Testwiki/Virtual Private Networks

From MikroTik Wiki
Jump to: navigation, search

Virtual Private Networks

PPPoE

PPPoE is an extension of the standard Point to Point Protocol (PPP). It’s not real VPN solution, but it provides only secure and permanent connection between two end points. The difference between them is expressed in transport method: PPPoE employs Ethernet instead of serial link. PPPoE encapsulates PPP frame inside Ethernet frame. Currently PPPoE is used mainly by ISPs to control of their client connections for xDSL and cable modems as well as plain Ethernet networks.

Generally speaking, PPPoE is used to hand out IP addresses to clients based on the username and password authentication as opposed to DHCP, therefore PPPoE could be as authentication way of deploying VPN networks, to assign IP addresses to clients based on these username and password.

The PPPoE works over any Ethernet level interface, like 10/100/1000 Mbps Ethernet, wireless 802.11 and EoIP (Ethernet over IP tunnel).

Simple configuration example:

Image9001.gif

PPPoE Server configuration

To configure MikroTik RouterOS to be an Access Concentrator (PPPoE Server):

  • add an address pool for the clients from 10.0.1.2 to 10.1.1.14;
  • add ppp profile;
  • add ppp secret (username/password);
  • add pppoe server itself.


Add an address pool for the clients from 10.0.0.2 to 10.0.0.14, called pppoe-pool, these addresses can be assigned to PPPoE clients:

 [admin@MikroTik_A] /ip pool > add name="pppoe-pool" ranges=10.0.0.2-10.0.0.14


Add PPP profile, called pppoe-profile where local-address will be the router's address and clients will have an address from pppoe-pool:

 [admin@MikroTik_A] /ppp profile > add name="pppoe-profile" local-address=10.0.0.1 \
 remote-address=pppoe-pool


Add a user with username user and password 123:

 [admin@MikroTik_A] /ppp secret > add name=user password=123 service=pppoe profile=pppoe-profile


Now add a pppoe server to interface (wlan):

 [admin@MikroTik_A] /interface pppoe-server server >add service-name=internet interface=wlan1 \ 
 default-profile=pppoe-profile


Show pppoe server:

[admin@MikroTik_A] /interface pppoe-server server> print 
Flags: X - disabled 
 0   service-name="" interface=wlan1 max-mtu=1480 max-mru=1480 mrru=disabled 
     authentication=pap,chap,mschap1,mschap2 keepalive-timeout=10 
     one-session-per-host=no max-sessions=0 default-profile=default

By default pppoe server supports all four authentication algorithms.


PPPoE Client configuration

To configure MikroTik RouterOS to be a PPPoE client, just add a pppoe-client on certain interface:

 [admin@MikroTik_B] /interface pppoe-client > add name=pppoe-user user=user password=123 \
 interface=wlan1 disabled=no


Show pppoe-client configuration:

[admin@MikroTik_A] /interface pppoe-client> print 
Flags: X - disabled, R - running 
 0 R  name="pppoe" max-mtu=1480 max-mru=1480 mrru=disabled interface=ether4 
      user="user" password="123" profile=default service-name="" ac-name="" 
      add-default-route=no dial-on-demand=no use-peer-dns=no 
      allow=pap,chap,mschap1,mschap2

By default it allow all four authentication types are supported: pap, chap, mschap1, mschap2.


EoIP

Before we start read about EoIP (Ethernet over IP) we need understand two concepts - concept of bridge and tunneling:

  • Ethernet bridges represent the software analog to a physical Ethernet switch. The Ethernet bridge can be thought of as a kind of software switch which can be used to connect multiple Ethernet interfaces (physical or virtual) on a single router and share a single IP subnet.
  • One protocol encapsulation into another protocol is known as tunneling. Protocol that you are encapsulating called passenger protocol and “carrier” or “transport” protocol is one of protocol used to carry the encapsulated protocol (IP only). RouterOS supports several types of tunnel protocols, like EoIP (allowed to bridge two LANs over routed (IP) network), IPIP (IP based tunnel between two routers, allows to encapsulate IP packet in another IP packet) or PPTP tunnel (provides to create encrypted tunnel over IP).


Ethernet over IP (EoIP) Tunneling is a MikroTik RouterOS protocol that creates an Ethernet tunnel between two routers on top of an IP connection. The EoIP tunnel may run over other tunnels, like IPIP tunnel or PPTP tunnel or any other connection capable of transporting IP.
EoIP use GRE (Generic Routing Encapsulation) protocol that encapsulate various network layer protocol packet inside another IP packet (add additional IP header – it means to create IP tunnel). One of the most common uses of GRE tunnels is for VPNs over the Internet. IP traffic with private address gets encapsulated in packet that has routable public IP address (IP tunnel address).

When the bridging function of the router is enabled together with EoIP, all Ethernet traffic (all Ethernet protocols) will be bridged just as if there were a physical Ethernet interface and cable between the two routers with bridging enabled (see Figure 9.2).

Image9002.gif

Specific Properties:

  • Each EoIP tunnel interface can connect with one remote router which has a corresponding interface configured with the same 'Tunnel ID'.
  • The EoIP interface appears as an Ethernet interface under the interface list.
  • This interface supports all features of an Ethernet interface. IP addresses and other tunnels may be run over the interface.
  • The EoIP protocol encapsulates Ethernet frames in GRE (Generic Routing encapsulation - IP protocol number 47) packets (just like PPTP) and sends them to the remote side of the EoIP tunnel.


This protocol makes multiple network schemes possible.

Network setups with EoIP interfaces:

  • Possibility to bridge LANs over the Internet
  • Possibility to bridge LANs over encrypted tunnels (EoIP together with PPTP)
  • Possibility to bridge LANs over 802.11b 'ad-hoc' wireless networks

EoIP configuring example

Assume that we have network design as shown below and we want to bridge two LAN 1 and LAN 2 networks, By using EoIP setup can be made so that Office and Remote LANs are in the same Layer2 broadcast domain.

Image9003.gif

I assume that IP addresses are configured and IP routing is enabled between MikroTik_A and MikroTik_B routers.

At first we create EoIP tunnel on our edge’s routers:

MikroTik_A:

[admin@MikroTik_A] > interface eoip add remote-address=12.0.1.11 tunnel-id=1 
mac-address=00:00:5E:80:00:'''01''' disabled=no

MikroTik_B:

[admin@MikroTik_B] > interface eoip add remote-address=13.0.1.2 tunnel-id=1 
mac-address=00:00:5E:80:00:'''02''' disabled=no


Tunnel-id is method of identifying tunnel. Tunnel-id on both participant routers must be equal.

When bridging EoIP tunnels, it is highly recommended to set unique MAC addresses for each tunnel for the bridge algorithms to work correctly. For EoIP interfaces you can use MAC addresses that are in the range from 00-00-5E-80-00-00 to 00-00-5E-FF-FF-FF, which IANA has reserved for such cases.


Print info about created EoIP interface on MikroTik_A:

Now we have a new interface available named “eoip-tunnel1”.

[admin@MikroTik_A] /interface> print  
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                       TYPE             MTU   L2MTU
 0  R  ether1                     ether            1500  1526 
 1  R  ether2                     ether            1500  1522 
 2     ether3                     ether            1500  1522 
 3  R  eoip-tunnel1               eoip-tunnel      1500  65535


Next step is to bridge local interfaces with EoIP tunnel on both edge routers (LAN side of the Mikrotik routers are the ether1 interface).

MikroTik_A:

[admin@MikroTik_A] /interface bridge> add name=eoip-bridge
[admin@MikroTik_A] /interface bridge port> add interface=eoip-tunnel1 bridge=eoip-bridge
[admin@MikroTik_A] /interface bridge port> add interface=ether1 
bridge=eoip-bridge


MikroTik_B:

[admin@MikroTik_B] /interface bridge> add name=eoip-bridge 
[admin@MikroTik_B] /interface bridge port> add interface=eoip-tunnel1 bridge=eoip-bridge 
[admin@MikroTik_B] /interface bridge port> add interface=ether1 
bridge=eoip-bridge


Set up ip addresses to the bridge interface:

MikroTik_A:

[admin@MikroTik_A] /ip address> add address=192.168.8.1/24 
interface=eoip-bridge

MikroTik_B:

[admin@MikroTik_B] /ip address> add address=192.168.8.254/24 
interface=eoip-bridge


Show arp table on MikrTik_A router:

[admin@MikroTik_A] /ip arp> print 

Flags: X - disabled, I - invalid, H - DHCP, D - dynamic 
 #   ADDRESS         MAC-ADDRESS       INTERFACE                               
 0 D 13.0.1.1        00:0C:42:43:39:01 ether1                                  
 1 D 192.168.8.3     E0:CB:4E:25:13:53 eoip-bridge                             
 2 D 192.168.8.2     00:1B:38:24:FC:13 eoip-bridge
 3 D 192.168.8.4     00:1B:58:25:A2:12 eoip-bridge


Check your connection to remote LAN:

[admin@MikroTik] > ping 192.168.8.3
192.168.8.3 64 byte ping: ttl=64 time=14 ms
192.168.8.3 64 byte ping: ttl=64 time=3 ms
192.168.8.3 64 byte ping: ttl=64 time=5 ms
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 3/7.3/14 ms


PPTP

PPTP (Point to Point Tunnel Protocol) establishes the tunnel but does not provide encryption. It is used in conjunction with the Microsoft Point-to-Point Encryption (MPPE) protocol to create encrypted tunnels over IP. The MikroTik RouterOS implementation includes support for PPTP client and server. PPTP encapsulates PPP in virtual lines that run over IP. PPTP incorporates PPP and MPPE (Microsoft Point to Point Encryption) to make encrypted links. (MPPE 40bit RC4 and MPPE 128bit RC4 encryption are supported.) The purpose of this protocol is to make well-managed secure connections between routers as well as between routers and PPTP clients (clients are available for and/or included in almost all OSs including Windows).

PPTP includes different PPP authentication methods like: mschap2, mschap1, chap, pap and accounting for each PPTP connection. Full authentication and accounting of each connection may be done through a RADIUS client or locally.

PPTP traffic uses TCP port 1723 and the same as EoIP also PPTP uses GRE encapsulation protocol. If EoIP encapsulated Ethernet frame into IP GRE tunnel, then PPTP protocol encapsulating PPP frame inside IP GRE tunnel that allows transfer PPP protocol through Internet.

General applications of PPTP tunnels:

  • For secure router-to-router tunnels over the Internet
  • Remote clients to remotely access an Intranet/LAN of a company (create VPN tunnel to remote office, check info how to set up PPTP client on your Operating System)
  • to bridge LANs over the Internet via encrypted PPTP tunnel (PPTP together with EoIP)


PPTP configuring example

Router-to-Router secure tunnel example.

Each router can also be connected to a different ISP, but each router can access each other through the Internet.

Image9004.gif


I assume that IP addresses are configured and IP routing is enabled between MikroTik_A and MikroTik_B routers.

We will set the left router (MikroTik_A) as the PPTP server and the right router (MikroTik_B) as the PPTP client.

MikroTik_A: (PPTP server)

 [admin@MikroTik_A] /ppp secret> add name="bob" service=pptp password="pass" \
 local-address=10.0.100.1 remote-address=10.0.100.2 disabled=no

 [admin@MikroTik_A] <code>/interface pptp-server server> set enabled=yes</code>

 [admin@MikroTik_A] /interface pptp-server server> print             
             enabled: yes
             max-mtu: 1460
             max-mru: 1460
             mrru: disabled
      authentication: mschap1,mschap2
   keepalive-timeout: 30
     default-profile: default-encryption
 [admin@MikroTik] /interface pptp-server server>


MikroTik_B: (PPTP client)

 [admin@MikroTik_B] /interface pptp-client> add name="pptp-tunnel1" connect-to=13.0.1.2 \
 user="bob" password="pass" profile=default-encryption disabled=no 

 [admin@MikroTik_B] /interface pptp-client> print
 Flags: X - disabled, R - running
  0    name="pptp-out1" max-mtu=1460 max-mru=1460 mrru=disabled
       connect-to=13.0.1.2 user="user" password="pass"
       profile=default-encryption add-default-route=no dial-on-demand=no
       allow=pap,chap,mschap1,mschap2

To set up PPTP client with username bob and password pass allows connect to the 13.0.1.2 PPTP server. At least one of the authentication algorithms must be identical between the server and client.

Now we need to add static routes on each of these PPTP routers. These static routes point to that the packets with destination address 192.168.2.0/24 or 192.168.1.0/24 is routed through PPTP tunnel.

 [admin@MikroTik_A] > ip route add dst-address 192.168.2.0/24 gateway 10.0.100.2
 [admin@MikroTik_B] > ip route add dst-address 192.168.1.0/24 gateway 10.0.103.1

Now tunnel is established and you should be able to ping remote network.

This tunnel encrypts data using MPPE 128 bits encryption algorithm.

[admin@MikroTik_A] > interface pptp-server monitor 0
     status: "connected"
     uptime: 5m28s
  idle-time: 0s
       user: "bob"
  caller-id: "12.0.1.11"
   encoding: "MPPE128 stateless"
        mtu: 1460
        mru: 1460


PPTP client via PPTP tunnel (PC to router)

PPTP incorporates PPP and MPPE (Microsoft Point to Point Encryption) to make encrypted links. One of purpose of this protocol is also to make well-managed secure connections between routers and PPTP clients (clients are available for almost all OSs including Windows, linux, Mac OS).

Image9005.gif

The following example shows how to connect a computer to a remote office network over PPTP encrypted tunnel giving that computer an IP address from the same network as the remote office has (without need of bridging over EoIP tunnels).


Creating PPTP users:


 [admin@MikroTik_A] /ppp secret> add name=home service=pptp password=pass
 local-address=192.168.1.1 remote-address=192.168.1.100

 [admin@MikroTik_A] /ppp secret> print detail
 Flags: X - disabled
   0   name="home" service=pptp caller-id="" password="pass" profile=default
       local-address=192.168.1.1 remote-address=192.168.1.100 routes==""
 [admin@MikroTik_A]  /ppp secret>
Icon-note.png

Note: PPTP local address is the same as routers address on local interface and remote address is from the same range as local network (192.168.1.0/24).


Next step is to enable PPTP server:

 [admin@MikroTik_A] <code>/interface pptp-server server> set enabled=yes </code>
 <code>authentication=mschap1,mschap2 </code>
 [admin@MikroTik_A] /interface pptp-server server> print             
             enabled: yes
             max-mtu: 1460
             max-mru: 1460
             mrru: disabled
      authentication:mschap1,mschap2
   keepalive-timeout: 30
     default-profile: default-encryption
[admin@MikroTik] /interface pptp-server server>

Finally, the proxy APR must be enabled on the “Office” local interface, because Laptop needs ARP information from Office workstations:

 [admin@MikroTik_A] /interface ethernet> set ether1 arp=proxy-arp
 [admin@MikroTik_A] /interface ethernet> print
 Flags: X - disabled, R - running
   #    NAME                 MTU   MAC-ADDRESS         ARP
   0  R ether1              1500  00:30:4F:0B:7B:C1 proxy-arp
   1  R ether2              1500  00:30:4F:06:62:12 enabled
 [admin@MikroTik_A] /interface ethernet>


Finally, we need to configure PPTP client on the home computer:

Please, consult the respective manual on how to set up a PPTP client on your computer.

Below is given instruction how to configuring PPTP client in Windows XP.

1) Go to Start and open Control Panel.

2) Control Panel window will open, then double click Network Connections icon.

3) Click Create a new connection on Network Connections window.

4) New Connection Wizard window will appear, click Next.

5) Select Connect to my network at my workplace option and click Next.

6) Select Virtual Private Network connection option and click Next.

7) You can then name this VPN connection and click Next.

8) If you have dial up connection setting on your computer, this Public Network window will appear. If you computer already connected to public network or hotspot, click Do not dial the initial connection option. If you need to dial Internet connection and then initiate VPN connection, then you need to select the other option, Automatically dial this initial connection. Click Next again.

9) Enter your server PPTP IP address. For this example, PPTP server IP address is 12.0.1.11

10) Click Finish to complete the new connection wizard. Tick that Add a shortcut to this connection to my desktop option.

11) Now you can go to your desktop and double-click the new VPN connection icon, after that enter your username and password and click Connect button. In this example username is home and password is pass.

12) Once you are connected to VPN server, the connected icon will be shown in Network Connections window.


L2TP

L2TP is a secure tunnel protocol for transporting IP traffic using PPP. The Layer 2 Tunneling Protocol (L2TP) was developed after PPTP. One advantage of L2TP over PPTP is that it can be used on different network types such as ATM, frame relay and X.25. It doesn’t provide any encryption by itself, but it the same as PPTP incorporates MPPE (Microsoft Point to Point Encryption) to make encrypted tunnel.

If IP network is used the entire L2TP packet, including payload and L2TP header is sent within a UDP datagram. The L2TP standard says that the most secure way to encrypt data is using L2TP over IPsec (Note that it is default mode for Microsoft L2TP client) where L2TP control and data packets for a particular tunnel appear as homogeneous UDP/IP data packets to the IPsec system.

L2TP traffic uses UDP protocol for both control and data packets. UDP port 1701 is used only for link establishment, further traffic is using any available UDP port (which may or may not be 1701). This means that L2TP can be used with most firewalls and routers (even with NAT) by enabling UDP traffic to be routed through the firewall or router.


L2TP configuring example

Router-to-Router L2TP tunnel example.

Each router can also be connected to a different ISP, but each router can access each other through the Internet.

Image9006.gif


I assume that IP addresses are configured and IP routing is enabled between MikroTik_A and MikroTik_B routers.

We will set the left router (MikroTik_A) as the L2TP server and the right router (MikroTik_B) as the L2TP client.

MikroTik_A: (L2TP server)


 [admin@MikroTik_A] /ppp secret> add name="bob" service=l2tp password="pass" 
 local-address=10.0.100.1 remote-address=10.0.100.2 disabled=no 

 [admin@MikroTik_A] <code>/interface l2tp-server server> set enabled=yes</code>
 [admin@MikroTik_A] /interface <code>l2tp</code> -server server> print              
             enabled: yes
             max-mtu: 1460
             max-mru: 1460
             mrru: disabled
      authentication: mschap1,mschap2
   keepalive-timeout: 30
     default-profile: default-encryption
 [admin@MikroTik_A] /interface pptp-server server>


MikroTik_B: (L2TP client)


 [admin@MikroTik_B] <code>/interface l2tp-client> add connect-to=13.0.1.2 user="bob" \
 password="pass" profile=default-encryption disabled=no </code>

 [admin@MikroTik_B] /interface l2tp-client> print
 Flags: X - disabled, R - running
  0  R name="l2tp-out" max-mtu=1460 max-mru=1460 mrru=disabled
       connect-to=13.0.1.2 user="bob" password="pass"
       profile=default-encryption add-default-route=no dial-on-demand=no
       allow=pap,chap,mschap1,mschap2

To set up L2TP client with username bob and password pass allows connect to the 13.0.1.2 L2TP server. At least one of the authentication algorithms must be identical between the server and client.

Finally, we need to add static routes on each of routers. These static routes point to that the packets with destination address 192.168.2.0/24 or 192.168.1.0/24 is routed through L2TP tunnel.

 [admin@MikroTik_A] > ip route add dst-address 192.168.2.0/24 gateway 10.0.100.2
 [admin@MikroTik_B] > ip route add dst-address 192.168.1.0/24 gateway 10.0.103.1

Now tunnel is established and you should be able to ping remote network.

The same as PPTP case L2TP configuration can be implemented between remote client (PC) and L2TP server (router). As remote clients can be well-known operating systems with installed L2TP client software. For example, Microsoft supports L2TP/IPSec gateway-to-gateway virtual private network (VPN), it means that L2TP is running over IPSec tunnel, for this reason, L2TP server requires also to configure IPSec tunnel (See next section below how to configure and implement secure IPSec tunnel ).

Here can found manual how to introduce L2TP tunnel between RouterOS and Windows XP: http://wiki.mikrotik.com/wiki/MikroTik_RouterOS_and_Windows_XP_IPSec/L2TP.


IPSec

Internet Protocol Security (IPsec) is a set of protocols defined by the Internet Engineering Task Force (IETF) to secure packet exchange over IP network. IPSec can be used to protect data stream between a pair of hosts, between a pair of gateways (e.g. routers), or between a host and router. When you use IPSec to encrypt the data portion of IP packets, you're protecting them from everyone except the sender and receiver.

The IPSec include suite of open standard protocols to perform various functions:

  • Authentication Header (AH) RFC 4302 – provide authentication function only
  • Encapsulating Security Payload (ESP) RFC 4303 – A combined authentication/ encryption function
  • Internet Key Exchange (IKE) protocols. Provide key exchange function. Dynamically generates and distributes cryptographic keys for AH and ESP.
  • Manual Keys. ESP and AH cryptography keys are static and manually distributed. Manual keys should be used when remote peer does not IKE.

Both authentication (AH) and encryption (ESP) are generally desired because:

AH - assure that unauthorized users do not get inside the VPN

ESP - assure that eavesdroppers on the Internet cannot read messages sent over

IPSec tunnel.

IPSec allow also to use one of them most implementations are likely to use ESP rather than AH.


Before we continued to speak about IPsec configuring we must first to understand two important logical concepts that include IPSec:

A security Policy is a rule that is configured into the IPSec implementation that tells it how to process datagrams received by the device. For example, security policies are used to decide if a particular packet needs to be processed by IPSec or not. If security is required, the security policy provides general guidelines for how it should be provided. Security policies are stored in the device's Security Policy Database – SPD.

A security association (SA) includes set of security information (used algorithms, parameters (such as keys)) and is used to share this security information between two network devices that want to establish secure communication between one another. Security association is used for both the authentication (AH) and confidentiality (ESP) protocol as well as it is unidirectional, so for each direction is needed to implement separate SA. If peer relationship is needed, for two-way secure exchange, then two security associations are required. SA is dynamically created before IPSec VPN is established between two IPsec peers (hosts). SA is contained into Security Association Database - SAD.

Each SA is uniquely identified by three parameters:

  • Security Parameter Index (SPI): The SPI is 32-bit number assigned to the SA and has local significance only. SPI is included in AH and ESP headers to enable receiver to select correct SA under which a received packet will be processed.
  • IP Destination Address''': The IP address of the destination endpoint for whom the SA is established.
  • Security Protocol Identifier: Indicates which IPSec protocol is used on the SA (AH or ESP).
  • At first, device checks the SPD database for determine what to do with particular datagram. SPD may references a particular SA in the SAD. If so, the device will look up that security association and use it for processing the datagram.

Authentication Header (AH)

AH is a protocol that provides authentication of either all or part of the contents of a datagram through the addition header that is calculated based on the values in the datagram, it means that AH is something similar to frame checksum which also is calculated using content of datagram, but AH protocol uses also key and is more sophisticated algorithm. It means that additional header is attached to IP packet. What parts of the datagram are used for the calculation, and the placement of the header, depends whether tunnel or transport mode is used.

RouterOS supports the following authentication algorithms for AH:

  • SHA1
  • MD5

AH provides authentication, but it does not provide encryption. (Another protocol ESP is used to provide encryption). AH can be used by the recipient to ensure that the data has not been changed in transit.

As I mentioned, here are two modes available, transport mode and tunnel mode. In transport mode the authentication header is added after the original IP header of the datagram but in tunnel mode it is added after the new IP header that encapsulates the original datagram being tunneled.

Transport mode

In transport mode AH header is inserted after IP header. IP data and header is used to calculate authentication value. IP fields that might change during transit, like TTL and hop count, are set to zero values before authentication. How datagram looks in transport mode is shown in Figure 9.7.

Image9007.gif

The AH Transport Mode, the IP packet is modified only slightly to include the new AH header between the IP header and (TCP) payload.

Tunnel mode

In tunnel mode new IP headers is added in front of the original IP header. All of the original IP packet is authenticated.

Image9008.gifNew IP header includes new IP source and destination IP address between IPSec peers.


Encapsulating Security Payload (ESP)

Encapsulating Security Payload (ESP) uses shared key encryption to provide data privacy. ESP also supports its own authentication scheme like that used in AH, or can be used in conjunction with AH.

ESP packages its fields in a very different way than AS. Instead of having just a header, it divides its fields into three components:

  • ESP Header - Comes before the encrypted data and its placement depends on whether ESP is used in transport mode or tunnel mode.
  • ESP Trailer - Payload and trailer are encrypted. It contains padding that is used to align the encrypted data.
  • ESP Authentication Data - ESP’s authentication data are added at the end of IP packet and ESP header, payload, and ESP trailer are used to create the authentication data. It is computed in a manner similar to how the AH protocol works, for when ESP's optional authentication feature is used.

Transport mode

In transport mode ESP header is inserted after original IP header. ESP trailer and authentication value is added to the end of the packet. In this mode only IP payload is encrypted and authenticated, IP header is not secured.

Image9009.gif


Tunnel mode

In tunnel mode original IP packet is encapsulated within a new IP packet thus securing IP payload and IP header.

Image9010.gif

When this datagram is processed by ESP in transport mode, the ESP Header is placed between the IPv4 header and data, with the ESP Trailer and ESP Authentication Data following. In tunnel mode, the entire original IPv4 datagram is surrounded by these ESP components, rather than just the IPv4 data.


Internet Key Exchange

  • IKE is a composite of three protocols, which include the ISAKMP, Oakley and Diffie-Hallman security protocols. IKE automatically negotiates IPSec security associations (SA) and enables IPSec secure communications.
  • ISAKMP – defines the procedures and works like framework for authenticating IPSec peers, establishing Security Associations and creating, managing shared key generation.
  • Oakely Key Determination Protocol – is used to establish a shared key (new key called also as public key that generated from existing (private) key) with assigned identifiers and associated authenticated identities between two parties (IPSec peers). This key exchange process between two parties is based on Diffie-Hellman key exchange algorithm.
  • Diffie-Hellman (DH) Key Exchange Protocol – allows two parties without any previous communication of each other to share secret keying material used to generate shared secret keys across insecure connection. This key is then used for data encryption.

The Internet Key Exchange (IKE) is a protocol that provides authenticated keying material for Internet Security Association and Key Management Protocol (ISAKMP) framework. There are other key exchange schemes that work with ISAKMP, but IKE is the most widely used one. Together they provide means for authentication of hosts and automatic management of security associations (SA).

Most of the time IKE daemon is doing nothing. There are two possible situations when it is activated:

There is some traffic caught by a policy rule which needs to become encrypted or authenticated, but the policy doesn't have any SAs. The policy notifies IKE daemon about that, and IKE daemon initiates connection to remote host. IKE daemon responds to remote connection.

In both cases, peers establish connection and execute 2 phases:

  • Phase 1 - The basic purpose of IKE phase 1 is to exchange with information between IPSec peers on which basis will be introduced SAs, it includes IKE messages authentication, protection and matching SA policy parameters (like, authentication, encryptions algorithms, shared secret keys) between peers.
  • Phase 2 - The peers establish one or more IPSec security associations that will be used by IPsec to encrypt data. All SAs established by IKE daemon will have lifetime values (either limiting time, after which SA will become invalid, or amount of data that can be encrypted by this SA, or both), therefore periodically renegotiates IPSec SAs to ensure better security.


There are two lifetime values - soft and hard. When SA reaches it's soft lifetime threshold, the IKE daemon receives a notice and starts another phase 2 exchange to replace this SA with fresh one. If SA reaches hard lifetime, it is discarded. The key also is discarded when SAs is terminated. If subsequent SAs is needed, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation. A successful negotiation results in new SAs and new keys.


IPSec configuring example

To get IPsec to work with automatic keying using IKE-ISAKMP you will have to configure policy, peer and proposal (optional) entries. For manual keying you will have to configure policy and manual-sa entries.

In the next figure is illustrated network design for this example. I assume that IP addresses and routes for IP connectivity is configured on both routers.


Image9011.gif

In this example we will create the IPSec VPN between two offices. Offices are connected to Internet and Office workstations have own local subnets with private IP addresses 192.168.1.0/24 for Office1 and 192.168.2.0/24 for Office2. NAT is used on both routers for translating private IP addresses to Public.

Here can be several IPSec configuration types:

  • Tunnel mode with ESP
  • Tunnel mode with AH
  • Transport mode with ESP
  • Transport mode with AH
  • Transport mode with AH and ESP
  • Tunnel mode with AH and ESP

Tunnel mode example using ESP

Configuring IPSec Peers

Peer configuration settings are used to establish connections between IKE daemons (phase 1 configuration). This connection then will be used to negotiate keys and algorithms for SAs. We need to specify peers address and port and pre-shared-key. Other parameters are left to default values.


Office1 router (MikroTik_A):

/ip ipsec peer add address=12.0.1.11/32:500 auth-method=pre-shared-key secret="test"


Office2 router (MikroTik_B):

/ip ipsec peer add address=13.0.1.2/32:500 auth-method=pre-shared-key secret="test"


Configuring IPSec policy and proposal

It is important that proposed authentication and encryption algorithms match on both routers. In this example we will use predefined "default" proposal. Proposal defines settings that will be used to encrypt actual data in this case as authentication algorithm is allowed sha1 and as encryption algorithm can be used 3des or aes-256.

[admin@MikroTik_A] /ip ipsec proposal> print 
Flags: X - disabled 
 0   name="default" auth-algorithms=sha1 enc-algorithms=3des,aes-256 
     lifetime=30m pfs-group=modp1024



[admin@'''MikroTik_B'''] /ip ipsec proposal> print 
Flags: X - disabled 
 0   name="default" auth-algorithms=sha1 enc-algorithms=3des,aes-256 
     lifetime=30m pfs-group=modp1024

As we already have proposal as a next step we need correct IPSec policy. Policy table is needed to determine whether encryption should be applied to a packet. We want to encrypt traffic coming from 192.168.1.0/24 to 192.168.2.0/24 and vice versa.

Office1 router (MikroTik_A):

/ip ipsec policy add src-address=192.168.1.0/24:any 
dst-address=192.168.2.0/24:any sa-src-address=13.0.1.2 
sa-dst-address=12.0.1.11 tunnel=yes ipsec-protocols=esp action=encrypt proposal=default


Office2 router (MikroTik_B):


/ip ipsec policy add src-address=192.168.2.0/24:any 
dst-address=192.168.1.0/24:any sa-src-address=12.0.1.11 
sa-dst-address=13.0.1.2 tunnel=yes ipsec-protocols=esp action=encrypt proposal=default

A tunnel mode provides site to site encryption.

At this point if you will try to establish IPSec tunnel it will not work, packets will be rejected. This is because both routers have NAT rules that is changing source address after packet is encrypted. Remote router receives encrypted packet, but after decryption it discards packet because it has been changed after encryption.

To fix this we need to set up NAT bypass rule before all others rules on each router. Theses rules determine that packets transmitted between Offices are not NATed.

Office1 router (MikroTik_A):


/ip firewall nat add chain=srcnat action=accept place-before=0 \

src-address=192.168.1.0/24 dst-address=192.168.2.0/24


Office2 router (MikroTik_B):

/ip firewall nat add chain=srcnat action=accept place-before=0 \
src-address=192.168.2.0/24 dst-address=192.168.2.0/24


Transport mode example using AH


All packets are encapsulated with new header in tunnel mode, and their new IP header source address and destination address are set to sa-src-address and sa-dst-address values of this policy. If you use transport mode (set tunnel=no), then only packets whose source and destination addresses are the same as sa-src-address and sa-dst-address can be processed by this policy. Therefore, transport mode can only work with packets that originate at and are destined for IPsec peers (hosts or router that established SA). To encrypt traffic between networks (or a network and a host) you have to use tunnel mode.


Peers

Office1 router (MikroTik_A):

/ip ipsec peer add address=12.0.1.11/32:500 auth-method=pre-shared-key secret="test"

Office2 router (MikroTik_B):

/ip ipsec peer add address=13.0.1.2/32:500 auth-method=pre-shared-key secret="test"


Policy

Office1 router (MikroTik_A):

/ip ipsec policy add src-address=13.0.1.2/32:any 
dst-address=12.0.1.11/32:any sa-src-address=13.0.1.2
sa-dst-address=12.0.1.11 tunnel=yes ipsec-protocols=ah action=encrypt proposal=default

Office2 router (MikroTik_B):

/ip ipsec policy add src-address=12.0.1.11/32:any 
dst-address=13.0.1.2/32:any sa-src-address=12.0.1.11 
sa-dst-address=13.0.1.2 tunnel=yes ipsec-protocols=ah action=encrypt proposal=default