: > 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.
: I tell it what hosts are in the dmz .... it does not autodetect. I
: just add the host to the shorewall config.
Right. So, you make a manual change. That answers my implied question.
I'm not sure why I assumed you had any autodection.
: I have a question maybe you can help me with though:
I saw your question before, and I do not know how to explain this. I
share your desire to understand why something works even though it appears
to be incomplete.
: Here is the working configuration of my testing firewall using proxy
: arp:
:
: 192.168.1.0/24
: |
: eth0: 192.168.1.1
: Firewall
: eth1: 192.168.3.1
: |
: 192.168.1.2
:
: There are the following routes used by proxy-arp:
: 192.168.1.2 dev eth1 scope link
: 192.168.1.0/24 dev eth0 scope link
:
: This moves host 192.168.1.2 from the public network to the dmz behind the
: firewall. Where I am confused is when I check the proxy_arp settings:
:
: []# cat /proc/sys/net/ipv4/conf/eth0/proxy_arp
: 0
:
: []# cat /proc/sys/net/ipv4/conf/eth1/proxy_arp
: 1
First, this makes sense to me. If any machine behind eth1 generates an
ARP request, and the firewall can reach the requested IP (directly), the
firewall will generate an ARP reply. This is proxy ARP for eth1. In your
case, this means that any host behind eth1 will think it is on the same
ethernet as the entire 192.168.1.0/24, when in fact, it is not.
This allows you to insert your packet filter between it and
192.168.1.0/24.
: Why is proxy_arp not turned on for eth0?? Every howto I can find says
: to turn on proxy_arp for both interfaces.
Well, I don't exactly know why your upstream router (available on eth0
with IP 192.168.1.x/24) thinks it can reach 192.168.1.2. I would be
interested in knowing what the ARP cache entry for 192.168.1.2 looked
like in the upstream router.
The interesting part is the 0 in your net.ipv4.conf.eth0.proxy_arp.
Machines in 192.168.1.0/24 on eth0 should not be able to receive an answer
for the IP 192.168.1.2. There is no problem at all with this aside from
the router. The upstream router must have a link layer address to which
to forward ethernet frames with IP packets.
So, you'll need to
- tell us what you see in the ARP cache on your router
- test "arping -I $INTERFACE 192.168.1.2" from another host in
192.168.1.0/24 on the eth0 side of firewall
- perhaps "tcpdump -nn -i eth0 host 192.168.1.2 and arp" to see what
sorts of ARP traffic is occurring in regard to 192.168.1.2
I don't have any speculation about why this continues to work for you. I
can certainly understand why outbound packets/frames can successfully
pass the firewall and reach the world, but I do not understand how
machines on the eth0 side of your firewall are resolving a link layer
address for 192.168.1.2.
So, I don't have an explanation. Can you get us one?
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
