Dave,

I enjoyed talking with you today and would be happy to help with clarifying the Big Sandy installation and helping to solve future ones. Below is an outline of the problem and what we had to do to get Big Sandy up. There are a few holes that may need to be filled in by your developer as my memory of the Linux particulars may be inaccurate.

Trax, as I understand it, is a three function information support system

that:

1) collects in store data such as Door Entry events with photo correlation.

2) collates and organizes this data in a centrally accessible Internet location.

3) reports these data events and allows global customer database interaction via Http.

Normally the Trax server will sense an event of interest such as a customer entry into the store, take a snapshot of this entry and upload this data to a central SQL sever on the internet. The management can then remotely Browse to the server's web page to view and manage the data.

In most networks this is an automatic and pretty straight forward process.

The data flow goes something like this:

Local_Trax_Server---->Gateway_Router---->Internet---->SQL_Server---->Web_Pag

e

In this example, I will use the following IP address scheme:

The Gateway Router performs NAT (network address translation, or IP

Masquerading) to "convert" the inside IP Addresses to Outside Routable Addresses.

So, the TCP/IP trail would be:

66.165.131.193 with NAT doing the wizardry.

In some networks the Gateway_Router provides additional security by acting as a Firewall. The Firewall's job is to take a close look at each packet and permit or deny the packet based on rules that the Administrator has provided. In this case, the Firewall also performs NAT.

A simple example of a firewall rule (In English) for the above would be:

Simple, but real Firewalls can and do get more complicated with other options such as time of day, number of users, amount of bandwidth, ranges of addresses etc. This should be all that the local admins will need to get their particular model working.

Another scenario is when the Gateway_Router acts as a Proxy_Server.

This is a bit more complicated so I'll start with a new data flow diagram:

Local_Trax_Server_---->Proxy_Server---->Internet---->SQL_Server---->Web_Page

This doesn't look so different and if you looked at just the wires and boxes, it might look exactly the same.

The difference is in the TCP/IP connection trail. It works like this:

A Proxy_Server does not perform NAT as the Firewall and Gateway_Router did above. Instead, the Proxy_Server establishes two independent connections, one with the inside address pair and another with the outside address pair.

The outside connection is pretty simple, the Proxy_Server just connects to the destination and passes any traffic handed to it from the inside connection. The trick is what happens on the inside connection. The source of the traffic, the Trax_Server in this case, must know how to redirect all outbound traffic to the proxy server. This is usually performed by a Proxy_Client installed on the source PC or Server and acts as a wedge between what the server wanted to do, "send the traffic to the SQL_Server", and what the Proxy_Server needs, "Send the traffic to ME and I'LL send it to the SQL_Server".

So with this twist, here is a Proxy Trail:

Data from 192.168.1.100 with Trax information (SQL port 1433) is destined to

66.165.131.193 but is grabbed by the Proxy_Client and sent to 192.168.1.1 instead. The Proxy_Server accepts this client connection and makes a connection from 1.2.3.4 to 66.165.131.193. Data is passed from the client to Proxy to SQL. Digestion, presentation etc. is the same as above.

NO problem right? Wrong. The Trax_Server's Linux implementation does not include a Proxy_Client so data that was destined for the SQL_Server is never connected to the Proxy_Server and remember the Proxy_Server will only pass traffic from inside connected sources so the data ends up in the floor instead of on the Web Page.

Question...

How can we fake out Linux to send Trax SQL data to 192.168.1.1, the Proxy_Server inside address, instead of 66.165.131.193, the SQL_Server?

The Solution ...

Most Windows and Linux TCP/IP implementations have an ordered Name lookup algorithm. It goes something like this:

Have a Name and need a Number? Look up the Name in the local HOSTS file if not found try the DNS server. With this we have some ammunition...

192.168.1.1 instead of the DNS IP 66.165.131.193 then we make an entry in the proxy server expecting it, like this:

ALL Inside traffic on port 1433 is sent to 66.165.131.193 on outside address

1.2.3.4 .

Now the trail is:

A side benefit is that the Proxy_Server does not need to be on the local network and can be on the other side of a gateway. This is the case where several remote sites share a common Internet connection and Proxy server as in the Big Sandy network.

Caveats

I hope this helps!

PS I changed my mind.. How about dinner at Outback for the misses and me?

Call if I can help.

Thanks,

Ray