TCP Mapping testing

[neujron]

Hi,

We will be testing a connection for our TCP Mapping (this is related to my previous topic which is PCAnywhere and USDA TCP connection) this evening and I just want to clarify something on you guys before we do this.

Since you have recommended before that we need to put separate NIC for our internal IP (currently we are using 2 IP for 1 NIC card) because it conflicts, will it make any difference if we're going to disable or remove the internal IP from the adapter and use only the external IP just for our testing? We would like to connect to USDA (TCP mapping) using only the external IP on the server itself just to check if we can connect with 1 IP address only without the internal IP.

Your information / opinion is vital to our test plan. Thank you.

[Pascal]

I don't think it should affect it - but if you only have the external IP, then having a TCP Mapping is redundant - or am I missing the test case you want to setup?

You can simply open the firewall hole, as the connection would be going directly to the server, correct?

[neujron]

Hi Pascal,

Know what? I was able to connect already to the internal machine hosting the PCAnywhere! I just tried it this afternoon. Because we're newbie here regarding firewall and PCAnywhere, we don't know what should be the IP we're going to connect to. We are in the notion that whatever the IP address (in this case the internal IP of the local machine not the internal IP of our wingate server adapter) of the machine hosting the PCA, is the one we're going to connect to. I have tried connecting to our external IP and whoala, it routes and connects me to the host machine!

But we have one more thing left, there's still 1 problem we have. In this case, we are the one that will connect to the remote machine of USDA on port 8423. We still can't connect to their server and we got this error: "class e:IO (Host:151.121.3.252) Connection time out: connect". Just now, my boss is bugging me so much and putting the pressure on us.

I need your solutions guys very badly....

Thanks.

[Pascal]

You are trying to do this with TCP Mappings as well, right?

Or are you doing this through NAT?

What shows up in GatEKeeper?

[neujron]

Yes, it's TCP Mapping also. By the way, how do I know it's NAT and what will be the best to use, what's the difference?

The scenario is we are trying to connect to a remote server of USDA to access their program and we cannot connect internally. There's an HTML file we are running that will connect us to their server. If I'm going to run it to the server itself where Wingate was installed, it connects. But on our PC we can't and connection error "timed out" occurs.

Please advise, thanks.

[neujron]

By they way, you've asked me what shows up in Gatekeeper?

Well, absolutely nothing is recorded there, Activity, Firewall or History, nothing's showing in there.

[Pascal]

Well, it's difficult to tell if you NAT or not. If you have the "Extended Networking" option in GateKeeper (Under System Services) you should have it installed. Then, if you go in there, it should be "Enabled". Then, if your client computer is set to use the WinGate Server as it's default gateway, you should not need to do anything to make this work.

However, if I recall correctly you are running either an older version of WinGate or you do not use ENS / NAT.

So, assuming you have the TCP mapping setup (Similar as the one for PCAnywhere, except you change the port numbers) then you should only need to connect the application to the internal IP of the WinGate Server on the port number specified (Not the actual public IP). That's the purpose of a TCP Mapping - it allows WinGate to connect you to your destination.

[neujron]

Hello Pascal,

Well, I have checked the configuration for Extended Networking and on General menu, Extended Network Driver and General Purpose Internet Sharing (NAT) are both checked/selected so I think we are using both feature together with the Support for Multiple Subnetworks (router).

We are already using the latest version (6), remember we had the issue when we upgrade which is "An unsupported operation attempted" something like that on the Policies when we try to modify it? I think we're the one who 1st reported this.

BTW, with regards to that error, I have seen the posting of Adrien regarding the new patch for version 6. Does it include also the fix for our problem which is upgrade from previous version (4) to latest version specifically the problem for "An unsupported operation attempted" error? Is this the one we need for that issue?

Best regards.

[Pascal]

Yes, under the release notes

5. Fixed a problem with GateKeeper crashing if the user edited policies whilst using a version 4 or previous license.

relates to your "Unsupport Operation" case.

[Pascal]

need to connect the application to the internal IP of the WinGate Server on the port number specified (Not the actual public IP). That's the purpose of a TCP Mapping - it allows WinGate to connect you to your destination.

