MikroTik RouterOS IPSec

Document revision 16-Jul-2002
This document applies to the MikroTik RouterOS V2.6


IPSec (IP Security) supports secure communications over IP networks.

Contents of the Manual

The following topics are covered in this manual:


Please download the ipsec-2.x.npk package from the MikroTik's web site, upload the package to the router and reboot.

Use the /system package print command to see the list of installed packages.

Hardware Resource Usage

To be updated.

DHCP Description

Comes soon.

IPSec Setup

How IPsec works


After packet is src-natted, but before putting it into interface queue, 
IPsec policy database is consulted to find out if packet should be 
encrypted. Security Policy Database (SPD) consists of ordered list of 
rules that have to parts - packet matching part and action part. Packet 
source/destination, protocol and ports (for TCP and UDP) are compared to 
values in policy rules, one after another. If rule matches action 
specified in rule is performed.  Actions can be "accept" - to continue 
with packet as if there was no IPsec, "drop" to drop packet or "encrypt" 
to encrypt it.

Each SPD rule can have several security associations (SA) associated with 
it. SA tells exactly how packet should be encrypted (key, algorithm, SPI).

Note that packet can only be encrypted if there is usable SA for policy 
rule. By setting SPD rule security "level" user can control what happens 
when there is no valid SA for policy rule:
level "use" - if there is no valid SA, send packet unencrypted (like 
"accept" rule);
level "acquire" - send packet unencrypted, but ask IKE daemon to establish 
new SA
level "require" - drop packet, and ask IKE daemon to establish new SA.

If packet can be encrypted, it is encrypted and sent as LOCALLY 
ORIGINATED packet - i.e. it is processed with "output" firewall, src-nat 
again and IPsec SPD again (this way one packet can be encrypted several 
times if encrypted packet has to be sent over encrypted tunnel itself). If 
packet matches the same SPD rule that it matched before, it is sent out 
without encrypting (to avoid encryption loops).


When encrypted packet is received for local host (after dst-nat and
"input" filter", appropriate SA to decrypt it is looked up (using packet
source, destination, security protocol and SPI value). If no SA is found,
packet is dropped. If SA is found, packet is decrypted. Then decrypted
packets fields are compared to policy rule that SA is linked to. If packet
does not match policy rule it is dropped. If packet is decrypted fine (or 
authenticated fine) it is "received once more" - it goes through dst-nat 
and routing (which finds out what to do - either forward or deliver 

Note that right before "forwarding" and "input" firewall chains, packet
that was not decrypted on local host is compared against SPD to see if it
did not have to be encrypted. Note that to do this check, matching values
from SPD rule are reversed. If it had to be encrypted (there is valid SA
associated with matching SPD rule), packet is dropped. This is called
incoming policy check.

IKE traffic

To avoid problems with IKE packets hit some SPD rule and require to 
encrypt it with not yet established SA (that this packet perhaps is trying 
to establish), locally originated packets with UDP source port 500 are not 
processed with SPD. The same way packets with UDP destination port 500 
that are to be delivered locally are not processed in incoming policy 

Configuring IPsec

  What configuration can be found under /ip ipsec: 

policy - set up security policies
installed-sa - look at currently installed security associations
manual-sa - templates for manual security associations
peer - IKE peer configuration
pre-shared-secret - to authenticate with IKE peers
key - keys for manual security associations
proposal - phase2 IKE proposal settings

  To get IPsec to work with automatic keying you will have to configure
policy, peer, pre-shared-secret and proposal entries. For manual keying you
will have to configure policy, manual-sa and key entries.

  Examples below assume following setup: -------   -------
            -------                 -------
              R1                       R2


src-address - A.B.C.D/M:P
dst-address - A.B.C.D/M:P
protocol - name or number of protocol
  These three settings form the matching part of policy. You allways configure
them to match outgoing packets. If you want to encrypt all UDP packets that
are sent from R1 to R2 you add to R1 policy:
  src-address= dst-address= protocol=udp
and it will match both outgoing> and incoming>
udp packets on R1.

action - What to do with packet that matches policy. Choices are:
  accept - pass the packet. This is default action when no policies are
  drop - drop the packet.
  encrypt - apply transormations specified by this policy and it's security
            associations (see below)

dont-fragment - default value works OK.
  This setting says what value DF bit will have in packet after encryption.
  It is good to have DF cleared so that encrypted packets that always are
  bigger than original packets can be fragmented if needed.

tunnel - 'yes' if you want to use tunnel mode. In tunnel mode all packets are
  IPIP encasulated, and their new IP header src and dst are set to sa-src and
  sa-dst values of this policy. If you don't use tunnel mode (i.e. you use
  transport mode), then only packets whose source and destination is the same
  as sa-src and sa-dst can be processed by this policy. Transport mode
  can only work with packets that originate at and are destined for IPsec
  peers (hosts that established security associations). To encrypt traffic
  between networks (or network and host) you have to use tunnel mode.

