I assume that you are not seeing anything in "show attack stats"? Do you see the ARP packet counter increasing?
# show attack stats
attack counters
--------------------------------------
Counter Value
------- -------
arp packet counter 152
drop bad arp packet counter 0
dhcp response packet counter 0
fixed bad dhcp packet counter 0
send arp attack alert counter 0
send dhcp attack alert counter 0
arp poison check counter 0
garp send check counter 0
To be honest, whether you are spoofing the GW or another client, then (IMHO) the effect for a MITM attack should be the same.
I have tested this in the lab and I see something that strikes me as strange:
# show arp
IP address HW type Flags HW address Mask Device
10.10.51.5 0x1 0x2 24:a0:74:xx:xx:xx * br0
10.10.51.1 0x1 0x2 24:a0:74:xx:xx:xx * br0
I have obfuscated the last bytes of the test PC's MAC@, but as you can see the client IP is 10.10.51.5 and is spoofing the def. GW's address (10.10.51.1 = upstream router) and the IAP has updated its ARP table with the test PC's MAC@. On another test PC connected to the same WiFi network and subnet, the def. GW is also seen as 24:a0:74:xx:xx:xx, so by definition, the ARP poisoning can be considered to have worked.
As the test PC is a WiFi client, I would have thought that should be enough to trigger alarm bells in the IAP i.e. IAP should think "how is my def. GW coming from a WiFi client?" A pkt debug on the IAP confirms this:
Received packet from bond0 (timestamp (117-2-3 12:52:35:455531))
[asap_firewall_forward(5457):firewall entry] len 60, vlan 0, egress CP, ingress bond0:
#mac: etype 0806 smac 24:a0:74:xx:xx:xx dmac ff:ff:ff:ff:ff:ff
#arp: opcode response(2), sip 10.10.51.1, tip 0.0.0.0, smac 24:a0:74:xx:xx:xx, tmac ff:ff:ff:ff:ff:ff
[asap_firewall_forward(5633):vlan decision] len 60, vlan 1, egress CP, ingress bond0:
[asap_firewall_forward(6142):looking up pkt ingress/src bridge entry 24:a0:74:xx:xx:xx] len 60, vlan 1, egress CP, ingress bond0:
[asap_firewall_forward(6182):Found ingress/src bridge entry 24:a0:74:xx:xx:xx rechable via bond0] len 60, vlan 1, egress CP, ingress bond0:
[asap_firewall_forward(6473):bridge section, looking for dst bridge entry ff:ff:ff:ff:ff:ff] len 60, vlan 1, egress CP, ingress bond0:
[asap_firewall_forward(6569):Unable to find dst bridge entry ff:ff:ff:ff:ff:ff, flood to VLAN 1] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_forward(6604):session section] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_forward(6851):fastpath session returned 0 opcode 0] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_forward(7421):route section] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_forward(7471):cp route section] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_forward(7789):forward section] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_flood(9215):flooding] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_flood(9419):checking dev2 bond0] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_flood(9988):stack section protocol=0x806, type=1] len 60, vlan 1, egress vlan 1, ingress bond0:
[asap_firewall_send_up_stack(3697):going to stack protocol:0x806 type:1] len 46, vlan 1, egress vlan 1, ingress br0:
This needs some further testing, because here the test PC's and IAP are all using the same subnet (def. VLAN 1).
Do you have a TAC case open for this?
David