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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
