2023年12月22日发(作者：)

场景一、SCVPN客户端常见问题及解决方案

1. Client 与 server的通讯逻辑不匹配

原因分析

原因1：scvpn地址池中的地址和远端pc的本地网卡地址冲突

原因2：scvpn的tunnel 接口地址与scvpn pool 地址不在同一个网段

解决方法

修改Hillstone安全网关设备上scvpn pool的地址设置，尽可能不使用像192.168.1.0或192.168.0.0这类客户端常用的IP，来避免IP冲突

检查Hillstone安全网关设备上SCVPN的tunnel 接口地址是否和scvpn pool 地址在同一网段

2. 服务器证书还没生效

原因分析

Hillstone安全网关的时间与SCVPN用户系统时间不匹配

解决方法

通过web 同步Hillstone安全网关的系统时间，然后重启设备

如果还不行，请手动删除SCVPN用户PC上安装目录（如“C:Program

FilesHillstoneHillstone Secure Connectcert”）下的所有文件，再尝试进行连接。

3. 设置tunnel接口失败

原因分析

SCVPN用户端创建的虚拟网卡在接受Hillstone安全网关下发的网卡参数时失败，一般是因为与其它软件（主要是指杀毒软件或同类VPN客户端软件）写注册表或软件冲突原因造成

解决方法

A. 建议检查当前您是否具有本地PC机的管理员权限，建议关闭杀毒软件；

B. 检查本地PC上是否安装了同类VPN客户端软件，并建议删除

C. 请删除SCVPN客户端软件后，使用本地PC机管理员重新登陆VPN页面进行安装，在安装过程中如果有杀毒软件提示时请选择允许操作

D. 在cmd命令行输入ipconfig/all,若提示“ipconfig/all 不是内部命令”，但输入c:可以执行，在点击计算机->属性->高级系统属性->环境变量，在用户变量中新建或编辑变量名为path,值为c:windowssystem32；在系统变量中新建或编辑变量名为path,值为;%SYSTEMROOT%SYSTEM32;%SYSTEMROOT%;%SYSTEMROOT%SYSTEM32WBEM;%SYSTEMROOT%SYSTEM32WINDOWSPOWERSHELLV1.0;

E. Win7和Win8系统确保系统已激活；

F. 关闭UAC

控制面板->用户帐户->更改用户帐号控制->从不通知。该操作需要重启后生效。

G . 在客户端日志中查找netsh interface ip set命令，例如2013.08.17 23:54:14

LOG_INFO [11744:9360]: Command netsh interface ip set interface "29" metric=1

forwarding=enabled store=active，找到该命令后再cmd中输入netsh interface

ip set interface "29" metric=1 forwarding=enabled store=active后回车，若提示RPC服务器不可用，则进行如下操作：

1). 在cmd中输入如下命令：net start rpcss。若问题仍然存在，则继续执行下一步；

2).使用 Microsoft Windows 支持工具（包含在 Windows CD-ROM 上）中包含的 Netdiag 工具确定域控制器是否正常工作。可以使用 MSRPC、DNS、NBT、LDAP 或 TCP 协议执行网络跟踪。如果域控制器存在问题，请与网络管理员联系以解决问题。如果仍然出现此问题，则继续执行下一步。

3).使用 Windows 支持工具中包含的 Netdom 工具验证网络信任关系，然后重置或建立到服务器的连接。

4).运行，检查一下RPC的Remote Procedure Call (RPC)和Remote Procedure Call (RPC) Locator这两项服务的情况，将它们设置为自动启动。如果还不行，看看DCOM Server Process Launcher这个服务是否已经运行？如果没有，启动DCOM服务即可解决。

4. 处理IP设置消息失败

原因分析

SCVPN客户端驱动安装异常

解决方法

1).建议检查当前您是否具有本地PC机的管理员权限，并检查杀毒软件是否有拦截

2).检查本地PC上是否安装了同类VPN客户端软件，并建议删除

3).请删除SCVPN客户端软件后，使用本地PC机管理员重新登陆VPN页面进行安装，在安装过程中如果有杀毒软件提示时请选择允许操作

