背景描述：

在部署Remote AP时，我们会设置Bridge Forward Mode（基于Virtual AP配置下）来实现用户的本地桥接转发数据，尤其在AGV小车的无线连接场景下，我们需要该AGV小车的流量可以本地转发，同时也需要本地的服务器可以网络访问该AGV小车来实现数据运维的操作。

那我们发现本地服务器通过FTP或者SSH方式去访问无线侧的AGV小车时，无法成功。而本地服务器通过ping方式去访问无线侧的AGV小车，是可以成功的。

原因：

在Remote AP的场景下，如果无线用户采用了Bridge Forward Mode，那么该无线用户从无线侧访问有线侧数据时，是经过AP的firewall role策略控制的。而当有线侧的服务器访问无线侧的AGV小车时，默认是有ACL来控制的，该ACL默认是在 AP system profile中Session ACL中被调用，默认值是 ap-uplink-acl，仅仅影响的是Remote AP 部署，而CAP不受影响。

默认的ap-uplink-acl的策略如下:

ip access-list session ap-uplink-acl 
any any udp 68 permit 
any any svc-icmp permit 
any host 224.0.0.251 udp 5353 permit 
ipv6 any any udp 546 permit 
ipv6 any any svc-v6-icmp permit 
ipv6 any host ff02::fb udp 5353 permit

这样，默认仅仅开放了上述的几个端口，所以当你的有线侧服务器主动去访问AGV小车的FTP或者SSH时，是无法访问的，而如果是Ping的话，系统默认是放行的。

解决办法：

我们需要修改该ACL中的策略即可，由于我们是基于状态防火墙的策略机制，仅仅只要单向建立相关的ACL访问策略，而击中该策略的回应报文会自动被放行。

需要将默认的ap-uplink-acl的策略修改为如下的：

CLI参考

ip access-list session ap-uplink-acl 
any any udp 68 permit 
any any svc-icmp permit 
any host 224.0.0.251 udp 5353 permit 
any any svc-ftp permit 
any any svc-ssh permit
ipv6 any any udp 546 permit 
ipv6 any any svc-v6-icmp permit 
ipv6 any host ff02::fb udp 5353 permit

这样才能保证有线侧的服务器可以主动访问无线侧的AGV小车的FTP和SSH服务。

我们在设置策略规则时，源地址和目标地址中，经常会碰到user 和 any的参数，那么通常我们将user代表的是该角色下的任何无线用户（即进入到user-table中的该角色的无线用户，一般代表的是untrusted 无线用户），而不关心该用户的源地址是什么。在user中，不能包含的是有线侧的源地址用户（通常Aruba的控制器会将有线侧的用户认为是trusted 用户，不进入到user-table的，除非你在接口上设置为untrusted）。

而any代表的是无线用户和有线用户全体。比如我们配置下面的策略ACL时，实现的效果是不一样的：

1. 如果是any，可以是无线侧用户主动发起的报文，也可以是有线侧的用户主动发起的报文。
2. 如果是user，仅仅只能是无线侧的用户主动发起的报文，而有线侧的用户主动发起的报文不会匹配user别名的。
3. 所有的策略都是基于状态防火墙的，仅仅只要单向策略即可，一个session发起和回应都会击中同一个ACL策略。