Gentoo Archives: gentoo-user

From: Pandu Poluan <pandu@××××××.info>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] ARP-Caching of non-link-local adresses
Date: Wed, 04 Jan 2012 17:33:43
Message-Id: CAA2qdGXSRc4yLVACr+wT18y5_iGOvuqd9XQ38w3X6wJ695aWEg@mail.gmail.com
In Reply to: Re: [gentoo-user] ARP-Caching of non-link-local adresses by Pandu Poluan
1 On Jan 5, 2012 12:28 AM, "Pandu Poluan" <pandu@××××××.info> wrote:
2 >
3 >
4 > On Jan 4, 2012 11:20 PM, "Peter Pan" <osaka@×××.net> wrote:
5 > >
6 > > Hi list,
7 > >
8 > >
9 > >
10 > > I’m kind of despair.
11 > >
12 > > The history: We recently brought up a new firewall with Gentoo.
13 > >
14 > > There are (for my finding) some big nets behind this firewall (1x
15 public /24, 2x public /27, 1x public /26, at least 2 private /24).
16 > >
17 > > Filtering is done via iptables and snort should jump as IPS on
18 software-bridge br0. If it helps: There is also ip rule involved for
19 source-based routing.
20 > >
21 > >
22 > >
23 > > The new firewall replaces an older Gentoo-system which did not show
24 this behavior. We therefore copied several configfiles from the old to the
25 new one.
26 > >
27 > >
28 > >
29 > > After getting it live, it runs well for a few hours and then becomes
30 unreachable (also for hosts behind the bridge).
31 > >
32 > > Dmesg / kern.log stated at this time a neighbor table overflow and
33 indeed, arp –n | wc –l showed a lot of entry’s.
34 > >
35 > >
36 > >
37 > > As Google suggested, We then adjusted /proc/sys/net/ipv4/neigh/default/
38 to:
39 > >
40 > > gc_thershold1 -> 8192
41 > >
42 > > gc_thershold2 -> 16384
43 > >
44 > > gc_thershold3 -> 32768
45 > >
46 > >
47 > >
48 > > Fireing an “arp –d $bogus-ip-adress” is failing with
49 „SIOCDARP(dontpub): Network is unreachable”, adding –i br0 doesn’t fail,
50 but does not remove the line in the arp-table (it only says “incomplete”
51 after greping arp -n again)..
52 > >
53 > > Therefore we are currently killing the arp-cache with “ip link set arp
54 off dev br0 && ip link set arp on dev br0” by a cronjob.
55 > >
56 > >
57 > >
58 > > The combination of these workarounds are keeping the firewall reachable
59 and “alive”.
60 > >
61 > >
62 > >
63 > > After stabilizing, we looked at the output of arp –n and noticed, that
64 about 99(.999)% of the roundabout 11.000 (and rising) arp-cache-entry’s
65 contained public addresses for which the bridge of the firewall should not
66 feel responsible (e.g. the public Google-dns-resolver and a load of more).
67 > >
68 > > The MAC-entry for these public addresses is always the one of our
69 router, which is for sure the correct next hop.
70 > >
71 > >
72 > >
73 > > But from my understanding, it should arp-cache only “our” net’s
74 directly at the cable and not those public ones.
75 > >
76 > > It looks like a configuration-issue, but I don’t know, where to start
77 looking. I’ve already checked the default-gateway, netmasks,
78 broadcast-addresses and to me, they are looking fine, so any poke where to
79 start looking is greatly appreciated.
80 > >
81 > >
82 > >
83 > > In case it will help, I attached the /etc/conf.d/net, ifconfig –a and
84 route -n.
85 > >
86 > > If something else is needed, feel free to ask.
87 > >
88 > >
89 > >
90 > > Hope, anyone can help.
91 > >
92 >
93 > Try turning off proxy ARP on the internal and/or external interfaces.
94 >
95
96 Bah, tapped "Send" accidentally. Here's a reference on turning ON Proxy ARP:
97
98 http://www.sjdjweis.com/linux/proxyarp/
99
100 Use "echo 0" to turn off.
101
102 If it works, make the concomitant changes in /etc/sysctl.conf
103
104 Rgds,