4).禁用再启用虚拟网卡

5. 卸载SCVPN客户端失败

在注册表中搜索“hssvc”字符串，一旦发现则删除之。

注：修改注册表有风险，谨慎使用。

6. 其他错误

1). 恢复IE的默认设置。具体过程：Ie->选项->Internet选项->高级->重置

2). 设置设备地址为安全站点。具体过程：Ie->选项->Internet选项->安全->受信任的站点->站点->受信任的站点->输入设备地址->添加

3). 查看本地服务列表中Hillstone Secure Connect服务是否存在，如果存

在是否为自动并已启动，如果不存在请重新安装客户端并刷新列表。如果存在但不是自动并已启动，请手动更改状态。

场景二、SCVPN拨号成功后过一分钟左右会自动断开或数据不通

分析：最有可能的原因是两个：一是scvpn拨入的接口所在安全域和实际流量进入的接口安全域不一致,二是scvpn所用的udp端口不通。排除掉这两个因素后根据实际情况抓包分析，下面介绍一个此种情况下的案例：

1. 在故障电脑抓包，过滤到SCVPN地址的报文，查看SCVPN数据的UDP报文传输是否正常。

2. 分析抓包，ping –l 1000的报文：

3. SCVPN也正常的回包了，感觉是SCVPN的客户端没有解密

4. 数据传输用的是UDP报文，从抓包看client 发的报文Server也回了，所以判断PC发的报文应该没有什么问题，需要分析Server 返回的报文为何client

没解密的问题

5. 通过PC的netstat –s –p UDP查看ping不通的情况系统接收的错误UDP报文一直是累加的

6. UDP报文错误一般是checksum，于是再分析Hillstone设备返回报文的的checksum。Wireshark 有checksum 检查功能:Edit>>Preferences,在 Protocols

中选择UDP,将这个选择勾上：7. 再分析Hillstone返回的报文，确实checksum有问题，所以应该是报文的checksum不对被windows系统丢弃了

8. 分析正常情况下的Hillstone的返回报文，发送设备发出来的UDP报文checksum是none的（udp报文的checksum选项是可选的），而客户端显示的checksum不为none且为错误值

9. 所以应该是中间设备修改了该checksum，让client端的电脑跳开他的网络环境直接接Internet测试正常，并且Hillstone返回报文的checksum 是none的，所以基本可以判断是客户端网络中的NAT设备对checksum 值为none处理不当，而对带checksum的udp报文可正常处理，否则dns等应用也无法正常工作

解决方法：升级到4.0R6P184.5R3P115.0R3P45.0R2P5以上的版本，并开启scvpn-udp-checksum enable命令（如果是l2tp over ipsec开启l2tp-udp-checksum enable）。修改命令后，重新连接客户端生效。

场景三、SCVPN拨号后有时候能通有时候不通

1. 在故障电脑抓包，过滤到SCVPN地址的报文，查看SCVPN数据的UDP报文传输是否正常。

2. 分析抓包，ping –l 1000的报文，通过抓包发现不通时发现只有PC发的UDP报文看不到Server返回的报文

3. 要么是PC端发的UDP报文没有到达Hillstone设备；要么是Hillstone设备主动丢弃；要么是Hillstone设备也返回了但没有达到client的电脑

4. 在Hillstone设备上通过DEBUG分析，发现很短时间内从client过来的UDP报文的源端口变化了，造成匹配不上tunnel session从而SCVPN数据传输不正常

2013-09-29 02:56:35, DEBUG@FLOW: core 2 (sys up 0x50fa1b2 ms): 84910: (i)

len=60 0018.82a2.45a1->001c.5416.7f00/800

218.22.20.130->221.224.30.141/17

vhl=45, tos=00, id=58638, frag=0000, ttl=58, tlen=29

udp:ports 47404->4433, len=9

2013-09-29 02:56:40, DEBUG@FLOW: core 2 (sys up 0x50fb540 ms): 84915: (i)

len=60 0018.82a2.45a1->001c.5416.7f00/800

218.22.20.130->221.224.30.141/17

vhl=45, tos=00, id=58694, frag=0000, ttl=58, tlen=29

