PC与S6520-EI上的int vlan12互连,绑定vpn;int vlan 12上开启portal认证,方式为直接认证;vpn内存在默认路由引向防火墙,互连接口为int vlan1001;流量经过防火墙再次回到交换机的公网接口int vlan 1002;认证时报文需到IMC侧进行认证。PC到IMC ping测试可达。
某局点使用S6520-EI结合IMC进行portal认证。当PC、IMC和交换机都在公网侧时,流量不经过防火墙时,PC可以正常认证上线;当如认证报文经过防火墙时,portal认证有web弹窗,但是无法上线,提示超时。
1、 根据反馈的诊断查看设备相关信息,设备上无硬件相关报错,配置也未见异常,终端到IMC网络可达,并且相关地址也都在防火墙上放通策略。结合现场通过公网直连的方式进行认证时可以正常上线,判断设备、IMC侧的portal功能正常,怀疑现场组网原因导致无法进行认证;
2、 收集了终端上线时debugging portal all和debugging radius all信息发现,设备能够将报文重定向至portal server,并且IMC也能回应对应的portal报文和radius报文,但是到达交换机时却因找不到终端的接入接口而丢弃:
*Aug 4 22:01:22:624 2021 SW1 PORTAL/7/ERROR:
Packet validity check failed due to failure of getting user access interface by user IP.
3、根据设备portal认证报文处理的机制以及设备上的配置分析,当portal server回复的报文到达交换机时,会根据portal报文中的user ip、从0开始遍历vrf查找fib表项获取对应的用户接入的接口和vpn;当前设备上有不带vpn的明细OSPF路由,所以查表时能在vrfIndex=0时便能查到fib表项,进而认为用户是从Vlan1002接入的,而interface Vlan1002没有使能Portal,所以会丢弃收到的Portal报文。
===============display fib===============
Destination/Mask Nexthop Flag OutInterface/Token Label
10.1.1.0/24 172.16.100.189 UDGR Vlan1002 Null
4、 综合以上,判断现场的服务器回复的报文到达交换机后因出接口int vlan 1002未使能portal,导致报文丢弃无法继续发给终端。至于这种情况下终端能够弹出web界面,则是因为交换机上连接终端的int vlan 12上使能了portal,设备底层会下发redirect的重定向acl,指导转发终端的请求到web服务器进行认证,这种流量就是常规的三层转发,不涉及交换机处理。
Pri 6, Group 5,usedEntries 66,mode Double, physlice 4/5/
==================================================================
acl type usedEntries[66] all[256] remain[190]
==================================================================
[32 ]Portal Free 8
[33 ]Portal User 54
[34 ]Portal Redirect 2
[35 ]Portal Deny 2
针对这种组网情况,可以通过以下两种途径来解决问题:
1、建议调整组网,不要将portal认证报文经过防火墙三层转发;
2、在int vlan1002上开启跨三层portal认证,关闭int vlan 12上的直连portal认证。这种方案的思路是将终端的流量理解为经过交换机的vrf--防火墙--交换机公网进行跨三层portal认证。该方案存在的缺陷是,所有经过交换机int vlan1002进行三层转发的流量都需要经过portal认证。