Derek T. Murphy <[EMAIL PROTECTED]> wrote:
>
> | > -----------------
> | > ----------- | Linux-2.0.34 |
> | > | dial-up |<---->ppp0 |
> | > |static IP| | eth0<====>192.168.36.0 local network
> | > | address | | 192.168.36.50|
> | > ----------- | |
> | > | eth1<====>204.4.21.240 router to the "world"
> | > | 204.4.21.50 |
> | > -----------------
> I put that first rule in expecting it would allow ppp0 to see the
> localnet, and the localnet to see the machine on ppp0, since they BOTH
> live on the 192.168.36.0 network.
Wait a minute... WHAT?? Er, sorry for my emphatic response, but, you
can't do that.
See, you've got two different interfaces, eth0, and ppp0, and they both
are in the SAME subnet. That means, that the networking kernel thinks
that they are exactly the same network cable, which means that the
system is unable to differentiate between the two networks! Suppose a
packet comes in for 192.168.36.79. Some random packet. How does the
system know which subnet to send it over? eth0? ppp0?
Now, in practice, you probably have a static route pointing directly to
the ppp0 interface for its particular IP address, so this will work, but
only on the Linux box. Other systems will be unable to tell that they
are supposed to forward through the Linux box, because they will ASSUME
that they are all on the same network cable, and can talk directly to
one another, which is clearly not the case.
> It _looks_ like I'm sending incoming ppp0 traffic BACK to ppp0, but
> why don't the packets log at all? If ppp0 pings 204.4.21.50, the
> packets show up; if it pings 192.168.36.50, NOTHING show up.
That's right. The remote system, behind the static ppp0 interface,
wants to ping another system on the 192.168.36 network. It assumes,
because that system is on the same subnet, that it should be able to
send the packet directly to that other host. It does NOT try to forward
the packet through the Linux box. Instead, it generates an ARP request
to determine the MAC address for that other system, and that other
system never responds, so no traffic occurs.
I think you will find that this works better if you put the eth0 or the
static dialup IP's on a different subnet, like 192.168.37.*, and then
you will find that things work better, because all systems involved will
realize that they are talking to different subnets, and need to do some
forwarding. You will need to replace that rule that you removed, which
previously was trying to forward the same subnet to itself, and now
needs to forward the packets between these two *different* subnets.
By the way, I think I need to clear up a misconception that you and
some others on this list seem to have shown. Your comment above says
"It loks like I'm sending ppp0 traffic back to ppp0," but you must
understand that ipfwadm rules do not determine where traffic is going to
be routed. The route table serves that function. The firewall rules
come into play, AFTER the route table has been consuled. The route
table determines which interface is going to receive the packet next,
and it is at that time that the ipfwadm forwarding rulesets are called,
to determine IF the packet should proceed to be forwarded. That's why
the rulesets -W option only controls the destination interface; the
Linux kernel has forgotten where the packet came in from, at that time;
it only knows where the packet is trying to go. So, your forwarding
rule must match the source, destination, and interface via which the
packet will travel, in order to match the rule.
Does that make any sense? :)
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Nothing takes the taste out of peanut
sometimes known as David DeSimone || butter quite like unrequited love."
http://www.dallas.net/~fox/ || -- Charlie Brown
PGP signature
