This sounds as if it should be simple, but it is giving me problems.
I have a 4506 switch with a number of VLANs. I have used access lists to implement a sort of reverse-path check on some VLANs, so that if the switch sees packet sourced from an IP address that I do not expect to find on the VLAN, then it is denied.
So, now that I have packets hitting the "deny", and being logged, how can I find their source MAC address so I can trace them through the switches? They are not in the ARP cache because the "router" is not expecting to find them on that VLAN, and so never ARPs for them there. I tried setting a host route for that address to that VLAN, but that did not work; they are not answering even an ARP request to the rogue IP address.
It should be simple to find the MAC address, but I don't know how.
BTW, it is not practicable to snoop the whole VLAN because the volume of traffic through this switch is enormous, and the rogue packets are quite infrequent.
Can anyone tell me if there is any way to log the MAC address of a packet that hits a "deny" on an IP access list?
I believe you already have the ip address of those rogue host correct? If they get an ip address from DHCP server you can go ahead and check the binding table and get to know this ip address is assigned to which mac address.
AFAIK if the switch does not have an arp entry then it is not possible to track the mac address based on ip address.
No, unfortunately they do not come from DHCP as far as I know. If they are, then it is a rogue DHCP server as well! But I don't see any trace of DHCP when I snoop the broadcasts on an access port on the VLAN, so I think they must be coming from somewhere else.
I did consider this. There are two ways I can sniff the VLAN: I could connected the sniffer to an access port on the VLAN, or I can set up a span monitor on the VLAN.
I tried setting a sniffer on an access port on the VLAN, but I received nothing from the rogue address, even when the "router" was telling me that it had seen packets hitting the access list. That tells me that these packets were MAC-unicast to the router. So that makes me wonder where the rogue machine got the router MAC address from. What I suspect is that these packets are originating on some PC that has two NICs in it, one on the VLAN, and the other on a rogue network, and that the PC has bridging enabled on it. Therefore, the PC knows the router MAC address from its ARP on the legitimate side of the network. So I don't think there are any broadcasts to be sniffed, so I am not getting anywhere with the access port.
The alternative is to span the whole VLAN to a monitor port, and use the capture filter on the sniffer. I am reluctant to do that because the VLAN is carrying an aggregate of about 250 Mbps through this switch, and the monitor port is only 100 Mbps. If I do that, I want to absolutely sure that the monitoring process is non-blocking.
Can anyone answer that please? Is it safe to monitor source a vlan that has 250 Mbps running through it when the monitor destination has only 100 Mbps?
Alternatively, is it possible to span monitor the layer-3 vlan interface only?
I know in theory that it should be possible to filter a monitor session with an access list, but I tried that on a quieter VLAN and it did not seem to work when the source was a VLAN. Has anyone else experienced that?
This is a wild idea, but... I can't remember which comes first between ACLs and policy routes? if it's the latter perhaps you could policy route the rogue IP around the ACL and out of another interface - you could put the sniffer there? or if policy routing comes second let the IP through the ACL first.....
I seem to think policy routing might not be fast switched, it could put a heavy load on the CPU...
My initial reaction was great, good idea. And even if the access-list came before the policy route, I could still afford to let a couple of packets through just to diagnose : after all, they won't be going anywhere. And the amount of routed traffic is tiny compared to the local traffic.
But then I thought again ... the router will put its own MAC on the forwarded packets. :-(
Nice idea tho'.
There must be something in the CEF tables or the CAM that will tell me ...
An off the wall kind of idea.
Get a PC or similar, manually configure it with an IP address close to the rogue IP address, I would initially go with a /24 mask, and try to ping the rogue MAC address and check your arp table.
Out of interest (assuming it is not sensitive info) What IP address is popping up? I am just wondering about the 169 addresses that appear from time to time...
I'm afraid I already tried that. I went to a switch that was no ip routing and created a VLAN interface on it and did something similar, but no response .. not even an ARP response.
The address is variable, but always 192.168.x.1. That is why I want to make sure there is no user(s) with a second NIC card attached to an Internet router. It looks suspiciously like the kind of address you would use on a home network router.
I have also had the 169.254.x.y, but I manage to track all those down fairly quickly. They do respond to the technique you suggested. They also tend to be quite broadcasty. It does happen from time to time when someone forgets that we don't do DHCP here. Sometimes I'm tempted to install a single-address honeypot DHCP server, and an alarm on its address on my NMC. That would make those quicker to track down.
Think SMURF attack, any host when hit by a broadcast will respond regardless of its configuration. More specifically now that you know the IP address you are looking for use a ping of the broadcast address or a ping of the network number from the connected router interface and the device will respond. From there you will have an entry in the arp table of the router and the corresponding MAC address.