From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RiUf5-0002TO-Ic for garchives@archives.gentoo.org; Wed, 04 Jan 2012 17:30:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E8DA321C13D; Wed, 4 Jan 2012 17:29:48 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id E09CD21C043 for ; Wed, 4 Jan 2012 17:28:37 +0000 (UTC) Received: from mail-ww0-f53.google.com ([74.125.82.53]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1RiUdk-003pnG-CK for gentoo-user@lists.gentoo.org; Thu, 05 Jan 2012 00:28:40 +0700 Received: by wgbds1 with SMTP id ds1so26702777wgb.10 for ; Wed, 04 Jan 2012 09:28:33 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.227.197.78 with SMTP id ej14mr56905881wbb.2.1325698113327; Wed, 04 Jan 2012 09:28:33 -0800 (PST) Received: by 10.223.78.208 with HTTP; Wed, 4 Jan 2012 09:28:33 -0800 (PST) Received: by 10.223.78.208 with HTTP; Wed, 4 Jan 2012 09:28:33 -0800 (PST) In-Reply-To: <001d01cccafc$650f4290$2f2dc7b0$@gmx.net> References: <001d01cccafc$650f4290$2f2dc7b0$@gmx.net> Date: Thu, 5 Jan 2012 00:28:33 +0700 Message-ID: Subject: Re: [gentoo-user] ARP-Caching of non-link-local adresses From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=0015174c3fd41fd20804b5b72581 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: 4b7f1660-95be-448c-a501-3be0341250bd X-Archives-Hash: a359450d1fbad8f17dbd494e78054947 --0015174c3fd41fd20804b5b72581 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jan 4, 2012 11:20 PM, "Peter Pan" wrote: > > Hi list, > > > > I=E2=80=99m kind of despair. > > The history: We recently brought up a new firewall with Gentoo. > > There are (for my finding) some big nets behind this firewall (1x public /24, 2x public /27, 1x public /26, at least 2 private /24). > > Filtering is done via iptables and snort should jump as IPS on software-bridge br0. If it helps: There is also ip rule involved for source-based routing. > > > > The new firewall replaces an older Gentoo-system which did not show this behavior. We therefore copied several configfiles from the old to the new one. > > > > After getting it live, it runs well for a few hours and then becomes unreachable (also for hosts behind the bridge). > > Dmesg / kern.log stated at this time a neighbor table overflow and indeed, arp =E2=80=93n | wc =E2=80=93l showed a lot of entry=E2=80=99s. > > > > As Google suggested, We then adjusted /proc/sys/net/ipv4/neigh/default/ to: > > gc_thershold1 -> 8192 > > gc_thershold2 -> 16384 > > gc_thershold3 -> 32768 > > > > Fireing an =E2=80=9Carp =E2=80=93d $bogus-ip-adress=E2=80=9D is failing w= ith =E2=80=9ESIOCDARP(dontpub): Network is unreachable=E2=80=9D, adding =E2=80=93i br0 doesn=E2=80=99t fail= , but does not remove the line in the arp-table (it only says =E2=80=9Cincomplete=E2=80=9D after = greping arp -n again).. > > Therefore we are currently killing the arp-cache with =E2=80=9Cip link s= et arp off dev br0 && ip link set arp on dev br0=E2=80=9D by a cronjob. > > > > The combination of these workarounds are keeping the firewall reachable and =E2=80=9Calive=E2=80=9D. > > > > After stabilizing, we looked at the output of arp =E2=80=93n and noticed,= that about 99(.999)% of the roundabout 11.000 (and rising) arp-cache-entry=E2=80= =99s contained public addresses for which the bridge of the firewall should not feel responsible (e.g. the public Google-dns-resolver and a load of more). > > The MAC-entry for these public addresses is always the one of our router, which is for sure the correct next hop. > > > > But from my understanding, it should arp-cache only =E2=80=9Cour=E2=80= =9D net=E2=80=99s directly at the cable and not those public ones. > > It looks like a configuration-issue, but I don=E2=80=99t know, where to s= tart looking. I=E2=80=99ve already checked the default-gateway, netmasks, broadcast-addresses and to me, they are looking fine, so any poke where to start looking is greatly appreciated. > > > > In case it will help, I attached the /etc/conf.d/net, ifconfig =E2=80=93a= and route -n. > > If something else is needed, feel free to ask. > > > > Hope, anyone can help. > Try turning off proxy ARP on the internal and/or external interfaces. Rgds, --0015174c3fd41fd20804b5b72581 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 4, 2012 11:20 PM, "Peter Pan" <osaka@gmx.net> wrote:
>
> Hi list,
>
> =C2=A0
>
> I=E2=80=99m kind of despair.
>
> The history: We recently brought up a new firewall with Gentoo.
>
> There are (for my finding) some big nets behind this firewall (1x publ= ic /24, 2x public /27, 1x public /26, at least 2 private /24).
>
> Filtering is done via iptables and snort should jump as IPS on softwar= e-bridge br0. If it helps: There is also ip rule involved for source-based = routing.
>
> =C2=A0
>
> The new firewall replaces an older Gentoo-system which did not show th= is behavior. We therefore copied several configfiles from the old to the ne= w one.
>
> =C2=A0
>
> After getting it live, it runs well for a few hours and then becomes u= nreachable (also for hosts behind the bridge).
>
> Dmesg / kern.log stated at this time a neighbor table overflow and ind= eed, arp =E2=80=93n | wc =E2=80=93l showed a lot of entry=E2=80=99s.
>
> =C2=A0
>
> As Google suggested, We then adjusted /proc/sys/net/ipv4/neigh/default= / to:
>
> gc_thershold1 -> 8192
>
> gc_thershold2 -> 16384
>
> gc_thershold3 -> 32768
>
> =C2=A0
>
> Fireing an =E2=80=9Carp =E2=80=93d $bogus-ip-adress=E2=80=9D is failin= g with =E2=80=9ESIOCDARP(dontpub): Network is unreachable=E2=80=9D, adding = =E2=80=93i br0 doesn=E2=80=99t fail, but does not remove the line in the ar= p-table (it only says =E2=80=9Cincomplete=E2=80=9D after greping arp -n aga= in)..
>
> Therefore we are currently killing the arp-cache =C2=A0with =E2=80=9Ci= p link set arp off dev br0 && ip link set arp on dev br0=E2=80=9D b= y a cronjob.
>
> =C2=A0
>
> The combination of these workarounds are keeping the firewall reachabl= e and =E2=80=9Calive=E2=80=9D.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>
> After stabilizing, we looked at the output of arp =E2=80=93n and notic= ed, that about 99(.999)% of the roundabout 11.000 (and rising) arp-cache-en= try=E2=80=99s contained public addresses for which the bridge of the firewa= ll should not feel responsible (e.g. the public Google-dns-resolver and a l= oad of more).
>
> The MAC-entry for these public addresses is always the one of our rout= er, which is for sure the correct next hop.
>
> =C2=A0
>
> But from my understanding, =C2=A0it should arp-cache only =E2=80=9Cour= =E2=80=9D net=E2=80=99s directly at the cable and not those public ones. >
> It looks like a configuration-issue, but I don=E2=80=99t know, where t= o start looking. I=E2=80=99ve already checked the default-gateway, netmasks= , broadcast-addresses and to me, they are looking fine, so any poke where t= o start looking is greatly appreciated.
>
> =C2=A0
>
> In case it will help, I attached the /etc/conf.d/net, ifconfig =E2=80= =93a and route -n.
>
> If something else is needed, feel free to ask.
>
> =C2=A0
>
> Hope, anyone can help.
>

Try turning off proxy ARP on the internal and/or external interfaces.

Rgds,

--0015174c3fd41fd20804b5b72581--