Re: TCPIP Services and IP masquerading
From: David Webb (david20@alpha2.mdx.ac.uk)
Date: 04/17/03
- Next message: Andrew Robinson: "DECNET IV, TELNET & DCL Files"
- Previous message: Phillip Helbig: "Re: TCPIP Services and IP masquerading"
- In reply to: JF Mezei: "Re: TCPIP Services and IP masquerading"
- Next in thread: JF Mezei: "Re: TCPIP Services and IP masquerading"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: david20@alpha2.mdx.ac.uk (David Webb) Date: Thu, 17 Apr 2003 11:30:46 +0000 (UTC)
In article <3E9DB027.42A4A401@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes:
>David Webb wrote:
>> Hence your NAT device will not know where to send the connection to port 6000
>> and will therefore reject it.
>
>I don't understand what you are trying to say. I have just recently tested
>this and on a Netgear 314, I had no problem getting a remote X-client on the
>internet to open a window on my VAX X-server here. And the remote X-client was
>also running VMS and was also behind some sort of NAT router because its IP
>address was in the 10.* range.
If it is doing pure NAT without port translation or if there is a static NAT
mapping pointing port 6000 at the VMS box you will be OK.
However if it is doing port translation then the NAT box will not know that
the request for the NAT box's address port 6000 is intended for your VAX.
The NAT mapping table could quite easily have setup port 6000 as the external
port corresponding to an outbound connection from another system or more likely
it will not have any entry corresponding to port 6000.
For NAT with PORT mapping the table will contain entries like :-
internal address internal port External address External port
================ ============== ================ =============
10.1.1.4 49168 158.94.100.1 7003
10.1.1.5 4670 158.94.100.1 49200
If 10.1.1.4 telnets to a box on the internet and then tries to run an X
application then the display on the remote system will have to be pointed back
to 158.94.100.1 (the external interface of the NAT box).
The remote system will then send packets back to port 6000 on 158.94.100.1
but when the NAT box receives them it doesn't know what to do with them.
It doesn't have a mapping for 158.94.100.1 port 6000. What should it do -
should it send to port 6000 on 10.1.1.4 or port 6000 on 10.1.1.5 ?
It can't know so it refuses the connection.
You can overcome it by putting in a static mapping explicitly telling it where
to send traffic destined for 158.94.1.100 port 6000
ie
10.1.1.4 6000 158.94.100.1 6000
But this doesn't help if you have users on other machines behind the NAT device
also wanting to display X.
If your NAT box just does NAT translation rather than also doing port
translation ie it has a pool of external addresses to assign then you don't
have this problem.
Internal address External address
================ ================
10.1.1.4 158.94.100.1
10.1.1.5 158.94.100.2
Anything destined for 158.94.100.1 will go to 10.1.1.4
and anything destined for 158.94.100.2 will go to 10.1.1.5
David Webb
VMS and Unix team leader
CCSS
Middlesex University
- Next message: Andrew Robinson: "DECNET IV, TELNET & DCL Files"
- Previous message: Phillip Helbig: "Re: TCPIP Services and IP masquerading"
- In reply to: JF Mezei: "Re: TCPIP Services and IP masquerading"
- Next in thread: JF Mezei: "Re: TCPIP Services and IP masquerading"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|