IPsec

Document revision 1.5 (17-Jun-2003)
This document applies to MikroTik RouterOS v2.7

Table of Contents

Summary

Specifications

Packages required : security
License required : Any
Home menu level : /ip ipsec
Protocols utilized : IPsec (RFC2401)
Hardware usage: consumes a lot of CPU time (Intel Pentium MMX or AMD K6 suggested as minimal configuration)

Related Documents

Software Package Installation and Upgrading
IP Addresses and Address Resolution Protocol (ARP)
Firewall Filters and Network Address Translation (NAT)

Description

IPsec (IP Security) supports secure (encrypted) communications over IP networks.

Encryption

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) is a list of rules that have two parts:
  • Packet matching: Packet source/destination, protocol and ports (for TCP and UDP) are compared to values in policy rules, one after another
  • Action: If rule matches action specified in rule is performed:

    Each SPD rule can be associated with several Security Associations (SA) that determine packet encryption parameters (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:

  • use - if there is no valid SA, send packet unencrypted (like accept rule)
  • acquire - send packet unencrypted, but ask IKE daemon to establish new SA
  • 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).

    Decryption

    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 before forward and input firewall chains, packet that was not decrypted on local host is compared with SPD reversing its matching rules. If SPD requires encryption (there is valid SA associated with matching SPD rule), packet is dropped. This is called incoming policy check.

    Internet Key Exchange

    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:

  • Some traffic is caught by policy that needs to provide encryption or authentication, but doesn't have any SAs. It 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 - peers agree on algorithms they will use in following IKE messages, authenticate. Also, keying material (used to derive keys for all SAs and to protect following ISAKMP exchanges between hosts) is generated.
  • Phase 2 - peers establish one or several SAs 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).

    There are two lifetime values - soft and hard. When SA reaches it's soft lifetime, IKE daemon receives notice about it and starts another phase 2 exchange to replace this SA with fresh one. If SA reaches hard lifetime, it is discarded.

    Perfect Forward Secrecy (PFS) that can optionally be provided by IKE is a property of key exchanges, which for IKE means that compromising the long term phase 1 key will not allow to easily gain access to all IPsec data that is protected by SAs established through this phase 1. It means an additional keying material is generated for each phase 2.

    Generation of keying material is computationally very expensive. Use of modp8192 group can take several seconds even on very fast computer. It usually takes place once per phase 1 exchange, which happens only once between any host pair and then is kept for long time. PFS adds this expensive operation also to each phase 2 exchange.

    Diffie-Hellman MODP Groups

    Diffie-Hellman (DH) key exchange protocol allows two parties without any initial shared secret to create one. The following Modular Exponential (MODP) Diffie-Hellman (also known as "Oakley") Groups are supported:
    Diffie-Hellman Group Modulus Reference
    Group 1 768 bits RFC2409
    Group 2 1024 bits RFC2409
    Group 5 1536 bits RFC3526
    Group 14 2048 bits RFC3526
    Group 15 3072 bits RFC3526
    Group 16 4096 bits RFC3526
    Group 18 8192 bits RFC3526

    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.

    Setup Steps

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

    Policy Settings

    Submenu level :/ip ipsec policy

    Description

    Policy table is needed to determine if encryption should be applied to a packet.

    Property Description

    src-address (IP address/mask:ports; default: 0.0.0.0/32:any) - source IP address
    dst-address (IP address/mask:ports; default: 0.0.0.0/32:any) - destination IP address
    protocol (name | integer; default: all) - name or number of protocol
    action (accept | drop | encrypt; default: accept) - what to do with packet that matches policy:
  • accept - pass the packet
  • drop - drop the packet
  • encrypt - apply transormations specified by this policy and it's security
    level (acquire | require | use; default: require) - what to do if some of the 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
    ipsec-protocols (multiple choice: ah , esp; default: 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 tunnel mode and AH - in transport mode
    tunnel (yes | no; default: no) - whether to use tunnel mode
    sa-src-address (IP address; default: 0.0.0.0) - SA source
    sa-dst-address (IP address; default: 0.0.0.0) - SA destination
    proposal (name; default: default) - name of proposal info that will be sent by IKE daemon to establish SAs for this policy
    manual-sa (name; default: none) - name of manual-sa template that will be used to create SAs for this policy
  • none if you don't want to set up any manual keys
    dont-fragment (clear | inherit | set; default: clear)- The state of the Don't Fragment IP header field:
  • clear - clear (unset) the fiels, so that packets previously marked as Don't Fragment, got fragmented
  • inherit - do not change the field
  • set - set the fiels, so that each packet matching the rule, will not be fragmented

    Statistics:

    ph2-state (string) - progress of key establishing:

  • expired - there are some leftovers from previous phase2, it is similar to no-phase2
  • no-phase2 - nothing has happened
  • established - SAs are in place and everything should be working
    Anything else falls between these last two states
    in-accepted (integer) - how many incoming packets were passed through by policy without attempting decryption
    in-dropped (integer) - how many incoming packets were dropped by policy without attempting decryption
    out-accepted (integer) - how many outgoing packets were passed through by policy without encryption
    out-dropped (integer) - how many outgoing packets were dropped by policy without attempting encryption
    encrypted (integer) - how many outgoing packets were encrypted and passed on successfully
    not-encrypted (integer) - how many outgoing packets policy attempted to encrypt, but discarded for any reason
    decrypted (integer) - how many incoming packets policy decrypted and passed on successfully
    not-decrypted (integer) - how many incoming packets policy tried to decrypt, but discarded for any reason

    Notes

    In tunnel mode all packets are IPIP encapsulated, 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.

    It is good to have dont-fragment cleared because encrypted packets are always bigger than original and thus they may need fragmentation.

    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.

    Example

    To add policy to encrypt all the traffic between us (10.0.0.147) and 10.0.0.148 host: 
    [admin@MikroTik] ip ipsec policy> add sa-src-address=10.0.0.147 \
\... sa-dst-address=10.0.0.148 action=encrypt
[admin@MikroTik] ip ipsec policy> print
Flags: X - disabled, I - invalid
  0   src-address=10.0.0.147/32:any dst-address=10.0.0.148/32:any
      protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=no
      sa-src-address=10.0.0.147 sa-dst-address=10.0.0.148 proposal=default
      manual-sa=none dont-fragment=clear


[admin@MikroTik] ip ipsec policy>
    To view the policy statistics: 
    [admin@MikroTik] ip ipsec policy> print stats
Flags: X - disabled, I - invalid
  0   src-address=10.0.0.147/32:any dst-address=10.0.0.148/32:any
      protocol=all ph2-state=no-phase2 in-accepted=0 in-dropped=0
      out-accepted=0 out-dropped=0 encrypted=0 not-encrypted=0 decrypted=0
      not-decrypted=0


[admin@MikroTik] ip ipsec policy>

    Peer

    Submenu level : /ip ipsec peer

    Description

    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.

    Property Description

    address (IP address/mask:port; default: 0.0.0.0/32:500) - address prefix. If remote peer's address matches this prefix, then this peer configuration is used while authenticating and establishing phase 1. If several peer's address matches several configuration entries, the most specific one (i.e. the one with largest netmask) will be used
    secret (string; default: "") - secret string. If it starts with '0x', it is parsed as a hexadecimal value
    generate-policy (yes | no; default: no) - allow this peer to establish SA for non-existing policies. Such policies are created dynamically for the lifetime of SA. This way it is possible, for example, to create IPsec secured l2tp tunnels, or any other setup where remote peer's IP address is not known at configuration time
    exchange-mode (main | aggressive | base; default: main) - see RFC 2408 for an overview of ISAKMP phase 1 exchange modes. Currently only main mode is tested
    send-initial-contact (yes | no; default: yes) - yes
    proposal-check (claim | exact | obey | strict; default: strict) - phase 2 lifetime check logic:
  • 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
    hash-algorithm (md5 | sha; default: md5) - hashing algorithm. SHA (Secure Hash Algorithm) is stronger, but slower
    enc-algorithm (des | 3des | aes-128 | aes-192 | aes-256; default: 3des) - encryption algorithm. Algorithms are named in strength increasing order
    dh-group (modp768 | modp1024 | modp1536 | modp2048 | modp3072 | modp4096 | modp8192; default: modp1024) - Diffie-Hellman MODP group (cipher strength). First three allowed strengths (768, 1024 and 1536) are standard, others might be incompatible with similarly named groups in other implementations
    lifetime (integer; default: 1d) - phase 1 lifetime: how long the SA is valid; it is discarded after this time
    lifebytes (integer; default: 0) - phase 1 lifetime: how much bytes can be transferred before SA is discarded
  • 0 - SA won't expire based on byte count

    Notes

    AES (Advanced Encryption Standard) encryption algorithms are much faster than DES, so it is recommended to use this algorithm class whenever possible. But, AES's speed is also its drawback as it potentially can be cracked faster, so use AES-256 when you need security and AES-128 when speed is also important.

    Both peers MUST have the same encryption and authentication algorithms, DH group and exchange mode. Some legacy hardware may support only DES and MD5.

    You should only set generate-policy flag to yes for trusted peers, because there is no verification done for the established policy. To protect yourself against possible unwanted events, add poilcies with action=accept for all networks you don't want to be encrypted at the top of policy list. Since dynamic policies are added at the bottom of the list, they will not be able to override your configuration.

    Example

    To define new peer configuration for 10.0.0.147 peer with secret = gwejimezyfopmekun: 
    [admin@MikroTik] ip ipsec peer> add address=10.0.0.147/32 secret=gwejimezyfopmekun
[admin@MikroTik] ip ipsec peer> print
Flags: X - disabled
  0   address=10.0.0.147/32:500 secret="gwejimezyfopmekun" generate-policy=no
      exchange-mode=main send-initial-contact=yes proposal-check=strict
      hash-algorithm=md5 enc-algorithm=3des dh-group=modp1024 lifetime=1d
      lifebytes=0


[admin@MikroTik] ip ipsec peer>

    Remote Peer Statistics

    Submenu level : /ip ipsec remote-peers

    Description

    You can see various statistics about remote peers that curently have phase 1 established with this router. Note that if peer doesn't show up here, it doesn't mean that no IPsec traffic is being exchanged with it. For example, manual SA configurations will not show up here.

    Property Description

    Statistics:

    local-address (IP address) - local ISAKMP SA address
    remote-address (IP address) - remote address of the peer
    state (string) - state of phase 1 negotiation with this peer

  • established is the normal working state
    side (initiator | responder) - who spoke first:
  • initiator - phase 1 negotiation was started by this router
  • responder - phase 1 negotiation was started by peer
    established (sting) - data and time when phase 1 was established with this peer
    ph2-active (integer) - how many phase 2 negotiations with this peer are currently taking place
    ph2-total (integer) - how many phase 2 negotiations with this peer took place

    Example

    To see currently established SA: 
    [admin@MikroTik] ip ipsec> remote-peers print
  0 local-address=10.0.0.148 remote-address=10.0.0.147 state=established
    side=initiator established=jan/25/2003 03:34:45 ph2-active=0 ph2-total=1


[admin@MikroTik] ip ipsec>

    Manual SA

    Submenu level : ip ipsec manual-sa

    Property Description

    name (name; default: sa1) - name of item for reference from policies
    ah-algorithm (null | md5 | sha1; default: null) - Authentication Header encryption algorithm, one of the following:
  • md5 - 128 bit key
  • null - any key length
  • sha1 - 160 bit key
    esp-auth-algorithm (null | md5 | sha1; default: null) - Encapsulating Security Payload authentication encryption algorithm, one of the following:
  • md5 - 128 bit key
  • null - any key length
  • sha1 - 160 bit key
    esp-enc-algorithm (null | des | 3des | aes-128 | aes-192 | aes-256; default: null) - Encapsulating Security Payload encryption algorithm, one of the following:
    ah-key (string; default: "") - incoming-authentication-key/outgoing-authentication-key (even-length hexadecimal string)
    esp-auth-key (string; default: "") - incoming-authentication-key/outgoing-authentication-key (even-length hexadecimal string)
    esp-enc-key (string; default: "") - incoming-encryption-key/outgoing-encryption-key (even-length hexadecimal string)
    ah-spi (integer > 255; default: 0x100) - incoming-SA-SPI/outgoing-SA-SPI, in hexadecimal. May be equal - in this case only one SPI number is printed
    esp-spi (integer > 255; default: 0x100) - incoming-SA-SPI/outgoing-SA-SPI, in hexadecimal. May be equal - in this case only one SPI number is printed

    Notes

    Note 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.

    Example

    To add manual-sa entry and specify its incomming AH key is A0 and outgoing AH key is 0A: 
    [admin@MikroTik] ip ipsec manual-sa> add ah-key=A0/0A
[admin@MikroTik] ip ipsec manual-sa> print
Flags: X - disabled, I - invalid
  0   name="sa1" ah-algorithm=null esp-auth-algorithm=null
      esp-enc-algorithm=null ah-key=A0/0A esp-auth-key="" esp-enc-key=""
      ah-spi=100 esp-spi=100


[admin@MikroTik] ip ipsec manual-sa>

    Proposal

    Submenu level : /ip ipsec proposal

    Description

    Proposal is used to set which algorithms may be used on the actual traffic (phase 2 configuration). It also defines if PFS should be used.

    Property Description

    name (name; default: proposal1) - name of proposal for referencing it from policy
    auth-algorithms (multiple choice: md5, sha1, null; default: sha1) - allowed algorithms for authorization:
  • md5 - 128 bit key
  • null - any key length
  • sha1 - 160 bit key
    enc-algorithms (multiple choice:des, 3des, aes-128, aes-192, aes-256, null; default: 3des) - allowed algorithms and key lengths to use for SAs that will be acquired from IKE daemon by policy that references this proposal
    lifetime (time) - how long to use SA before throwing it out
    lifebytes (integer; default: 0) - how many bytes to encrypt using SA before throwing it out and making new one
  • 0 - SA won't expire based on byte count
    pfs-group (none | modp768 | modp1024 | modp1536 | modp2048 | modp3072 | modp4096 | modp8192; default: modp1024) - Diffie-Hellman MODP group (cipher strength) for PFS. First four allowed strengths (none, 768, 1024 and 1536) are standard, others might be incompatible with similarly named groups in other implementations
  • none - PFS will not be used

    Notes

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

    There is the default proposal already.

    Example

    To set the default proposal to use DES and AES-128 encryption algorithms: 
    [admin@MikroTik] ip ipsec proposal> set default enc-algorithms=des,aes-128
[admin@MikroTik] ip ipsec proposal> print
Flags: X - disabled
  0   name="default" auth-algorithms=sha1 enc-algorithms=des,aes-128
      lifetime=30m lifebytes=0 pfs-group=modp1024


[admin@MikroTik] ip ipsec proposal>

    Installed SA

    Submenu level : /ip ipsec installed-sa

    Description

    Prints a lot of information about each installed SA (including keys)

    Property Description

    Statistics:

    spi (integer) - SPI value of SA, in hexadecimal
    direction (in | out) - SA direction
    src-address (IP address) - source of SA from policy configuration
    dst-address (IP address) - destination of SA from policy configuration
    auth-algorithm (none | md5 | sha1) - authentication algorithm
    enc-algorithm (none | des | 3des | aes) - encryption algorithm
    replay (integer) - size of replay window, in bytes
    state (larval | mature | dying | dead) - period of SA's life
    auth-key (string) - authentication key, as hex string
    enc-key (string) - encryption key, as hex string (only used by ESP SAs)
    add-lifetime (time/time) - soft/hard expiration time counted from installation of SA
    use-lifetime (time/time) - soft/hard expiration time counter from the first use of SA
    lifebytes integer/integer) - soft/hard expiration threshold for amount of processed data
    current-addtime (string) - time when this SA was installed
    current-usetime (string) - time when this SA was first used
    current-bytes (integer) - amount of data processed by this SA's crypto algorithms

    Example

    [admin@MikroTik] ip ipsec> installed-sa print
