In article <. com>,
GeekMarine1972 <> wrote:
:First nat states client machine should use pub ip of 64.64.64.4 when
:going to Internet. It works fine and client can access many public
:sites.
:Second nat states that a Public IP of 64.64.64.3 with port 80 inbound
:should translate traffic to 10.0.0.8.4 so that outside folks can access
:the website it hosts.
:Now, the question comes, it appears by default that the client cannot
:access the public IP of the server (64.64.64.1) for some reason.
Unless you are using a policy map, NAT isn't done until after the
output interface is chosen, because it isn't until then that it knows
which nat pool to draw from. So your inside packet is going to
head outwards because of the default route, hit the router, the router
will send it outwards. Then the next hop outwards will
see that the packet is destined for the public IP space and will
send it back again, provided that it hasn't been configured to block
this possibility. The packet would be received at the router,
which would then have to de-nat the destination and send it inwards.
:What's more odd is that the client can PING and TRACERT to the public
:IP of the server.
When the packet heads outwards like that, if you have firewall
protections turned on, the router is going to take note of the sequence
number; when the packet with that same sequence number and destination
arrives back, the statefull firewall would punt the packet.
ping and Windows 'tracert' use icmp packets, which don't have sequence
numbers, so a statefull firewall might not notice that the packet just went
out.
But you also have to ask yourself what the source IP address is during
this process. If the client you refer to is using a public source IP
that is not being translated as it goes outward, then if the router
isn't doing stateful inspection, the packet that gets forwarded back
inward will have the original public IP as the source IP. The server
would go to reply to the packet, and would address the reply to the
source IP from the packet -- an IP that we are supposing is internally
routable in this instance. Because of the internal routing, the
reply would go -directly- to the client, and the reply packet is going to
have the internal IP of the web server as its source IP. ping and
tracert are going to be happy with such packets, since they will
look at the icmp echo-reply data sequence fields to know which user
to pass the packet back to. TCP, though, is going to look in its
state tables, see that it isn't expecting a packet with SYN ACK set coming
back from that internal IP address towards the destination port, so
TCP is going to drop the packet. In the case where the user had
specified something that resolved to the internal IP, then the packet
would have skipped the out-and-in-again hop (just an optimisation
for this purpose): more importantly, the reply packet in this case
would be from the same IP that the outbound SYN packet was addressed to,
so the TCP stack would be able to match up IPs and would know where to
deliver the packet.
Anyhow, that's why you are having problems. What you should be
doing is telling the users "Don't do that!" -- don't directly specify
the web server by external IP address when they are internal.
They should be specifying the web server by hostname instead.
Specifying by hostname is not a problem because you have split DNS views
configured or else because your DNS server is external and your
router is configured to de-NAT the DNS replies that come back.
Right? You have done split DNS views or DNS IP translation at the
router, haven't you?
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
|
