Please implement this arpon opensource project on mikrotik, this very helpful to prevent arp snooping, i don't see a reason why mikrotik doesn't want to implement this, the package already runnable at linux and bsd, here is the site : http://arpon.sourceforge.net . If mikrotik implemented this, mikrotik would most powerful soho router available on the market with affordable price .

But this is not very usefull if it's only implemented on the router. According to the website it has to be implemented on every node (router, clients, ...) and since it's not available on windows which most of the clients run

cmon mikrotik must be apply dynamic arp inspection, customer just few clicks away to steal everything from my hotspot ,or mikrotik could add this as an addon to the mikrotik os?i don't mind paying 50-100$ for this addon.I cann't apply static arp fix as my client would be varied for their mac address .

Someone spoofing a MAC and IP address combination can't be caught on a router, it MUST be caught on the edge switch port. If the clients are connected to the same AP you can't tell at all. That's how ARP inspection works.
If a frame comes in with the same source and destination MAC addresses, and the frame encapsulates an IP packet with the same source and destination IP addresses, how is the router supposed to tell they are from different clients? They look 100% identical.

Someone spoofing a MAC and IP address combination can't be caught on a router, it MUST be caught on the edge switch port. If the clients are connected to the same AP you can't tell at all. That's how ARP inspection works.
If a frame comes in with the same source and destination MAC addresses, and the frame encapsulates an IP packet with the same source and destination IP addresses, how is the router supposed to tell they are from different clients? They look 100% identical.

When running as AP mikrotik is the edge switch.

An AP cannot determine MAC/IP spoofing when both clients are connected to the same radio because there is no physical connection to differentiate the two.
A switch can't tell either when there's a hub behind the switch port and the original and cloned machine are behind the hub.

An AP cannot determine MAC/IP spoofing when both clients are connected to the same radio because there is no physical connection to differentiate the two.
A switch can't tell either when there's a hub behind the switch port and the original and cloned machine are behind the hub.

Yes, you're right. Theoretically, though, one could tell the client by 802.11 frame when using encryption and per user GTK...

i am sorry i am newbie at networking stuff, if so what's the fancy about dhcp snooping/dynamic arp inspection?, if even this cann't really fix this problem, how the big boys(cisco,junifer) fix this in their network for guest authenticating? i mean without static arp.

They only have it solved for certain deployment scenarios.

If you have a switch with 24 ports you can inspect all ARP and DHCP traffic and determine what MAC/IP address combination sits behind each switchport. Let's say user A sits behind port 1, and the switch notes that. Then user B connects to port 2 and spoofs user A's MAC and IP address. The switch sees that, knows that the MAC/IP combination should be behind port 1, and shuts down port 2 and generates an alert. That works great, and could work on RouterOS in scenarios where clients connect to different ports on the same broadcast domain. Now let's say there's an unmanaged hub or switch connected to port 1 on a switch that does ARP and DHCP inspection, and user A and the malicious user B both connect to that hub. At that point the switch doing inspection sees the same MAC/IP combination from both users, but they're both sourced from the same switchport. Both users will experience performance degradation unless it's a true hub that floods out all ports, but the switch doing the inspection doesn't know that because it isn't the thing directly connected to the users. The switch cannot tell that the frames are sourced from two different machines and doesn't generate an alert.
The same principle applies to APs - if user A and user B connect to the same radio the radio - being of a nature where it just transmits stuff into the air and receives stuff from the air - cannot tell that there are two users receiving the signals, or that the signal comes from two different machines. On wireless there is far less of a penalty for this, as a wireless radio is essentially a hub that just sends stuff that can be seen by anyone.

You can work around this by requiring more user authentication, but that simply isn't possible to deploy on open access systems such as Hotspots. Having users provide credentials used to generate per user encryption of signals defeats the purpose of having a system anyone can connect to. You also absolutely HAVE to have users connect directly to the device doing the inspection. It is generally speaking fairly rare that users connect directly to a router, and of course RouterOS is primarily a router or wireless AP.

I'm not saying RouterOS shouldn't do DHCP and ARP inspection, I'm just cautioning that the primary deployment purposes of RouterOS are ill suited for that function and that many times it will not solve your problem. But there are absolutely situations where having it would help. I'd also like to see 802.1x for the same reason - usually RouterOS isn't in a position where you'd do 802.1x against it, but sometimes it is and then it would be useful to have.

I think ARPWATCH (or other MAC changes information via email) would be very helpfull. Pleas mikrotik guys implement this

Thanks

As far as ArpWatch goes, you can throw together a nice script to do this task. It may take some work, but it can be done (with email notifications, firewall blockage, hotspot redirection, the whole thing).

Yes we have workaround, but native function would be nice.

@fewi
Great insight, thanks, now i more understand why it's quite hard to block, for now my temporary 'cheap' solution is flash my ap(wrt54gl) with ddwrt and enable client isolation, now it seems the spoofing are stopped. Haven't tested with netcut tough.

@dssmiktik & @mindaugasr
if you guys don't mind to share the tricks?, would be helpful to community. Yeah, Mikrotik should implement this as a core feature then it would be perfect.

Solaris, I installed debian OS on virtual cloud on it arpwatch, aprox 5minutes try ping broadcast my network, and arpwatch resolves all ip and mac bindings in network and report changes via email, that simple my workaround. Native function i agree would be better.

Best regards,
Mindaugas R.

Solaris, I installed debian OS on virtual cloud on it arpwatch, aprox 5minutes try ping broadcast my network, and arpwatch resolves all ip and mac bindings in network and report changes via email, that simple my workaround. Native function i agree would be better.

Best regards,
Mindaugas R.

I've had the same ideas to run it on metarouter but it stop me to realize, it takes much more resource to run good linux distro on it, i've only run this on rb1100 so it doesn't have that much resources, by your idea i've guess it possible to sort of kill the suspected ip & mac by setup a web server on that monitoring box and log in all of the ip & mac, then from mikrotik to fetch the log and process it through firewall rules, hmm long process and lot's of scripting, i think i would wait for mikrotik have the heart to solve this out the box .

Do you think mikrotik should have uservoice pages? where customer have the chances to vote which feature they need the most?.

Do you think mikrotik should have uservoice pages? where customer have the chances to vote which feature they need the most?.

http://wiki.mikrotik.com/wiki/Category:Requests

Wow, I haven't checked that for awhile. I agree it should be a "rolling list" similar to the release format. Just keep adding requests, and Mikrotik keep releasing. This process should work pretty good, but so far it's failing for some reason when new versions are released.

DHCP snooping and ARP inspection / MAC protection is more something for switches.

If you need such a high level of protection, you can use 802.1x and a radius server to manage VLAN access and priority according to users. For devices not supporting 802.1x, you can use MAC control or WEB control. All this is managed easily by advanced switches, not routers.

All entry level fully managable switches can do this today. Smart switches cannot, you need at least level 3 switches (quite expensive).


Don't forget that even with 802.1x, the trafic is clear, so it's possible to sniff it on the wires or on the fiber, with a simple copper tap or macrobend tap for fiber, regardless wich protection you put in the switches.

For full protection, you need to use IPSEC on the LAN... Do you really want to do this ?

Last, if you want free ARP protection, you can disable ARP on Ethernet interfaces and define static ARP tables on each machine on the network, even Router OS can do this and it's very safe, simple, and efficient.