Flags: A - AH, E - ESP, P - pfs, M - manual
  0 E   spi=E727605 direction=in src-address=10.0.0.148
        dst-address=10.0.0.147 auth-algorithm=sha1 enc-algorithm=3des
        replay=4 state=mature
        auth-key="ecc5f4aee1b297739ec88e324d7cfb8594aa6c35"
        enc-key="d6943b8ea582582e449bde085c9471ab0b209783c9eb4bbd"
        add-lifetime=24m/30m use-lifetime=0s/0s lifebytes=0/0
        current-addtime=jan/28/2003 20:55:12
        current-usetime=jan/28/2003 20:55:23 current-bytes=128

  1 E   spi=E15CEE06 direction=out src-address=10.0.0.147
        dst-address=10.0.0.148 auth-algorithm=sha1 enc-algorithm=3des
        replay=4 state=mature
        auth-key="8ac9dc7ecebfed9cd1030ae3b07b32e8e5cb98af"
        enc-key="8a8073a7afd0f74518c10438a0023e64cc660ed69845ca3c"
        add-lifetime=24m/30m use-lifetime=0s/0s lifebytes=0/0
        current-addtime=jan/28/2003 20:55:12
        current-usetime=jan/28/2003 20:55:12 current-bytes=512


[admin@MikroTik] ip ipsec>

    Flushing Installed SA table

    Command name : /ip ipsec installed-sa flush

    Description

    In some cases when incorrect/incomplete negotiations took place, it is required to manually flush the installed SA table so that SA could be renegotiated.

    Property Description

    sa-type (ah | all | esp; default: all) - which SA types to flush:
  • ah - delete AH protocol SAs only
  • esp - delete ESP protocol SAs only
  • all - delete SAs of both AH and ESP protocols

    Example

    To flush all the SAs installed: 
    [admin@MikroTik] ip ipsec installed-sa> flush
