Maxexchange 7: Server And Client both behind firewalls

Hi, Ray.

>I am banging my head in trying to figure out Why Passive mode refuses
>to work

In earlier versions of MaxExchange there was an issue with FTP transport using a non-standard response to the PASV command. Specifically, it would return...

209 (192.168.156.231,10035)

...where the standard response would be something like...

227 Entering Passive Mode (192,168,156,231,39,51)

This somteimes caused firewalls that do dynamic packet filtering (a.k.a. stateful inspection) to block the response because it didn't look like "real" FTP traffic. This issue was fixed in MaxExchange v9.

.

Ok!
It took me ALOT of figuring out and headbanging and sweat but I Finally Figgured it Out!!

The Problem:
Getting the Remote computers, whom are now all behind personal physical firewalls, to connect to our Maxexchange Server, who itself is behind a physical firewall.

The Solution:
VPN!

The Physical firewall at the office has VPN capabilities, which allows me to let my remotes connect to my LAN and exchange packets. I set up the clients to connect to VPN into the Firewall, and from there the clients have unobstructed access to the Maxexchange server.

The CAVEAT:
The VPN MUST BE ON A DIFFERENT IP ADDRESS RANGE!

My office serves as a perfect example:

We hae absolutely NO need for every computer to be directly connected to the Internet, and so we are behind a Ubuntu Firewall: All company computers are served Internet content via Proxy (Dansguardian content filter), with a few select computers given full unblocked access to the web (The Firewall rules are all IPTABLES based). The subnet behind our firewall is 192.168.0.x.

Our Remotes are all protected by Broadband Routers, which keeps the net at bay without all the thousands of Internet worms trying to directly attack the computer.

By Default: Many of these routers use 192.168.0.x as their subnet, too, which causes a problem when you try to do VPN... Specifically:

If your Maxexchange Server in the office is (for example) 192.168.0.3, and the remotes IP address behind the firewall is 192.168.0.100 (which is a common starting IP that the routers are set for), you WILL NOT be able to ping or get to the server from the client: This is because the remote believes that the Server, having the same IP subnet as the Client, is on the same network, which is not true.

To correct this: You Must create the VPN subnet that is not on either network (for example, 192.168.20.x: This second subnet is commonly known as a DMZ subnet: Its not on the main network, but it still gives access to computers within the same subnet). Then, give the Server a secondary IP address that is On the DMZ subnet by going to the TCP/IP properties, clicking the ADVANCED button, and then under IP ADDRESSES, ADD a new IP address that is in the DMZ: For example, if the existing IP address is 192.168.0.3, click ADD, then type in 192.168.20.3 and click OK: The network card will now see Both subnets, and serve data to computers on either subnet.

The VPN server must now be set up to assign IP addresses that are in the range of the DMZ: for example 192.168.20.100-120.

Once this is done, create the VPN connection on the client, and have it connect to the VPN server. When it connects, and if you issue IPCONFIG at the cmd prompt, you can see that the IP address assigned to it over the VPN is now on the DMZ. The annoying thing tho is that it will automatically route ALL traffic through the VPN, which is easily corected: Disconnect from the VPN, Open the VPN's TCP/IP properties, click Advanced, and Clear the "use default gateway on remote network" checkbox. now when you connect, all normal web traffic will go over the regular Internet, while traffic destined for the Maxexchange Server will go over the VPN: If you Ping the Maxexchange servers DMZ IP address, you will see activity over the VPN connection, while when you ping yahoo.com, you will only see stndard Internet activity.

I FINALLY have Maxexcnahges working properly with this setup, working over "Active" connections!