[LUNI] Setting up a simple choke

[Martin Maney]

On Tue, Nov 19, 2002 at 04:08:40PM -0600, Michael Knoop wrote:
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> xxx.yyy.zzz.72 *               255.255.255.255 UH    0      0        0 eth1
> localnet        *               255.255.255.0   U     0      0        0 eth0
> localnet        *               255.255.255.0   U     0      0        0 eth1

I think this is the problem right here: you need a bridge to connect
two segments of a single subnet, not a router.  (if that caused you to
smack your forehead, you may not need the rest of this; otherwise, read
on for much more).

> All the documentation I can find says that these are all the things that
> should be sufficient to do the package forwarding.

The documentation assumes that you have different networks on the two
interfaces, or a network and a subnet.  What you have is a single
network that's been divided into two broadcast domains, which is quite
a different thing.

> It does not forward anything.
> If I am logged on the box itself, I can ping the printer just fine, but I
> cannot ping it from the network.
> What am I missing?

Two things, probably.

First, from the eth0 localnet side: how does any device connected there
know how to pass traffic to x.y.z.72?  Well, x.y.z is the network
segment they're attached to, so they assume that they can broadcast an
ARP query and use the result (a MAC address) to address the ethernet
packet to the .72 interface.  But in fact that won't work, because the
.72 device's ethernet interface is NOT attached to the local network. 
You would have to either setup a special route for x.y.z.72 on *every*
device in the x.y.z network, or have the filtering box act as an ARP
proxy for .72 (ie., answer ARP queries for .72 giving its own (eth0)
MAC address.  That will get packets from devices on the eth0-attahced
network to the filter box.

Much the same problem exists on the eth1 side.  The filter box and the
printer can find each other because they are, in fact, attached to that
degenerate network.  But the printer has no special understanding that
this is in fact a point-to-point network, so it "knows" that any IP
address in x.y.z can have its interface's MAC address found by ARPing. 
but that only works for the filter box's eth1 interface's address,
since there are no other directly attached interfaces.  This is a good
deal more difficult to work around *using* *router* *level* *logic*. 
It would be handled automagically by an ethernet bridge, however.

Now, there is bridging code in the 2.2 line.  But I don't know if you
can (easily?) apply chains rules to bridge-forwarded packets - I don't
think that was ever in the stock 2.2 line; perhaps it's available as a
patch?  I'm pretty sure that's in 2.4.  Is an upgrade to a 2.4 kernel
out of the question for some reason?

> that.  I was able to set it up just fine, but windows sharing does not pass
> through NAT because the packages contain embedded IP addresses.  The
> printer has an internal server that works by windows sharing.  This windows

Two thoughts, if NAT would be easier than a 2.4 upgrade: have you
looked to see if there's a protocol-specific handler for this protocol
(there are many more than come with the kernel sources)?  Or perhaps
you could setup samba to proxy the traffic - the server would accept
print jobs on the eth0 side and push them off to the printer.  It seems
at least superficially similar to things I've done (samba server
accepting from Windows clients, handing off to lpr or, perversely, to
Netware, as a back-end).

Luck!

-- 
I've just realised that one of the things I really hate hate hate
about Windows is that it doesn't have any personality. It's corporate
and it hates me but it wouldn't ever do anything but smile falsely
and refuse to talk to me.  -- Jo Walton http://www.bluejo.demon.co.uk