ipsec-protocols - One of "ah", "esp", "ah,esp". Specifies what combination of
  Authentication Header and Encapsulating Security Payload protocols you want
  to apply to matched traffic. AH is applied after ESP, and in case of tunnel
  mode ESP will be applied in tunel mode and AH - in transport mode.

level - What to do if some of the required SAs for this policy cannot be found:
  use - skip this transform, don't drop packet, don't acquire SA from IKE
  acquire - skip this transform, but acquire SA for it from IKE daemon.
  require - drop packet, acquire SA.

sa-src - SA source
sa-dst - SA destination
  These two fields are used by SA to construct header for encrypted package.
manual-sa - Name of manual-sa template that will be used to create SAs for
  this policy, or 'none' if you don't want to set up any manual keys.
proposal - Name of proposal info that will be sent by IKE daemon to
  establish SAs for this policy.

  If you are using IKE to establish SAs automatically, then policies on both
routers must be exactly matching, i.e. src-address= on one router and
dst-address= on another won't work. src values on one router must
be equal to dst values on the other one, and vice versa.


  There you configure settings that will be used to establish connections
between IKE daemons (phase1 configuration). This connection then will be used
to negotiate keys and algorithms for SAs. These parameters won't affect the
established SAs in any way.

address - address of remote 
auth-method - currenty only 'pre-shared-secret' supported
dh-group - choose 'modp1024', EC are not expected to work, others may fail.
enc-algorithm - leave it at '3des'.
exchange-mode - 'main', 'aggressive' or 'base'. See RFC 2408 for a nice
                overview of ISAKMP phase 1 exchange modes. Currently only main
                mode is tested.
hash-algorithm - 'md5' or 'sha'
nonce-size - 8...256 bytes. Default 16 is OK.
proposal-check - Lifetime check logic. This is for phase 2 lifetimes (note that
                 you cannot configure lifetimes for phase 1 proposals yet).
                 One of:
  claim - take shortest of proposed and configured lifetimes, notify initiator
          about it.
  exact - lifetimes must be the same.
  obey - accept whatever is sent by initiator.
  strict - If initiator proposes longer lifetime than default, reject proposal,
           otherwise accept proposed lifetimes. The default. Works well.
           Don't change it.
send-initial-contact - 'yes'


  For IKE peers to know each other they must have same pre-shared-secret
configured on them. It's kind of like passwords. For R1 and R2 it would be
like, on R1:
  #   ADDRESS         SECRET                                                  
  0         gwejimezyfopmekun
and on R2:
  #   ADDRESS         SECRET                                                  
  0         gwejimezyfopmekun

address - address of remote peer.
ident-string - identity string of remote peer.
  Secret is matched by either one, but is sent using only address identity
secret - secret string. If it starts with '0x', it is parsed as a hexadecimal


  Keys are kept separately only to spare you some typing. They are part of
manual-sa configuration.

algorithm - one of the following:
  3des - 192 bit key.
  aes - 128, 192 or 256 bit key.
  des - 64 bit key.
  md5 - 128 bit key.
  null - any key length.
  sha1 - 160 bit key.
length - length of key in bits. Must be valid value for chosen algorithm.
key - hexadecimal value of key (without leading '0x'). It might have more bits
      that specified in 'length' - it will be truncated.
name - name of this key, used to reference it from manual-sa.


ah-key - incoming-authentication-key/outgoing-authentication-key
ah-spi - incoming-SA-SPI/outgoing-SA-SPI
esp-auth-key - incoming-authentication-key/outgoing-authentication-key
esp-enc-key - incoming-encryption-key/outgoing-encryption-key
esp-spi - incoming-SA-SPI/outgoing-SA-SPI
name - name of item for reference from policies.

  Example setup(assuming they both have the same key configuration),
on R1:
  1   name="sa1" ah-key=auth-key1 esp-enc-key=enc-key1/enc-key2
      esp-auth-key=none ah-spi=256/257 esp-spi=258/259 

on R2:
  1   name="sa1" ah-key=auth-key1 esp-enc-key=enc-key2/enc-key1
      esp-auth-key=none ah-spi=257/256 esp-spi=259/258 

  Notice that incoming SPI numbers on one router must match outgoing SPI
numbers on another, and vice versa. Same for keys.
  You can reference same manual-sa template from several policies, because
actual SAs are inserted based on info in policies (AH, ESP) as well as in
this template, as well as in key config. Also, each SA is distinguished by
its source (sa-src), destination (sa-dst), protocol (AH or ESP), SPI and


algorithms - comma seprarated string of followings:
  enc-null, enc-des, enc-3des, enc-aes-128, enc-aes-192, enc-aes-256,
  auth-md5, auth-sha1, auth-null.
  It specifies what algorithms and key lengths to use for SAs that will be
acquired from IKE daemon by policy that references this proposal. It is wise
to specify one enc- and one auth- value.
lifebyte - how many bytes to encrypt using SA before throwing it out and making
  new one. 0 means SA won't expire based on byte count. Default.
lifetime - how long to use SA before throwing it out. See also proposal-check
           in peer config.
