[ale] seeking advanced proxy ARP assistance

[Jay Libove]

Hi ALE -

I need help with an advanced proxy ARP configuration.  I'll happily trade 
beer and pizza (or your beverage and food of choice, within reason!) for 
successful assistance.

I have Speakeasy Internet service with 10 static bridged IP addresses.
I have Vonage Voice over IP phone service with a Linksys RT31P2.
I want to put the RT31P2 in front of my whole network to take advantage of 
its traffic shaping capability.

The problem is that the RT31P2 neither bridges nor proxy ARPs, so though 
it can route (just well enough, it does have quirks but I've worked around 
them I think), Speakeasy's (Covad's) router ARPs for my static IP 
addresses and does not get answers (except for the one which I assign to 
the RT31P2 itself of course).

My idea is to configure my Linux (Fedora Core 3) firewall to have an extra 
ethernet adaptor which does not have an IP address but will listen for and 
answer the ARP requests coming from the Speakeasy / Covad router, 
supplying as the target MAC address the MAC of the outside interface of 
the RT31P2.

The basic automagic proxy ARP functionality of the 2.6.x kernel does not 
handle this properly. For one thing, it does not seem to want to answer at 
all unless there is some (any) IP address assigned to the interface. Okay, 
I could drop another RFC1918 address on that interface, though I'd prefer 
to not do so. With an address assigned, it always provides that 
interface's MAC address as the target, despite published permanent ARP 
entries I set on that interface saying that the target should be something 
else. (Took me right off the net until the router's ARP cache timed out 
again, heh).

Next attempt: ebtables, with this command:

# ebtables -t nat -A PREROUTING -p arp -i eth3 --arp-opcode request \
     --arp-ip-dst one_of_my_statics -j arpreply \
     --arpreply-mac MAC_of_RT31P2_outer_interface

along with appropriate INPUT and OUTPUT permissions in iptables:

# iptables -A INPUT -i eth3 -j ACCEPT
# iptables -A OUTPUT -o eth3 -j ACCEPT
# iptables -A FORWARD -i eth3 -o eth3 -j ACCEPT
# iptables -A FORWARD -i eth3 -j DROP

Note that all ebtables policies are ACCEPT by default.


Then I captured on eth3:

# tethereal -n -i eth3 -s 500 -w arp.cap arp

and waited until the particular test IP address I chose in the ebtables 
command above got ARP'd. Unfortunately, it got just one answer, which is 
the published permanent ARP entry for the eth0 interface (which happens to 
presently be plugged in to the same outside network segment hub which eth3 
is in). The eth3 funny ARP entry did not get sent in reply.

I did a further test, guessing that maybe the kernel will only send a 
first possible ARP reply, by removing the published ARP entry for the test 
host on eth0.  Unfortunately, that too did not work - instead of sending 
an ARP reply from eth3, the Linux box simply sent no ARP reply at all for 
that test IP address.  (I seem to be very good at dropping my boxes off of 
the Internet, and not so good at advanced proxy ARP configurations!).



Here's what the network should eventually look like if I can get this 
funky proxy ARP working:


phone line carrying the DSL signal
               |
               | 
BroadXent 8012 DSL modem
               |
               | 
Outer 10Mbit Ethernet HUB (not switch)
                          |          +-----> sniffer
                          |
                          |
                     Vonage Voice Terminal (Linksys RT31P2)
                     Static IP address 1.1.1.43
                          |
                          |
                     Inner 10Mbit Ethernet hub (not switch)
                          |                               +-----> sniffer
                          |
proxy ARP                |
outside interface        Outside interface
no IP address            static IP address 1.1.1.42
   ^======firewall Linux server======^
            Inside interface
            local address 192.168.255.2
               |
               |
       Core network switch
        |    |    |    |   ...
various servers, workstations, &etc 
Static IP addresses 1.1.1.44 through 1.1.1.51



Here's what the network actually looks like right now as I do these tests:

phone line carrying the DSL signal
               |
               | 
BroadXent 8012 DSL modem
               |
               | 
Outer 10Mbit Ethernet HUB (not switch)
         |        |                  +-----> sniffer
         |        |
         |        |
         |        +--->Vonage Voice Terminal (Linksys RT31P2)
         |             Static IP address 1.1.1.43
         |
         |
Outside interface static IP address 1.1.1.42
     firewall Linux server
               |
               |
       Core network switch
        |    |    |    |   ...
various servers, workstations, &etc 
Static IP addresses 1.1.1.44 through 1.1.1.51




Sorry for the sucky ASCII artwork... I'm a computer security engineer, not 
a draftsman :)

Thanks for any help you can offer!
-Jay Libove, CISSP
libove at felines.org