Setup guide

To add a policy to encrypt all the traffic between two hosts (10.0.0.147 and 10.0.0.148), we need do
the following:
[admin@WiFi] ip ipsec policy> add sa-src-address=10.0.0.147 \
\... sa-dst-address=10.0.0.148 action=encrypt
[admin@WiFi] ip ipsec policy> print
Flags: X - disabled, D - dynamic, 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@WiFi] ip ipsec policy>
to view the policy statistics, do the following:
[admin@WiFi] ip ipsec policy> print stats
Flags: X - disabled, D - dynamic, 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@WiFi] ip ipsec policy>
Peers
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 addresses matches several configuration entries, the most specific one (i.e. the
one with largest netmask) will be used
secret (text; default: "") - secret string. If it starts with '0x', it is parsed as a hexadecimal value
generate-pollicy (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 (multiple choice: main | aggressive | base; default: main) - different ISAKMP
phase 1 exchange modes according to RFC 2408.DO not use other modes then main unless you
know what you are doing
send-initial-contact (yes | no; default: yes) - specifies whether to send initial IKE information or
wait for remote side
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