Running two web servers on one IP address

The following is a tutorial for advanced FuguHub users:

You may already have a web server and an existing web-application infrastructure such as PHP or ASP that cannot be ported to FuguHub. Though it is possible to run two web servers on the same IP address by configuring one of the servers to run on a non standard port, it is not practical for the following reasons:

  • A server running on a non standard port is not user friendly since the user must use an URL such as http://mydomain:8080 -- i.e. the user must specifically enter the port number the server is listening on.
  • The local firewall may not allow a non standard port number to be used.
  • The client user may be behind a corporate firewall that prevents all external access other than the standard web-server port numbers 80 for HTTP and 443 for HTTPS.

The FuguHub server can be configured to forward requests to another server. A server that can forward or route requests to another server is known as a reverse proxy. See Wikipedia for more information on reverse proxies.


A typical FuguHub deployment is shown above, where the firewall is a router such as a D-Link or a Linksys device. The router -- i.e. the firewall is configured to forward port 80 and 443 to the server running FuguHub. The original web server may be running on another computer on the internal LAN or the original server may be running on the same computer as FuguHub.

If you have FuguHub and the original server on the same computer, the original server must be configured to run on a non standard port such as 8080. The original server running on the non standard port number can still be accessed from the Internet using port 80 since FuguHub translates the port number when forwarding the request to the original server. In addition to translating the port number, FuguHub also enables you to access the original server using a secure connection, HTTPS.  FuguHub translates the secure connection to a standard HTTP connection before forwarding the request.

In order to activate the reverse proxy in FuguHub, a text file with one line of Lua code must be created. The FuguHub server uses the Lua scripting language to configure and/or write FuguHub web-applications. You do not need to understand Lua, you can simply copy and paste the example we provide and change the parameters, if necessary. Activating the reverse proxy consists of the following steps:

  1. Create a sub-directory in the FuguHub installation directory.
  2. Create a FuguHub .preload script in the new sub-directory.
  3. Register the new sub-directory as a FuguHub application using the administrator panel.
  4. Disabling the CMS or enable domain name filtering on the CMS.

Steps 1 and 2

Create a sub directory in the FuguHub installation directory such as reverseproxy. If your FuguHub installation directory on a Windows computer is c:\bd, create c:\bd\reverseproxy.

Use an editor such as notepad and create a new file in the reverseproxy directory. The new file must be named .preload. The .preload script is run by the FuguHub server when it loads and starts auxiliary applications. Notice that the name starts with a dot, -- i.e. the name is ".preload", and not "preload".

Copy one of the following and paste into the new file .preload that you should now have open in an editor.

Update for FuguHub version 5.0 or newer

Note: The redirector was not properly integrated with the Barracuda Embedded Web server's Virtual File System before FuguHub version 5.0. The two examples below are still valid, but consider using the new API added to the end of this article.

  • If the original server is running on the same computer as FuguHub:

    myReverseProxy = bd.redirect("/", app.dir, "localhost",8080)

    In the above, 8080 is the port number the original server is listening on.  You need to change the number if the server is listening on a different port.

  • If the original server is running on another computer on your LAN:

    myReverseProxy = bd.redirect("/", app.dir, "",80)

    In the above, is the local IP address of the computer running the original server.  You must change the number to the IP address of your original web server.

Note, in versions prior to FuguHub 4.0, the above must be:
myReverseProxy = bd.redirect("/", "localhost",8080)
myReverseProxy = bd.redirect("/", "",80)

Step 3

In steps 1 and 2, a FuguHub web application was created with the application startup script .preload. The next step is to register and start the application. By starting the application, the .preload script is executed and the reverse proxy is installed.

  1. Start the Administrator Panel.
  2. Click Application Manager.
  3. Click New.
  4. Enter any name for your new application. For example, enter reverseproxy.
  5. Click the Browse button and select the new reverseproxy directory that you created in steps 1 and 2.
  6. Click Submit.
  7. On the "Add a new application" page, select:
    • Root application: yes
    • Application type: LSP
    Leave all other fields blank and press the Submit button.

Step 4

The new reverseproxy application should now be running, but the application may at this point not route traffic to the other computer. The reason for this is that you have two root applications which are competing for resources. The CMS and your new reverseproxy application compete for resources since both applications can be accessed as http://mydomain/*, where * denotes any URI.

