Peter Peltonen wrote:
> Bret Hughes wrote:
>
> > I have not really looked at the subneting but are you sure your isp is sending
> > packets to you router, or are they merely sending them in that direction from
> > theirs? I believe they need to know that all packets destined for your
>
> I believe this is the problem, yes. My actual situation is this:
>
> HDSL
> |
> |
> CISCO
> eth0
> |
> |
> eth0
> Linux
> eth1
> |
> |
> DMZ
>
> The CISCO router's eth0 is in the net xxx.xx.xxx.128/255.255.255.128. Now,
> when I divided that net into three parts and tried to put my Linux box to use
> those nets my Linux's eth0 isn't in the same net with the CISCO's eth0
> anymore, right?
>
> So I should contact my ISP and ask them to change the CISCO's eth0 net to the
> same one my Linux is using.
>
NO, I don't think that is the problem. The issue is, I believe, that your linux
box is now the router/gateway to your network(s) and your isp's routing is assuming
that there is no additional hops needed to get to your boxes. I may be off base
here but if I understand the setup correctly, your linux box will have to be the
target for all packets going to your network(s). Here is an explainatioin of what
I think is happening:
An IP packet has a source and a destination address as part of the header. Lets
say that the linux box has eth0 address of xxx.xxx.xxx.129 and eth1 address of
xxx.xxx.xxx.130. The addresses don't really matter at this point for the
explaination. Now lets assume that a webserver in the DMZ has a machine with an
address of xxx.xxx.xxx.131.
The problem is that the last router in the isp network does not know that there is
another router (your linux box) between it and the webserver, so it when gets a
packet destined for your webserver, checks its routing table and sees that there is
a route for that network range (and no gateway defined) and sends the packet with
the address of xxx.xxx.xxx.131 as the destination straight down the wire.
The packet gets to your firewall's eth0, the firewall's NIC and kernel try to
figure out if this packet is of interest. It sees the destination address is
xxx.xxx.xxx.131 and already knows it's address is xxx.xxx.xxx.129 and says "hmm
this packet is not for me" and lets it drop on the floor.
Now lets assume that your isp's router knows about your firewall:
It recieves a packet for the webserver (xxx.xxx.xxx.131), checks its routing table,
and finds that it knows the network range, and that there is a gateway of
xxx.xxx.xxx.129 (linux firewall eth0). The router then takes the whole packet
(including the header) and wraps it in another packet with the destnation of the
gateway it knows about, the linux firewall at xxx.xxx.xxx.129.
Now when the packet arrives at the firewall the NIC and kernel (I think the NIC
does this actually, but I am not sure) it sees the destination is xxx.xxx.xxx.129
and says "hey! That is my address, I am supposed to do something with this packet"
and "lets" it in and begins processing it. If the firewall's ipchains rulles allow
it and the ip_forwarding is set and all the other stuff is correct, unwraps the
packet and looks at the destination of the internal packet, looks in it's routing
table, and sure enough, finds that it knows that xxx.xxx.xxx.131 is in the network
range that is supposed to go out eth1, there is no gateway, so it sends the packet
out the internal NIC to the DMZ where your webserver will see it and do it's deal.
Each router in the chain does this unwrapping of these packets, checking which
gateway to send it to, (If not one there is the old default route right?) wrapping
it back up or sending it straight out one of it's interfaces if the network is
connected to it. There is some other stuff done like decrementing the TTL so that
packets that do not have routing set up correctly will get dropped after too many
hops, fragmenting packets for the network media and transmission characteristics
etc...
This is the long version of why I believe that your packets are not getting past
your firewall. I don't think that the subnetting makes a difference if all the
packets are going through your firewall, but of course I may be wrong. I am just a
business owner that manages his own network so keep that in mind as you figure out
what is happening :)
I hope this helps and I also hope that if I have incorrectly stated the operations
in any way, that someone will jump in here and let us know where the error is. I
have never actually tried to explain this before and may have botched it up some
how.
A test would be to run tcpdump or ethereal on the firewall and ping something on
the internet from behind the firewall. You should see the return packets on the
wire with the destination of the internal machine on the wire.
Short version: tell your isp that you need a gateway added to thier routing tables
for your network. The ipaddress of the gateway will be the external interface of
you linux firewall.
> But I still wonder why I could use the network from the Linux router even when
> it was in the wrong network? That I find odd...
>
This is because all the packets had a destination address of the NIC.
HTH
Bret
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
