IPsec VPN原理描述


1 IPsec VPN的分类


可以从多个角度给IPsec VPN分类,不过,看一下IPsec VPN试图解决的VPN二个主要设计问题是很有意义的.
--为把二个专用的网络组合成一个虚拟网络的无缝连接.
--将虚拟网络扩展成允许远程访问用户(也被称为road warriors)成为可信任网络的一部分.


<?xml:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" />
基于这二个设计的基础上, IPsec VPN可以被分为二类:
--LAN-to-LAN IPsec 实现(也被称作site-to-site VPN).
--远程访问客户端IPsec VPN实现.





2 IPsec VPN的组成


IPsec 结合了三个主要的协议从而组成了一个和谐的安全框架
--Internet密钥交换(IKE)协议----提供协商安全参数和创建认证密钥的框架
--ESP(负载安全封装)协议----提供加密,认证和保护数据的框架
--认证头(AH)协议----提供认证和保护数据的框架
在这些协议中,IKE和ESP在一起配置.尽管AH也是IPsec协议的一个重要成分.但不像使用IPsec时那样要做那么多的配置.一般情况下,AH的很多功能都被嵌入到ESP中了.

3 IKE介绍

IKE协议是负责在二个IPsec对等体间协商一条IPsec隧道的协议,IKE在隧道建立过程中主要完成以下任务:
--协商协议参数
--交换公共密钥
--对双方进行认证
--在交换后对密钥进行管理



IKE也是由三个协议组成
--SKEME----提供为认证目的使用公开密钥加密的机制
--Oakley----提供在二个IPsec对等体间达成相同加密密钥的基于模式的机制
--ISAKMP----定义了消息交换的体系结构,包括二个IPsec对等体间分组形式和状态转换.



IKE协议分为二个阶段.一条完整的IPsec隧道通过以下事件序列建立起来:
第一步: IPsec对等体收到感兴趣流量(即我们想被加密的流量)后,将产生IKE会话.
第二步: 使用IKE的主模式(6条消息)或主动模式(3条消息)协商来使二个IKE对等体的IKE安全联盟被创建.
第三步: 使用IKE的快速模式协商,创建二个IPsec对等体间的二个安全联盟.
第四步: 数据开始在加密的信道上传输,使用了ESP或是AH封装技术(或都采用了).

从第二步和第三步可以看出IKE协议分为二个阶段:
第一阶段使用主模式(6条消息)或主动模式(3条消息)来完成下面三个任务:

--协商形成用来认证二个对等体的一个参数集合并加密一部分主模式和所有的快速模式交换.如果协商中使用主动模式则没有主动模式被加密.
--二个对等体间相互认证.这里验证有三种方法:预共享,数字签名,加密临时值.
--当协商完成时产生密钥,该密钥用于生成实际加密数据的密钥资源.



第二阶段为快速模式(3条消息):
主要目标是允许二个对等协商一些用于产生IPsec安全联盟的属性,安全联盟可以加密二个主机间的数据(ESP).

4 IKE如何用来形成一条IPsec隧道的呢?


这一系列过程都是IKE这个协议来实现,IKE这个协议也存在着一些不足,“IKE之子”或第二版IKE正在开发之中.




主模式(6条消息)或主动模式(3条消息)

第一阶段三个任务,分别用6个消息(主模式)来完成,每二个为一组.


第一个消息由隧道的发起者发起,携带了如这样一些参数,如加密机制-DES,散列机制-MD5-HMAC,Diffie-Hellman组-2,认证机制-预共享.


第二个消息由响应者回应,内容基本一样,主要与发起者比较,是否与发起者匹配,不匹配就进行下一组的比较.如果最终都找不到匹配,隧道就停止建立.


第三个消息由发起者发出,但是在发出这个消息之前,有个过程必须先完成,就是Diffie-Hellman算法过程.

该过程的目的是什么呢？刚刚第一二条消息中所协商的算法它们必须需要一个KEY,这个KEY在二个对等体上必须一样,但同时这个KEY不能在链路中传递,因为传递KEY是一个不安全的手段.所以,该过程的目的是分别在二个对等间独立地生成一个DH公共值(该DH公共值不是我们上面所说的KEY),该公共值有什么用呢？因为二个对等体上都生成该DH公共值后,它们会在接下来的第三第四消息中传送给对方,打个比方,就是A收到了B的DH公共值Xb,B收到了A的DH公共值Xa.当A,B都收到了对方的该公共值后,问题就好解决了.因为有一个公式在数学中被论证成立,借助该公式,就可以在二个对等上生成一个只有他们二个对等体知道的相同的KEY,该公式为

发起者密秘=(Xb)amod p=(Xa)bmod p=响应者密秘

Xb为对等体B的DH公共值,Xa为对等体A的DH公共值
a为只有对等体A知道的秘密. b为只有对等体B知道的秘密.

注意,这里发起者秘密和响应者密秘相等,但这个秘密不是最终算法中使用的KEY,但对等体可通过该秘密材料来生成另外三个密钥,分别是:
SKEYID_d--此密钥被用于计算后续IPsec密钥资源.
SKEYID_a--此密钥被用于提供后续IKE消息的数据完整性以及认证.
SKEYID_e--此密钥被用于对后续IKE消息进行加密.

所以由发起者发起的第三条消息主要是向对等体发送自己的DH公共值和一个临时值.
临时值被用作生成上述3个SKEYID的材料.
第四条消息由响应者向发起者发送,主要是向发送者发送自己的DH公共值和临时值.


由于第一二条消息协商算法,第三四条消息生成KEY,所以在后续的第五六条消息就能被加密传送.


第五条消息由发起者向响应者发送,主要是为了验证对端就是自己想要与之通信的对端.这可以通过预共享,数字签名,加密临时值来实现.


第六条消息由响应者向发起者发送,主要目的和第五条一样.


在这六条消息过后,也就是验证一旦通过,就进入了第二阶段:快速模式,快速模式使用二条消息来实现.


快速模式


发起者会在第一条消息中发送IPsec SA的转换集属性,如:封装--ESP,完整性检验--SHA-HMAC,DH组--2,模式--隧道
响应者向发起者发送第二条消息,同意第一条消息中的属性,同时也能起到确认收到对端消息的作用.


这一步一旦完成,隧道就建立起来了,用户的数据就能被放入隧道中传送.


实例研究

使用预共享密钥作为认证机制的路由器到路由器的IPsec

这是IPsec VPN中最基本最常用的类型.这种类型的VPN属于LAN-to-LAN.这里使用的认证方法是预共享密钥.以后的实例研究有更安全的认证方法的例子.

在实例中我们将给出发起者路由器和响应者路由器的配置,同时也给出了DEBUG输出以及相关的SHOU命令输出,以便我们共同研究.



例1 作为IPsec协商的发起者的路由器配置
hostname Initiator

The ISAKMP policy defines the attributes which will be negotiated with peers for the IKE SA.
crypto isakmp policy 1
The encryption method defined below is used for encrypting the IKE negotiation packets using SKEYID_e

encr 3des
The hash algorithm defined below is used to generate the hashes which are used for IKE authetnication purposes.

hash sha
The line below defines the authentication method as pre-shared key authentication

authentication pre-share
The line below defines the pre-shared key for the peer at the IP address
172.16.172.20.Please note that the initiator will search through its config for thiskey using the source IP address of the IKE negotiation packets it isreceiving.
crypto isakmp key jw4ep9846804ijl address 172.16.172.20

Thefollowing line defines the transform set for use with IPsec. Thistransform set !specifies the name of the transform set as 'myset'. Theencapsulation method
defined !is ESP and the encryption algorithm to use is 3DES
(triple DES). The last part of !this command specifies MD5 as the ESP integrity checking hash.
crypto ipsec transform-set myset esp-3des esp-md5-hmac
Thefollowing configuration is for the crypto map named 'vpn'. Crypto mapsessentially bind the entire IPsec configuration together. Variouselements of IPsec defined in various places in the configuration aretied together using the crypto map. 10 is the instance number for themap here. Instance numbers are used to specify the order in whichmultiple crypto maps are parsed in a config. The key word'ipsec-isakmp' is used to specify that this particular crypto map is tobe used for IPsec rather than CET.
crypto map vpn 10 ipsec-isakmp
The command line below defines the IP address of the IPsec peer.