You have several options when it comes to resolving the conflicts:

  • Remove (disable the CMS) if you do not need the CMS. Click the CMS on the Manager tab in the Application Manager and stop the CMS.
  • Enable domain name filtering for the CMS or for your new reverseproxy application. By default, applications in FuguHub accept all domain names. By enabling domain name filtering for root applications, the application only accepts the request if the host header equals the domain name configured for the root application. As an example, the CMS may be configured to use a sub-domain name such as, where is your registered domain name.
  • Let the CMS handle the resource conflict. The CMS is designed to delegate the request to the next root application if the requested resource is not found in the CMS. This means that as long as the resource names in your original server are not the same as those in the CMS, the two root applications can co-exist on the same domain name. You cannot remove the root index page in the CMS; thus http://mydomainname/ will be handled by the CMS and not by your original server.

Conflicts can be resolved by setting priorities on root applications. If you do not disable the CMS, the CMS priority should be changed from 0 to 1. Never change the priority for your reverseproxy above 0 unless you enable domain name filtering for this application since the reverseproxy will not delegate the request to other root applications.  By setting a priority higher than 0,  all access to the internal user interface in FuguHub will be blocked and you will no longer be able to start and/or use the Administrator Panel.

If you have disabled the CMS, and you still see the CMS root page, clear your browser cache. The CMS tells the browser to cache the pages and you may not see the pages on your original server unless you clear the browser cache.

Proxying a secure connection

You cannot redirect traffic to a HTTPS connection, but proxying a secure connection works. The proxy decrypts the message and redirects the request as a HTTP connection. In other words, the proxy accepts HTTP and HTTPS connections. Both connections are redirected as HTTP connections.

New API for FuguHub 5.0 or newer

The following is the complete API available in FuguHub 5.0 or newer:

The HttpRedirect class inherits from HttpDir and implements a basic
reverse proxy.

The purpose with the HttpRedirect class is to make it possible to
integrate existing web solutions with the Barracuda server and/or
provide a means to implement cross site scripting.

The reverse proxy behaves as a standard Barracuda Server directory
class since the HttpRedirect class inherits from HttpDir. One or
several instances of the HttpRedirect class can be inserted into the
Barracuda virtual file system. The reverse proxy can also implement
authentication and authorization just like any other Barracuda
directory node. One can for this reason provide security to less
secure backend servers. The reverse proxy also offers SSL termination.

The HttpRedirect class can be used by C code and can be inserted into the
virtual file system by C++ startup code. We also provide Lua bindings
for the HttpRedirect class. The following documentation is for using
the Lua bindings:

-- Create a cross site scripting redirector.

  name - The Barracuda Virtual File System directory node name
  priority - The directory node priority

-- Create a standard reverse proxy.
  name - The Barracuda Virtual File System directory node name
  domain - Domain name or IP address of the backend server
  port - The backend server's port number, which is typically 80
  baseuri - Append a base URI/offset to the redirect URL
  priority - The directory node priority

Creating a standard reverse proxy:
The most common operation is to create a standard reverse proxy. The
following example creates a reverse proxy for a backend server with IP


The backend server can now be access as: http://localserver/backend/
Use the baseuri if you only want to access a subset of the backend server:


The backend server URL can now be accessed as:

The basic proxy does not provide a rewrite module, thus absolute
encoded URLs in web pages retrieved from a backend server such as
images will not show up in the browser unless the reverse proxy is
installed as a root directory.

rproxy=ba.create.redirector(nil,"",80,-1) -- Priority=-1
rproxy:insert() -- Insert as root directory

The above is the most common case for inserting an existing web
application into a barracuda server. The reverse proxy is inserted as
a root directory with a priority that is less than the root directory
for the existing application. This will make sure the Barracuda server
first searches for the requested resource locally and then delegates
the request to the reverse proxy only if the requested resource was
not found in the Barracuda Server.

Cross site scripting redirector
 -- Create a cross site scripting redirector.

Any server and web page can now be access as:

e.g. http://localserver/gateway/

Posted in Tutorials Wednesday, December 31th, 2008 by bd

Powered by the Barracuda Application Server and the SharkSSL Embedded SSL Stack