Re: Wackamole problem with arp cache on firewall/gateway

I think this might be a bug/missing feature in Wackamole 2.0.0    After 
much messing around I figured out arprelease 
(http://arprelease.sourceforge.net/ ) had no problem remotely flushing 
my firewall's arp table.

Thus I theorized it was a bug in wackamole and  tried Wackamole from CVS 
(as of this evening) and everything works fine!  I did some diff's and 
looked at some cvs logs but there were lots of changes and  I was unable 
to figure out what made the CVS version work and the 2.0.0 fail.

So My questions:

1.  Is the Wackamole CVS version stable enough for production use?

2. Any idea why the CVS version can remotely update the arp cache on my 
firewall, but 2.0.0 fails?   (Note: With the 2.0.0 version , it seems to 
be able to update the cache after it expires in 20 minutes.  However, 
the CVS version can do it instantly).

Thank you for your time,
-Rama

Theo Schlossnagle wrote:

>
> On Dec 11, 2003, at 1:48 PM, Rama K. McIntosh wrote:
>
>> Everything works perfect, except my firewall/gateway arp cache does 
>> not get updated.   My firewall is not running Wackamole but I thought 
>> the Notify part of wackamole would tell my firewall  to refresh it's 
>> arp cache.  If I manually delete the arp entry in my firewall 
>> everything works after wackamole changes the owner of my virtual 
>> IP.   Actually, only the two machines running wackamole seem to have 
>> good arp caches.  Every other machine (solaris) on my subnet has a 
>> stale arp entry.
>>
>> Here is my conf (with the IPs changed to protect the guilty):
>> Notify {
>>        # Let's notify our router:  ***** My firwall, 10.10.10.1's arp 
>> cache becomes stale, this is my problem **********
>>        eth0:10.10.10.1/32
>
>
> What kind of firewall is it?
>
> So.  Try adding eth0:0.0.0.0/32 and eth0:255.255.255.0/32 and and 
> eth0:networkaddress/32 and eth0:broadcastaddress/32 (where network 
> address or broadcast address is the IP network address and IP 
> broadcast address on that subnet, respectively).
>
> Different devices and OSs respond differently to unsolicited ARP 
> responses.  Some take "protective measures" to disable this to prevent 
> "arp-spoofing" attacks.  On FreeBSD/NetBSD/OpenBSD I believe there is 
> a kernel option to allow/disallow this.  Sometimes systems are more 
> receptive to unsolicited arp resopnses to IP network, IP broadcast, IP 
> subnet, or IP subnet broadcast addresses.
>
> Check the logs on your firewall to see if it sees the ARP request but 
> is rejecting it.
>
> // Theo Schlossnagle
> // Principal Engineer -- http://www.omniti.com/~jesus/
> // Postal Engine -- http://www.postalengine.com/
> // Ecelerity: fastest MTA on earth
>
>
> _______________________________________________
> wackamole-users mailing list
> [email protected]
> http://lists.backhand.org/mailman/listinfo/wackamole-users
>