Is that the case? If you connect to the internal IP of the WinGate server, it should go out through your mapping. As an alternative (As a quick test)

Have you tried using NAT?

[neujron]

Thanks for the info, I'll try to update now.

For the USDA TCP mapping (port 8423), I still can't connect, same error message. I've modified the default mapping to our internal IP instead of connecting to 151.121.3.252 (USDA) but still unsuccessful.

Any other ideas on this? My manager is getting frustrated already. Please help... (SOS).

[Pascal]

Don't really know how to draw this without a pen/paper, but here goes.

Example:
Client computer - running USDA connecting application
IP: 192.168.0.10

WinGate server - running TCP mapping
Internal IP: 192.168.0.1
External IP: 202.xxx.xxx.xxx

USDA server
External IP: 151.121.3.252

The WinGate Server has a TCP mapping that will listen on port 8423. This mapping will redirect to 151.121.3.252 (Port 8423). Your client computer should be making a request to the port + internal IP of WinGate. I.e. 192.168.0.1 port 8423, in this example. WinGate will then make the connection to 151.121.3.252 on port 8423.

At which point, the mapping is an established connection, etc.

[neujron]

That's exactly what we have tried and configured on the wingate server. We have opened the port 8423 and created a TCP Mapping that listens to it and redirects to USDA external IP.

But I'm not that clear about the thing you've said about client PC's making a request to the PORT + Internal IP of Wingate. Is this being done on the Mappings where we are going to make a "Link" to Internal IP of Wingate thru port 8423?

For example:
Link to 192.168.0.1:8423

Or is it somewhere else? Please guide us further. Thank you.

[Pascal]

In the application / method that you use to connect to USDA. THAT must connect to the internal IP of WinGate.

Is it possible for me to see / get the application that makes this connection? That might be the easiest, then I can tell you exactly where to set it up?

[neujron]

I was supposed to ask you if I can give you the application file and check the connection from there. I have asked permission already to my manager and he gave me the go signal. Actually, he told me that you can download it from the USDA site and no registration is required but I'll just give you the files anyway thru e-mail off-list.

Is it okay for you if it's a ZIP file about 1.5MB size?