set peer 172.16.172.20
The line below defines the transform set to use for this crypto map.

set transform-set myset
Theline below specifies the access list which will be define traffic whichwill either trigger IKE negotiation or be used to verify that the proxyIds being offered during an IKE negotiation are valid.

match address 101
interface Ethernet0/0

ip address <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-comffice:smarttags" />10.1.1.1 255.255.255.0
interface Ethernet1/0

ip address 172.16.172.10 255.255.255.0
The line below is used as a toggle switch to turn on IPsec functionality as defined by the crypto map vpn.

crypto map vpn
The access list define below is used to specify interesting traffic for IPsec.
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255

例2 作为IPsec协商的响应者的路由器配置
hostname Responder
crypto isakmp policy 1

encr 3des

hash sha

authentication pre-share
crypto isakmp key jw4ep9846804ijl address 172.16.172.10
crypto ipsec transform-set myset esp-3des esp-md5-hmac
crypto map vpn 10 ipsec-isakmp

set peer 172.16.172.10

set transform-set myset

match address 101
interface Ethernet0/0

ip address 10.1.2.1 255.255.255.0
interface Ethernet1/0

ip address 172.16.172.20 255.255.255.0

crypto map vpn
access-list 101 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255

对debug的解释紧接着该解释对应的实际debug


例3 作为IPsec协商的发起者的路由器debug
Initiator#show debug
Cryptographic Subsystem:

Crypto ISAKMP debugging is on

Crypto Engine debugging is on

Crypto IPSEC debugging is on

A#ping
Protocol [ip]:
Target IP address: 10.1.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
Theping source and destination addresses matched the match address accesslist for the crypto map VPN. 'local' is the local tunnel endpoint, and'remote' is the remote crypto endpoint as configured in the map. srcproxy is the src interesting traffic as defined by the match addressaccess list. dst proxy is the destination interesting traffic asdefined by the match address access list.
00:04:10: IPSEC(sa_request):


(key eng. msg.) OUTBOUND local= 172.16.172.10, remote= 172.16.172.20,

local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
The protocol and the transforms are specified by the crypto map that has been hit, as are the lifetimes
protocol= ESP, transform= esp-3des esp-md5-hmac ,


lifedur= 3600s and 4608000kb,

spi= 0x8EAB0B22(2393574178), conn_id= 0, keysize= 0, flags= 0x400C
Begins main mode exchange. The first two packets negotiate phase I SA parameters.
00:04:10: ISAKMP: received ke message (1/1)
00:04:10: ISAKMP: local port 500, remote port 500
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
MMstands for main mode, and QM stands for quick mode. The IKE debugs showwhich stage of IKE the negotiation is in, such as MM1. As you saw inthe discussion of IKE, main mode is divided into sixportions or messages, and quick mode into three.
Old State = IKE_READY
New State = IKE_I_MM1
00:04:10: ISAKMP (0:1): beginning Main Mode exchange
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) MM_NO_STATE
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) MM_NO_STATE
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM1
New State = IKE_I_MM2
00:04:10: ISAKMP (0:1): processing SA payload. message ID = 0
The preshared key is searched for and found based on the source IP address of IKE negotiation packets.
00:04:10: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.20
00:04:10: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 1 policy
These are the parameters offered by the other side. Policy 1 is the policy set up on this router.
00:04:10: ISAKMP:
encryption 3DES-CBC
00:04:10: ISAKMP:
hash SHA
00:04:10: ISAKMP:
default group 1
00:04:10: ISAKMP:
auth pre-share
00:04:10: ISAKMP:
life type in seconds
00:04:10: ISAKMP:
life duration (VPI) of
0x0 0x1 0x51 0x80
The policy 1 on this router and the attributes offered by the other side matched.
00:04:10: ISAKMP (0:1): atts are acceptable. Next payload is 0
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM2
New State = IKE_I_MM2
The third and fourth packets complete Diffie-Hellman exchange.
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) MM_SA_SETUP
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM2
New State = IKE_I_MM3
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) MM_SA_SETUP
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM3
New State = IKE I_MM4
00:04:10: ISAKMP (0:1): processing KE payload. message ID = 0
00:04:10: ISAKMP (0:1): processing NONCE payload. message ID = 0
00:04:10: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.20
00:04:10: ISAKMP (0:1): SKEYID state generated
00:04:10: ISAKMP (0:1): processing vendor id payload
Notebelow that some vendor ID payloads are being exchanged. These arenecessary to gauge the peer's ability to do the things described in thevendor payload. For example, below, VID payloads for Unity ProtocolSupport (a new protocol introduced by Cisco for its newer version ofVPN clients) and dead peer discovery are received.
00:04:10: ISAKMP (0:1): vendor ID is Unity
00:04:10: ISAKMP (0:1): processing vendor id payload
00:04:10: ISAKMP (0:1): vendor ID is DPD
00:04:10: ISAKMP (0:1): processing vendor id payload
00:04:10: ISAKMP (0:1): speaking to another IOS box!
00:04:10: ISAKMP (0:1): processing vendor id payload
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM4
New State = IKE_I_MM4
The fifth and sixth packets complete IKE authentication. Phase I SA is established.
00:04:10: ISAKMP (0:1): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
00:04:10: ISAKMP (1): ID payload

next-payload : 8

type
: 1

protocol
: 17

port
: 500

length
: 8
00:04:10: ISAKMP (1): Total payload length: 12
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) MM_KEY_EXCH
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM4
New State = IKE_I_MM5
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) MM_KEY_EXCH
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM5
New State = IKE_I_MM6
00:04:10: ISAKMP (0:1): processing ID payload. message ID = 0
00:04:10: ISAKMP (0:1): processing HASH payload. message ID = 0
00:04:10: ISAKMP (0:1): SA has been authenticated with 172.16.172.20
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM6
New State = IKE_I_MM6
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM6
New State = IKE_P1_COMPLETE
Begin quick mode exchange. IPsec SA will be negotiated in quick mode.
00:04:10: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of 965273472
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) QM_IDLE
00:04:10: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
Old State = IKE_QM_READY
New State = IKE_QM_I_QM1
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Old State = IKE_P1_COMPLETE
New State = IKE_P1_COMPLETE
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) QM_IDLE
The IPsec SA proposal offered by the far end is checked against the local crypto map configuration


