Hello all,
This is a correction to Christopher's post and a further explanation of
proxy ARP with reference to Don Cohen's excellent post [1] of earlier
today.
: as far as i know, it would be difficult to tinker with proxy_arp, but
: you could always turn off arp on the "public" interface with ifconfig.
:
: #ifconfig eth0 -arp
While this does indeed turn off ARP entirely on an interface, this also
prevents any ARP replies from an interface, including proxy ARP replies.
I haven't yet had the opportunity to digest all of Don Cohen's message of
earlier today, but my first reading of his post agreed with my
understanding of proxy ARP by the linux kernel. I would make two
general notes of caution about using proxy ARP.
- The interface on which the user is using proxy ARP must have ARP
support. Practically speaking, this means that if the NOARP flag*
is visible in "ip link" or "ifconfig" output, proxy ARP will not
work.
- The router which is performing proxy ARP must have a route (for
the IP address of the destination) which uses an interface other
than the interface on which the router is performing proxy ARP.
In other words, the kernel will not send an ARP reply on interface
Y for IP address X if IP address X is reachable through interface
Y. Make sure your routing table is correct. (This is not a problem
for Joseph.) (Upon re-reading Don's post, he says the same thing
more eloquently.)
: this is a tactic employed by the linux virtual server project, and
: *might* do what you want. couldn't test here because of some
: particularities with my setup.
Because machines functioning as realservers in an LVS cluster often host
the same IP address on multiple machines, ARP suppression is required to
prevent uncontrolled ARP flux from defeating the benefits of load
balancing. The complete suppression of ARP would break a network using
proxy ARP.
: a shame that bridging doesn't allow netfiltering (iptables) control --
: this would correspond most closely to your goal -- a transparent layer 2
: bridge, with layer 3 filtering.
Bridging does allow packet filtering with netfilter. You need to use the
br+nf patches to the kernel [2]. In fact, at the main bridging site, [3],
there are links to a number of documents, and Shawn Grimes has even
written an entire PDF about how to use packet filtering on a bridge [4].
Also, consult the bridge mailing list archives [5].
: clearly, iptables rules on the INPUT and OUTPUT chains pursuant to the
: firewall itself should minimize your risk
Christopher--you could be a bit clearer in expressing this answer. I
think Don Cohen's answer to the question "can I use a different set of
addresses for managing the firewall" was more complete. The firewall
could make use of RFC 1918 addresses and limit connections to these
address to a known set of hosts. You are correct, though that INPUT and
OUTPUT chains would minimize risk to the firewall itself, whether bridging
or not.
Joseph--I have a question for you about how your shorewall box is
detecting when you move a host from one interface to another? I have been
puzzling over ways to do this, and I believe I have stumbled on one, but I
was hoping you might have already solved this problem. Naturally, the
shorewall box needs to know at all times the location of your roving host,
so autodetection of the location of the box might be handy.
-Martin
* Here is an example of an ethernet interface with ARP functionality
suppressed. "ip link" and "ifconfig" output is shown for completeness.
# ip link show dev eth1
3: eth1: <BROADCAST,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:80:c8:e8:1e:fc brd ff:ff:ff:ff:ff:ff
# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:80:C8:E8:1E:FC
inet addr:10.10.20.89 Bcast:10.10.20.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:547 errors:0 dropped:0 overruns:0 frame:0
TX packets:7293 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:62174 (60.7 Kb) TX bytes:399178 (389.8 Kb)
Interrupt:12 Base address:0x6600
[1] http://mailman.ds9a.nl/pipermail/lartc/2003q2/008315.html
[2] http://bridge.sourceforge.net/devel/bridge-nf/
[3] http://bridge.sourceforge.net/docs.html
[4] http://bridge.sourceforge.net/docs/Firewalling%20for%20Free.pdf
[5] http://www.math.leidenuniv.nl/pipermail/
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