udp:ports 47570->4433, len=9

5. 怀疑中间的NAT设备的UDP报文的超时时间设置的比较短

6. 和用户一起查看用户端的NAT设备，发现UDP的超时时间设置为5s，修改成200s后SCVPN正常

场景四、SCVPN拨上后立即断开

案例1：

问题描述：

防火墙透明部署，PC、Vswitch接口、Server都在10.88.16.0/24网段。配置SCVPN出接口为vswitch1接口，隧道路由也下发10.88.16.0/24的路由。

PC拨SCVPN，现象为登陆成功后马上断开。

解决方法：

将隧道路由改成Server的主机路由，登陆后就不会断开，且访问正常。

分析定位：

开始远程到客户电脑，查看SCVPN客户端日志，有如下报错：

2013.10.17 14:11:55 LOG_WARNING [2700:6344]: Reach max buffer limit

2013.10.17 14:11:55 LOG_ERR [2700:6344]: Can not allocate buffer for read device file

怀疑是设备内存问题，登陆设备查看，show memory CP内存确实比较高，达到近98%。

由于内存问题不好搞，尝试本地按此拓扑复现，复现成功，且设备内存正常，排除内存原因。

修改隧道路由为服务器的主机路由后，登陆且使用正常时，debug也有以上的报错。但SCVPN客户端不会报错。

接着在PC上抓登陆过程的报文，发现PC发送给设备的最后一个TCP报文源地址为SCVPN地址池的地址，显然有问题。

通常情况SCVPN登陆后PC上会产生一条去往设备出接口的主机路由，保证和设备的通信使用物理网卡，但是发现该拓扑中并没有产生该路由，导致死循环。

测试发现，当PC和设备SCVPN出接口同网段时，不会产生该主机路由，此时如果下发的是默认路由或者下发的隧道路由网段中包含了SCVPN出接口的IP，会导致发包时死循环，登陆成功立即断开；只要PC和SCVPN出接口不是同一网段，登陆后PC上就可以产生该主机路由，使得去往SCVPN出接口的流量走PC物理网卡发出。

案例2：

问题描述：

PC使用U-key登陆SCVPN时，点击登陆后立刻提示断开，该U-key在其他电脑上登陆可以正常使用。

分析定位：

查看SCVPN客户端日志可以看到，在InitSSL usb_key = 2之后，正常的PC接下来会有一条CSP_rsa_sign ret = 1的日志信息，而无法登陆的PC就没有后续信息了。原因是该电脑开启了用户账户控制UAC，关闭即可。如果没有使用U-key认证，UAC原因造成的不能登陆的现象为一直显示正在连接，没有报错，也不提示断开。

场景五、Scvpn更换硬件后提示需要更新证书

客户之前使用的设备A，配置了scvpn功能。由于某些原因更换了其他硬件型号的设备B，配置没有改变，此时用户使用scvpn客户端登陆时候一般都会提示“服务器端证书已改变，请从web方式重新登陆”。如果用户较少可以重新web登陆的方式解决，但如果用户很多，全部重新登陆太麻烦，以下为解决办法：

一． 导出设备A的Scvpn信任域

确定Scvpn使用的信任域（一般默认为trust_domain_default），选择“对象用户---Pki”，选择“管理”，选择信任域、内容（必须选择PKCS#12）、填写密码（随意输入，后期导入时候需要使用）、行为选择导出。

二． 在设备B中新建信任域

进入设备B的Pki管理，新建信任域，输入新信任域名称后，选择“自签名证书”，点击“应用”。

三． 将设备A的信任域导入新建信任域

进入设备B的Pki管理，选择新建立的信任域，选择导入内容（PKCS#12），密码（与步骤1中密码一致），导入的文件。

四． 配置设备B的Scvpn的信任域

打开scvpn配置实例中的高级配置，在参数配置中将信任域修改为新建立的信任域。

注意点：在导出设备A的证书时候，不能分别导出ca证书和本地证书后再导入设备B，因为每台设备都有一个属于自己的私钥，分别导出ca和本地证书后，再导入设备B的时候会因为私钥不匹配而无法导入。