GRE over IPsec & IPsec over GRE
IPSec -Over-GRE是先ipsec后gre，这种我没用过。
GRE -Over-IPSec 是先gre后ipsec，也就是说ipsec是最后的承载方式。一般常用的就是这种，解决了ipsec不支持多播的问题。
另外在mtu上也有一些相关，gre是先分段后封装，而ipsec则是先封装再分段。
个人理解。
IPsec over GRE 和GRE over IPsec在配置上的区别：
GRE over IPsec IPsec over GRE
ACL定义： GRE数据流 内网数据流
IKE Peer中指定的remote-address 对方公网地址 对方GRE Tunnel地址
应用端口： 公网出口 GRE Tunnel上
GRE over IPSEC(传输模式)
IPSEC封装GRE
好处：可以利用GRE封装组播或广播了以及非IP流量，因为如果不使用GRE的话，IPSEC是传不了组播或广播IP流量的
IPSEC over GRE(里外)(tunel模式)
IPSEC over GRE:GRE在IPSEC外面,由GRE来封装IPSEC注意!!!IPSEC over GRE的时候,路由协议流量是明文的
注意!!!当指的peer是对等体物理接口地址的时候不是IPSEC over GRE,只有当peer是对等体的lookback是才是真正的IPSEC over GRE
Cisco Tunnel Over IPSec例子
R1 (s1/0)----------------------------------------------S1/0(R2)
200.1.1.1 200.1.1.2
由于IPSEC隧道不能承载路由协议.所以对×××的扩展性造成了很大的影响.
GRE能够封装路由协议,但是单纯的password不能解决在公网上面安全性的问题.所以如果把GRE和IPSEC完美的结合起来,不仅可以解决××× 扩展性的问题,同时也能解决安全性的目的.一下的例子是完全按照小弟的一个案子模拟出来的.有什么不妥的地方希望大家指正批评.
R1配置:
sh run
Building configuration...
Current configuration : 1466 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R1
!
!
ip subnet-zero
!
!
no ip domain-lookup
!
ip audit notify log
ip audit po max-events 100
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 200.1.1.2
!
!
crypto ipsec transform-set cisco ah-sha-hmac esp-3des
!
crypto map vpn local-address Serial1/0
crypto map vpn 10 ipsec-isakmp
set peer 200.1.1.2
set transform-set cisco
match address 100
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
tunnel source Serial1/0
tunnel destination 200.1.1.2
crypto map vpn
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface Serial1/0
ip address 200.1.1.1 255.255.255.0
serial restart-delay 0
crypto map vpn
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 172.16.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
!
ip classless
ip http server
!
access-list 100 permit gre host 200.1.1.1 host 200.1.1.2 非常重要
!
dial-peer cor custom
!
!
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
!
end
-----------------------------------------------------------------------------------------------------------------------------------
R2的配置:
sh run
Building configuration...
Current configuration : 1466 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R2
!
!
ip subnet-zero
!
!
no ip domain-lookup
!
ip audit notify log
ip audit po max-events 100
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco address 200.1.1.1
!
!
crypto ipsec transform-set cisco ah-sha-hmac esp-3des
!
crypto map vpn local-address Serial1/0
crypto map vpn 10 ipsec-isakmp
set peer 200.1.1.1
set transform-set cisco
match address 100
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Loopback0
ip address 192.168.2.1 255.255.255.0
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
tunnel source Serial1/0
tunnel destination 200.1.1.1
crypto map vpn
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface Serial1/0
ip address 200.1.1.2 255.255.255.0
serial restart-delay 0
crypto map vpn
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 172.16.1.2 0.0.0.0 area 0
network 192.168.2.1 0.0.0.0 area 0
!
ip classless
ip http server
!
access-list 100 permit gre host 200.1.1.2 host 200.1.1.1
!
dial-peer cor custom
!
!
!
!
!
line con 0
exec-timeout 0 0
logging synchronous
line aux 0
line vty 0 4
!
end
关于GRE Tunnel Over Ipsec ×××速度很慢的问题：
楼上说的不错，但是一阶段的group的资源浪费不是太明显，因为ISAKMP的SA超时时间是一天，一天内只要ipsec不断，一般来说，一阶段是不会重新协商的，但是如果2阶段设置PFS，那CPU就厉害了
有个做法，在inter tun 0下敲tunnel mode ipsec ipv4------------这是IPSEC自己的tunnel,(不再需要GRE了)敲了后就不是GRE OVER IPSEC了，12.4开始有的，不知道你那26支持不
上面的问题已解决了，原因是那些安全性的设置，导致不能访问应用程序。将这些
no ip redirects
no ip unreachables
no ip proxy-arp
删掉之后正常。
现在还有一个问题，我×××通了之后，用户反映访问速度很慢，用show proc cpu 看到encrypt proc 占用CPU很高，当占用率达到50%左右的时候，Ping值就会很大，访问速度很慢。我尝试将IPSEC参数做了修改，现已改到：
encry---des hash---md5 group----1
crypto ipsec trans esp-des
CPU就会下降一点。但当数据流大时，还是会占用很高的CPU。
请问，需怎么样调整啊？ IPSEC我已调到最低了啊。。。
还忘大家指点指点，谢谢！
补充: 路由器用的是Cisco 2611XM
Cisco IOS Software, C2600 Software (C2600-ADVSECURITYK9-M), Version 12.4(4)T, RELEASE SOFTWARE (fc1)
IPSEC主模式SA建立详细过程总结
第一阶段
有主模式和积极模式2种
注意!!!只有remote vpn和Easy vpn是积极模式的,其他都是用主模式来协商的
让IKE对等体彼此验证对方并确定会话密钥,这个阶段永DH进行密钥交换,创建完IKE SA后,所有后续的协商都将通过加密和完整性检查来保护
phase 1帮助在对等体之间创建了一条安全通道,使后面的phase 2过程协商受到安全保护
第二阶段
快速模式
协商IPSEC SA使用的安全参数,创建IPSEC SA,使用AH或ESP来加密IP数据流
详细过程主模式协商
IKE phase 1在IPSEC对等体间交换6条消息,这些消息的具体格式取决于使用的对等体认证方法
一,使用预共享密钥进行验证的主模式(6条)
协商过程使用ISAKMP消息格式来传递(UDP 500)
第一阶段
准备工作
在前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设置错了
接受者处理过程
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，感兴趣流不对称
