L2TP启用LCP协商以后VT接口下配置验证方式隧道不能正常建立

发布时间:  2012-07-18 浏览次数:  280 下载次数:  0
问题描述

配置了L2TP以后,在VT接口下面配置了CHAP或者PAP认证,不能正常建立隧道,不配置认证可以正常建立隧道



LNS设备为USG2210,配置如下:
sysname LNS
#
l2tp enable
#
interface Virtual-Template1
 ppp authentication-mode chap----如果加上认证隧道无法建立
 ip address 192.168.0.1 255.255.255.0
 remote address pool 1
#
l2tp-group 1
 mandatory-lcp
 allow l2tp virtual-template 1
 tunnel password simple  Password1
 tunnel name LNS
#
aaa
 local-user vpdnuser@domain1.com password simple Hello123
 authentication-scheme default
ip pool 1 192.168.0.2  192.168.0.100
LAC参考LNS的参数配置,查看时始终无法建立隧道

告警信息
处理过程
根据L2TP隧道建立的协商过程


1     用户端PC发起呼叫连接请求,PC和LAC端(USG_A)进行PPP LCP协商,LAC对PC机提供的用户信息进行PAP(Password Authentication Protocol)或CHAP(Challenge Handshake Authentication Protocol)认证,通过本地认证以后,LAC端向指定LNS发起Tunnel连接请求。
2     LAC端向指定LNS发送CHAP challenge信息,LNS回送该challenge响应消息CHAP response,并发送LNS侧的CHAP challenge,LAC返回该challenge的响应消息CHAP response,隧道验证通过。
3     LAC端将用户CHAP response、response identifier和PPP协商参数传送给LNS,LNS将接入请求信息进行本地认证,认证通过则返回响应信息,验证通过,用户可以访问企业内部资源,在该过程VT接口二次认证为接入访问验证,但客户配置以后不能正常建立隧道,即二次认证失败,不配置可以正常建立,也就是不需要进行二次认证,那么原因应该为启用了LCP重协商功能。
4     在LSN做二次验证有三种方式:
?  LCP重协商
LCP重协商的一个目的是考虑到LAC与LNS可能是不同厂商的设备,LAC之前已经协商出来的LCP参数可能并不是LNS所期望的,则可以配置LNS与用户间进行LCP重协商,如果VT接口下没有配置验证方式,那么重协商时不验证,否则要求LAC与LNS一致。
?  强制CHAP验证
如果只配置强制CHAP验证,则LNS对用户进行CHAP验证,如果验证不过的话,会话就不能建立成功
?  代理验证
如果既不配置LCP重协商,也不配置强制CHAP验证,则LNS对用户进行的是代理验证。
代理验证:LAC将它从用户得到的所有验证信息及LAC端配置的验证方式传给LNS,LNS会利用这些信息和LAC端传来的验证方式对用户进行验证,除非在LNS端配置AAA的验证方式为NONE
代理验证与VT上配的验证方式也是有一些关系:
 如果LAC送来验证方式为PAP,但VT上配的为CHAP,PPP认为这种情况不合理,LNS的要求高,不能通过验证。

 
根因
l2tp-group 1组中启用了mandatory-lcp重协商功能,LAC的验证方式与LNS不一致,协商LCP参数匹配不上LNS的参数,如验证方式,导致配置了隧道无法建立
建议与总结
该问题与L2TP协商过程中一些小特性有关,需要熟悉L2TP的工作过程

END