internal routing
i'm a novice, at best and i've never been through any training for any of
this, only what i've learned here, other places, and worked out on my own.
i've also shared this sketch with others on the list from time to time who
have found it useful. if someone knows a better way, please let me know:
remote remote
\ /
inet<-fw<-host_router<-lan
/ \
remote remote
<-, ->, /, and \ all indicate the dg for the device/network
keep in mind that when the firewall software is installed it still operates
independently of nt routing. installing the package and reducing the
defenses will allow you to watch the logs. they can be useful for many
issues.
the moot point:
you mentioned in your previous that a machine that encounters a ping from a
machine _not_ on it's network automatically knows where to reply to because
of the address on the packet. while it is true that the packet itself does
have information about who sent it (ip, ttl, etc), it does not retain the
information about how it got there. the presence of the originators address
only tells it that the reply-to is _not_ on the same logical network, and to
send a reply to its dg because it has no idea how to get the packet _back_
to the sender (again-only who it came from, not how it got there).
the routing table:
from the look of your routing table every thing appears to be ok on the
firewall machine. i compared yours to mine (i have one active and two in
testing, so that's three tables all together with a slew of pretty funky
routing going on) and i didn't see any problems. i would imagine that the
issue with machines not replying has something to do with the machines dg,
the host routers tables, etc.
to verify that you _are_ getting the pings from outside hosts to inside
hosts use ms network monitor or a real sniffer on the machines that don't.
do the machines that reply trace route the way you expect?
when you try a tracert from the machines that don't reply where do they dead
end (if at all)?
is the route the one you expect?
what's the dg on the hosts that didn't reply?
is there a chance you have two routes to get to that external machine that
you are pinging _from_? (i believe it's called split-horizon)
(i cleaned it up a little but the address' aren't changed)
Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 x.x.61.1 x.x.61.2 1
whats up with this big assed domain?
10.0.0.0 255.0.0.0 10.0.0.1 10.0.0.1 1
is that the third interface or is it a second address bound to one of your
others?
internal
x.x.60.0 255.255.255.0 x.x.60.252 x.x.60.252 1
external
x.x.61.0 255.255.255.0 x.x.61.2 x.x.61.2 1
internal remote
x.x.63.0 255.255.255.0 x.x.60.253 x.x.60.252 1
from what i've gathered, this covers all the bases, it should work...
are you getting any of these routes from RIP?
the reason i asked about the remote network(s) was because if they can surf
over your new gateway to (and be pinged(pung, pang, whatever), as well) a
machine located externally more reliably, then i would look at the dg's and
tracert outputs of the clients who don't reply.
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
