SocketException

[George Bonfield]

Hello -

Connections are successful between my clients and server when on the LAN, but pointing the clients back to the server over the public IP address makes one of the sockets refuse its connection. The complaint is "TwoStacksPlainSocketImpl.socketConnect . . .".

Thanks,

[Rob Spoor]

Welcome to the Ranch!

Can you please post the full stack trace, and the method that it's thrown from?

[George Bonfield]

Thank you Rob.

java.net.ConnectException: Connection refused: connect
at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at peerServer$voxOfferListener.run(peerServer.java:256)
at java.lang.Thread.run(Unknown Source)

The method :

class voxOfferListener implements Runnable{
			
	      		private Vector invitees;
			protected Thread VoxBox;
			private boolean iamcaller = false;
	      		String protocol;
			String ipAddr;
			Socket objSocket;
			ObjectInputStream ois;
			ObjectOutputStream oos;
			


  	     		public void run() {

				try{
				
		 		try{
				while((!((protocol=(BR_voxinitreader.readLine().trim())).equals("")))&&socketopen){
					
					
				     switch (protocol) {
            					case "RNG":  
							try{ 
						      iamcaller=true;
						      ipAddr = So_mysocket.getInetAddress().getHostAddress();
						      
						      objSocket=null;System.gc();
						        try{Thread.sleep(1000);}catch(InterruptedException linkex){}
						      objSocket = new Socket(ipAddr,30312);
						      ois = new ObjectInputStream(objSocket.getInputStream());
						      oos = new ObjectOutputStream(objSocket.getOutputStream());
							}catch(Exception er){er.printStackTrace();}
						      
						      invitees = (Vector)ois.readObject();
				
						      invitees.remove(peerServer.this.getName());
						     						      
						      pS.accepteeVector.clear(); 
						     
						      voxOffer();
						      invitees.clear();
						      						      
						      protocol="";
						      
						      VoxBox=null;System.gc();
						      VoxBox = new Thread(new VoxBox());
						      peerServer.this.incall=true;
				  		      VoxBox.start();
 						      Integer I = new Integer(1);
						      oos.writeObject(I);
						      oos.flush();
						      ois.close();
						      oos.close();
						      objSocket.close();objSocket = null;System.gc();
						      break;
            					case "Y":       
						   
						    iamcaller=false;
						   
						    peerServer.this.incall=true;

						   
						    VoxBox=null;System.gc();						    
                  				    VoxBox = new Thread(new VoxBox());
				  		    VoxBox.start();
						    						    
						    PW_voxinitwriter.println("OK");						    						    
	  					    
						    break;

					case "STO": 
						    
						    if(iamcaller){for(Thread peer : pS.accepteeVector){
							boolean amstopping=((peerServer)peer).stopincall();}}
						    VoxBox=null;System.gc();
						    
						    protocol="";
						    incall=false;
						    break;
           
       				    }
				}
					     			
				}catch(SocketException vo){iamcaller=false;incall=false;System.out.println("Socket fault protocol mash");vo.printStackTrace();}						
		              		}catch(Exception invit){System.out.println("Unspecified Exception\n ");invit.printStackTrace();}
                  		 } 

line 256 is where the new Socket is created. (Sorry about the ragged layout).

G.

[Paul Clapham]

I added code tags to your post, so the code is more readable. (Perhaps that was what you meant by "ragged"?) However the line numbering in the post is not the same as the line numbering in your text editor, so "line 256" doesn't match anything in the post. Could you point at the actual line which threw the exception?

[George Bonfield]

Well, thank you bartender, that's kind of you. I wasn't sure how to best present the code. Will try harder in future.

The line the JVM reports is now the line coming up as 30 in your formal layout - viz where the Socket is instantiated.

[Paul Clapham]

That's about what I expected. That line of code tries to connect to some server, whose name we don't know, at port 30312. This could be for a variety of different reasons, but to start the debugging process you would need to know the value of that "ipAddr" variable, so you can tell exactly what it's failing to connect to.

[George Bonfield]

We're in luck then, because not only did I write the code, but I also know what kind of server it is trying to reach, as well as the IP.


The IP address is that of the client with which the server already has established socket connections. On this occasion, the server is to connect to a ServerSocket on the client, and prepare to receive a Vector Object from the client. Once the object is transferred (which happens faultlessly on a LAN), the socket is used one more time (since it is open), to send an Integer back to the client, signalling that the transfer has been concluded. Then the life of that objSocket is over.

[Paul Clapham]

Right. But that's "supposed to". What is the actual value of the "ipAddr" variable when the exception occurs?

[George Bonfield]

OK, so I wasn't expecting 'ipAddr' to be the same IP (the public one) as the client connected to the server on - but it is. I expected ipAddr to be 192.168.0.2.

Thing is, when the server is sitting on port 30312 on the LAN, the clients' IPs are all LAN addresses - aren't they? Where's the NAT in that?

G.

[Paul Clapham]

George Bonfield wrote:Thing is, when the server is sitting on port 30312 on the LAN, the clients' IPs are all LAN addresses - aren't they? Where's the NAT in that?

I don't understand that question. This is client code we're looking at, isn't it? So how the server sees the network has nothing to do with this code. It looks to me like the client is getting the IP address that it's supposed to connect to from a previous connection, or something like that. So how did that connection work? Did it use a different IP address than the one you're seeing which can't be connected to?

Edit: No, wait a minute, all my assumptions are wrong. You already answered that. This is running on the server and trying to connect to a client. But since you were talking about a NAT, chances are that the client is outside your network and the NAT is there to make sure that clients from outside the network can connect to your server. Not the other way around.

[George Bonfield]

OK - little office. 3 machines, local Ethernet LAN. Router. Me.

Program : Desktop Java 1.5 app., server and client.

Server sits on one machine. I run 2 clients on each of other 2, over the LAN, behind the NAT. Everything works just fine. No exceptions, no foul-ups, with the 2 clients pointing at '192.168.0.4'. The clients have 192.168.0.2 and 192.168.0.3.

Router has a rule (and so does the OS too), to open ports for in- and outbound on all my sockets, including 30312 of course.

Then I drop everything, and reconnect the both client and server, but this time point the clients at the server's public IP. This is when the TwoStackPlainSocket refusal turns up. No other changes are made. The rest of the programme goes on functioning as normal (mostly text streams), but the functionality over 30312 is dead from the exception.

[Paul Clapham]

So now the clients are sending requests which appear to come from outside your network. The NAT sees those requests and passes them on to your server. So far so good. But the NAT sees that they came from outside your network; in fact it sees that they came from your public IP address. Which is why the IP address you're getting is your public IP address.

The main problem is that you've accounted for your server running a server in your LAN, and you've configured the NAT to route connections requests to it successfully. But you haven't accounted for your clients running a server, and so the NAT doesn't route connection requests to them.

At least that's how I see it.

[George Bonfield]

How I see it is this : NAT sees a socket requested by a LAN client, and speedily opens a stack for it, because it knows whence all LAN packets originate. Then, it tries to resolve a call on the same port, but on the other side of the NAT, but sadly has no idea that it's dealing with exactly the same client host for both calls.

ipAddr = (((InetSocketAddress)So_mysocket.getRemoteSocketAddress()).getAddress()).getHostAddress();

This has the same problems as the posted code. I ask myself, 'what is a remoteSocket, if it isn't the one at the other end of your connection'.

[Paul Clapham]

Stepping back a bit: the idea of having a client also act as a server is problematic; most computers can readily act as TCP/IP clients but not as servers, because there are firewalls or proxy servers or security appliances or contractual restrictions or other things preventing them from doing that. So your application may work perfectly well inside your LAN, but if you are expecting computers outside the LAN to act as clients, there's a good chance they won't be able to act as servers and you're repeatedly going to have to deal with this sort of issue.

Which really means you shouldn't attempt to install your application outside your LAN. And which in turn means that you don't need to bother to understand what's going on here. Just don't do it.

[George Bonfield]

Your admonishments are of course pretty ridiculous for a number of reasons, not least of all because they would effectively spell the end of the internet if they were ever implemented. One machine can act as a server or client, depending on the application in hand, and that's precisely why in- and outbound rules exist for routers and firewalls.

[Paul Clapham]

I'm just saying that if you want to run a server on the Internet, you have some configuration to do to make it work as a server. Obviously people do run servers on the Internet. You haven't done any such configuration and therefore your clients aren't working as servers.

[George Bonfield]

Sorry - did I miss something here?

I am already running a server over the internet - the rest of this application serves clients over the internet. Did you not understand that originally?

The problem is that in one particular method, it is convenient and desirable for the server to call a serversocket on a client (we don't need to discuss why that is). And it is at that point that the connection collapses. But only on that socket. The rest keep working.

I can't repeat the scenario again here any more.

[Paul Clapham]

George Bonfield wrote:Sorry - did I miss something here?

Apparently so.

I am already running a server over the internet - the rest of this application serves clients over the internet. Did you not understand that originally?

Actually I did understand that.

The problem is that in one particular method, it is convenient and desirable for the server to call a serversocket on a client (we don't need to discuss why that is).

This is where you start missing things. Now your client starts to act as a server. You did configure your main server so that it can accept connections from outside via the NAT, and that part is working. However you haven't configured your clients so that they can accept connections from outside via the NAT, and so that part isn't working.

[George Bonfield]

And that brings me back to my question - what does one have to do to overcome the fact that the socket to allow such a relationship, is refused?

[Paul Clapham]

Okay. So let me ask you a theoretical question: You're running a server which accepts connections from clients on the Internet. So would you expect to be able to accept a connection from the computer I'm using right now? Obviously it can connect to Internet servers, otherwise you wouldn't be reading what I typed.

And if so, would you expect to be able to connect back to it (assuming your application was running here) in the way you are wrestling with now?

The fact is that you wouldn't be able to. Your server would tell you that the connection came from 204.244.x.y, but that isn't the address of my computer. It's the address of the proxy server which sits between the LAN where my computer is located and the Internet. So if you try to connect to IP address 204.244.x.y at port 30312, you will get the connection failure which you are now well familiar with. That's because the proxy server hasn't been told to forward such connection attempts to my computer, which is the one running the ServerSocket.

Which is precisely what is happening to you in the example you're asking about.

That's why I said the design where the client acts a server and the server connects back to it was "problematic". It requires the client to have a direct connection to the Internet, or else it requires the device through which the client connects to the Internet to be programmed to forward connection requests to it.

[George Bonfield]

Okay. So let me ask you a theoretical question: You're running a server which accepts connections from clients on the Internet. So would you expect to be able to accept a connection from the computer I'm using right now?

Of course I would expect to be able to accept a connection from your computer - if your computer were running my software.

And if so, would you expect to be able to connect back to it (assuming your application was running here) in the way you are wrestling with now?

Yes, if by "it" you mean my programme running on your machine - provided your firewalls were open on the right ports, and that when your client (which is now a partial server) has approval from the user via a response delivered over one of the existing sockets, then sure.

As for a proxy server, I don't know where that fits into anything.

[George Bonfield]

In any case, I expect my code *would* work if it were served on this machine, connected to your machine on a true remote IP, and then tried to connect back to this server using your public IP - that would work.

What won't work is me emulating that here, except that I haveto emulate *"your"* computer by getting one of my clients to address the server via the public IP.

[Rob Spoor]

And I think that's where the problem lies. You're trying to connect from inside your LAN to outside your LAN to back inside your LAN. You need to enable LAN loopback for that to work.

[Paul Clapham]

George Bonfield wrote:In any case, I expect my code *would* work if it were served on this machine, connected to your machine on a true remote IP, and then tried to connect back to this server using your public IP - that would work.

Right. But my machine doesn't have a public IP -- that's the problem. And your machines where you are running your client software on and trying to make them act as servers -- they don't have a public IP either.

As for a proxy server, I don't know where that fits into anything.

That's the same sort of thing you're calling a "NAT". But the fact that you don't understand its relevance is part of the reason why you're having a hard time with this problem.

[George Bonfield]

You're trying to connect from inside your LAN to outside your LAN to back inside your LAN.

I concur. That's exactly what it is. And that's the only way to emulate the real world, when you can't do it any other way.

Another irony here is that a machine such as yours, which is probably also behind a NAT, will receive return packets from my NATted machine, so it's not as if the routers can't work out where the packets should end up, so where is that information gone when the LAn client wants to connect back to itself from a remote-**looking** IP? That's what grinds my gears.

You need to enable LAN loopback for that to work.

AFAIK, there is no way to implement a LAN-wide loopback, - (which AFAICS would only mirror the entire problem down the hallway) - only a single-machine loopback is possible. Kick me if I'm wrong.

[George Bonfield]

I do understand the relevance of the NAT. However, I am not sure that you understand the pathology of this problem in the way that you need to.

To quote one of your recent facts, you say that your machine doesn't have a public IP. Fine. But it is connected to the internet, and so it has a public IP at the level of the router or proxy, wherein routing tables are kept to route the return packets back to the right machine - yours. So far so good.

If you were running my code on your machine, you'd be asked in a pop-up window to point it at the IP address of my server, which happens to be behind a NAT.

The two "routers" would know the end-to-end points for the traffic, and that would all work.

Your interface would then for some business reason we don't need to rehearse here, offer you the option of doing some other task with my server, for which another socket needed to be opened. At this point, the most convenient way of getting that link up and running quickly and according to the stochastic nature of the decisionmaking process on the client, is over a socket which your client needs to wait for - ie it needs to open a Serversocket. Your client obtains my server's IP from the socket address of one of the other already open sockets, and uses it along with a predefined port, to wait for the server to request an .accept() your end, and transfer a Vector via an ObjectOutputStream. None of this is rocket science, and none of it should surpise nor overhaul the capabilities of the routers to identify and resolve the origins and destinations of the packet exchange. And that's why it would all work between our machines, despite you not evidently having a public IP.

But the moment I emulate your machine in that scenario on my LAN, the objSocket at 30312 socket throws a fit, and thinks there is only one entry in the routing table, and that entry is for itself.

Feel free - you can have a copy of the client (and the server if you like), and the proof of the pudding will be forthcoming.

[Rob Spoor]

George Bonfield wrote:

You need to enable LAN loopback for that to work.

AFAIK, there is no way to implement a LAN-wide loopback, - (which AFAICS would only mirror the entire problem down the hallway) - only a single-machine loopback is possible. Kick me if I'm wrong.

It depends on the router / firewall. On my firewall at home I can add a full loopback NAT policy like this:
- Original source: the subnets to allow, as one address group.
- Translated source: the WAN primary (a.k.a. public) IP address.
- Original destination: the WAN primary IP address.
- Translated destination: the server.
- Original services: the services to connect to.
- Translated services: "original".
- Interface inbound: "any".
- Interface outbound: "any".

That sounds difficult, but here's what it does: when a connection comes from a PC in the LAN to the public IP address to the services (e.g. port 30312), the firewall converts this request as if it's a request from the public IP address to the server. For example, a request from 192.168.0.4 (original source) to 123.123.123.123 (original destination) for TCP port 30312 (original service) gets translated into a request from 123.123.123.123 (translated source) to 192.168.0.5 (translated destination) for TCP port 30312 (translated service). In other words - NAT loopback.

Now granted, my firewall is a bit more advanced than your basic firewall so it may not be possible with your firewall / router. Check its documentation to see if this is possible.

[Paul Clapham]

George Bonfield wrote:Your interface would then for some business reason we don't need to rehearse here, offer you the option of doing some other task with my server, for which another socket needed to be opened. At this point, the most convenient way of getting that link up and running quickly and according to the stochastic nature of the decisionmaking process on the client, is over a socket which your client needs to wait for - ie it needs to open a Serversocket. Your client obtains my server's IP from the socket address of one of the other already open sockets, and uses it along with a predefined port, to wait for the server to request an .accept() your end, and transfer a Vector via an ObjectOutputStream. None of this is rocket science, and none of it should surpise nor overhaul the capabilities of the routers to identify and resolve the origins and destinations of the packet exchange. And that's why it would all work between our machines, despite you not evidently having a public IP.

You seem to think that if you explain half of the system (the working half) often enough, that will make the other half (the broken half) start working. But you yourself have already done the experiment which demonstrates why it doesn't work, all of that hand-waving above notwithstanding. It isn't the configuration of your NAT which is the fundamental problem, it's the design which assumes that your two-way communication idea can be made to work. Maybe you and Rob can fiddle your NAT so that it starts working in your network, but that's just a local hack.

[George Bonfield]

Let me finally add this in response to Paul's last:

I neither want, nor need, a real deployment of my code to do what I am doing; if a LAN client here wants to connect to the server here, it'll have to do so using the LAN address - and that's completely fine.

Because then, if my client is connected, and 'your' remote machine connects, then our clients can communicate, and as far as I can see, the on-the-fly created troublesome socket will be operational. But it can't be *tested* locally (i.e. LAN-based, with a public IP connecting client as one of the clients), and that sucks.

[Rob Spoor]

Unfortunately, unless your firewall / router supports LAN loopback like my previous post described, that's something that you can't solve. It's not a flaw in Java programming, it's a "flaw" in the way networks work. My first step now would be to check my firewall / router documentation and figure out if it supports LAN loopback, and if so how, as that can be different for each brand / type of firewall / router.

Perhaps if you dare to and your firewall / router is supported, you can try to install DD-WRT. It's a custom firmware that often adds a lot of extra functionality. A word of caution though - you will lose all support on your device from the original vendor, and if the firmware upgrade fails your device may become permanently inoperable.

[George Bonfield]

Thanks. I won't be fiddling with my firewall however.

I don't profess to be an arch techie, and some low-level knowledge of router circuitry and IP packets eludes me. But one thing, as a programmer, I do know, and that is that if a contingency exists, then you have to accommodate (provide for) it within your system. This is clearly something that NAT technology fails in, and it surprises the life out of me that this meta-point has been overlooked or ignored by the designers. As I said in my previous so-called 'hand-waving posts' - (waving always being preferable to reciprocation) - if the thing works in a LAN, then at that point, my job ought to be over.

[Jeff Verdegan]

George Bonfield wrote:Thanks. I won't be fiddling with my firewall however.

I don't profess to be an arch techie, and some low-level knowledge of router circuitry and IP packets eludes me. But one thing, as a programmer, I do know, and that is that if a contingency exists, then you have to accommodate (provide for) it within your system. This is clearly something that NAT technology fails in

No, NAT technology is not failing. It is working exactly as designed, and there's no reason to expect it to behave otherwise. The NAT device cannot know, without you telling it explicitly, that stuff that it receives on some port is destined for 192.168.x.x:some_port. From your crosspost, is seems that you think that simply "opening" a port on the NAT device will allow you to connect to your LAN's 192.168.x.x from anywhere on the internet. This is, by design, not the case, as you would know if you'd read the links I provided in your crosspost on public and private IP addresses.

As I said in my previous so-called 'hand-waving posts' - (waving always being preferable to reciprocation) - if the thing works in a LAN, then at that point, my job ought to be over.

It's over if your job is only to write the code, but if you're also the network admin, then you have to don that hat and properly configure the NAT device to forward it's public.ip.what.ever:some_port to your LAN's 192.168.for.example:some_port.

[Jeff Verdegan]

George Bonfield wrote:OK, so I wasn't expecting 'ipAddr' to be the same IP (the public one) as the client connected to the server on - but it is. I expected ipAddr to be 192.168.0.2.

This, along with comments in your crosspost about "opening" ports, suggests that you're still misunderstanding port forwarding and IP addresses in a big way.

Do you understand the difference between public and private IP addresses? In particular, do you understand that there can be thousands of computers with the IP of 192.168.0.2, and that that IP is ONLY meaningful on a LAN, and cannot be used from outside that LAN to address a computer on that LAN?

[George Bonfield]

I live in a house. My house has an address. In that house, I have my own room, perhaps a bedroom with en suite.

All the mail that comes into the house, is addressed to a particular person, me being one such.

For reasons that matter to no-one except me, I cannot leave my room.

If I want to send mail to others in the house, I simply write their name on the envelope.

My guardian (who also lives in the house), delivers all mail. Letters come for me regularly - all from people I've written to first mind you. (After all, no-one wants to be the first to start correspondence with a freak). The guardian knows, and implements, this rule tightly. So he brings letters to my room on that understanding. The only people I don't need to write to first, before receiving a letter, are the others in the house, since we are all known to the guardian a priori.

Sadly, I send letters to myself sometimes too. They don't need a house address, only my name, just like the others. (I just give them to the guardian, who hands them right back to me). For good measure, I write my name on the back of the letter, so he knows what to do with it if I am not there. (That was a joke).

One day, just for fun, I decide to spend all my money on a stamp, and write a 'proper' letter to myself. I get someone on the street to post it for me. Next day, it comes back, and the guardian thinks he recognises the handwriting, but he can't be sure, thinks it may be a spoof, and decides to throw it in the bin. I'm left puzzled, because I thought the same rule would apply to that letter as apply to any I send myself in-house. Wrong; 'new' rule. The same rule applies if I try to send a franked letter to someone in my own house.

Making matters slightly worse, if they can be worse, is the censorship of my mail extending to any supernumerary letters which I receive; in other words, if I am in an ongoing written dialog with someone, if they send me even one extra letter, it gets binned, since it doesn't tally with my outgoing missives. This regime quickly impoverishes the nature of my correspondence, making the process of communication pedestrianly and unappetisingly slooooooooooooow. A lot of good information goes into my guardian's bin liner.

On the bright side, those years' of internal scriptural exile pay an ultimate dividend, when I realise I've stumbled across the methodology to allow the invention of the internet.

[Jeff Verdegan]

George Bonfield wrote:I live in a house.
etc.

None of which has anything to do with the problem at hand.

I understand how port forwarding works. So do the others who have been trying to help you in this and your other thread. We don't need a vague and inappropriate analogy to explain it.

If you still cannot figure out your problem, please respond, clearly and precisely, to the technical points that have been raised and the technical advice you have been given.

For starters:

Me wrote:
Do you understand the difference between public and private IP addresses? In particular, do you understand that there can be thousands of computers with the IP of 192.168.0.2, and that that IP is ONLY meaningful on a LAN, and cannot be used from outside that LAN to address a computer on that LAN?

[George Bonfield]

Yep -I absolutely understand those IP differences. And if you'd read my posts properly, you'd realise that I knew that, and that I'm not contending that is my problem. I'm don't need nor attempt to send my private IP to any part of the programme or the internet, least of all the server,since it will obtain it from the socket connection, putting it de facto out of my hands, unless I have some reason to query the socket for it later.

[Jeff Verdegan]

George Bonfield wrote:Yep -I absolutely understand those IP differences. And if you'd read my posts properly, you'd realise that I knew that, and that I'm not contending that is my problem.

The problem is in your writing and your comprehension, not in my reading. You have used non-standard terminology to weave inaccurate and meaningless statements and have not directly and clearly addressed the technical points and questions that EJP and I have raised.

I'm don't need nor attempt to send my private IP to any part of the programme or the internet,

Of course not. Nobody has even remotely suggested otherwise. Not sure why you would even think we did, but it leads further credence to the thesis that you don't really understand what you claim you do.

least of all the server,since it will obtain it from the socket connection,

Eh? No. The server will not, in general, learn the client's private IP address. It will, of course, when both are on the same LAN, but when one of the client/server pair is inside a given LAN and the other is not in that LAN, the private IP address of the one inside the LAN will NOT become known to the other one.

putting it de facto out of my hands, unless I have some reason to query the socket for it later.

Well, yes, the whole notion of public vs. private IP addresses, NAT, and port forwarding *is* out of the application programmer's hands. It is a network admin's job. So, as already stated many times, if a client outside the LAN cannot open a connection to a server inside that LAN, then it is one of the cases I listed in your other thread, such as that the NAT device has not been explicitly configured to explicitly forward public_ip:public_port to private_ip:private_port--a point which you have studiously avoided addressing for a dozen or more posts across both threads, despite two or more of us telling you this has to be addressed.

[Rob Spoor]

George Bonfield wrote:One day, just for fun, I decide to spend all my money on a stamp, and write a 'proper' letter to myself. I get someone on the street to post it for me.

How? How did you get that letter outside to that someone on the street? You can't send anything without your guardian. And that's the problem here. Your guardian is a bit dumb, and is very confused about getting a letter from inside the house to inside the house but with the outside address on it. Someone needs to tell him first that those kinds of letters should go to you. After you tell him that, he'll then be able to intercept the letter before it goes outside of the house and send it back to you.

If we translate this back to NAT, that's exactly what NAT loopback is. You tell the router / firewall that requests for a service from inside the LAN to the public IP address should be sent to the specific server inside the LAN.

[George Bonfield]

Actually my guardian doesn't need to read the address on my outgoing stamped mail, because that will get done in the sorting office. All he needs to do is to keep a count of the number of letters I send, and as long as the count of letters back to me is <= the number of letters I send, then he's happy. But should an extra one arrive, he bins it.

Jeff : from one greenhorn to another, please come back when you understand my issue.

[Jeff Verdegan]

George Bonfield wrote:Actually my guardian doesn't need to read the address on my outgoing stamped mail, because that will get done in the sorting office. All he needs to do is to keep a count of the number of letters I send, and as long as the count of letters back to me is <= the number of letters I send, then he's happy. But should an extra one arrive, he bins it.

The letter analogy is not apt. A phone call analogy would be better. Once can dial out from a telephone to the outside world, and the conversation can go both ways, but that doesn't mean the same phone call can be originated from the outside.

Jeff : from one greenhorn to another,

I'm only a greenhorn in terms of number of posts to this particular forum. Not in Java, not in writing networked applications, and not in helping people overcome misunderstandings they stubbornly cling to.

please come back when you understand my issue.

If I'm misunderstanding something, it's only because you've failed to explain it properly. Do you ever plan to address the specific technical points that EJP and I have raised? Unless you've completely misrepresented your problem (a host outside the LAN is unable to establish a connection to a host inside the LAN), we've already told you several times exactly what the source of the problem is and how to remedy it.

I'll stick around until I decide I'm ready to leave, thank you very much.