UltraVNC server, port forwarding

My question, basically, is, if a TCP request is received by the wan interface on a modem from the lan interface, and should be forwarded to the lan, will the modem send an ack with rst?

I'll explain my situation, topology, settings, what I'm trying to do and what's happening.

http://i7.photobucket.com/albums/y254/stealthyeliminator/topology.gif

Modem is a Speedstream 4200.

I'm trying to set up VNC server on a lan to be accessible from the internet. The server is set up correctly as I can connect to it using other computers on the lan. I know that ports are correctly forwarded through my router, as I can connect to the server by sending the request to the wan interface of the router. I cannot, however, connect by sending a request to the wan side of the modem. Port forwarding appears to be set correctly, and all documentation that I can find says it is.

The port forwarding in the router obviously forwards to the server, and the forwarding in the modem to the wan interface of the router. I cannot seem to figure out why this isn't working, unless it's because the request to the modem's wan interface is from the lan interface and that is confusing it.

When an attempt to connect through the wan interface of the modem occurs, I receive a rst, ack in return. Everything that I can find on the reset flag is basically not helpful, saying it could mean a lot of different things, or that it just means that the router/interface is "confused".

Any ideas on what might be going wrong?

So far I haven't had a chance to test it from the internet, but I'd assume that, like with the router, attempting a connection using the modems wan interface should simulate that and if it works using the wan interface from the lan, it should work using the wan interface from the internet, assuming the ISP doesn't block anything.

 

Hi,

Well, if it were me, I'd arrange a test from the "outside world", then I'd know whether or not it works for my needs

However, what you're describing is sometimes called "hairpinning" - as in "hairpin turn": For that to work, you'd need to explicitly define the routes/ports involved to the Speedstream, so that when such an "odd" request was made, the Speedstream would know what to do with it. And, it would need to be capable of such as well, which it may or may not be - it appears to be a "bridge/router", and so in theory is capable... but why would you want to?

By "odd" I mean: Generally, there's *no* need for any devices behind a router as depicted in your diagram to ever make such a request to the device "one jump" beyond it - by definition, they are behind the router immediately upstream, and so it is up to that router to determine where externally addressed packets should go, and handle them from there... and, since the node with which you wish to communicate is ALREADY available on the internal network, why wouldn't you simply address it directly?

The test scenario you're describing, considering your diagram, is, from a TCP/IP routing perspective, not necessary, especially when viewed with regards to the ultimate goal: To gain access from the outside world. And, in a real sense, it doesn't test true external connectivity at all, since the origin of the requests are internal.

At least, so it seems to me Do a real test, from somewhere outside the network - then you'll know whether or not it's working as intended.

Regards,

dj

 

Thanks.

The reason that I I'm was "hairpinning" it (glad to learn this term, hope I just used it right) is basically just to test to see if the forwarding is set up correctly. Theoretically, if everything is forwarded properly through the modem and router, it should be accessible from the internet, assuming that you can get to that interface from the internet.

The only reason that I'm trying to do this is to test the modem's configuration. Basically, I wanted to know, if I tried to connect from the internet (and therefore, to that interface), would it work? So, I figured I could test this by trying to connect to that interface. When it didn't work, no matter what I did, I can to the conclusion that maybe it isn't working because, like you said, it's coming from the lan and it's been told to forward to the lan, so it "isn't making sense" to it. However, since it worked in the router I somewhat assumed it might on the modem as well. I know they're two different devices, but I thought at least that aspect of them may operate the same. I can connect "through" the routers external IP, though there is no need, as they're on the same network. There's not really even a need to go through the internal interface, if you wanted to break the interface down between the actual router interface and switch. I believe that it's really basically a switch that you plug into, right? Considering all interfaces on the lan side of the router are really going to the same place, and all have one IP, etc. Though I'm actually using wireless, so that's different to. But that doesn't really matter....

Anyway, I guess that answers my question. So, the reason it's not working is probably because the request is from the lan side, right? Not necessarily because forwarding isn't set up correctly?

I'll see what I can do about testing it from an actually different network on the internet and see what happens. Really, I just wanted to play around with this, test it, and see how it worked. When it didn't work, it became even more of an educational journey, I guess you could say.

I know that it's not necessary and really even "wrong" to connect through the external interface of the modem, but my intention for it was to test it, not actually use it that way.

 

Hi,

But, my point was: Testing it in such a way, from inside the network, doesn't really test forwarding from the outside world, for the reasons I explained previously.

"In theory, there's no difference between theory and practice. In practice, however, there is"

However, I'd point out this: Sending requests, such as you stated initially, doesn't prove proper forwarding from the Internet, in any way, shape or form, for the reasons I already explained, and which I will explain again:

