newbie: could not connect to public IP address from behind NAT
Zhang Weiwu
61.49.215.196:22: (61.49.215.196 is the NAT public IP address.)
From 211.157.114.130 (an IP address on the Internet) I can access
192.168.1.100:22 by accessing 61.49.215.196:22
From 192.168.1.101 if I try to access 192.168.1.100:22 by accessing
61.49.215.196:22 I get connection refused (but I can access directly
192.168.1.100:22)
How can I find articles explain this issue and ways to workaround this,
to allow me to access public IP address of the NAT from internal hosts
behind the NAT and still get the port-mapping working correctly?
I have been working in a dozen or more different ADSL+NAT environment
(typical in China), all of them set up ADSL+NAT by using small devices
(instead of using a Linux/Windows server or PC acting as server). In
some offices this works, in some offices it doesn't. It seems to be
depend on the device brand they used. I wish I could get some in-depth
knowledge why it doesn't work for some devices and possibilities to
fix/workaround it. e.g. a Thomas modem and SureKVM modem with NAT
feature has this issue, but a TP-LINK router with NAT feature doesn't
have this issue. For NAT I only talk about IP masquerade which is used
in almost every Chinese office.
P.S.
I am sure this problem has been asked before and I do think likely I
posted to the wrong group, but anyway I could not describe this problem
in better English that I can google out good explanation of this topic,
neither can I found the right place to ask this question. Please forgive
and redirect me to the right place to ask or right keyword to google or
right articles to read. Thanks very much in advance. I have been trying
to understand this issue for 4 years!
Barry Margolin
Zhang Weiwu <zhang...@realss.com> wrote:
> Hello. For a typical NAT where 192.168.1.100:22 is mapped to
> 61.49.215.196:22: (61.49.215.196 is the NAT public IP address.)
>
> From 211.157.114.130 (an IP address on the Internet) I can access
> 192.168.1.100:22 by accessing 61.49.215.196:22
>
> From 192.168.1.101 if I try to access 192.168.1.100:22 by accessing
> 61.49.215.196:22 I get connection refused (but I can access directly
> 192.168.1.100:22)
>
> How can I find articles explain this issue and ways to workaround this,
> to allow me to access public IP address of the NAT from internal hosts
> behind the NAT and still get the port-mapping working correctly?
Many NAT routers will only perform port forwarding when they receive the
connection on the public interface.
A common solution is access the server by DNS name, not IP, and use
split DNS. When clients behind the router look up the hostname they get
192.168.1.100, when clients on the Internet look it up they get
61.49.215.196.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Eric Tao
> For a typical NAT where 192.168.1.100:22 is mapped to
> 61.49.215.196:22: (61.49.215.196 is the NAT public IP address.)
>
> From 211.157.114.130 (an IP address on the Internet) I can access
> 192.168.1.100:22 by accessing 61.49.215.196:22
I think you are talking about a static NAT?
> From 192.168.1.101 if I try to access 192.168.1.100:22 by accessing
> 61.49.215.196:22 I get connection refused (but I can access directly
> 192.168.1.100:22)
You mean you send package to 61.49.215.196:22 and expect
192.168.1.100:22 respond to you because of the static NAT?
I am wondering why do you want to do this in the first hand?
Thanks,
ET
Pascal Hambourg
Zhang Weiwu a écrit :
> Hello. For a typical NAT where 192.168.1.100:22 is mapped to
> 61.49.215.196:22: (61.49.215.196 is the NAT public IP address.)
>
> From 211.157.114.130 (an IP address on the Internet) I can access
> 192.168.1.100:22 by accessing 61.49.215.196:22
>
> From 192.168.1.101 if I try to access 192.168.1.100:22 by accessing
> 61.49.215.196:22 I get connection refused (but I can access directly
> 192.168.1.100:22)
>
> How can I find articles explain this issue and ways to workaround this,
> to allow me to access public IP address of the NAT from internal hosts
> behind the NAT and still get the port-mapping working correctly?
What you describe is a common issue. Unfortunately I cannot find a
consensual designation which would make a search easier. Maybe try
"loopback NAT".
The origin of the problem is that the steps required to do DNAT
(destination NAT) are sligthly different depending on which interface
the packet arrives at. Remember that the primary purpose of DNAT in most
SOHO routers is to redirect connections from the outside to the inside.
Steps for DNAT from the outside to the inside :
1) Change the destination address of packets arriving at the external
interface.
2) Forward DNATed packets from the external interface to the internal
interface.
Steps for (working) DNAT from the inside to the outside :
1) Change the destination address of packets arriving at the *internal*
interface.
2) Forward DNATed packets from the *internal* interface back to the
internal interface.
3) Replace the source address of DNATed packets with the address of the
router to avoid the "routing shortcut" affecting the reply. For graphic
description see <http://jengelh.medozas.de/images/dnat-mistake.png>.
(side effect : it hides the original source adddress to the server)
Zhang Weiwu
> Hello,
>
> Zhang Weiwu a écrit :
>> Hello. For a typical NAT where 192.168.1.100:22 is mapped to
>> 61.49.215.196:22: (61.49.215.196 is the NAT public IP address.)
>>
>> From 211.157.114.130 (an IP address on the Internet) I can access
>> 192.168.1.100:22 by accessing 61.49.215.196:22
>>
>> From 192.168.1.101 if I try to access 192.168.1.100:22 by accessing
>> 61.49.215.196:22 I get connection refused (but I can access directly
>> 192.168.1.100:22)
>>
>> How can I find articles explain this issue and ways to workaround this,
>> to allow me to access public IP address of the NAT from internal hosts
>> behind the NAT and still get the port-mapping working correctly?
>
> What you describe is a common issue. Unfortunately I cannot find a
> consensual designation which would make a search easier. Maybe try
> "loopback NAT".
Thanks for your detailed explanation! This is indeed very helpful
information