rejetto forum

Software => HFS ~ HTTP File Server => router & port problems => Topic started by: bbertrand on February 17, 2015, 01:50:03 AM

Title: Some Router Info for Newbies or Not So Newbies
Post by: bbertrand on February 17, 2015, 01:50:03 AM
When dealing with Client/Server architectures, such as HFS (HFS is the Server and your browser is the client), you should always test where the client and the server are on the same network first.  If this doesn't work, it won't work if the client is on a different network from the server.

Once you get this working, you can then proceed to implement the extra steps required to access the server from another network.

The extra steps required to access HFS from another network are:

1) Most homes have a NAT Router; this Router has (2) IP Addresses - one for the network in your home - this will use a Private IP Address such as 192.168.n.n, and one public IP Address - this is your IP Address on the Internet

2) To connect to your home computer, you are actually telling the browser to connect to your Public IP Address.

3) Your ISP may be providing you with either a STATIC IP Address or a DYNAMIC IP Address.  If you don't know, you have a DYNAMIC IP Address.  This means that your ISP can change your IP Address at any time. 

4) If you have a STATIC IP Address, you can either use that address in your browser - e.g., or you can obtain a Domain Name (easier to remember) and use that domain name in your browser - e.g.

5) If you have a DYNAMIC IP Address, you must obtain a domain name AND subscribe to a DDNS (not just a DNS) provider.  You define your DDNS account userid, password and domain name to your router's DDNS software, which you must enable.  Whenever your router notices that your Public IP Address has changed, your router essentially logs on to your DDNS provider using the provided credentials, and updates your DDNS provider's database for your domain name with your new Public IP Address.  That way anyone accessing your server using your domain name will always get your current Public IP Address.

6) The computer that will be running HFS - if there is a firewall on that computer (e.g. Windows Advanced Firewall) - you must specify an incoming rule for the Port that HFS will be listening on, otherwise when a browser attempts to connect to your computer's HFS, that computer's firewall will block it before it reaches HFS.  On the Windows firewall, make sure its scope includes PUBLIC (PRIVATE is not sufficient/DOMAIN is only used if you are using AD - if you don't know what AD is, you aren't using it).

7) When someone out on the Internet attempts to connect to your HFS server, by specifying your STATIC Public IP Address or your Domain Name, which will be translated to your current Public IP Address, their connection will now make it to your NAT Router.

8) When your Router gets this connection request, your Router must know to which computer on your network to send it.  By default, your Router will have no idea, so you must define a Port Forwarding rule, which defines when the Router receives a connection request on a particular Port, to which computer's Private IP Address the request should be forwarded to - e.g. Forward all connection requests on Port 80 to the computer with Private IP Address (e.g.  This implies that the computer that is executing HFS have a constant (STATIC) Private IP Address.

9) The computer that is executing HFS can have a STATIC Private IP Address by either (a) defining it a fixed IP address in the Operating System, or (b) most Routers have what is called a Reserved DHCP Table - in it, you define the MAC Address of your computer's network adapter, and the IP Address it should always be given; when a network adapter sends a request to the DHCP Server software, typically executing on your home Router, they are in essence saying "help, my Electronic Serial Number (MAC ADDRESS) and I need an IP Address, Subnet Mask, Default Gateway and DNS Server's IP Address.  The DHCP Software executing in the Router looks in its Reserved DHCP Table to see if this MAC Address is defined and if so, the device is provided the specified network information, which will include a fixed IP Address; if not, the DHCP Server software has a range of IP Address that it can provide to requests who's MAC Addresses are not in its Reserved DHCP Table, and it will randomly select an unused one.  On a Windows computer, your network adapter's MAC Address can be obtained by (a) opening a command prompt and typing IPCONFIG  /ALL - it looks like twelve characters consisting of the following characters: 01234567890ABCDEF - e.g. 00:12:AF:3D:9A:55, and your computer's current Private IP Address - define these both in your Router's Port Forwarding Rule

One anomaly is if you try to connect to your HFS Server, by specifying either its Public IP Address, or a Domain Name, which will be translated to its Public IP Address, and the client is located on the same network as the server.  This should work, but many routers have a bug which prevents them from working.  Look on your Router's GUI for an options with a name similar to "NAT Loopback" or "Hairpin NAT".    Whereas when you define a Port Forwarding rule - technically referred to as a Destination NAT Rule, enabling NAT Loopback/Hairpin NAT creates a Source NAT Rule.  If your Router's GUI doesn't have this option and your Router does not enable you to manually define a Source NAT Rule, then there is no way to overcome this BUG in your router and you will need to connect to your HFS Server using (a) its Public IP Address or Domain Name, when the client is not on the same network as the HFS Server, or (b) its Private IP Address (e.g., when the client is on the same network as the HFS Server.

Without this option, here is what happens:

- assume your Router's Public IP Address is, its Private IP Address is,
  your HFS Server's IP Address is, and your browser/client is on a computer who's IP Address is 192.168.0.x
