On Fri, Feb 18, 2000 at 10:16:19AM -0500, Bill White wrote:
: Hi. Sorry to bother you again, but my problem is not fixed. I looked
: at the ICMP Masquerade Enabled setting in my kernel, and it appears to
: be enabled.
:
: I think that the problem I am having is:
: o I have a firewall machine, with an interface whose number is 192.168.2.10.
: o I have machines on the same hub as this interface whose numbers are not on
: the 192.168.2.0/24 subnet.
: o I want these machines to route through the 192.168.2.10 interface to the
: firewall's gateway.
That's not going to work without some rethinking of your network. A
basic understanding of IPv4 would make this more clear ... (that's not
meant as a knock against you, but I sense some confusion here. That
might be because I don't have enough info ...)
: o I have a second hub whose machines are all on a 192.168.1.0/24 subnet,
: and do IP Masquerade to the internet. This works fine.
:
: My routing tables are:
: Kernel IP routing table
: Destination Gateway Genmask Flags Metric Ref Use Iface
: 216.254.24.1 0.0.0.0 255.255.255.255 UH 0 0 1 eth0
: 216.254.24.95 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
^^
This is a host route, not a network route.
: 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 1 eth2
: 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
: 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 1 lo
: 0.0.0.0 216.254.24.1 0.0.0.0 UG 1 0 2 eth0
:
: and this is what I expect:
: o The default route is 216.254.24.1, which is the DSL gateway.
: o 216.254.24.95 is on eth1, which is the hub whose if address is
: 192.168.2.10. I can in fact ping 216.254.24.95.
Your terminology is confusing. "216.254.24.95 is on eth1" implies
that IP 216.254.24.95 is bound to eth1 - that doesn't appear to be the
case.
: o The 192.168.1.0/24 subnet is on eth2. This subnet works fine
: through IP Masquerade.
: o The 192.168.2.0/24 subnet is on eth1, even though the only
: address in this subnet is the if address.
If it's the only address on a subnet, it's of little value.
Networking requires two addresses per subnet - that's how
communication works :)
: o The 216.254.24.1 DSL gateway is on eth0, where it is supposed
: to be.
:
: Just for completeness, the behavior seems to be that things are routed
: from eth2 (the mixed subnet hub) through the fw machine to eth1 just
: fine when they are for the eth1 subnet. But they do not get out to
: the default gateway when they are for addresses on the wider internet.
:
: So, I guess the real question is: is it possible to have an interface
: accept packets which are not on the subnet of the interface's address?
: It seems as if it is possible, since I can ping machines which go
: 216.254.24.95 to 192.168.1.1 just fine. But it doesn't seem to route
: these to the default gateway.
What kind of machine is on this other hub? Where did you get this
216.254.24.95 address? What is the external address of the firewall?
You don't include the output of `/sbin/ifconfig', nor your ipchains
rules, nor a physical layout diagram, so I don't want to make too many
assumptions. However, if I had to guess, I'd venture the following:
You've been assigned two addresses from your DSL provider. You've
bound one of those to your firewall, and the other to some other
machine. The simplest way to make that setup work is like this:
[DSL]--[HUB]--[216.254.24.95]
\
----[Firewall]
|
[HUB]
|
Internal LAN
Obviously this provides no firewalling for 216.254.24.95!
If you want 216.254.24.95 behind the firewall, there are two ways to
do it:
1) Bridging
[DSL]--[Firewall]*--[HUB]--[216.254.24.95]
|
[HUB]
|
Internal LAN
The interface marked with a '*' is bridging traffic. Your kernel
needs to be recompiled to support this.
2) Aliasing
[DSL]--[Firewall]
|
[HUB]--[192.168.1.42]
|
Internal LAN
In this scenario, you bind both IPs from the provider to the external
firewall interface. You masq all traffic from 192.168.1.42 to
216.254.24.95. You masq all traffic from net 192.168.1.0/24 to the
other IP.
There are a couple ways to do option 2. One requires aliasing support
in the kernel. The other requires netfilter. SysAdmin magazine had a
writeup on netfilter recently that addressed several scenarios like
this.
Hope that helps,
--
Nathan Norman Network Magician, Eclectic Engineer
GPG Key ID 1024D/51F98BB7 "Eschew Obfuscation"
Key fingerprint = C5F4 A147 416C E0BF AB73 8BEF F0C8 255C 51F9 8BB7
Attachment:
pgpSdKBfi1HYQ.pgp
Description: PGP signature