Internal Client Accessing Internal Server Via Public IP Address

Discussion in 'Cisco' started by GeekMarine1972, Jan 15, 2005.

  1. Client machine is at say 10.0.8.3.
    Server machine is at say 10.0.8.4.
    Router is at 10.0.8.1.

    On router are two NATs.

    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.
    What's more odd is that the client can PING and TRACERT to the public
    IP of the server.

    Both client and server are in VLAN8.

    ip nat pool natpool 64.64.64.4 64.64.64.4 netmask 255.255.255.0
    ip nat inside source static tcp 10.0.8.3 80 64.64.64.3 80 extendable
    Blah
    GeekMarine1972, Jan 15, 2005
    #1
    1. Advertising

  2. In article <>,
    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
    Walter Roberson, Jan 15, 2005
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page