[admin@MikroTik] ip ipsec installed-sa> print

[admin@MikroTik] ip ipsec installed-sa>

    Counters

    Submenu level : /ip ipsec counters

    Property Description

    Statistics:

    out-accept (integer) - how many outgoing packets were matched by accept policy (including the default "accept all" case)
    out-accept-isakmp (integer) - how many locally originated UDP packets on source port 500 (which is how ISAKMP packets look) were let through without policy matching
    out-drop (integer) - how many outgoing packets were matched by drop policy (or encrypt policy with level=require that doesn't have all SAs)
    out-encrypt (integer) - how many outgoing packets were encrypted successfully
    in-accept (integer) - how many incoming packets were matched by accept policy
    in-accept-isakmp (integer) - how many incoming UDP packets on port 500 were let through without policy matching
    in-drop (integer) - how many incoming packets matched drop policy (or encrypt policy with level=require that didn't have all SAs)
    in-decrypted (integer) - how many incoming packets were successfully decrypted
    in-drop-encrypted-expected (integer) - how many incoming packets were matched by encrypt policy and dropped because they were not encrypted

    Example

    To view current statistics: 
    [admin@MikroTik] ip ipsec> counters print
                    out-accept: 6
             out-accept-isakmp: 0
                      out-drop: 0
                   out-encrypt: 7
                     in-accept: 12
              in-accept-isakmp: 0
                       in-drop: 0
                  in-decrypted: 7
    in-drop-encrypted-expected: 0
[admin@MikroTik] ip ipsec>

    Application examples

    IPsec setup between two RourerOS routers

    MT-to-MT

    Minimal config example for transport mode ESP with automatic keying on Router 1: 

    ip ipsec policy add sa-src=1.0.0.1 sa-dst=1.0.0.2 action=encrypt
ip ipsec peer add address=1.0.0.2 secret="roberkenon"
    And for Router 2: 
    ip ipsec policy add sa-src=1.0.0.2 sa-dst=1.0.0.1 action=encrypt
ip ipsec peer add address=1.0.0.1 secret="roberkenon"
    Minimal config example for transport mode ESP with automatic keying and automatic policy generating on Router 1: 
    ip ipsec peer add address=1.0.0.0/24 secret="roberkenon" generate-policy=yes
    And with static policy on Router 2: 
    ip ipsec policy add sa-src=1.0.0.2 sa-dst=1.0.0.1 action=encrypt
ip ipsec peer add address=1.0.0.1 secret="roberkenon"
    Minimal config example for tunnel mode AH with manual keying on Router 1: 
    ip ipsec manual-sa add name=ah-sa1 ah-spi=0x101/0x100 ah-key=abcfed
ip ipsec policy add src-address=10.1.0.0/24 dst-address=10.2.0.0/24 \
   action=encrypt ipsec-protocols=ah tunnel=yes sa-src=1.0.0.1 sa-dst=1.0.0.2 \
   manual-sa=ah-sa1
    And for Router 2: 
    ip ipsec manual-sa add name=ah-sa1 ah-spi=0x100/0x101 ah-key=abcfed
ip ipsec policy add src-address=10.2.0.0/24 dst-address=10.1.0.0/24 \
   action=encrypt ipsec-protocols=ah tunnel=yes sa-src=1.0.0.2 sa-dst=1.0.0.1 \
   manual-sa=ah-sa1

    IPsec Setup for Routing Between two Masquerading MikroTik Routers

    MT-to-MT

    On Router1:

  • Add accept and masquerading rules in SRC-NAT: 
    /ip firewall src-nat add src-address=10.1.0.0/24 dst-address=10.2.0.0/24
/ip firewall src-nat add out-interface=public action=masq
  • Configure IPsec: 
    /ip ipsec policy add src-address=10.1.0.0/24 dst-address=10.2.0.0/24 \
    action=encrypt tunnel=yes sa-src-address=1.0.0.1 sa-dst-address=1.0.0.2
/ip ipsec peer add address=1.0.0.2 exchange-mode=aggressive secret="sviestapika"

    On Router2:

  • Add accept and masquerading rules in SRC-NAT: 
    /ip firewall src-nat add src-address=10.2.0.0/24 dst-address=10.1.0.0/24
/ip firewall src-nat add out-interface=public action=masq
  • Configure IPsec: 
    /ip ipsec policy add src-address=10.2.0.0/24 dst-address=10.1.0.0/24 \
action=encrypt tunnel=yes sa-src-address=1.0.0.2 sa-dst-address=1.0.0.1
/ip ipsec peer add address=1.0.0.1 exchange-mode=aggressive secret="sviestapika"

    IPsec Setup Between MikroTik and CISCO Routers

    MT-to-CISCO

    Must configure IPsec encryption for traffic between 10.0.0.0/24 and 10.0.2.0/24 subnets.

    Configuring RouterOS

    Set encryption proposal (phase2 proposal - settings that will be used to encrypt actual data) to use DES to encrypt data: 
    [admin@MikroTik] ip ipsec proposal> set default enc-algorithms=des
    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 secret=test_key \
\... enc-algorithm=des
    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 action=encrypt tunnel=yes sa-src=10.0.1.1 \
\... sa-dst=10.0.1.2

    Configuring Cisco

    Parts from Cisco configuration with comments follow... 
    configure terminal

! 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 9
  encryption des
  group 2
  hash md5
  exit

! Add preshared key to be used when talking to RouterOS
crypto isakmp key mykey address 10.0.1.1 255.255.255.255

! 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
  mode tunnel                                        
  exit                                               

! 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
  set pfs group2
  match address 101
  exit

! And finally apply crypto map to serial interface:
interface Serial 0
  crypto map mymap
  exit

    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
Flags: A - AH, E - ESP, P - pfs, M - manual
  0 E   spi=9437482 direction=out src-address=10.0.1.1
        dst-address=10.0.1.2 auth-algorithm=sha1 enc-algorithm=des
        replay=4 state=mature
        auth-key="9cf2123b8b5add950e3e67b9eac79421d406aa09"
        enc-key="ffe7ec65b7a385c3" add-lifetime=24m/30m use-lifetime=0s/0s
        lifebytes=0/0 current-addtime=jul/12/2002 16:13:21
        current-usetime=jul/12/2002 16:13:21 current-bytes=71896

  1 E   spi=319317260 direction=in src-address=10.0.1.2
        dst-address=10.0.1.1 auth-algorithm=sha1 enc-algorithm=des
        replay=4 state=mature
        auth-key="7575f5624914dd312839694db2622a318030bc3b"
        enc-key="633593f809c9d6af" add-lifetime=24m/30m use-lifetime=0s/0s
        lifebytes=0/0 current-addtime=jul/12/2002 16:13:21
        current-usetime=jul/12/2002 16:13:21 current-bytes=0


[admin@MikroTik] ip ipsec installed-sa>
    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:

    IPsec setup between RouterOS router and Windows SonicWall Client

    IPSec setup of RouterOS router as a Security Gateway for SonicWALL VPN client

    MT-to-SW

    Configuring remote access of 1.1.1.0 network through 10.0.0.204 RouterOS router

    Configuring RouterOS

    1. Add peer configuration. Use Triple-DES and SHA-1 algorithms to protect phase 1 traffic. Set "proposal-check" to "obey" to allow remote client to connect even if lifetime and pfs settings in its proposal don't match ours. 
      / ip ipsec peer add address=10.0.0.81:500 exchange-mode=main \
send-initial-contact=no proposal-check=obey hash-algorithm=sha \
enc-algorithm=3des dh-group=modp1024 secret="********"
    2. Add encryption proposal. Use MD5, DES and Diffie-Hellman Group 1 for Perfect Forward Secrecy. 
      / ip ipsec proposal add name=sw-client auth-algorithms=md5 enc-algorithms=des \
lifetime=30m pfs-group=modp768
    3. Add policy rule that matches traffic between remote client and 1.1.1.0/24 network, use ESP in tunnel mode to encript all data. 
      / ip ipsec policy add src-address=1.1.1.0/24 dst-address=10.0.0.81/32 \
action=encrypt ipsec-protocols=esp tunnel=yes sa-src-address=10.0.0.204 \
sa-dst-address=10.0.0.81 proposal=sw-client

    Configuring SonicWALL

    Here you create IPSec policy that should match all traffic between 10.0.0.81 host and 1.1.1.0/24 network. You also specify the address of remote IPSec peer: 

    "Connection Security": select "Secure"
in "Remote Party Identity And Addressing" box:
  "ID Type": select "IP Subnet"
  "Subnet": enter "1.1.1.0"
  "Mask": enter "255.255.255.0"
  check "Connect using", select "Secure Gateway Tunnel"
  "ID Type": select "IP Address", enter below "10.0.0.204"

    Configure pre-shared key, select correct interface to connect to 10.0.0.204 router with the proper address 10.0.0.81:

    My Identity

    in "My Identity" box:
  "Select Certificate": select "None"
  click "Pre-Shared Key"

"Pre-Shared Key" pops up:

    Pre-Shared Key

        click "Enter Key"
    type ********, click "OK"

in "Internet Interface" box:
  "Name": select interface that is connected to 10.0.0.0/24 network
  "IP Addr": check that it shows 10.0.0.81

    Configure phase 1 setting to use same algorithms as on RouterOS side:

    Security Policy

    "Select Phase 1 Negotiation Mode": select "Main Mode"
check "Enable Perfect Forward Secrecy (PFS)"
"PFS Key Group": select "Diffie-Hellman Group 1"
clear "Enable Replay Detection"

    Authentication (Phase 1) Proposal 1 

    "Authentication Method": select "Pre-Shared Key"
in "Encryption and Data Integrity Algorithms" box:
  "Encrypt Alg": select "Triple DES"
  "Hash Alg": select "SHA-1"
  "SA Life": select "Unspecified"

"Key Group": select "Diffie-Hellman Group 2" (this is called "modp1024"
in RouterOS)

    Configure phase 2 settings:

    Key Exchange (Phase 2) Proposal 1

    in "IPSec Protocols" box:
  "SA Life": select "Seconds", enter "1800" in "Seconds" field
  "Compression": select "None"
  check "Encapsulation Protocol (ESP)"
    "Encrypt Alg": select "DES"
    "Hash Alg": select "MD5"
    "Encapsulation": select "Tunnel"
  clear "Authentication Protocol (AH)"

click "Save" (on the toolbar)

    Testing

    Try accessing some host on 1.1.1.0/24 network from 10.0.0.81 box. After some time IPSec tunnel will be established and data will start to pass through.

    On RouterOS side you can see the statistics for established SAs:

    [admin@xxx] ip ipsec installed-sa> print
Flags: A - AH, E - ESP, P - pfs, M - manual
  0 E   spi=3C3C7A8D direction=out src-address=10.0.0.204
        dst-address=10.0.0.81 auth-algorithm=md5 enc-algorithm=des replay=4
        state=mature auth-key="5697ee9fe98867005ac057e1b62a6c3b"
        enc-key="7b992840ea30b180" add-lifetime=24m/30m use-lifetime=0s/0s
        lifebytes=0/0 current-addtime=nov/26/2002 09:33:47
        current-usetime=nov/26/2002 09:33:53 current-bytes=896

  1 E   spi=A472A105 direction=in src-address=10.0.0.81
        dst-address=10.0.0.204 auth-algorithm=md5 enc-algorithm=des replay=4
        state=mature auth-key="70655b51846308f68ce964d90b5580cd"
        enc-key="a3623a16f6bef13d" add-lifetime=24m/30m use-lifetime=0s/0s
        lifebytes=0/0 current-addtime=nov/26/2002 09:33:47
        current-usetime=nov/26/2002 09:33:53 current-bytes=0

    On SonicWall side you can view logs and connection statistics by right-clicking SonicWALL tray icon and choosing apropriate options:

    Additional Resources

    How to Configure a L2TP/IPSec Connection Using Pre-shared Key Authentication

    © Copyright 1999-2003, MikroTik