00:04:10: ISAKMP (0:1): processing HASH payload. message ID = 965273472
00:04:10: ISAKMP (0:1): processing SA payload. message ID = 965273472
00:04:10: ISAKMP (0:1): Checking IPsec proposal 1
00:04:10: ISAKMP: transform 1, ESP_3DES
00:04:10: ISAKMP: attributes in transform:
00:04:10: ISAKMP: encaps is 1
00:04:10: ISAKMP: SA life type in seconds
00:04:10: ISAKMP: SA life duration (basic) of 3600
00:04:10: ISAKMP: SA life type in kilobytes
00:04:10: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
00:04:10: ISAKMP: authenticator is HMAC-MD5
The proposal 1 and transform 1 offered by the other end are found to be
acceptable.
00:04:10: ISAKMP (0:1): atts are acceptable.
00:04:10: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 172.16.172.10, remote= 172.16.172.20,
local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
00:04:10: ISAKMP (0:1): processing NONCE payload. message ID = 96527347
00:04:10: ISAKMP (0:1): processing ID payload. message ID = 965273472
00:04:10: ISAKMP (0:1): processing ID payload. message ID = 965273472
Two IPsec SAs have been negotiated--an incoming SA with the SPI generated by the
local machine, and an outbound SA with the SPIs proposed by the remote end.
00:04:10: ISAKMP (0:1): Creating IPsec SAs
00:04:10: inbound SA from 172.16.172.20 to 172.16.172.10
(proxy 10.1.2.0 to 10.1.1.0)
00:04:10: has spi 0x8EAB0B22 and conn_id 2029 and flags 4
00:04:10: lifetime of 3600 seconds
00:04:10: lifetime of 4608000 kilobytes
00:04:10: outbound SA from 172.16.172.10 to 172.16.172.20
(proxy 10.1.1.0 to 10.1.2.0 )
00:04:10: has spi -343614331 and conn_id 2030 and flags C
00:04:10: lifetime of 3600 seconds
00:04:10: lifetime of 4608000 kilobytes
The IPsec SA info negotiated by IKE is populated into the router's SADB.
00:04:10: IPSEC(key_engine): got a queue event...
00:04:10: IPSEC(initialize_sas): ,
(key eng. msg.) INBOUND local= 172.16.172.10, remote= 172.16.172.20,
local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0x8EAB0B22(2393574178), conn_id= 2029, keysize= 0, flags= 0x4
00:04:10: IPSEC(initialize_sas): ,
(key eng. msg.) OUTBOUND local= 172.16.172.10, remote= 172.16.172.20,
local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0xEB84DC85(3951352965), conn_id= 2030, keysize= 0, flags= 0xC
IPsec SA created in SADB, sent out last packet with commit bit set. IPsec tunnel
established.
00:04:10: IPSEC(create_sa): sa created,
(sa) sa_dest= 172.16.172.10, sa_prot= 50,
sa_spi= 0x8EAB0B22(2393574178),
sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2029
00:04:10: IPSEC(create_sa): sa created,
(sa) sa_dest= 172.16.172.20, sa_prot= 50,
sa_spi= 0xEB84DC85(3951352965),
sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2030
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) QM_IDLE
00:04:10: ISAKMP (0:1): deleting node 965273472 error FALSE reason ""
00:04:10: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE



例4 作为IPsec协商的发起者的路由器show命令输出
Thecommand below shows the state of the crypto ISAKMP SA. It is shown herein QM IDLE, meaning that quick mode has completed successfully.
Initiator#show crypto isakmp sa
dst
src
state
conn-id
slot
172.16.172.20
172.16.172.10
QM_IDLE

1
0
Thecommand below gives details on both the incoming and outgoing IPsecSAs. It gives information on the attributes negotiated during theexchange as well as statistics for how many packets have been exchangedvia each of these SAs.
Initiator#show crypto ipsec sa
interface: Ethernet1/0

Crypto map tag: vpn, local addr. 172.16.172.10
local
ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.1.2.0/255.255.255.0/0/0)

current_peer: 172.16.172.20

PERMIT, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4

#pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 6, #recv errors 0
local crypto endpt.: 172.16.172.10, remote crypto endpt.: 172.16.172.20

path mtu 1500, media mtu 1500

current outbound spi: EB84DC85

inbound esp sas:

spi: 0x8EAB0B22(2393574178)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 2029, flow_id: 1, crypto map: vpn

sa timing: remaining key lifetime (k/sec): (4607998/3347)

IV size: 8 bytes

replay detection support: Y
inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0xEB84DC85(3951352965)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 2030, flow_id: 2, crypto map: vpn


sa timing: remaining key lifetime (k/sec): (4607999/3347)

IV size: 8 bytes

replay detection support: Y

outbound ah sas:

outbound pcp sas:
The command below basically prints the configuration of the crypto map on the router


Initiator#show crypto map
Crypto Map "vpn" 10 ipsec-isakmp

Peer = 172.16.172.20

Extended IP access list 101

access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255

Current peer: 172.16.172.20

Security association lifetime: 4608000 kilobytes/3600 seconds

PFS (Y/N): N

Transform sets={ myset, }

Interfaces using crypto map vpn:

Ethernet1/0

例5 作为IPsec协商的响应者的路由器debug
Responder#show debug
Cryptographic Subsystem:

Crypto ISAKMP debugging is on

Crypto Engine debugging is on

Crypto IPSEC debugging is on
1w1d: ISAKMP (0:0): received packet from 172.16.172.10 (N) NEW SA
1w1d: ISAKMP: local port 500, remote port 500
1w1d: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_READY
New State = IKE_R_MM1
1w1d: ISAKMP (0:1): processing SA payload. message ID = 0
1w1d: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.10
1w1d: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 1 policy
1w1d: ISAKMP:
encryption 3DES-CBC
1w1d: ISAKMP:
hash SHA
1w1d: ISAKMP:
default group 1
1w1d: ISAKMP:
auth pre-share
1w1d: ISAKMP:
life type in seconds
1w1d: ISAKMP:
life duration (VPI) of
0x0 0x1 0x51 0x80
1w1d: ISAKMP (0:1): atts are acceptable. Next payload is 0
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM1
New State = IKE_R_MM1
1w1d: ISAKMP (0:1): sending packet to 172.16.172.10 (R) MM_SA_SETUP
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_R_MM1
New State = IKE_R_MM2
1w1d: ISAKMP (0:1): received packet from 172.16.172.10 (R) MM_SA_SETUP
1w1d: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_R_MM2
New State = IKE_R_MM3
1w1d: ISAKMP (0:1): processing KE payload. message ID = 0
1w1d: ISAKMP (0:1): processing NONCE payload. message ID = 0
1w1d: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.10
1w1d: ISAKMP (0:1): SKEYID state generated
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): vendor ID is Unity
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): vendor ID is DPD
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): speaking to another IOS box!
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM3
New State = IKE_R_MM3
1w1d: ISAKMP (0:1): sending packet to 172.16.172.10 (R) MM_KEY_EXCH
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_R_MM3
New State = IKE_R_MM4
1w1d: ISAKMP (0:1): received packet from 172.16.172.10 (R) MM_KEY_EXCH
1w1d: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_R_MM4
New State = IKE_R_MM5
1w1d: ISAKMP (0:1): processing ID payload. message ID = 0
1w1d: ISAKMP (0:1): processing HASH payload. message ID = 0
1w1d: ISAKMP (0:1): SA has been authenticated with 172.16.172.10
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM5
New State = IKE_R_MM5
1w1d: ISAKMP (0:1): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
1w1d: ISAKMP (1): ID payload

next-payload : 8


type
: 1

protocol
: 17

port
: 500

length
: 8
1w1d: ISAKMP (1): Total payload length: 12
1w1d: ISAKMP (0:1): sending packet to 172.16.172.10 (R) QM_IDLE
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_R_MM5
New State = IKE_P1_COMPLETE
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Old State = IKE_P1_COMPLETE
New State = IKE_P1_COMPLETE
1w1d: ISAKMP (0:1): received packet from 172.16.172.10 (R) QM_IDLE
1w1d: ISAKMP (0:1): processing HASH payload. message ID = 965273472
1w1d: ISAKMP (0:1): processing SA payload. message ID = 965273472
1w1d: ISAKMP (0:1): Checking IPsec proposal 1
1w1d: ISAKMP: transform 1, ESP_3DES
1w1d: ISAKMP:
attributes in transform:
1w1d: ISAKMP:
encaps is 1
1w1d: ISAKMP:
SA life type in seconds
1w1d: ISAKMP:
SA life duration (basic) of 3600
1w1d: ISAKMP:
SA life type in kilobytes
1w1d: ISAKMP:
SA life duration (VPI) of
0x0 0x46 0x50 0x0
1w1d: ISAKMP:
authenticator is HMAC-MD5
1w1d: ISAKMP (0:1): atts are acceptable.
1w1d: IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 172.16.172.20, remote= 172.16.172.10,

local_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
1w1d: ISAKMP (0:1): processing NONCE payload. message ID = 965273472
1w1d: ISAKMP (0:1): processing ID payload. message ID = 965273472
1w1d: ISAKMP (0:1): processing ID payload. message ID = 965273472
1w1d: ISAKMP (0:1): asking for 1 spis from ipsec
1w1d: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Old State = IKE_QM_READY
New State = IKE_QM_SPI_STARVE
1w1d: IPSEC(key_engine): got a queue event...
1w1d: IPSEC(spi_response): getting spi 3951352965 for SA

