First, the first phase of IPSECVPN
The first stage, known as management connection phase ISAKMP / IKE of using bidirectional data UDP port 500 is connected to the shared message IPSEC.
The first stage main mode and aggressive mode two kinds. Note! Only remote vpn and Easy vpn mode is active, the other is to negotiate with the main mode of,
let IKE peer validation at each other and determine the session key, the key exchange stage with DH, we've created after IKE SA, all subsequent consultation will be protected by encryption co-integrity checking
phase 1 among peers to help create a secure channel, so that the back of the phase 2 consultation process protected by security.
Master mode to Step 3, 6 bidirectional exchange of data packets is as follows:
1. Room peers negotiate how to secure management connections. (Using encryption to protect the set of transformations)
2. Inter-DH peer uses the shared key algorithm and a protection connection.
3. Inter-peer authentication with each other.
Active mode during the execution of:
1. exchange management strategy to protect connections, DH algorithm builds public / private key pair and authentication between peers.
2. received packets do verification, DH algorithm to the shared encryption key, and see if the connection is successfully established.
PS:. In addition to pre-shared key authentication alia authentication method defaults to the main mode.
The second stage
quick mode
negotiation of security parameters IPSEC SA used to create IPSEC SA, use AH or ESP to encrypt IP data stream
summary
of the first stage role ----- verify each other between peers with each other and negotiate IKE SA to protect the second stage IPSEC SA negotiation process
of the second phase of consultation role ------way IPSEC SA, created to protect the data stream IPS
Two, IPSecVPN connection negotiation process, packet
IPSEC negotiation is divided into two phases, the first main mode packages 6, the second stage a total of three packages. 1-4 packet is transmitted in clear text, encrypted transport packets 5-9.
For simplicity, we assume that this is an Intranet example, each host is active IPSec policy:
1. A user (on the host A) sends a message to the user B (on the host B)
2. IPSec driver on Host A IP filter checks to see whether the packet needs to be protected and what protection
3. Drivers began to notice IKE security negotiation
4. IKE on the host B receives a request security negotiation notification
5. Two hosts to establish the first phase of SA, generating a shared their "master key" Note: If the two machines in the previous communication has been established the first phase of SA, SA may direct the second stage of consultation
6. SA to build the second phase of negotiation: SA inbound and outbound SA. SA including key and SPI.
7. A IPSec driver on the host using the outbound data packets signature SA (integrity check) and / or encrypted.
8. The packet driver to submit the IP layer, the IP layer then forwards the data packet to the host B
. 9. Host network adapter driver B receives the packet and submit it to the IPSec driver.
10. IPSec driver on the host computer B uses the inbound SA check the integrity of the signature and / or decrypting data packets.
11. Driver decrypted packets submitted upper layer TCP / IP driver, then the TCP / IP driver to submit an application packet received host B.
The above is a complete workflow IPSec, though looks very complicated, but all operations are completely transparent to the user. Intermediary router or repeater only responsible for forwarding packets, if she had encountered a firewall, security router, or proxy server requires them to have IP forwarding function to ensure IPSec and IKE traffic is not rejected.
It should be noted here is that the use of IPSec protected packet can not pass through the network address decoding NAT. Because the IKE negotiation carried NAT IP address can not be changed, to address any changes will lead to an integrity check failure.
四、协商过程两个阶段包的另一种理解
第一阶段
准备工作
在前2条消息发送以前,发送者和接受者必须先计算出各自的cookie(可以防重放和DOS攻击),这些cookie用于标识每个单独的协商交换消息
cookie---RFC建议将源目IP,源目端口,本地生成的随机数,日期和时间进行散列操作.cookie成为留在IKE协商中交换信息的唯一标识, 实际上cookie是用来防止DOS攻击的，它把和其他设备建立IPSEC所需要的连接信息不是以缓存的形式保存在路由器里，而是把这些信息HASH成个 cookie值
1&2消息
消息1---发送方向对等体发送一条包含一组或多组策略提议,在策略提议中包括5元组(加密算法,散列算法,DH,认证方法,IKE SA寿命)
消息2---接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应
注意!!!发起者会将它的所有策略发送给接受者,接受者则在自己的策略中寻找与之匹配的策略(对比顺序从优先级号小的到大的)（默认策略实际就是个模版没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）
在1&2消息中报错可能出现的原因
1，peer路由不通
2，crypto iskmp key没有设置
3，一阶段的策略不匹配
3&4消息
这2条消息,用于交换DH的公开信息和随机数
两个对等体根据DH的公开信息都算出了双方相等的密植后,两个nonce连通预共享密钥生成第一个skeyID
随后便根据SKEY__ID来推算出其他几个skeyID
skeyID_d---用来协商出后续IPSEC SA加密使用的密钥的
skeyID_a---为后续的IKE消息协商以及IPSEC SA协商进行完整性检查(HMAC中的密钥)
skeyID_e---为后续的IKE消息协商以及IPSEC SA协商进行加密
5&6消息
这2条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的
为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时由于ID还没到,彼此先用HASH来彼此验证对方)
HASH认证成分－－－SKEYID_a,cookieA,cookieB，preshare_key,SA paload,转换集，策略
在5&6消息中报错可能出现的原因
1，crypto iskmp key设置错了
消息6--接受者处理过程
1,用skeyID_e对消息进行加密 2,用ID(源IP)查找出与共享密钥 3,skeyID_a和preshare-key等一堆东西一起来计算HASH 4,和收到的HASH做比较
第二阶段(3条)
phase 2的目标是协商IPSEC SA,而且只有一种模式,快速模式,快速模式的协商是受IKE SA保护的
1&2消息
消息1---发送方发送一条报文,其中包含HASH,IPSEC策略提议,NONCE和可选的DH,身份ID
HASH:是用于给接受方作完整性检查的,用于再次认证对等体(必须)HASH的成分和5－6阶段一样
IPSEC策略提议:其中包括了安全协议,SPI,散列算法,隧道模式,IPSEC SA生命周期(必须)
NONCE:用于防重放攻击,还被用作密码生成的材料,仅当启用PFS时用到
ID:描述IPSEC SA是为哪些地址,协议和端口建立的
PFS(利用DH交换,可选):用了PFS后就会在第二阶段重新DH出个数据加密KEY,这个KEY和以前IKE协商出来的KEY没有任何关系,然后由这 个新KEY来加密数据，只有到这个IPSEC SA的生命周期后,会再次DH出新的KEY,这样,安全性就提高了（普通等ipec SA过期或密钥超时时，重新生成的数据加密密钥还是根据以阶段DH出来的skeyID_d衍生出来的）（PFS启用后，数据加密部分使用的密钥就没有了衍 生的过程）
DH:重新协商IPSEC SA实使用的密钥(正常情况下IPSEC阶段使用的密钥都是由skeyID_d衍生而来,密钥之间都有一定的关系,就算IPSEC SA超时,新的KEY还是和skeyID_d有一定的关系)
在1&2消息中报错可能出现的原因
1，ipsec trasport不匹配
2，感兴趣流不对称
消息2---使用相同的消息进行相应
3消息
发送方发送第三条消息,其中包含一个HASH,其作用时确认接受方的消息以及证明发送方处于Active状态(表示发送方的第一条消息不是伪造的)