- your browser (client) sends a request to or, which translates to
- since is not on same network as client's computer (192.168.0.x), request is sent to Default Gateway (typically your Router)
- your client now waits for a response from
- Router gets request and realizes that the destination IP Address is the Router's own Public IP Address,, so it does not send the request outside but rather loops it back
- Router now processes the request as if it HAD come from the outside
- Router sees destination is Port 80 so it looks in its Destination NAT (Port Forwarding) Table and sure enough, Port 80 is forwarded to
- Due to this Destination NAT rule, the Router sends request to HFS Server computer on Port 80
- HFS gets request and sends its initial screen back to the originator, which is 192.168.0.n
- HFS Server's Network Software determines that since its IP Address is and it is sending this request to 192.168.0.n - that the destination (client) is on the same network as it is, so it does not send the reply back to the router, but rather, it does what network software always does when sending data on the same network - it sends it directly
- client computer 192.168.0.n is still waiting for an answer to its connection request from, however it now receives a "reply" from; it has no idea why it is receiving an answer from - it hadn't sent it any request, so it ignores it and continues to wait for a response from
- eventually the client's connection request times out

By defining a Source NAT rule, either manually or via a GUI options such as NAT Loopback, this problem is resolved. 

Again, if your router does not provide a GUI method or the ability to manually specify a SNAT Rule, you will need to connect to your HFS Server by specifying the HFS Server's Private IP Address, when the client is on the same network, and its Public IP Address (or its Domain Name) when the client is not on the same network.

For those of you who's ISP provide a Dynamic IP Address, you must register a domain name and obtain DDNS support (a provider of DNS support is NOT sufficient; if you have a Dynamic IP Address, you MUST have D DNS support).  Often the Domain Name Registrar also (optionally) provides DDNS Services.  Two such providers are DYN.ORG and NOIP.COM, which provide both Domain Name registration and DDNS Services.

I hope that this information helps people trying to set up HFS to be publicly accessible.  One final note - see this forum - if you make your HFS Server available to those "outside of your house", you will find that some of those people are nice and kind.  You will find some that aren't.  I strongly encourage you to specify STRONG passwords for your HFS userids, AND to implement automatic IP banning after several failed login attempts - this optional code can be found on this forum, otherwise someone could write a computer program to try logging on to your HFS server, trying password after password, maybe thousand's of tries per hour, eventually breaking in.

If running HFS on Port 80 does not work, ask your ISP what Ports they block.  You will not be able to run and have HFS listening on a port that they block.

Finally if your HFS Server works when accessed by a client on the same network, AND it works from "your friend's house", but it doesn't work from your work, often this is because your computer at work is connected to the Internet VIA what is called a Proxy Server which eavesdrops.  Depending on how it is configured, it may detect that you are trying to connect to a computer out on the Internet using the HTTP protocol and check that the request is being sent to the HTTP Server (HFS) on HTTP's standard Port - Port 80, and block any other port.  If this is the case, it is your work's network that is blocking the connection request from the client (browser), and you will need to use only protocol standard ports - Port 80 for HTTP and Port 443 for HTTPS.  If you want to use HTTPS - see other documents on this forum regarding using HFS with STUNNEL.  The next version of HFS, V3, will supposedly include integrated HTTPS support.

I hope this info helps network newbies who have HFS working locally, but can't seem to get it to work over the Internet.

To configure your Router, while each Router may be different, they are typically accessed by opening a browser to - or whatever your Router's Private IP Address is.
Title: Re: Some Router Info for Newbies or Not So Newbies
Post by: bmartino1 on February 18, 2015, 02:07:21 AM
Looks good :)

I would also like to add some info. Most of the new routers don't support nat form your public ip to your in home network.. .Meaning that i'm trying to talk to my routers public IP to my routers private IP.

Issues like this occur when you set up HFS correctly with a dynamic name service.
Meaning you routers Public IP is set to

but when your at home, going to name .com gives either a browser error or can't process request.

Fortunately, there is a solution!

Your HFS Machine must be set to a staic IP
---to find you router and current ip settings:
run Command prompt
ipconfig /alll

for this example, i assume you are setting it to
IP address (last dhcp ip address assigned on class C network)
Subnet: (subnet on which the networks is based on -- default class C network)
gateway (In home network router ip address)

this is because the in home network machines need a simple text line in 1 file to make this work...

This file requires an administrator to edit (run notepad as administrator )

Some Antivirus programs prevent editing this file due to the power it has over the machine. There are also settings to make a machine ignore this file as well... but default windows, editing this file will fix access to

path: C:\Windows\System32\drivers\etc

file: hosts

It is a command cmd file, the file extension is "hosts.file" ....
as the host document says with in it

-------------------Default host file

# Copyright (c) 1993-2009 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
#          # source server
#              # x client host

# localhost name resolution is handled within DNS itself.
#       localhost
#   ::1             localhost

add this to make go to your hfs ip

so the host file will now be:


# Copyright (c) 1993-2009 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
#          # source server
#              # x client host