from 172.16.172.20
to 172.16.172.10
for prot 3
1w1d: ISAKMP: received ke message (2/1)
1w1d: ISAKMP (0:1): sending packet to 172.16.172.10 (R) QM_IDLE
1w1d: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_FROM_IPSEC, IKE_SPI_REPLY
Old State = IKE_QM_SPI_STARVE
New State = IKE_QM_R_QM2
1w1d: ISAKMP (0:1): received packet from 172.16.172.10 (R) QM_IDLE
1w1d: ISAKMP (0:1): Creating IPsec SAs
1w1d:
inbound SA from 172.16.172.10 to 172.16.172.20

(proxy 10.1.1.0 to 10.1.2.0)
1w1d:
has spi 0xEB84DC85 and conn_id 2029 and flags 4
1w1d:

lifetime of 3600 seconds
1w1d:
lifetime of 4608000 kilobytes
1w1d:
outbound SA from 172.16.172.20
to 172.16.172.10

(proxy 10.1.2.0 to 10.1.1.0)
1w1d:
has spi -1901393118 and conn_id 2030 and flags C
1w1d:

lifetime of 3600 seconds
1w1d:
lifetime of 4608000 kilobytes
1w1d: ISAKMP (0:1): deleting node 965273472 error FALSE reason "quick mode done (await()"
1w1d: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Old State = IKE_QM_R_QM2
New State = IKE_QM_PHASE2_COMPLETE
1w1d: IPSEC(key_engine): got a queue event...
1w1d: IPSEC(initialize_sas): ,

(key eng. msg.) INBOUND local= 172.16.172.20, remote= 172.16.172.10,

local_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0xEB84DC85(3951352965), conn_id= 2029, keysize= 0, flags= 0x4
1w1d: IPSEC(initialize_sas): ,

(key eng. msg.) OUTBOUND local= 172.16.172.20, remote= 172.16.172.10,

local_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),

remote_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0x8EAB0B22(2393574178), conn_id= 2030, keysize= 0, flags= 0xC
1w1d: IPSEC(create_sa): sa created,

(sa) sa_dest= 172.16.172.20, sa_prot= 50,

sa_spi= 0xEB84DC85(3951352965),

sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2029
1w1d: IPSEC(create_sa): sa created,

(sa) sa_dest= 172.16.172.10, sa_prot= 50,

sa_spi= 0x8EAB0B22(2393574178),

sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2030
1w1d: ISAKMP (0:1): purging node 965273472

例6 作为IPsec协商的响应者的路由器show命令输出
Responder#show cry isa sa
dst

src
state
conn-id
slot
172.16.172.10
172.16.172.20
QM_IDLE
1
0
Responder#show crypto ipsec sa
interface: Ethernet1/0

Crypto map tag: vpn, local addr. 172.16.172.20

local
ident (addr/mask/prot/port): (10.1.2.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)

current_peer: 172.16.172.10

PERMIT, flags={origin_is_acl,}

#pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4

#pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4

#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.: 172.16.172.20, remote crypto endpt.: 172.16.172.10

path mtu 1500, media mtu 1500

current outbound spi: 8EAB0B22
inbound esp sas:

spi: 0xEB84DC85(3951352965)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 2029, flow_id: 1, crypto map: vpn

sa timing: remaining key lifetime (k/sec): (4607998/3326)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x8EAB0B22(2393574178)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 2030, flow_id: 2, crypto map: vpn

sa timing: remaining key lifetime (k/sec): (4607999/3326)

IV size: 8 bytes

replay detection support: Y


outbound ah sas:

outbound pcp sas:

Initiator#show cry map
Crypto Map "vpn" 10 ipsec-isakmp

Peer = 172.16.172.10

Extended IP access list 101

access-list 101 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255

Current peer: 172.16.172.10

Security association lifetime: 4608000 kilobytes/3600 seconds

PFS (Y/N): N

Transform sets={ myset, }

Interfaces using crypto map vpn:

Ethernet1/0

1 ESP和AH
IPsec流量可以使用二种协议封装,AH和ESP.比较AH和ESP的不同之处:
AH功能为:
为二个系统这间传输的IP包进行数据认证和完整性保障.它用于检查从路由器A到路由器B的传输过程中消息有没有被更改.另外,它还负责验证数据的来源是路由器A或还是路由器B.AH并不提供数据包的私密性(加密)功能.它执行以下任务.
确保数据的完整性
提供数据源认证
使用密钥散列机制
不提供数据的私密性
提供防重放攻击

ESP功能为:
可以用于提供私密性和认证的安全协议.ESP通过IP包层的加密提供数据的私密性.IP包加密隐藏了数据净载、数据源和目的地.ESP对内部IP包和ESP头标进行认证.它执行以下任务:
数据私密性
数据完整性
数据源的认证
防重放保护

AH工作过程:
AH功能适用于整个数据报,但在传输过程中发生过变化的易变性IP头标除外,如TTL字段.
(1) IP头标和数据净载使用了散列算法.
(2 )散列用于建立一个AH头标,并将其插入原始数据包
(3) 新的数据据包被发送到IPsec的对等路由器
(4) 对等到路由器对IP头标和数据净载使用了加密算法
(5) 对等路由器从AH头标中取出传送的散列
(6) 对等路由器将二个散列进行比较.

ESP工作过程:
在二个安全网关之间,由于整个的原始IP数据报文都被加密,原始的净载受到了很好的保护.ESP头标和结尾被加入加密的净载.通过ESP认证功能,加密的IP数据报文、ESP头标或结尾被加入散列计算的流程.最后,在经过验证的净载之前将加上一个新的IP头标.新的IP地址可以被用于INTERNET路由.

2 操作模式
ESP和AH可以通过二种不同的方法或模式应用于IP包:
传输模式
隧道模式

传输模式可以保护数据包的净载和更高层的协议,但原始的IP地址仍然是暴露的.原始的IP地址可以通过因特网选择数据包的路由.

隧道模式可以加密整个IP数据包,然后,在加密的数据包之前加入一个新的IP头标.用新的外部IP地址通过因特网将数据包路由到远端的安全网关.隧道模式为整个IP数据包提供安全保护.

3 扩展认证(x-auth)
扩展认证允许IPsec客户端的使用者,而不是IPsec客户端软件,被IPsec网关认证.这使被称作通配符的预共享密钥可用于认证所有的使用同一预共享密钥并连接到IPsec网关的IPsec客户端.这种方式带来的不安全性依靠多阶段的认证——展扩认证而得到克服.扩展认证是基于每一用户的,一般靠IPsec网关与TACACS+或ADIUS服务器合作完成.

扩展认证也被称作X-AUTH,在IKE阶段1完成后开始,在快速模式开始前结束.所以,这就是为什么说它是在IKE的阶段1.5发生的.

在IKE阶段1结束后,由配置X-AUTH的网关给客户端发送一个属性负载给客户端,要求用户输入用户名和密码.网关得到这些数据后提交给验证服务器（如TACACS+）进行验证,验证成功就进行快速模式,不成功则终止隧道建立过程.

4 模式配置
模式配置产生的背景是什么呢？
原因1,因为IPsec客户端被作为它们连接专用网络的一部分对待,它们必须以已知的IP地址进入专用网络而不是ISP给它们指定的IP地址
原因2,IPsec客户端必须使用DNS服务器,DHCP服务器和其它一些在专用网络上作为信息主要来源的服务器而不是使用ISP服务器,它提供的信息不被认做内部资源.

针对这样的二个问题,允许将指定的IP地址,DNS,其它服务器推送给客户端.

推送到客户端的IP地址被称为内部IP地址.当不使用这项特性时,在ESP负载中加密并封装的分组IP头同外部的IP头包含同样的IP地址:由ISP分配给客户端地址.不过,当使用这项特性后,所有使用ESP发送的封装的分组的源地址就被改为该客户端的内部IP地址.采用这种方法,当网关对ESP分组解除封装并解密后,分配给该对等体的内部IP地址就显露出来了.除了内部IP地址,模式配置还向客户推送了其它参数,如DNS服务器IP地址,DHCP服务器IP地址等.

