linux, zywall and arp flux

Z replied on arp who-has from both interfaces, and L chooses wrong answer from time to time. Because ARP was populated, subsequent arp request was not sent to broadcast, but to specific mac, just to refresh arp cache entry. When we cleaned arp table, first request was sent to broadcast and both replys showed up .. huh. never saw it before.

/home/bodik# cat arp.py
#! /usr/bin/env python
# arping2tex : arpings a network and outputs a LaTeX table as a result
import sys
if len(sys.argv) != 2:
    print "Usage: arping2tex <net>\n  eg: arping2tex 192.168.1.0/24"
    sys.exit(1)
from scapy import srp,Ether,ARP,conf
conf.verb=0
ans,unans=srp(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst=sys.argv[1]), timeout=2)
for snd,rcv in ans:
    print rcv.sprintf(r"%Ether.src% & %ARP.psrc%")

/home/bodik# python arp.py  xx.yy.102.1/32
00:zz:ww:09:21:96 & xx.yy.102.1

# tcpdump arp
00:10:48.789724 arp who-has xx.yy.102.1 tell xx.yy.102.8
00:10:48.790086 arp reply xx.yy.102.1 is-at 00:zz:ww:09:21:96
00:10:48.790116 arp reply xx.yy.102.1 is-at 00:zz:ww:09:21:95
 
/home/bodik# python arp.py  xx.yy.102.2/32
00:zz:ww:09:21:96 & xx.yy.102.2

# tcpdump arp
00:10:36.032704 arp who-has xx.yy.102.2 tell xx.yy.102.8
00:10:36.033048 arp reply xx.yy.102.2 is-at 00:zz:ww:09:21:96
00:10:36.033088 arp reply xx.yy.102.2 is-at 00:zz:ww:09:21:95

Zyxel support stated, that this behavior is quite fine, and it's part of some security policy. I think that linux would handle cross mac/ip communication in kernel fine, but zywall blocks it since it is not really by the rules, and so it prevents arp poisoning/manipulating attacks.

  • techblog/arp_flux.txt
  • Last modified: 2018/09/01 20:14
  • by bodik