Re: RRAS Win2003: Cannot reach public IP reserved hosts behind our NAT

From: Phillip Windell (_at_.)
Date: 08/02/04 

Date: Mon, 2 Aug 2004 09:22:43 -0500

If you want some reference material on this issue look in this article about
two-thirds the way down under the heading called "14120 Errors"

[Those are underscores, not spaces between the words]
14120 Errors; Discussion and Solution
http://www.isaserver.org/articles/14120_Errors_Discussion_and_Solution.html 

-- 
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
"Phillip Windell" <@.> wrote in message
news:uJ6rRuJeEHA.1764@TK2MSFTNGP10.phx.gbl...
> "Nick" <Nick@discussions.microsoft.com> wrote in message
> news:1A20D5E0-1056-4D97-9687-19DBCFAD2B5B@microsoft.com...
> > The problem is, we are unable to access them by their public IP address
> from our intranet. From within our intranet we can access the machines by
> their private addresses (10.x.x.x) just fine, as these packets are not
> routed to our RRAS box.
>
> Since you are accessing by IP# there isn't any DNS involved here (sorry,
> guys).  What you describe is exactly the way it is supposed to behave if
you
> are "reverse-NATting" (Static NATing) from publich IP#s bound to the
> external Interface of the Router back to these machines on your internal
> LAN.
>
> Contrary to popular misconception, Ethernet runs on MAC addresses not on
> IP#s. The role of the IP# in Ethernet is only to provide a Layer3 routing
> mechanism and to provide a means to resolve the MAC address (ARP).  The
> reason intranet host must use the private addresses to access the servers
is
> because NAT can't make "u-turns".  When you send a packet to the external
> IP#  the "NAT" process takes it and creates a situation where the source
and
> destination MAC addresses in the packet headers are the same address. It
> can't go from itself to istself and shoots itself in the head.
>
> These types of situations will work with other types of "processing" like
> the "Web Publishing" or "Server Publishing" features of ISA & Proxy2
because
> the internal methodology is different, but it will not work with a NAT
> Device.
>
> So when outside your system use the public IP# and when inside the system
> use the private IP#.  If you want to access by "FQDN" then make sure your
> DNS functions properly to resolve to the proper IP# as the other guys are
> describing.
>
> -- 
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>

Relevant Pages

  • Re: Static IP Vs DHCP
    ... How many people have a current database of which MAC is in which computer ... My point is that the abundance of private addresses eliminates the need for ... The DHCP ... NAT means they can't initiate a connection, ...
    (comp.security.misc)
  • [fw-wiz] Sunscreen EFS 3.1 stealth mode and NAT
    ... NAT of an internal host which has a private address. ... to the address group for the external interface. ... When I snoop the incoming and outgoing interfaces I see the packet ...
    (Firewall-Wizards)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... In such case he has no option, other than dealing with MAC addresses, and, ... The proper way to do this is to add your IPv4 header, ... IPv4 header will be larger than the MTU. ... After prepending IPv4 header and UDP header to the original IPv6 packet, ...
    (microsoft.public.development.device.drivers)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... This is a reasonable solution if the OP wants to avoid dealing with MAC ... IPv4 header will be larger than the MTU. ... After prepending IPv4 header and UDP header to the original IPv6 packet, ...
    (microsoft.public.development.device.drivers)
  • Re: WinRoute Pro
    ... the NAT table for I believe. ... packet logging shows some nice information but other times the ... when the connection is torn down from the client side ...
    (comp.security.firewalls)