模式配置使用同X-AUTH一样的负载工作.它在X-AUTH后发生,同样在阶段1.5.网关向客户端推送它认为可以推送的那些属性到客户端.
5 NAT透明
NAT透明是一种为解决ESP中加密TCP/UDP端口时防止PAT发生问题而引入IPsec的机制.这个问题的解决是靠将ESP分组封装在UDP头中并附带必需的端口信息以使PAT能正确工作.一接收到这个分组,网关就剥去UDP头并正常处理分组的其余部分.IKE协商不存该问题,因为协商发生在使用UDP端口500时,只有ESP存在这个问题.
基于这种技术思想,即在UDP或TCP中封装IPsec数据包.主要使用到了三种技术手段,分别是:
(1) IPsec over UDP,这是CISCO专有的技术,这种技术就是直接把ESP封装进UDP中,利用UDP来实现地址转换.
(2) NAT-T 基于标准的IPsec over UDP
NAT-T是IETF提出的基于标准的IPsec overUDP方案.NAT-T用来执行二种任务:检查是否二端都支持NAT-T,并检查传输路径中的中间NAT设备.第一项任务地完成是依赖于他们会交换一个供应商身份的数据包来确实是否都能支持NAT-T.第二项任务地完成是依赖于他们各自向对方发送二个NAT-D载荷数据包,每个NAT-D载荷数据包都是原始IP地址和端口号的散列.它们相互收到对方的数据包后执行散列算法,最终比较散列值是否匹配来决定中间路径是否有NAT设备.
(3) IPsec over TCP:CISCO专有
IPsec over TCP,这是CISCO专有的技术,这种技术是把ESP封装进TCP中,利用TCP来实现地址转换.
6 IPsec失效等体发现机制
IPsec提供了一种当对等体发现其一个IPsec断开连接时,通过IKE发送一个删除通知负载到该对等体的机制.不过,在通常情况下,这种通知负载并不能被发送,这可能是由于该对等体连接断开得非常突然（系统崩溃）,也可能是网络原因（有人将膝上型电脑的以太网线拔掉了）.在这种情况下,有一个对等体崩溃的发现机制非常重要,它可以避免由于向不再活跃的对等体发送分组而导致数据损失（这是很有效的,IPsec对等体可以在时间的扩展期内持续向崩溃对等体发送流）.这种机制靠一种称为失效对等体发现（Dead PeerDiscovery,DPD）的技术实现.
DPD通过使用通知负载工作,该负载在对等体的非活跃时间超过所配置的“担扰的度量”之后以及新数据将要发送之前发送给对等体.IPsec流量数据被认为是对等体处于生存期的标志.如果对等体处于活跃状态,对等体就在接收到通知负载后返回一个它自己的通知负载作为应答.
为这种机工作,供应商ID负载必须在IKE主模式交换中交换,这意味着二个主机都要支持该机制.“担扰的度量”都是在本地定义的.这种仅基于需求的机制大大减少了对等体的负担,因为这不会使用可能南非要也可能不需要的周期性keeplive.同样,DPD机制也允许在网关过一段时间后想要整理其资源并查看一些空闲客户端是否仍然活跃的进修发送R-U-THERE消息.

7 NAT同IPsec相互作用
因为隧道模式下的IPsec隐藏了私有IP地址,为进入IPsec隧道的流量做网络地址转换（NAT）没有必要了.实际上,通常都不需要为进入隧道的流量做NAT.这在通过VPN网络连接的二个网路的管理员想要允许二个网络的用户可以使用同一IP就可以访问这二个网络的所有资源的环境下是正确的.这意味着网络A上的用户可以访问网络A上使用IP地址10.1.1.1的服务器,通过VPN连接到网络A的网络B上的用户就能连接到这个IP地址为10.1.1.1的服务器,而不用管在网络A前面的IPsec路由器是否有一个该服务器的适适静态的NAT转换以允许从INTERNET上来的连接.
下面的配置中给出了忽略NAT进入IPsec隧道的一种方法.忽略IPsec是为了使用特定策略路由技巧.现在,感兴趣流量从INSIDE端口进来从OUTSIDE端口出去,有什么方法可以绕过NAT呢？可以使用策略路由,把从INSIDE端口进来的流量策略到一个环回接口,而环回接口没有配置IP NATINSIDE命令,现在,路由器以为流量是从环回接口来去往隧道另一端,所以,将不执行NAT,直接送入隧道.

这种思想是一种经典！

例子:

本实例研究中路由器NATRTR的配置
Router#write terminal
hostname NATRTR
crypto map test 10 IPsec-isakmp
set peer 1.1.1.1
set transform-set transform
match address 100
This is the loopback the traffic will be routed to in order to change the order of events on the router
interface Loopback1
ip address 10.2.2.2 255.255.255.252
interface Ethernet0/0
ip address 1.1.1.2 255.255.255.0
ip nat outside
crypto map test
interface Ethernet0/1
ip address 10.1.1.1 255.255.255.0
ip nat inside
ip route-cache policy
The policy route map below is used to force the IPsec interesting traffic to the loopback interface.
ip policy route-map nonat
This is the dynamic NAT configuration we are trying to bypass.
ip nat inside source access-list 1 interface Ethernet0/0 overload
access-list 1 permit 10.0.0.0 0.255.255.255
The access list below defines IPsec interesting traffic.
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
The access list below defines the traffic that is to be used by the route map nonat to route to the loopback interface.
access-list 120 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
Below is the route map used to route the traffic matching access list 120 to the loopback interface.
route-map nonat permit 10
match ip address 120
set ip next-hop 10.2.2.1
8 IPsec隧道终点发现(TED)
本实例研究包括了CISCO路由器实现中提供的特殊属性.TED允许路由器动态配置其IPsec对等体地址而不用在路由调协中手动配置.这种可扩展特性很有用,它使创建数目众多的对等体仅需定义一个它们感兴趣的流量访问列表并允许TED找出这些对等体窨是哪能些即可.重要的是,如果VPN创建在INTERNET上,那么感兴趣的流量必须使用全局可路由地址定义.这是必须的,因为TED使用一般路由以计算出IPsec对等体的位置.
TED靠发送一个分组,该探测分组的目的地址为定义感兴趣流量的访问控制列表中的目的地址.这个探测分组终止于目的IP地址前的IPsec路由器.该路由器收集关于代理ID的必须信息,并返回一个探测应答,应答中包含相同代理和自己的IP地址.发起者收到该响应消息后就开始IKE的协商.
例子:

配置TED-Initiator路由器:
TED-Initiator#show running-config
Building configuration...
Current configuration:
version 12.0
service timestamps debug uptime
service timestamps log uptime
hostname TED-Initiator
enable secret 5 <removed>
enable password <removed>
ip subnet-zero
crypto isakmp policy 10
authentication pre-share
One of the issues with using a presharedkey with TED is the need to use a wildcard preshared key because thepeer's address is not known beforehand. A resolution to this is to usedigital certificate-based digital signatures as the authenticationmethod.
crypto isakmp key abc123 address 0.0.0.0
crypto ipsec transform-set ted-transforms esp-des esp-md5-hmac
Note that no peer address has been configured in the crypto map below.
crypto dynamic-map ted-map 10
set transform-set ted-transforms
match address 101
The keyword discover in the crypto map below triggers the use of TED
crypto map tedtag 10 ipsec-isakmp dynamic ted-map discover
interface Ethernet0/0
ip address 13.13.13.13 255.255.255.0
no ip directed-broadcast
no mop enabled
interface Ethernet0/1
ip address 11.11.11.1 255.255.255.0
crypto map tedtag
ip classless
ip route 0.0.0.0 0.0.0.0 11.11.11.2
no ip http server
access-list 101 permit ip 13.13.13.0 0.0.0.255 12.12.12.0 0.0.0.255
access-list 101 permit icmp 13.13.13.0 0.0.0.255 12.12.12.0 0.0.0.255
line con 0
transport input none
line aux 0
line vty 0 4
password ww
login
end
配置TED-Responder路由器:
TED-Responder#show running-config
Building configuration...
Current configuration:
version 12.0
service timestamps debug uptime
service timestamps log uptime
hostname TED-Responder
enable secret 5 <removed>
enable password <removed>
crypto isakmp policy 10
authentication pre-share
crypto isakmp key abc123 address 0.0.0.0
crypto ipsec transform-set ted-transforms esp-des esp-md5-hmac
crypto dynamic-map ted-map 10
set transform-set ted-transforms
match address 101
crypto map tedtag 10 ipsec-isakmp dynamic ted-map discover
interface Ethernet0/0
ip address 12.12.12.12 255.255.255.0
no ip directed-broadcast
no mop enabled
interface Ethernet0/1
ip address 11.11.11.2 255.255.255.0
crypto map tedtag
ip classless
ip route 0.0.0.0 0.0.0.0 11.11.11.1
no ip http server
access-list 101 permit ip 12.12.12.0 0.0.0.255 13.13.13.0 0.0.0.255
access-list 101 permit icmp 12.12.12.0 0.0.0.255 13.13.13.0 0.0.0.255
line con 0
transport input none
line aux 0
line vty 0 4
password ww
login
no scheduler allocate
end
在TED-Initiator路由器中的debug:
TED-Initiator#show debug
Cryptographic Subsystem:
Crypto ISAKMP debugging is on
Crypto Engine debugging is on
Crypto IPSEC debugging is on
TED-Initiator#
The TED process has started. The proxy IDs are shown in the message below.
01:33:56: IPSEC(tunnel discover request): ,
(key eng. msg.) src= 13.13.13.14, dest= 12.12.12.13,
src_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),
dest_proxy= 11.11.11.1/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4044
01:33:56: GOT A PEER DISCOVERY MESSAGE FROM THE SA MANAGER!!!
01:33:56: src = 13.13.13.14 to 12.12.12.13, protocol 3, transform 2, hmac 1
The TED process below determines which address is the source address in the TED packet and which addresses are the proxy IDs.
01:33:56: proxy source is 13.13.13.0 /255.255.255.0 and my address (not used now) is 11.11.11.1
01:33:56: ISAKMP (1): ID payload
next-payload : 5
type : 1
protocol : 17
port : 500
length : 8
01:33:56: ISAKMP (1): Total payload length: 12
The initiator determines below that thefirst ID payload will be its own IP address, 11.11.11.1, and the secondpayload contains its source IPsec proxy:13.13.13.0/24
01:33:56: 1st ID is 11.11.11.1
01:33:56: 2nd ID is 13.13.13.0 /255.255.255.0
01:33:56: ISAKMP (0:1): beginning peer discovery exchange
The TED probe is being sent to thedestination IP address found in the original packet that was receivedon the initiator and that matched the IPsec interesting traffic accesslist.
01:33:56: ISAKMP (1): sending packet to 12.12.12.13 (I) PEER_DISCOVERY
The peer has been discovered to be 12.12.12.13, and it responds as shown below
01:33:56: ISAKMP (1): received packet from 12.12.12.13 (I) PEER_DISCOVERY
Upon processing the vendor ID payload, the initiator ascertains that the responder does indeed understand what was sent to it.
01:33:56: ISAKMP (0:1): processing vendor id payload
01:33:56: ISAKMP (0:1): speaking to another IOS box!
01:33:56: ISAKMP (0:1): processing ID payload. message ID = 0
The responder's IP address is encoded in the ID payload. It is equal to 11.11.11.2
01:33:56: ISAKMP (0:1): processing ID payload. message ID = 1168952014
Upon looking at the ID payload sent by theresponder, the initiator finds that the responder's proxy ID indeedmatches the proxy configured on itself.
01:33:56: ISAKMP (1): ID_IPV4_ADDR_SUBNET dst 12.12.12.0/255.255.255.0 prot 0 port 0
01:33:56: ISAKMP (1): received response to my peer discovery probe!
Normal IKE processing starts at this point to the IP address discovered through TED
01:33:56 ISAKMP: initiating IKE to 11.11.11.2 in response to probe.
01:33:56: ISAKMP (2): sending packet to 11.11.11.2 (I) MM_NO_STATE
01:33:56: ISAKMP (0:1): deleting SA
01:33:56: ISAKMP (2): received packet from 11.11.11.2 (I) MM_NO_STATE
01:33:56: ISAKMP (0:2): processing SA payload. message ID = 0
01:33:56: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 10 policy
01:33:56: ISAKMP: encryption DES-CBC
01:33:56: ISAKMP: hash SHA
01:33:56: ISAKMP: default group 1
01:33:56: ISAKMP: auth pre-share
01:33:56: ISAKMP (0:2): atts are acceptable. Next payload is 0
01:33:56: CryptoEngine0: generate alg parameter
01:33:56: CRYPTO_ENGINE: Dh phase 1 status: 0
01:33:56: CRYPTO_ENGINE: Dh phase 1 status: 0
01:33:56: ISAKMP (0:2): SA is doing pre-shared key authentication
01:33:56: ISAKMP (2): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
01:33:56: ISAKMP (2): sending packet to 11.11.11.2 (I) MM_SA_SETUP
01:33:56: ISAKMP (2): received packet from 11.11.11.2 (I) MM_SA_SETUP
01:33:56: ISAKMP (0:2): processing KE payload. message ID = 0
01:33:56: CryptoEngine0: generate alg parameter
01:33:57: ISAKMP (0:2): processing NONCE payload. message ID = 0
01:33:57: CryptoEngine0: create ISAKMP SKEYID for conn id 2
01:33:57: ISAKMP (0:2): SKEYID state generated
01:33:57: ISAKMP (0:2): processing vendor id payload
01:33:57: ISAKMP (0:2): speaking to another IOS box!
01:33:57: ISAKMP (2): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
01:33:57: ISAKMP (2): Total payload length: 12
01:33:57: CryptoEngine0: generate hmac context for conn id 2
01:33:57: ISAKMP (2): sending packet to 11.11.11.2 (I) MM_KEY_EXCH
01:33:57: ISAKMP (2): received packet from 11.11.11.2 (I) MM_KEY_EXCH
01:33:57: ISAKMP (0:2): processing ID payload. message ID = 0
01:33:57: ISAKMP (0:2): processing HASH payload. message ID = 0
01:33:57: CryptoEngine0: generate hmac context for conn id 2
01:33:57: ISAKMP (0:2): SA has been authenticated with 11.11.11.2
01:33:57: ISAKMP (0:2): beginning Quick Mode exchange, M-ID of 474637101
01:33:57: CryptoEngine0: clear dh number for conn id 1
01:33:57: IPSEC(key_engine): got a queue event...
01:33:57: IPSEC(spi_response): getting spi 348588451 for SA from 11.11.11.2 to 11.11.11.1 for prot 3
01:33:57: CryptoEngine0: generate hmac context for conn id 2
01:33:57: ISAKMP (2): sending packet to 11.11.11.2 (I) QM_IDLE
01:33:57: ISAKMP (2): received packet from 11.11.11.2 (I) QM_IDLE
01:33:57: CryptoEngine0: generate hmac context for conn id 2
01:33:57: ISAKMP (0:2): processing SA payload. message ID = 474637101
01:33:57: ISAKMP (0:2): Checking IPsec proposal 1
01:33:57: ISAKMP: transform 1, ESP_DES
01:33:57: ISAKMP: attributes in transform:
01:33:57: ISAKMP: encaps is 1
01:33:57: ISAKMP: SA life type in seconds
01:33:57: ISAKMP: SA life duration (basic) of 3600
01:33:57: ISAKMP: SA life type in kilobytes
01:33:57: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
01:33:57: ISAKMP: authenticator is HMAC-MD5
01:33:57: validate proposal 0
01:33:57: ISAKMP (0:2): atts are acceptable.
01:33:57: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 11.11.11.2, src= 11.11.11.1,
dest_proxy= 12.12.12.0/255.255.255.0/0/0 (type=4),
src_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
01:33:57: validate proposal request 0
01:33:57: ISAKMP (0:2): processing NONCE payload. message ID = 474637101
01:33:57: ISAKMP (0:2): processing ID payload. message ID = 474637101
01:33:57: ISAKMP (0:2): processing ID payload. message ID = 474637101
01:33:57: CryptoEngine0: generate hmac context for conn id 2
01:33:57: ipsec allocate flow 0
01:33:57: ipsec allocate flow 0
01:33:57: ISAKMP (0:2): Creating IPsec SAs
01:33:57: inbound SA from 11.11.11.2 to 11.11.11.1 (proxy 12.12.12.0 to 13.13.13.0)
01:33:57: has spi 348588451 and conn_id 2000 and flags 4
01:33:57: lifetime of 3600 seconds
01:33:57: lifetime of 4608000 kilobytes
01:33:57: outbound SA from 11.11.11.1 to 11.11.11.2 (proxy 13.13.13.0 to 12.12.12.0)
01:33:57: has spi 132187477 and conn_id 2001 and flags 4
01:33:57: lifetime of 3600 seconds
01:33:57: lifetime of 4608000 kilobytes
01:33:57: ISAKMP (2): sending packet to 11.11.11.2 (I) QM_IDLE
01:33:57: ISAKMP (0:2): deleting node 474637101
01:33:57: IPSEC(key_engine): got a queue event...
01:33:57: IPSEC(initialize_sas): ,
(key eng. msg.) dest= 11.11.11.1, src= 11.11.11.2,
dest_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),
src_proxy= 12.12.12.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0x14C709A3(348588451), conn_id= 2000, keysize= 0, flags= 0x4
01:33:57: IPSEC(initialize_sas): ,
(key eng. msg.) src= 11.11.11.1, dest= 11.11.11.2,
src_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),
dest_proxy= 12.12.12.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0x7E10555(132187477), conn_id= 2001, keysize= 0, flags= 0x4
01:33:57: IPSEC(create_sa): sa created,
(sa) sa_dest= 11.11.11.1, sa_prot= 50,
sa_spi= 0x14C709A3(348588451),
sa_trans= esp-des esp-md5-hmac , sa_conn_id= 2000
01:33:57: IPSEC(create_sa): sa created,
(sa) sa_dest= 11.11.11.2, sa_prot= 50,
sa_spi= 0x7E10555(132187477),
sa_trans= esp-des esp-md5-hmac , sa_conn_id= 2001
TED-Initiator路由器show命令输出:
TED-Initiator#show crypto ipsec sa
interface: Ethernet0/1
Crypto map tag: tedtag, local addr. 11.11.11.1
local ident (addr/mask/prot/port): (13.13.13.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (12.12.12.0/255.255.255.0/0/0)
current_peer: 11.11.11.2
PERMIT, flags={}
#pkts encaps: 9, #pkts encrypt: 9, #pkts digest 9
#pkts decaps: 9, #pkts decrypt: 9, #pkts verify 9
#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.: 11.11.11.1, remote crypto endpt.: 11.11.11.2
path mtu 1500, media mtu 1500
current outbound spi: 7E10555
inbound esp sas:
spi: 0x14C709A3(348588451)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: tedtag
sa timing: remaining key lifetime (k/sec): (4607998/3557)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x7E10555(132187477)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: tedtag
sa timing: remaining key lifetime (k/sec): (4607998/3557)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:

SSL 介绍
安全套接致层(Secure Socket Layer,SSL)是一种在二台机器之间提供安全通道的协议.它具有保护传输数据以及识别通信机器的功能.安全通道
是透明的,意思就是说它对传输的数据不加变更.客户与服务器之间的数据是经过加密的,一端写入的数据完全是另外一端读取的内容.透明性使
得几乎所有基于TCP的协议稍加改动就可以在SSL上运行,非常方便.
SSL历经多次修订,从开始的版本1到IETF最终所采纳的传输层安全(Transport Layer Security,TLS)标准.所有IETF版本之前的SSL版本都是由网
景通信公司(Netscape Communications)的工程师们设计的.版本1从未经过广泛的部署,所以讨论将从版本2(SSLv2)开始.
SSLv2的设计目标
SSL原先是为WEB设计的.网景公司的意图是针对其所有的通信安全问题,包括WEB,电子邮件及新闻组通信提供一种单一的解决方案.因为他们当时
所面临的问题只是WEB通信,所以SSL就是为了满足WEB通信的需要而设计的.也就是说SSL必须能够与WEB所使用的主要协议--超文本传输协议
(HTTP)一起很好的工作.
SSLv3的设计目标
SSLv2的广泛流行大体保证了SSLv2原先所有的设计目标得以在SSLv3中保留下来.SSLv3设计者的首要工作就是修正SSLv2中的多处安全问题.也就
是说,设计一种更加强壮而且更易分析的系统.需要SSLv3比SSLv2支持的算法数据多得多.最终,这些要求使SSLv3与SSLv2完全不同,只保留了一些
基本的协议特色.
SSL的历史
最早的版本(SSLv2)位于该树的顶端,而最新近的版本(WTLS)位于树的底部.原先的SSLv2规范于1994年11月首次公开发表.中间经历了SSLv3,TLS.
用于WEB的SSL
SSL的首要用途就是保护使用HTTP的WEB通信.过程很简单.当在HTTP中建立了TCP连接后,客户端先发送一个请求,服务器具随即回应一个文档.而
在使用SSL的时候,客户端先创建一个TCP连接,并在其上建立一条SSL通道.然后再在SSL通道上发送同样的请求,而服务器则以相同的方式沿SSL连
接予以响应.
对普通的HTTP服务器来说,SSL握手就像是垃圾信息,因为并不是所有的服务器都是支持SSL,所以为了使该过程能够正确的工作,客户端需要某种
了解服务器已准备好接受SSL连接的方法.使用以HTTPS而不是HTTP开头的WEB地址(技术上被称做统一资源定位符(URL))来指示应当使用SSL.
如:https://secure.example.com
因此,这种在SSL上运行HTTP的组合常常被称做HTTPS.

SSL握手
SSl握手有三个目的.
第一,客户端与服务器需要就一组用于保护数据算法达成一致.
第二,它们需要确立一组由那些算法所使用的加密密钥.
第三,握手还可以选择对客户端进行认证
具体表现为:
(1)客户端将它所支持的算法列表连同一个密钥产生过程用作输入的随机数发送给服务器.
(2)服务器根据从列表的内容中选择一种加密算法,并将其连同一份包含服务器公用密钥的证书发回给客户端.该证书还包含了用于认证目的服务
器标识,服务器同时还提供了一个作为密钥产生过程部分输入的随机数.
(3)客户端对服务器的证书进行验证,并抽取服务器的公用密钥.然后,再产生一个称做pre_master_secret的随机密码串,并使用服务器的公用密
码对其进行加密.最后,客户端将加密后的信息发送给服务器.
(4)客户端与服务器端根据pre_master_secret以及客户端与服务器的随机数值独立计算出加密和MAC密钥.
(5)客户端将所有握手消息的MAC值发送给服务器.
(6)服务器将所有握手消息的MAC值发送给客户端.
那么,该过程达到了怎样的效果呢?还记得我们的二个目标是什么吗?第一,就一组算法达成一致.第二,确立一组加密密钥.第一和第二步实现了第
一个目标.客户端收到了服务器在第二步所发的消息时,它也会知道这种算法,所以双方现在就都知道要使用什么算法了.
第二个目标,确立一组加密密钥是通过第二和第三步来实现的.在第二步服务器向客户端提供其证书,这样就可以允许客户端给服务器传送密码.
经过第3步后,客户端与服务器端就都知道了pre_master_secret.客户端知道pre_master_secret是因为这是它产生的,而服务器则是通过解密而
得到pre_master_secret的.

注意,第3步是握手过程中的关键一步.所有要被保护的数据都依赖于pre_master_secret的安全.原理非常简单:客户端使用服务器的公用密钥(从
证书中抽取的)来加密共享密钥,而服务器使用其私用密钥对共享密钥进行解密.握手的其余步骤主要用于确保这种交换过程的安全进行.然后在
第四步,客户与服务器分别使用相同的密钥导出函数来产生master_secret,最后再次通过KDF使用master_secret来产生加密密钥.
第5步和第6步用以防止握手本身遭受篡改.设想一个攻击者想要控制客户端与服务器所使用的算法.客户端提供多种算法的情况下当常见,某些强
度弱而某些强度强,以便能够与仅支持弱强度算法的服务器进行通信.攻击者可以删除客户端在第1步所提供的所有高强度算法,于是就迫使服务
器选择一种弱强度的算法.第5步与第6步的MAC交换就能阻止这种攻击,因为客户端的MAC是根据原始消息计算得出的,而服务器的MAC是根据攻击
者修改过的消息计算得出的,这样经过检查就会发现不匹配.由于客户端与服务器所提供的随机数为密钥产生过程的输入,所以握手不会受到重放
攻击的影响.这些消息是首个在新的加密算法与密钥下加密的消息.
因此,在此过程结束时,客户端与服务器已就使用的加密算法达成一致,并拥有了一组与那些算法一起使用的密钥.更重要的是,它们可以确信攻击
者没有干扰握手过程,所以磋商过程反映了双方的真实意图.

握手消息
刚才所描述的每一步都需要通过一条或多条握手消息来实现.在此先简要地描述哪些消息与哪几步对应.
第一步对应一条单一的握手消息,ClientHello.
第二步对应一系列SSL握手消息,服务器发送的第一条消息为ServerHello,其中包含了它所选择的算法,接着再在Certificate消息中发送其证书.
最后,服务器发送ServerHelloDone消息以表示这一握手阶段的完成.需要ServerHelloDone的原因是一些更为复杂的握手变种还要在Certificate
这后发送其它一些消息。当客户端接收到ServerHelloDone的原因是一些更为复杂的握手变种还要在Certificate这后发送其它一些消息.当客
户端接收到ServerHelloDone复杂的握手变种还要在Certificate之后发送其它一些消息.当客户端接收到ServerHelloDone消息时,它就知道不会
再有其它类似的消息过来了,于是就可以继续它这一方面的握手.
第三步对应ClientKeyExchange消息.
第五步与第六步对应Finished消息.该消息是第一条使用刚刚磋商过的算法加以保护的消息.为了防步握手过程遭到篡改,该消息的内容是前一阶
段所有握手消息的MAC值.然而,由于Finished消息是以磋商好的算法加以保护的,所以也要与新磋商的MAC密钥一起计算消息本身的MAC值.

SSL配置实例
有三种方法来利用SSL VPN技术：Clientless SSL VPN, Thin-Client SSL VPN (Port Forwarding)和SSL VPN Client (SVC Tunnel Mode)
每一种都有自己的优势和独特的访问方法

1. Clientless SSL VPN
公司内部启用了http或https的资源,远程用户只需要使用基于webbrowser来访问.浏览带有Common Internet File System(CIFS)的文件也是可以的.一个好的例子是基于WEB的Outlook Access client.

2. Thin-Client SSL VPN (Port Forwarding)
远程用户必须下载一个小的,基于JAVA的小应用程序.以便能访问到使用静态端口的TCP应用,UDP不被支持.包括的例子如OP3, SMTP, IMAP, SSH, andTelnet.用户需要本地管理员特权,因为对文件的修改是在本地机器中进行.这种VPN技术不能让使用动态端口的应用正常工作.如,个别的FTP服务器.

3. SSL VPN Client (SVC-Tunnel Mode)
在这种技术中,远程工作站需要下载一个小的客户端软件,对公司内部资源的全部安全访问.这个小的客户端软件可以永久地被下载到远程工作站或者安全会话结束后就被删除.

关于第2,第3种SSL VPN技术的配置,这里暂不给出,如果有感兴趣朋友请在论坛中反馈给我.

Clientless SSL VPN 配置步骤(前央是图形化配置,后面是命令行配置)

(1)启用WebVPN在ASA的接口
(2)对WebVPN访问创建一个SERVER或URLS列表
(3)对WebVPN用户创建一个组策略
(4)对隧道组应用一个组策略

本实例中拓朴图

1 In ASDM, choose Configuration > VPN > WebVPN > WebVPN Access.

Choose the interface to terminate WebVPN users > Enable > Apply.

2 Choose Servers and URLs > Add

Enter a name for the list of serversaccessible by WebVPN. Click the Add button. The Add Server or URLdialogue box displays. Enter the name of each server. This is the namethat the client sees. Choose the URL drop-down menu for each server andchoose the appropriate protocol. Add servers to your list from the AddServer or URL dialogue box and click OK.

Click Apply > Save.
3 Expand General in the left menu of ASDM. Choose Group Policy > Add.

Choose Add Internal Group Policy. Uncheck the Tunneling Protocols: Inherit check box. Check the WebVPN check box.

Choose the WebVPN tab. Uncheck the Inherit check box. Choose from the list of features. Click OK > Apply.


4 Choose the Tunnel Group in the left column. Click the Edit button.


Click the Group Policy drop-down menu. Choose the policy that was created in Step 3.


It is important to note that if new GroupPolicies and Tunnel Groups are not created, the defaults areGroupPolicy 1 and DefaultWEBVPNGroup. Click the WebVPN tab.

Choose NetBIOS Servers. Click the Addbutton. Fill in the IP address of the WINS/NBNS server. Click OK >OK. Follow the prompts Apply > Save > Yes to write theconfiguration.

命令行配置
ciscoasa#show running-config
Building configuration...

ASA Version 7.2(1)
hostname ciscoasa
domain-name cisco.com
enable password 9jNfZuG3TC5tCVH0 encrypted
names
dns-guard
interface Ethernet0/0
nameif outside
security-level 0
ip address 172.22.1.160 255.255.255.0
interface Ethernet0/1
nameif inside
security-level 100
ip address 10.2.2.1 255.255.255.0
interface Ethernet0/2
nameif DMZ1
security-level 50
no ip address
interface Management0/0
description For Mgt only
shutdown
nameif Mgt
security-level 0
ip address 10.10.10.1 255.255.255.0
management-only
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
dns server-group DefaultDNS
domain-name cisco.com
pager lines 24
logging enable
logging asdm informational
mtu outside 1500
mtu inside 1500
mtu DMZ1 1500
mtu Mgt 1500
icmp permit any outside
asdm image disk0:/asdm521.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 10.2.2.0 255.255.255.0
route outside 0.0.0.0 0.0.0.0 172.22.1.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout uauth 0:05:00 absolute
!
!--- group policy configurations
!
group-policy GroupPolicy1 internal
group-policy GroupPolicy1 attributes
vpn-tunnel-protocol IPSec l2tp-ipsec webvpn
webvpn
functions url-entry file-access file-entry file-browsing mapi port-forward filter
http-proxy auto-download citrix
username cisco password 53QNetqK.Kqqfshe encrypted
!
!--- asdm configurations
!
http server enable
http 10.2.2.0 255.255.255.0 inside
!
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
!
!--- tunnel group configurations
!
tunnel-group DefaultWEBVPNGroup general-attributes
default-group-policy GroupPolicy1
tunnel-group DefaultWEBVPNGroup webvpn-attributes
nbns-server 10.2.2.2 master timeout 2 retry 2
!
telnet timeout 5
ssh 172.22.1.0 255.255.255.0 outside
ssh timeout 5
console timeout 0
!
class-map inspection_default
match default-inspection-traffic
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
!
service-policy global_policy global
!
!--- webvpn configurations
!
webvpn
enable outside
url-list ServerList "WSHAWLAP" cifs://10.2.2.2 1 url-list ServerLis
t "FOCUS_SRV_1" https://10.2.2.3 2 url-list ServerList "FOCUS_SRV_2" http://10.2.2.4 3
!
prompt hostname context
!
end

验证

Establish a connection to your ASA device from an outside client to test this:
https://ASA_outside_IP_Address
The client receives a Cisco WebVPN pagethat allows access to the corporate LAN in a secure fashion. The clientis allowed only the access that is listed in the newly created grouppolicy.
Authentication:A simple login and password was created on the ASA for this lab proof of concept.

[ 本帖最后由 garnett_wu 于 2008-6-3 16:20 编辑 ]

高深，复杂。

找了很久了，谢谢分享哦！