name - name of proposal for referencing it from policy.
pfs-group - Diffie-Helman group used for Perfect Forward Secrecy. Untested.
            Ignore this parameter for now.

  Proposals on both peers must (at least partially) match. The more they match
the better.

  Prints a lot of pretty numbers about each installed SA. Including keys.

IPSec Setup Between MikroTik and CISCO Routers

Example of configuring IPsec between RouterOS and Cisco

Network setup: Ethernet
RouterOS (IP: on eth, on sync
synchronous link (to be encrypted)
Cisco (IP: on sync, on eth
      | Ethernet

Must configure IPsec encryption for traffic between and subnets.

Configuring RouterOS

Add encryption proposal (phase2 proposal - settings that will be used to
encrypt actual data), we will use DES to encrypt data and SHA1 to

[admin@MikroTik] ip ipsec proposal> add name=to_cisco pfs-group=none 

Add peer (with phase1 configuration parameters), DES and SHA1 will be used 
to protect IKE traffic:

[admin@MikroTik] ip ipsec peer> add address= enc-algorithm=des 
auth-method=pre-shared-key hash-algorithm=sha dh-group=modp1024

Add preshared secret to use when talking to Cisco:

[admin@MikroTik] ip ipsec pre-shared-secret> add secret=test_key 

Add policy rule that matches traffic between subnets and requires 
encryption with ESP in tunnel mode:

[admin@MikroTik] ip ipsec policy> add src-address= 
dst-address= protocol=all action=encrypt ipsec-protocols=esp 
level=require tunnel=yes sa-src= sa-dst= proposal=to_cisco

Configuring Cisco:

Parts from Cisco configuration with comments follow...

! Configure ISAKMP policy (phase1 config, must match configuration 
! of "/ip ipsec peer" on RouterOS). Note that DES is default (and only)
! encryption algorithm on this Cisco. SHA1 is default authentication
! algorithm
crypto isakmp policy 10
 authentication pre-share
 group 2

! Add preshared key to be used when talking to RouterOS
crypto isakmp key test_key address       

! Create IPsec transform set - transformations that should be applied to
! traffic - ESP encryption with DES and ESP authentication with SHA1
! This must match "/ip ipsec proposal"
crypto ipsec transform-set myset esp-des esp-sha-hmac

! Create access list that matches traffic that should be encrypted
access-list 101 permit ip

! Create crypto map that will use transform set "myset", use peer
! to establish SAs and encapsulate traffic and use access-list 101 to
! match traffic that should be encrypted
crypto map mymap 10 ipsec-isakmp   
 set peer
 set transform-set myset 
 match address 101

! And finally apply crypto map to serial interface:
interface Serial1
 crypto map mymap


After this simply ping from some host in one network to some host in other 
network - after some time (~10sec) replies should start coming back 
because SAs are established and data is being encrypted.

On RouterOS we can see installed SAs:

[admin@MikroTik] > ip ipsec installed-sa print 
  0 spi=9437482 replay=4 state=mature auth-algorithm=sha1hmac 
    enc-algorithm=descbc flags="" src-address= dst-address= 
    policy-id=1 xform-index=0 auth-key-length=160 
    auth-key="9cf2123b8b5add950e3e67b9eac79421d406aa09" enc-key-length=64 
    enc-key="ffe7ec65b7a385c3" sa-type=esp direction=out 
    current-addtime=jul/12/2002 16:13:21 current-usetime=jul/12/2002 16:13:21 
    current-bytes=71896 add-lifetime=24m/30m use-lifetime=0s/0s lifebytes=0/0 

  1 spi=319317260 replay=4 state=mature auth-algorithm=sha1hmac 
    enc-algorithm=descbc flags="" src-address= dst-address= 
    policy-id=1 xform-index=0 auth-key-length=160 
    auth-key="7575f5624914dd312839694db2622a318030bc3b" enc-key-length=64 
    enc-key="633593f809c9d6af" sa-type=esp direction=in 
    current-addtime=jul/12/2002 16:13:21 current-usetime=jul/12/2002 16:13:21 
    current-bytes=0 add-lifetime=24m/30m use-lifetime=0s/0s lifebytes=0/0 

And on Cisco:
interface: Serial1
    Crypto map tag: mymap, local addr.

   local  ident (addr/mask/prot/port): (
   remote ident (addr/mask/prot/port): (
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 1810, #pkts encrypt: 1810, #pkts digest 1810
    #pkts decaps: 1861, #pkts decrypt: 1861, #pkts verify 1861
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.:, remote crypto endpt.:
     path mtu 1500, media mtu 1500
     current outbound spi: 1308650C

     inbound esp sas:
      spi: 0x90012A(9437482)
        transform: esp-des esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: mymap
        sa timing: remaining key lifetime (k/sec): (4607891/1034)
        IV size: 8 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x1308650C(319317260)
        transform: esp-des esp-sha-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: mymap
        sa timing: remaining key lifetime (k/sec): (4607893/1034)
        IV size: 8 bytes
        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:

Additional IPSec Resources

Links for IPSec documentation:

See also RFCs 2402...2408

Copyright 1999-2002, MikroTik