Given your diagram: A request to "server", from "client", explicitly addressed to the Internet address of "modem", is not, by definition, a request "from the Internet".

It's important that you understand this, else we cannot converse further, because you need to understand that there's a fundamental difference between requests from the Internet into a network, and those that are only attempting to fake being such

So, not to be too blunt: The only real way to test forwarding from the Internet is to test it from the Internet. If you have a laptop with a WiFi NIC, go to a cafe, etc., and test it. If you don't, go to a local library that offers computers and Internet access to the public, and do the same.

In addition, because your question piqued my curiousity, I took the liberty of reading the manual for the Speedstream 4200, available here:

http://www.modemsupport.com.au/4x-UM_007-4035-001_1274276.pdf

The section relevant to your issue I quote below:

<snip>
"The Router supports two fundamental modes of operation with respect to connectivity between the Local Area Network (LAN) and the Wide Area Network (WAN): bridge/routing mode and bridge mode. The default mode of operation is bridge/routing mode. With bridge/routing mode, the Router provides typical routing functionality between the WAN side and the LAN side. However, all LAN-side interfaces are "bridged."
<snip>

This sentence: 'However, all LAN-side interfaces are "bridged."' explains why it doesn't work, to my satisfaction, and explains the symptoms you detailed.

I leave it to you, as an exercise, to discover why, and post it here

Regards,

dj

P.S. Yes, I KNOW why - and will explain it, but only after you give up

 

Lol, I wasn't trying to argue with you. Obviously I don't know, otherwise I wouldn't be posting. I was just saying, that's what I originally thought before it didn't work. Then, I began to question it, and utlimately came to the conclusion that it had something to do with the fact that the origin of the request was from the lan side. I didn't, however, know this for sure, and couldn't find any documentation. I did find what I thought was a manual for the 4200, but I didn't see what you quoted. It may have been a different manual.

Well, I didn't really know what a bridge was, so I did a little googling and I thought a little while, and everything that I think of, I start to type out, and then go, noooo that can't be it.

First I thought, because I read that it operates at layer 2, kind of like a switch, it was because the source and destination were the same, but that's not it, I don't think, cause, that's about when the source and destination are the same in the same frame, obviously the source and destination are going to reverse for the response. That theory was stupid. Plus, typically frames are dropped when they have the same source and destination mac, so there wouldn't be a response.

Second thought, was so stupid I'm not even going to mention it..

Third thought... Basically, all I can think of, is that it assumes that packets coming in on one interface are going to go out of the other interface, but that's just something I've come up with based on what it's done, and doesn't really have anything to do with the fact that I know the lan side interfaces operate in bridge mode. I still have a pretty foggy idea of bridging. I mean, I keep reading it acts kind of like a switch and operates at layer 2, yada yada yada, but isn't bridge mode set up between two different devices?

But, am I right that it "assumes" that it needs to go out the other interface?

The reason I haven't actually tested it from the internet is, because it's an UltraVNC server, wouldn't I need VNC viewer on the test computer to test it? Most computers that I'd have access to like at school or the library I don't really have permission to install programs on. I don't have a laptop, either... So... I guess I'll just have to go to a friends house or something. I have been wanting to actually test it from the internet, because, like I said, I really didn't have any idea if doing what I was doing was actually testing it or not, but based on what I know, I theorized that it was. Obviously I was wrong, and let me tell you, that assumption cost me quite a few hours worth of headache.

Based on what I just learned, though, I would assume that it would work from the internet. If I test it and it does work, more than likely, I'll never use it again, but like I said, I mainly just wanted to do it to try to learn.

 

It depends on the Router.

Some Routers allow Out, and In, on the same Network, most do not.

You probably can find a free Internet Dial up service and use a laptop or a computer with Dial up Modem to try.

 

If it makes any difference, I can communicate with the wan interface of the modem, just not using this application. I can ping it, and I can do a tracert to it. 3 hops, it says. First hop is the lan interface on the router(inside router), second hop is the lan side of the modem, third is the wan interface of the modem.

 

Can't edit my post anymore, but, is it because the forwarding only applies to requests that are ACTUALLY coming in on the wan interface, so, even though there is forwarding set up, it still doesn't know what to do with the packets? Communicating with the wan interface from the lan interface is different than communicating with the wan interface from a device actually connected to it, and so it doesn't look at forwarding rules? That would explain, I think, why communication to it would still work, just not forwarding. It sees the packet addressed to it, doesn't look at the forwarding because it's not ACTUALLY coming in on the wan interface, and doesn't know what to do with it. However, ping requests, it does know what to do with.