I have modified also the HTML file where port and host name can be found, where host name is the IP of USDA server and change it to our internal IP but I was being firewalled (with a blue arrow up icon - what's the meaning of that icon anyway?) in gatekeeper. Still I cannot connect.

Thanks.

[Pascal]

That is just a notification - not a block! That sounds like progress. If you've modified the HTML, that definately sounds like progress. If i can download it from their website, I'll do that - send me the link, please?

[neujron]

Here's the link: ftp://151.121.3.187/cotton/CTN6530/

I looked into the log file and somewhere between the lines it says "Socket Error 10057" (check log below - note: I have changed the connecting IP to 192.x.x.x), I think this is one of the reason we cannot connect after changing to the internal IP in the HTML file.

09/13/04 15:16:24 192.x.x.x Guest 0000000553 Created:
09/13/04 15:17:09 192.x.x.x Guest 0000000553 Error: Caught socket exception in CTCPMappingSession::Initialize() Connection to Remote Host timed out - terminating
09/13/04 15:17:09 192.x.x.x Guest 0000000553 Error: Caught socket exception in CTCPMappingSession::OnRead() Socket Error 10057 {Thd 143} [socket #E50, 192.0.0.8:1937 to :0] - terminating
09/13/04 15:17:09 192.x.x.x Guest 0000000553 Traffic 0 0 0 0 45s
09/13/04 15:17:09 192.x.x.x Guest 0000000553 Terminated exit code 1
09/13/04 15:21:22 192.x.x.x Guest 0000000564 Created:
09/13/04 15:22:07 192.x.x.x Guest 0000000564 Error: Caught socket exception in CTCPMappingSession::Initialize() Connection to Remote Host timed out - terminating
09/13/04 15:22:07 192.x.x.x Guest 0000000564 Error: Caught socket exception in CTCPMappingSession::OnRead() Socket Error 10057 {Thd 300} [socket #C0C, 192.0.0.8:1959 to :0] - terminating
09/13/04 15:22:07 192.x.x.x Guest 0000000564 Traffic 0 0 0 0 45s
09/13/04 15:22:07 192.x.x.x Guest 0000000564 Terminated exit code 1
09/13/04 15:24:26 Configuration changed
09/13/04 15:26:18 192.x.x.x Guest 0000000586 Created:
09/13/04 15:27:03 192.x.x.x Guest 0000000586 Error: Caught socket exception in CTCPMappingSession::Initialize() Connection to Remote Host timed out - terminating
09/13/04 15:27:03 192.x.x.x Guest 0000000586 Error: Caught socket exception in CTCPMappingSession::OnRead() Socket Error 10057 {Thd 444} [socket #FC4, 192.0.0.8:1997 to :0] - terminating
09/13/04 15:27:03 192.x.x.x Guest 0000000586 Traffic 0 0 0 0 45s
09/13/04 15:27:03 192.x.x.x Guest 0000000586 Terminated exit code 1
09/13/04 15:39:43 Configuration changed

- WHAT COULD BE THE REASON???

[neujron]

BTW, after downloading the self-extracting exe file to a folder, go to CNT6530 folder and look for CentralDatabase.HTML file, that's the file that will connect you to their server.

thanks.

[Pascal]

Okay, this is very strange. I have a server setup with one internal network card (private) and one external (public). Downloaded the application from a client (Through WinGate) and set it up on the client computer.

Without creating a TCP mapping (Using NAT) I ran the CentralDatabase.html. It started a TCP connection, asked me to download an application which was used to verify the CRL, and then opened the program. The program itself executed a few commands and then attempted to retrieve a file called \NATDB. (I assume that is the National Database itself). That failed - but there was no indication (Firewall hits or otherwise) that there is a problem from WinGate's side - so I'm pegging that it might simply be my setup of the application OR something that I should've done to make this all work sweetly.

Then, I created a TCP mapping, set it to bind to the internal adapter on port 8423 and told it to connect by default to 151...... on port 8423. I modified the CentralDatabase.html and told it to connect to 192.168.6.30 (Internal IP of my server) rather than 151........ and opened the HTML file again. Same result, except this time the session showed as a TCPMapping rather than NAT.

It all seems to work 100%. I took screenshots of every step along the way - can I email them to you? (Size is 492KB, as .jpg files)

[neujron]

Hi Pascal,

I'll be glad to have the screenshots and see the result also.

Have you created a TCP hole for port 8423 in ENS? You mentioned you have 2 NIC cards, 1 for internal IP 1 for external IP. For us, we have only 1 NIC card with 2 IPs together (external/internal). Maybe that's the reason why you're okay with the connection. The file NATDB will be searched on your local drive and I know it will look for that and that's the only point you'll be connected. You don't have to do anything because there's another system that handles that file.

I've created same process that you have before except that I bind to "any adapter on any IP" because that's how my PCAnywhere TCP mapping was configured.

Thanks

[Pascal]

No, I didn't create the hole. As I was making the connection it wasn't necessary. One adapter might complicate matters, slightly. Let me send you the screenshots though - they're on their way. Then you can have a look and see how close you are to that.

If you don't get the screenshots, let me know, please.

[neujron]

One more thing, did you run the HTML file on the server or did you connect to a client PC?

Just now, I tried also binding to the Internal IP by modifying the TCP mapping and modified also the HTML file and changed the value to our internal IP but still there's an error same as when I haven't changed the bindings yet, pls. check message below

"class e: IO (Host: 192.x.x.x) Tried to receive another message, but stream has no more data."

Thanks.

[Pascal]

I ran the HTML from a client PC.

[neujron]

I received already the screenshots and have tested already here. I followed every shots to my configuration.

At first, and I suspected also, the bindings is the problem. Your binding and my binding is different because when I tried using ANY internal IP on ANY adapter, it won't add up to the list. There's only 1 line which is the loopback. This is because we have only one NIC card. So, we can't connect.

What I did was to change it from ANY internal adapter to ANY IP Address on our NIC card. That's it, we are already connected!

Thanks for all the help guys and more power to you!!! Best regards.