Matthew G. Marsh
Tue, 25 Jan 2000 09:25:01 -0600 (CST)
On Mon, 24 Jan 2000, Tommi Virtanen wrote:
> On Sun, Jan 23, 2000 at 08:29:40AM +1100, Matthew G. Marsh wrote:
> > > The DSL router's configuration is black-box. I cannot tell it to use
> > > the linux box as a gateway for the subnet or anything like that. I
> > > have to assume it is just going to send the packets for all five
> > > addresses out on its ethernet port, assuming that the recipient is
> > > there. (which means I probably need to do some proxy-arp'ing as well
> > > in all of this).
> > Nope to the proxy-arp. If using Kernel 2.2.xx then assign all of the
> > addresses to the FW ethernet interface using Alexey's IP utility and then
> > either use the mfw facility for ipmasqadm or FastNAT to make it seem that
> > the boxes are out in front of the FW.
> Would you care to give a reason why you don't
> like proxy-arp? Seems a lot cleaner to give
> the ethercard some new MACs to listen to, than
> to have the same IP on two different boxes..
> If if ping one of those IPs from the internal
> network, wouldn't both the real owner and the
> linux gw respond?
Not against proxy arp at all but it seemed that the original poster also
wanted firewalling functionality. Your setup is correct and works but has
limited firewalling capacities. By assigning all of the IP's to the
firewall you can then use the full power of ipchains/netfilter/etal to
mediate the usage of those IP addresses within the internal network.
Additionally you can then play games using the multiple internal machines
appearing as one.
> Proxy-arp seems more correct. Why is it unpopular?
Definitions - what you are doing below is not really proxy-arp in the
sense of a bridging definition. All you are doing below is essentially
similar what I stated in my original reply. Assigning all IP's to the eth0
facing the DSL and assigning an RFC1918 to the inside. I assume of course
that your x.x.x.0/21 is not in the 10/8 domain. If indeed your x.x.x.0/21
belongs in the 10/8 domain then all of the addresses the original poster
obtained are essentially bridged into the internal network in translation.
If by Proxy Arp you mean "the host responds to those IP addresses as
though they belong to it" then why not make them belong to it? If however
by Proxy Arp you mean "the host responds to those addresses even though
they do not belong to it" then you are playing with RFC1027/RFC925 proxy
arp subnet routing with all of the wonderful bridging mechanisms that
belong to it.
You must remember that Proxy Arp was originally due to hosts (pre 4.2
BSD's IIRC) that did not perform subnet routing as we are accustomed to
today. Indeed many routers (Cisco, Proteon, WellFleet, etal) carried and
still carry to some extent commands to enable both RFC1027 Proxy Arp
routing as well as the heinous RFC925 ARP subnet routing structures.
Thankfully we do not have to deal with those today. (Although I think I
may still have a early BSD install tape around here somewhere if you would
like to try... 8-} )
For extreme amounts of fun try setting up DiffServ using ingress tagging
to provide both bandwidth adjustments and simplified firewalling
structures within the same scope as your script. You are most of the way
> Here's an old setup of mine, using 10.0.0.x as the
> internal network.
> ip link set up dev lo
> ip addr add 127.0.0.1/8 dev lo
> ip route add to 127.0.0.0/8 dev lo
> ip link set up dev eth0
> ip addr add x.x.x.0/21 brd + dev eth0 label eth0
> ip route add to x.x.x.0/21 dev eth0
> ip route add default via x.x.y.y metric 1 scope global
> ip link set up dev eth1
> ip addr add 10.0.0.1/24 brd + dev eth1 label eth1
> ip route add to 10.0.0.0/24 dev eth1
> # Untested, I'm not currently actively using this configuration.
> # You may need to play with the routing.
> #ip route add to x.x.x.z/32 dev eth1
> #arp -i eth0 -Ds x.x.x.z eth0 pub
> unix, linux, debian, networks, security, | Yesterday it worked
> kernel, TCP/IP, C, perl, free software, | Today it is not working
> mail, www, sw devel, unix admin, hacks. | Windows is like that
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250