Shorewall users - Nov 2007 - /etc/shorewall/proxyarp and /proc/sys/net/ipv4/conf<interface>/proxy_arp

Hi,

When I put individual proxy arp entries in /etc/shorewall/proxyarp, it  
seems shorewall automatically sets
/proc/sys/net/ipv4/conf<interface>/proxy_arp to 1. Of course the  
proxyarp option is _not_ set in /etc/shorewall/interfaces for any  
interface.
Following the comment in the interfaces file, I understood that the / 
proc/sys/net/ipv4/conf<interface>/proxy_arp should/would not be  
activated when using only /etc/shorewall/proxyarp with manual entries.  
Am I wrong ?

This causes problems in one of my networks where I have a single  
broadcast domain with two distinct IP subnets and two distinct  
firewalls (during a transition phase).
One of the firewalls is  using a shorewall setup in transparent  
proxyarp mode, with manual entries in /etc/shorewall/proxyarp.
As shorewall sets the proxy_arp kernel option to 1, the kernel on that  
firewall automatically replies arp requests for any  IP address it has  
a route to. And as the firewall has a default route (0.0.0.0), as a  
consequence it replies to arp requests for any host, even the one  
targeted at the second subnet, including the second firewall''s  
internal IP.

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 ?

Kind regards,
Gaetan

-------------------------------------------------------------------------
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/

Gaëtan Minet wrote:
> Hi,
> 
> When I put individual proxy arp entries in /etc/shorewall/proxyarp, it  
> seems shorewall automatically sets
> /proc/sys/net/ipv4/conf<interface>/proxy_arp to 1. Of course the  
> proxyarp option is _not_ set in /etc/shorewall/interfaces for any  
> interface.
> Following the comment in the interfaces file, I understood that the / 
> proc/sys/net/ipv4/conf<interface>/proxy_arp should/would not be  
> activated when using only /etc/shorewall/proxyarp with manual entries.  
> Am I wrong ?
Yes.
> 
> This causes problems in one of my networks where I have a single  
> broadcast domain with two distinct IP subnets and two distinct  
> firewalls (during a transition phase).
> One of the firewalls is  using a shorewall setup in transparent  
> proxyarp mode, with manual entries in /etc/shorewall/proxyarp.
> As shorewall sets the proxy_arp kernel option to 1, the kernel on that  
> firewall automatically replies arp requests for any  IP address it has  
> a route to. And as the firewall has a default route (0.0.0.0), as a  
> consequence it replies to arp requests for any host, even the one  
> targeted at the second subnet, including the second firewall''s  
> internal IP.
Only if it is receiving those arp requests on an interface other than
the one with the most specific route to the other firewall''s internal
IP
address. It the other firewall''s IP in a different IP network from the
Shorewall box''s internal net?
> 
> 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''.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
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/

Tom Eastep wrote:
> Gaëtan Minet wrote:
> 
>> This causes problems in one of my networks where I have a single  
>> broadcast domain with two distinct IP subnets and two distinct  
>> firewalls (during a transition phase).
>> One of the firewalls is  using a shorewall setup in transparent  
>> proxyarp mode, with manual entries in /etc/shorewall/proxyarp.
>> As shorewall sets the proxy_arp kernel option to 1, the kernel on that
>> firewall automatically replies arp requests for any  IP address it has
>> a route to. And as the firewall has a default route (0.0.0.0), as a  
>> consequence it replies to arp requests for any host, even the one  
>> targeted at the second subnet, including the second firewall''s
>> internal IP.
> 
> Only if it is receiving those arp requests on an interface other than
> the one with the most specific route to the other firewall''s
internal IP
> address. It the other firewall''s IP in a different IP network from
the
> Shorewall box''s internal net?
That last sentence should begin "_If_ the other...".

Let''s suppose that the internal IP of the firewall box is
206.124.146.176/32 and that the hosts 206.124.246.177 and
206.124.146.178 are in the /etc/shorewall/proxyarp. Further suppose that
the internal IP address of your other firewall is 206.124.146.1.

The solution to this problem is not to reset the proxyarp flag on the
Shorewall box''s internal interface but rather to add a direct route to
206.124.146.146 out of that interface.

ip route add 206.124.146.1/32 dev <interface>

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
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/

Hi Tom

Thank you for your reply.
> Only if it is receiving those arp requests on an interface other than
> the one with the most specific route to the other firewall''s  
> internal IP
> address. It the other firewall''s IP in a different IP network from
the
> Shorewall box''s internal net?

Yes, the firewalls have no knowledge of each other nor of the other  
network "behind" them.
Of course you''re right this is not the best setup network-wise as we  
_should_ have routes to both  local ip subnets in both firewalls.
But we want to test the full routing through both providers during the  
transition phase before shutting down the first one.
>>
>> 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''.
Sorry, I should have written "changed" instead.

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:

(1) Manual static public entries through /etc/shorewall/proxyarp (" do  
not use  /proc/sys/net/ipv4/conf/<interface>/proxy_arp")
(2) automatic sub-networking through proxy_arp flag if set in the  
interface file) (echo 1 >  /proc/sys/net/ipv4/conf/<interface>/ 
proxy_arp)

#                       proxyarp     -
#                               Sets
#                               /proc/sys/net/ipv4/conf/<interface>/ 
proxy_arp.
#                               Do NOT use this option if you are
#                               employing Proxy ARP through entries in
#                               /etc/shorewall/proxyarp. This option is
#                               intended soley for use with Proxy ARP
#                               sub-networking as described at:
#                               http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet
#


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).


Thank you
Kind regards
Gaetan

-------------------------------------------------------------------------
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/

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  \ teastep@shorewall.net
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/

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  \ teastep@shorewall.net
> 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
> Shorewall-users@lists.sourceforge.net
> 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/