Use the /system package print command to see the list of installed packages.
Hardware Resource Usage
To be updated.
DHCP Description
Comes soon.
How IPsec works
TX:
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).
RX:
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
locally)again.
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
check.
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:
10.1.0.0/24 ------- 1.0.0.0/24 ------- 10.2.0.0/24
-----------|1.0.0.1|---------------|1.0.0.2|-----------
------- -------
R1 R2
Policy
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=1.0.0.1/32 dst-address=1.0.0.2/32 protocol=udp
and it will match both outgoing 1.0.0.1->1.0.0.2 and incoming 1.0.0.2->1.0.0.1
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
configured.
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
daemon.
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=1.2.3.0/27 on one router and
dst-address=1.2.3.0/28 on another won't work. src values on one router must
be equal to dst values on the other one, and vice versa.
Peer
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'
Pre-shared-secret
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 1.0.0.2 gwejimezyfopmekun
and on R2:
# ADDRESS SECRET
0 1.0.0.1 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
type.
secret - secret string. If it starts with '0x', it is parsed as a hexadecimal
value.
Key
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.
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
direction.
Proposal
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.
Installed-sa
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:
10.0.0.0/24 Ethernet
|
RouterOS (IP: on eth 10.0.0.18, on sync 10.0.1.1)
|
synchronous link (to be encrypted)
|
Cisco (IP: on sync 10.0.1.2, on eth 10.0.2.254)
|
10.0.2.0/254 Ethernet
Must configure IPsec encryption for traffic between 10.0.0.0/24 and
10.0.2.0/24 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
authenticate:
[admin@MikroTik] ip ipsec proposal> add name=to_cisco pfs-group=none
algorithms=enc-des,auth-sha1
Add peer (with phase1 configuration parameters), DES and SHA1 will be used
to protect IKE traffic:
[admin@MikroTik] ip ipsec peer> add address=10.0.1.2 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
address=10.0.1.2
Add policy rule that matches traffic between subnets and requires
encryption with ESP in tunnel mode:
[admin@MikroTik] ip ipsec policy> add src-address=10.0.0.0/24
dst-address=10.0.2.0/24 protocol=all action=encrypt ipsec-protocols=esp
level=require tunnel=yes sa-src=10.0.1.1 sa-dst=10.0.1.2 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 10.0.1.1
! 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 10.0.2.0 0.0.0.255 10.0.0.0 0.0.0.255
! Create crypto map that will use transform set "myset", use peer 10.0.1.1
! 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 10.0.1.1
set transform-set myset
match address 101
! And finally apply crypto map to serial interface:
interface Serial1
crypto map mymap
Testing
-------
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=10.0.1.1 dst-address=10.0.1.2
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=10.0.1.2 dst-address=10.0.1.1
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. 10.0.1.2
local ident (addr/mask/prot/port): (10.0.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
current_peer: 10.0.1.1
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.: 10.0.1.2, remote crypto endpt.: 10.0.1.1
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:
http://www.ietf.org/rfc/rfc2131.txt?number=2401
See also RFCs 2402...2408