Hi Tom Thank you for your detailed reply. Greatly appreciated, I now see how you implemented proxyarp in shorewall.
The gateway on the "proxied" hosts is not an ip address defined on the firewall, but really the ip address of a router on the other side of the bridge as expected. But thanks to your example, I now understand where my "broken" view differs: My setup is more "manual". Indeed I defined in the proxyarp file what host lies on _each_ side of the bridge, thus I end with public static arp defined on _both_ sides of the bridge (and as a consequence the proxy_arp parameters that was bugging me on both interfaces , but I now understand why). That implies that if I need to split a whole /24 in my setup, I'll have 254 lines on the proxyarp file, some in the form "IP1 eth0 eth1" and others "IP2 eth1 eth0". That was not a problem for us as we added ips on a host-per-host basis, together with traffic control/shaping policies. I based this setup on a poor-man's bridge I implemented back in 99 to split an ethernet segment across a ppp fiber link using only static / 32 route and public arp entries. So in your example I'd not only define 206.124.146.177 eth0 eth1 but also the following: 206.124.146.222 eth1 eth0 I didn't consider when I implemented that setup that everything is ahead the firewall but the individual ips listed in proxyarp. Instead I "told" the bridge what to pretend to be on each side, on an ip by ip basis. Anyway, a lot of thanks for your support ! Kind regards Gaetan On 19-nov.-07, at 16:35, Tom Eastep wrote: > Gaëtan Minet wrote: > >> >>>> Of course manually resetting the /proc/sys/net/ipv4/ >>>> conf<interface>/ >>>> proxy_arp to 0 immediately solves the problem. >>>> I tested this behavior with shorewall 2.2.x through 3.2.5. Could >>>> this >>>> be solved in 4.x ? >>> Proxy ARP doesn't work without it -- it will never be 'solved'. > >> As for proxy arp not working without it, I believe you, but don't >> really understand why. >> >> Are you saying that proxyarp functionality - even when activated >> through static public arp addresses - is completely disabled in the >> kernel for the related interface when this parameter is off ? Doesn't >> this parameter only relate to "automatic" proxyarp for hosts / >> networks >> addresses in the firewall's routing table (i.e. proxyarp >> subnetworking) ? >> >> I do not need that automatic behavior, and reading the shorewall >> code, >> the proxyarp file in shorewall does just that: add static public arp >> entries. Why add those entries in shorewall if anyway shorewall will >> activate the proxy_arp flag that will automatically reply based on >> the >> routing table ? I'm further confused by this comment in the >> interfaces file as it seems to imply that shorewall really knows of >> "2 ways" for doing proxyarp: > > <quotes from documentation snipped> > >> >> I'll do some more checks on the arp table cache of servers behind the >> firewall with the current setup, but with the parameter turned off, >> the described setup is now working for days as expected. >> Of course I have entries in the proxyarp file for all hosts on _both_ >> sides of the firewall (well on one side there is only the ISP's >> gateway). > > With proxy ARP, there are two interfaces involved -- I'll call them > the > "External" Interface and the "Internal" Interface. An entry in > /etc/shorewall/proxyarp: > > a) Adds a manual ARP entry on the External interface for an "Internal" > system (one connected to the Internal interface). > b) Sets the proxyarp flag on the Internal interface. > > The manual ARP entries allow the firewall to respond to ARP who-has > requests > on the External interface for the Internal system. This allows systems > outside the firewall to send to the Internal system. Notice that the > manual > ARP entries are preferred to setting the proxyarp flag on the External > interface since setting the flag would allow an External system (one > connected to the External Interfaces's LAN) to probe the composition > of the > Internal network by issuing ARP requests and seeing which addresses > the > Shorewall-based firewall responded to. > > Now what about the other direction (Internal system sending to > systems in > the same IP network that are outside of the firewall)? > > Suppose that the Internal system is configured with IP address > 206.124.146.177/24 and suppose that it needs to communicate with > 206.124.146.222 which is outside of the firewall (connected to the > firewall's External interface). The Internal system issues an ARP > "who-has > 206.124.146.222". Unless the firewall responds to that ARP request, > it will > go unanswered since 206.124.146.222 isn't in the same broadcast > domain as > the Internal system. That is the purpose of setting the proxyarp > flag on the > Internal interface. > > I suspect that your Internal systems have their default gateway set > to an IP > address that is configured on the Shorewall box and that they don't > have a > need to communicate with External systems in the same IP network. So > resetting the proxyarp flag on the Internal interface appears to > work fine > in your limited case. > > In the end, Shorewall knows 1.5 ways of doing Proxy ARP -- it always > sets > the proxyarp flag on at least one interface when either form is used. > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ [EMAIL PROTECTED] > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Shorewall-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
