-----Original Message-----
From: Fuzzy Fox <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, September 15, 1998 12:11 PM
Subject: Re: [masq] For my own edification...
>Jose M. Sanchez <[EMAIL PROTECTED]> wrote:
>>
>> In a situation wherein there exists a Linux box connected to a Lan,
>> and that same Linux box's ethernet IP is assigned via DHCP (i.e. from
>> a BI-DIRECTIONAL cable modem connection) how is Masq configured to
>> allow other machines to use the Linux box as a masq gateway?
>
>Probably in exactly the same way that a Linux box using a dial-up PPP
>connection with a dynamically-assigned IP address is able to be a
>masquerade gateway.
>
In this scenario a dhcp client would have to be used for the cable modem
side, ethernet interface, and a second ethernet for the local lan, which in
turn could have a static IP...
>> I'm assuming ALL machines and the cable modem are plugged into a
>> single hub, with only one ethernet interface on the Linux machine...
>
>I suppose you could do it this way, or you could plug two NIC's into the
>Linux box and have it forward between the two nets.
>
Yes, the latter being the most commonly used method...
The reason I ask is that in my case, the cable modem is on the same hub/lan
as my masq'd machines, however the cable modem is unidirectional... that is
it requires a dialup for the uplink side...
In effect the packet requests are transmitted via the dialup modem, and the
packets are returned via the cable modem. Linux sees these two devices as
"one" PPP link with it's own unique ip that is dynamically assigned by the
ISP... Linux does not seem to care where the packets (or even what
interface) are coming from, only their destination...
This being the case, and extrapolating a bit, if someone has a bidirectional
cable modem connected to a common hub, could the same ethernet interface
function as both a gateway and a router?
Effectively the packets to be masq'd would arrive via eth0, and be
retransmitted to the cable modem via eth0.
I have to assume that this would actually slow things down a little over the
dual card method, since you could not effectively "stream" packets into the
ethernet card, each reception of packets from a Masq'd host would produce an
immediate retransmission adding a bit to the latency...
>> If the first thing ipfwadm does is a "deny all", doesn't this prevent
>> the linux box itself from sending packets over the internet?
>
>That "first thing" you're talking about is the "default policy" rule,
>usually "ipfwadm -F -p reject". It means that, if there is no specific
>rule to tell otherwise, the box will reject an attempt to forward a
>packet.
>
>Note that this applies to FORWARDING a packet. It only applies when the
>Linux box receives a packet, and determines that the packet is not
>destined for the Linux box, and needs to be forwarded somewhere else.
>Thus, it does not prevent the box from sending packets to the internet.
>
Ok, thanks for the clarification...
>At any rate, in all cases you've seen on this list, the default policy
>rule is immediately followed by a rule which defines that packets SHOULD
>be forwarded, if they meet certain criteria, such as being from a
>192.168.* address, with the stipulation that they be masqueraded. This
>prevents a machine on the Internet from reversing your Linux box, and
>masquerading its way INTO your network.
>
Hmm...
>> I'm assuming the eth0 interface becomes the default gateway for all of
>> the masq'd machines... is this correct?
>
>A default gateway is given as an IP address, generally. Not an
>interface. In this case, the IP address would be the address of the
>Linux box on the local LAN.
>
>You (and another poster here) expressed some confusion about the
>dynamically-assigned address. Well, how do your local LAN machines talk
>to the Linux box when it is not connected to the Internet at all?
>Surely your machine has TWO IP addresses: one on the local LAN, and
>another on the Internet at large, assigned dynamically. Your local LAN
>boxes will forward to the Linux box's local IP address, and it will in
>turn forward that traffic out to the Internet via masquerade. Thus,
>there should really be no confusion.
>
>
And now the heart of the matter, in the case of a single ethernet interface
connected to a common hub bidirectional cable modem, the ethernet interface
obtains it's IP dynamically.
The problem is that the clients would not know what ip to talk to, to access
the gateway.
Implementing a dhcp client on the linux box, would in turn mean that a dhcpd
daemon would have to be configured to wait until the dhcp client had
obtained it's address, and then this address in turn would be used to
broadcast the "network" gateway ip... this assumes the clients would be
allocated "reserved" ips...
Now the problem is that since the Linux box is broadcasting it's ability to
be a dhcp client to the local lan via the same ethernet interface using the
cable modem, wouldn't it in effect be broadcasting this to any other machine
connected to the same ISP???
(I sorta suspect this is happening to me in a way, since I see a lot of ICMP
echo request traffic on my lan which ends up keeping my diald connection
up...)
>Thinking further on what you said above, I don't see how a Linux box
>with a cable modem could work, if the cable modem were connected on the
>same hub with the rest of the local LAN. If the modem is a "dumb"
>device and does not have its own IP address, then there isn't any way
>for the Linux box to send it any traffic... is there? It seems to me
>that it would need to be on its own subnet, so that it could simply
>forward all traffic that it sees, like a bridge device would.
>
>But, I don't have one, so I can't say for sure.
>
It works because Linux believes (in effect) that it is connected to a much
bigger network, (namely the ISP's) and it is only a client on the larger
net... the eth0 card becomes the default route... even though this is on the
local LAN, the packets make it to the cable modem box and up to the ISP...
the interesting thing is that the local packets ALSO show up at the ISP, but
are rejected because they fail to originate from an authenticated MAC
address... (as most ISP's do...) or from a permitted IP (as my ISP does...)
In my case any ONE machine that has an IP of 10.0.0.1 becomes the internet
cable unit... because the uplink is a dialup, it also requires a modem...
once the modem has authenticated itself via pap, the ISP broadcasts, looking
for the 10.0.0.1 interface...
I've changed between one machine to another by merely hanging up, changing
the IP, and having the second machine dial... using arp, the new MAC address
gets added to the ISP "authenticated" database within seconds...
DHCP client Linux machines, as in the case of bidirectional cable modems,
get told what the default route is by DHCP. The Linux machine gets pointed
to the default gateway on the ISP's LAN, but the packets arrive via the
local LAN... again effectively all packets get sent from that interface to
the ISP...
This permits the cable modem to be a relatively cheap and "dumber" device
than a full fledged router...
So back to the original question, because of the dhcp client problem, is it
possible to set up linux to BOTH dhcp an IP and also have a static IP on the
same ethernet interface?
This would circumvent a few problems and permit people with BI-DIR Cmodems
to set thenselves up as Masq hosts for their local lans without needing any
other hubs, cards or routing?
Thanks, I find this interesting...
-JMS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
