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. http://1.2.3.4, or you can obtain a Domain Name (easier to remember) and use that domain name in your browser - e.g. http://mydomain.com
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.
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. 192.168.1.2). 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. http://192.168.1.2), 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 1.2.3.4, its Private IP Address is 192.168.0.1,
your HFS Server's IP Address is 192.168.0.2, and your browser/client is on a computer who's IP Address is 192.168.0.x
- your browser (client) sends a request to http://1.2.3.4 or http://mydomain.com, which translates to http://1.2.3.4
- since 1.2.3.4 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 1.2.3.4
- Router gets request and realizes that the destination IP Address is the Router's own Public IP Address, 1.2.3.4, 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 192.168.0.2
- Due to this Destination NAT rule, the Router sends request to HFS Server computer 192.168.0.2 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 192.168.0.2 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 1.2.3.4, however it now receives a "reply" from 192.168.0.2; it has no idea why it is receiving an answer from 192.168.0.2 - it hadn't sent it any request, so it ignores it and continues to wait for a response from 1.2.3.4
- 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 http://192.168.0.1 - or whatever your Router's Private IP Address is.
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. http://1.2.3.4, or you can obtain a Domain Name (easier to remember) and use that domain name in your browser - e.g. http://mydomain.com
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.
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. 192.168.1.2). 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. http://192.168.1.2), 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 1.2.3.4, its Private IP Address is 192.168.0.1,
your HFS Server's IP Address is 192.168.0.2, and your browser/client is on a computer who's IP Address is 192.168.0.x
- your browser (client) sends a request to http://1.2.3.4 or http://mydomain.com, which translates to http://1.2.3.4
- since 1.2.3.4 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 1.2.3.4
- Router gets request and realizes that the destination IP Address is the Router's own Public IP Address, 1.2.3.4, 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 192.168.0.2
- Due to this Destination NAT rule, the Router sends request to HFS Server computer 192.168.0.2 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 192.168.0.2 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 1.2.3.4, however it now receives a "reply" from 192.168.0.2; it has no idea why it is receiving an answer from 192.168.0.2 - it hadn't sent it any request, so it ignores it and continues to wait for a response from 1.2.3.4
- 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 http://192.168.0.1 - or whatever your Router's Private IP Address is.
Logged