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
hash-algorithm ( multiple choice: md5 | sha ; default: md5 ) - hashing algorithm. SHA (Secure
Hash Algorithm) is stronger, but slower
lifebytes ( integer ; default: 0 ) - phase 1 lifetime: specifies how much bytes can be transferred
before SA is discarded
• 0 - SA expiration will not be due to byte count excess
lifetime ( time ; default: 1d ) - phase 1 lifetime: specifies how long the SA will be valid; SA will be
discarded after this time
proposal-check ( multiple choice: claim | exact | obey | strict ; default: strict ) - phase 2 lifetime
check logic:
• claim - take shortest of proposed and configured lifetimes and notify initiator about it
• exact - require lifetimes to be the same
• obey - accept whatever is sent by an initiator
• strict - If proposed lifetime IS longer than default then reject proposal otherwise accept
proposed lifetime
secret ( text ; default: "" ) - secret string. If it starts with '0x', it is parsed as a hexadecimal value
send-initial-contact ( yes | no ; default: yes ) - specifies whether to send initial IKE information or
wait for remote side
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 or 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 set generate-policy flag to yes only for trusted peers, because there is no verification
done for the established policy. To protect yourself against possible unwanted events, add policies
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@WiFi] ip ipsec peer>add address=10.0.0.147/32 \
\... secret=gwejimezyfopmekun
[admin@WiFi] 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=obey
hash-algorithm=md5 enc-algorithm=3des dh-group=modp1024 lifetime=1d
lifebytes=0
Page 309 of 695
Copyright 1999-2007, MikroTik. All rights reserved. Mikrotik, RouterOS and RouterBOARD are trademarks of Mikrotikls SIA.
Other trademarks and registred trademarks mentioned herein are properties of their respective owners.
To Next Page
Loading...
General