# localhost name resolution is handled within DNS itself.
#       localhost
#   ::1             localhost


this tells the networking protocols to use the host file first, so host file points the dns name to your hfs ip address
so can continue to work and point to your proper ip (when at home) outside of home it will point to the public ip address assigned to the service you select as a dynamic dns provider...

good luck and have fun :)
Title: Re: Some Router Info for Newbies or Not So Newbies
Post by: bmartino1 on February 18, 2015, 02:25:32 AM
Oh, and some help full networking setup:

Sounds like you need to setup some basic networking to get things running!


you will need to double check 3 things to make it use able over the web:

1. Windows side: ( i will assume you are using windows 7 ) at least i will post info link to windows 7...(most likely useable for all windows side os...)

You might need to set the "hfs machine" to a static ip address (this way when you open ports or use web traffice it has a "definite path"

windwos comand prompt:
cmd > "ipconfig /all"(<=command) has all the network info you need:

ip address is the machine address
subnet depends on your network most likely ""
gateway is your router's ip adress most likely ""

you will need to allow hfs thorugh your firewall

2. Router/(intranet) network side
you router will need the port you chose in hfs (say you set the port to 80 go to you router- in a web browser type in the ip address of your gateway)

enable "port forward" to your machine and the router to the same port ie port (starting port) 80 to port (ending port) 80

*note some router don't allow you to use your "public" ip address to view inside, so while your at home your webpage is accessible via the ip address you set to the machine earlier (fixed in above post)

(if your router supports it you can have it memorize you "hfs" machine "network address (known as a mac address) and assign it a specific ip address so it will always be "192.168.1.x" x being the number you set i chose 254 as it is the last number dhcp will use...

3. Internet/Modem side
go to
This is your public ip adress so when you are not at home you will go to this ip adress ( what is shown at the website above one of many website that can tell you your public ip adress...

You should now have hfs viewable form the outside world via:
(xxx your public ip address)

Since modems can be dynamic ip adress you can opt to get a "dns name so instead of typing you type a predefined word such as mywebsite.(free public domain).org

DNS free domains names:
either by adding it into the router or have it client side, or even pre-setup in a dns online website..

I'm having good luck with using as my public domain...(website presetup)

I'm only trying to help i mean no offense.
thank you for your time and patience,
Title: Re: Some Router Info for Newbies or Not So Newbies
Post by: bbertrand on February 18, 2015, 06:19:32 PM
Regarding the HOSTS file solution, the inability to use your Public Domain Name or Public IP Address is due to a common bug in the router software - what I documented as the Source NAT problem.  Some routers allow in their GUI what is called NAT Loopback or Hairpin NAT - some don't.  By specifying these options in the GUI, they generate a Source NAT rule that allows you, as it should, to specify your Public IP/Domain Name.  Some don't - which is a bug, period.

The HOSTS solution - the problem with it is that you have to remember to add the line/remove the line depending on where your portable device is connected.  This may be the only way to do it, other than using the HFS computer's Private IP Address when your device is on the same network at the HFS computer.

Try finding your Router's GUI option first; if not, try to find if your router s/w will allow you to manually specify a Source NAT rule.  If not, your router s/w has a bug (many do), in which case, you can either use the HOSTS solution as you have documented, or create two icons - one opening your browser to your public IP / Domain Name - calling it HFS Server- External Access, and to your HFS Server computer Private IP Address - calling it HFS Server - Internal Access.  About half of the available home router's s/w allows specifying NAT Loopback in its GUI.  Most after market router s/w has this option - Tomato, DD-WRT and the one that I'm running - Endian (running on a previously retired low power computer).  Source NAT is the proper method. 

Rant - its amazing the "forced bugs" that many home router manufacturers force upon us.  Due to their specifically refusing to support WOL (Wake On LAN) - we can't remotely wake up our computer (saving electricity) remotely, and NAT Loopback, for two - there are others.  Rumor has it that if you want these "features" (one line of code in their software!!!), you have to buy their commercial routers $$$$$.
Title: Re: Some Router Info for Newbies or Not So Newbies
Post by: bbertrand on May 29, 2015, 06:59:18 PM
While I am a computer architect by profession, I prefer in situations like this to look at the problem in a "human" way.  If I call tel # 123-456-7890, I get the same person, regardless of WHERE I AM CALLING FROM.  If a user clicks on a link to a domain name, they should connect to that domain name, regardless of WHERE THEY ARE CALLING FROM.  Getting caught up in trivial details like "am I on same-net" as the domain name should not be "user relevent", and the technology, if it matters, should make this transparent.  Just like virtual storage or virtual machines.  So that is why I consider this a bug.  Sure make it an option, but who wants to have TWO icons for each service, labelled "Connect to XYZ IF ON SAMENET", "Connect to XYZ IF NOT ON SAMENET", "Connect to ABC IF ON SAMENET" etc?  I don't.  I do agree with your depiction of the logic involved.  If my POP was underpowered, I might be forced to turn S-NAT off.