I did echo 1>/proc/sys/net/ipv4/conf/all/proxy_arp... and I can do host
proxy arping ok. The problem is with subnet proxy-arping. I've gone ahead
and upgraded my kernel anyways. The solution I've taken for the time being
is to use arp's -f flag and read in a list of proxyarp definitions. So now
I have individual pub arp entries for every IP on the subnet I'm proxying
for. I still don't understand why subnet proxy-arp is "wrong" if regular
host proxy arping is good enough to leave in... Sorry if I was harsh or
blaming earlier... I was getting frustrated at that point :)
To explain the situation where I need to proxy-arp for an entire subnet
(here comes a long huge spew of details):
We have a network locally, call it 148.148.148.0/24. (network number
changed to protect the innocent :). There is a single Cisco router attached
to this subnet at 148.148.148.254, which is the default route for the
machines in the subnet. I wanted to add a firewall between this subnet and
the outside world beyond the Cisco. However, the Cisco (for that matter,
the entire network outside of the machines within this subnet) are out of
my control... and it would be a nearly impossible red tape battle to have
any configuration changes made in that Cisco or anything beyond it.
So... the solution was that I stuck a Linux box with two 100Base-TX cards
between the Cisco and the 148.148.148.0/24 network. eth0 points at the
subnet, eth1 points at the router. Here's the ifconfig and netstat -rn
output:
eth0 Link encap:Ethernet HWaddr 00:10:4B:66:7C:C4
inet addr:148.148.148.251 Bcast:148.148.148.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth1 Link encap:Ethernet HWaddr 00:10:4B:66:76:2D
inet addr:148.148.148.253 Bcast:148.148.148.255
Mask:255.255.255.252
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Destination Gateway Genmask Flags MSS Window irtt
Iface
148.148.148.252 0.0.0.0 255.255.255.252 U 0 0 0
eth1
148.148.148.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
0.0.0.0 148.148.148.254 0.0.0.0 UG 0 0 0
eth1
I put eth1 in an artificial subnet of 148.148.148.252/22. Now the only
trick to make packets route through this firewall instead of stopping dead
in the thier tracks is to convince the Cisco that it should give packets to
the Linux's eth1 for any 148.148.148.0/24 addresses. (I do have control of
the local machines, so changing their def gw to 148.148.148.251 was not a
problem, no proxyarp needed on that end). So I proxyarp for the entire
subnet on the eth1 interface to fool the Cisco.
This solution is of course not totally transparent, the Linux firewall
still shows up in traceroutes and the like.. but it solves the hard part of
my problem, which is that it be transparent to the router's configuration,
and not require the assigning of new visible IP's. Basically the network
configuration can't look different from the Cisco's perspective, or I would
be SOL.
Do you have a cleaner solution?
(please continue CC-ing me.. I'm not on the list)
Brandon
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> : Would whoever actually removed the code please respond to this, give a
> : decent explanation,
>
> The feature was wrong, that's decent explanation.
>
> You have choice --- to enable proxy arp by
> echo 1 > /proc/sys/net/ipv4/conf/*/proxy_arp
> or to use host proxy arp in exceptional situations.
>
> And stop blaming, please 8) If the above does not satify you,
> please, explain why it does not. If you will able to explain,
> than I'll write proxyarpd "out of band".
>
> Alexey Kuznetsov
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
