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 1RiV8V-0001pb-RG for garchives@archives.gentoo.org; Wed, 04 Jan 2012 18:00:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 282A421C18F; Wed, 4 Jan 2012 18:00:09 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pigeon.gentoo.org (Postfix) with SMTP id E799E21C16B for ; Wed, 4 Jan 2012 17:58:15 +0000 (UTC) Received: (qmail invoked by alias); 04 Jan 2012 17:58:14 -0000 Received: from e180006144.adsl.alicedsl.de (EHLO Dyonysos) [85.180.6.144] by mail.gmx.net (mp021) with SMTP; 04 Jan 2012 18:58:14 +0100 X-Authenticated: #20459314 X-Provags-ID: V01U2FsdGVkX1+52hU5DeW5wnCGFKssIsYLtgbgca4kX6rBuhMwh/ /OKlggTOYyBK4s From: "Peter Pan" To: References: <001d01cccafc$650f4290$2f2dc7b0$@gmx.net> In-Reply-To: Subject: AW: [gentoo-user] ARP-Caching of non-link-local adresses Date: Wed, 4 Jan 2012 18:58:13 +0100 Message-ID: <000d01cccb0a$6e5b7220$4b125660$@gmx.net> 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 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CCCB12.D02187D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG2bvM0q1XoWW2e63on4KscFr3yAgM8AUEPlg9WCIA= Content-Language: de X-Y-GMX-Trusted: 0 X-Archives-Salt: be6c16fa-41a7-496d-a10b-ebe6a427cecb X-Archives-Hash: b89257c7c0f561e82d9af9cabfe3e763 This is a multipart message in MIME format. ------=_NextPart_000_000E_01CCCB12.D02187D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pandu,=20 =20 thanks for your reply. As far as I can see, proxy_arp is not enabled on any interfaces: =20 host conf # pwd /proc/sys/net/ipv4/conf Host conf # for f in $(find | grep -i proxy_arp | grep -v pvlan ); do = echo $f && cat $f ;done ./all/proxy_arp 0 ./default/proxy_arp 0 ./lo/proxy_arp 0 ./sit0/proxy_arp 0 ./lan/proxy_arp 0 ./dmz/proxy_arp 0 ./isp/proxy_arp 0 ./dsl/proxy_arp 0 ./wlan/proxy_arp 0 ./mgm/proxy_arp 0 ./br0/proxy_arp 0 ./ppp0/proxy_arp 0 ./tun1/proxy_arp 0 ./tun0/proxy_arp 0 =20 Regards, Ralf =20 Von: Pandu Poluan [mailto:pandu@poluan.info]=20 Gesendet: Mittwoch, 4. Januar 2012 18:29 An: gentoo-user@lists.gentoo.org Betreff: Re: [gentoo-user] ARP-Caching of non-link-local adresses =20 On Jan 4, 2012 11:20 PM, "Peter Pan" wrote: > > Hi list, > > =20 > > 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. > > =20 > > 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. > > =20 > > 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. > > =20 > > As Google suggested, We then adjusted = /proc/sys/net/ipv4/neigh/default/ to: > > gc_thershold1 -> 8192 > > gc_thershold2 -> 16384 > > gc_thershold3 -> 32768 > > =20 > > Fireing an =E2=80=9Carp =E2=80=93d $bogus-ip-adress=E2=80=9D is = failing 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 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 set arp off dev br0 && ip link set arp on dev br0=E2=80=9D by a = cronjob. > > =20 > > The combination of these workarounds are keeping the firewall = reachable and =E2=80=9Calive=E2=80=9D. > > =20 > > 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. > > =20 > > 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 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 to start looking is greatly appreciated. > > =20 > > 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. > > =20 > > Hope, anyone can help. > Try turning off proxy ARP on the internal and/or external interfaces. Rgds, ------=_NextPart_000_000E_01CCCB12.D02187D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Pandu,

 

thanks for your = reply.

As far as I can see, proxy_arp is not enabled on any = interfaces:

 

host conf # pwd

/proc/sys/net/ipv4/conf

Host conf # for f in = $(find=C2=A0 | grep -i proxy_arp | grep -v pvlan ); do echo $f = && cat $f ;done

./all/proxy_arp

0

./default/proxy_arp

0

./lo/proxy_arp

0

./sit0/proxy_arp

0

./lan/proxy_arp

0

./dmz/proxy_arp

0

./isp/proxy_arp

0

./dsl/proxy_arp

0

./wlan/proxy_arp

0

./mgm/proxy_arp

0

./br0/proxy_arp

0

./ppp0/proxy_arp

0

./tun1/proxy_arp

0

./tun0/proxy_arp

0

 

Regards,

Ralf

 

Von:<= /b> = Pandu Poluan [mailto:pandu@poluan.info]
Gesendet: Mittwoch, = 4. Januar 2012 18:29
An: = gentoo-user@lists.gentoo.org
Betreff: Re: [gentoo-user] = ARP-Caching of non-link-local adresses

 


On Jan 4, 2012 11:20 PM, = "Peter Pan" <osaka@gmx.net> = 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 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 = 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 set 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.
>
> =             &= nbsp;     
>
> 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 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 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,

------=_NextPart_000_000E_01CCCB12.D02187D0--