rejetto forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bbertrand

Pages: 1
1
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.

2
HFS ~ HTTP File Server / Single file comments
« on: May 21, 2015, 04:35:20 AM »
I have VFS Load Single Comment Files checked.  I'm using Real Folders.  I have a file Bird Doo Doo On car.jpg; I create a text file Bird Doo Doo On car.jpg.comment, and add comments to it.  This file does NOT show up on the list (expected), but I don't see the comments it contains being displayed nor anyway to display them.  What might I be doing wrong?  Thanks.

3
The Go Daddy solution - using your Go Daddy Domain name registration only @ a real DDNS provider. 

Yeah, it would work but yuck.  I mean, Danila Patrick is REALLY hot, but..................(if you haven't seen her Go Daddy commercials - see youtube).  Rather go with a real DDNS provider, and I'm surprised that Go Daddy (and others) haven't gotten onto the DDNS wagon yet.  Many of us have to pay 10x for a static IP.  I have FTTH (true fibre) and I'm not willing to give up top line speed for a static IP.

4
LeoNeeson - there are several points where you are incorrect or misleading - let me correct them.

Domain Name Registration vs Domain Name Services

When you register a domain name, you essentially get a piece of paper saying you are the exclusive user of domain name xxxx for n months.  That's it.  There's one time admin work done by your registrar, but no on going cost to the registrar.  So domain name registration should be cheap - there isn't any great or on going expense.  In fact, to be a domain registrar, you wouldn't even need an online presence or any computer infrastructure.  Clients NEVER connect to a Domain Name Registrar.  Your domain name is essentially useless for all practical purposes.

You need the services of an Internet DNS provider to make use of your Domain Name.  Each time someone specifies your Domain Name, their computer will connect to and make use of the DNS provider's servers.  This is an ongoing expense.  Providing DNS services therefore is and should be more expensive than registering a domain name.


Domain Names vs Sub Domain Names

The information is misleading.  The previous free DYN service provided Sub Domain Names.  The paid service provides Domain Names.  With DYN you get a "real" Domain Name.  So no, DYN's not ripping you off my making you pay for only a sub domain name.


DNS A-Record vs DNS CNAME-Records

"A" records relate a domain or subdomain name to an IP Address.

"CNAME" records relate a domain or subdomain name to another domain or subdomain name - not to an IP addresses.  So this information is incorrect.  Your CNAME record CANNOT be configured to point to ANY IP address - it points to an existing "A" record.  Think of it as an ALIAS - another "name" that points to an "A" record and the "A" record points to the IP Address.


GO DADDY DOES NOT SUPPORT DDNS THEREFORE USELESS FOR DYNAMIC IP ADDRESS BASED COMPUTERS

When I first registered my domain name, I had a STATIC IP, and my domain registrar provided DNS services.  When I moved, my new ISP provided only DYNAMIC IP Addresses, so I needed DDNS services.  My current at the time registrar didn't support DDNS - DNS only, so I had to switch.  I switched to DYN.  Go Daddy does not support DDNS either.  Most DNS providers do NOT support DDNS - they support DNS only.


My feeling on Pay vs Free Services in General

How many complain about paying for work/services being provided by others, BUT EXPECT TO BE PAID WHEN THEY GO TO WORK.  How Hypocritical.

Free Software?  Why haven't the Hardware people gotten on board - Free Hardware?  Why not.  Same thing.  Hardware manufacturers should give their products away for free too, just like you want Free Software because they get the silicon and wires and boards they use to make their products for free from the Free Miners; the Free Miners work for free because they buy their food at the Free Grocery Store, who buy their produce from the Free Farmers.

And what do we call this political ideology?  Marxism.  And the political implementation of Marxism is called Communism.  Why should electricians, plumbers, bakers, doctors, lawyers, police, bus drivers, etc etc ad naudeaum, get paid - the only workers that shouldn't get paid are COMPUTER PROGRAMMERS?  WOW.  ALL I CAN SAY.  I'm a programmer - I think everyone else should work for free EXCEPT FOR PROGRAMMERS.

5
router & port problems / Re: Some Router Info for Newbies or Not So Newbies
« 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 $$$$$.

6
router & port problems / Re: HFS / Router Question
« on: February 17, 2015, 02:05:16 AM »
Rejetto - I understood the question another way - maybe you are right, but how I understood it was that his router is enabled for remote login - to login to the router's admin screens remotely, and the router is configured to use the same port as HFS is set up to use.  Again maybe I misunderstood.

I think what you are referring to is NAT Loopback or Source-NAT (SNAT).  I just posted some info for network newbies which refers to this.

I know this post is late.  Better late than even later!!!!

7
router & port problems / Some Router Info for Newbies or Not So Newbies
« 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. 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.

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. 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.

8
HFS ~ HTTP File Server / Re: For testing purpose (HFS including SSl tools)
« on: February 05, 2015, 12:50:06 AM »
bmartino1 - I'm simply confused regarding this software's relationship to HFS. 

I currently run HFS with STUNNEL using my real certification, and using SRVANY running HFS as a Windows Serivce.  I don't need any help with this.

What I wanted to know is how to:

1) Use my cert with this version of HFS (what is this version of HFS called - "HFS with Integrated STUNNEL"?
2) So this version of HFS can be run using SRVANY just like the vanilla version of HFS?
3) If I used IP banning code provided by REJETTO? - to ban too many failed logon attempts from an IP Address, this worked until I added STUNNEL - then HFS only saw 127.0.0.1 - which IP Address does this version of HFS see?

As HFS can't stop someone from repeatedly trying password after password, I have recently shut it down from the Internet as it is not safe.  Since it is ridiculous to daily review logs to see who broke in last night, then add their IP to a network block list, because my time is better spent thinking than being a monkey and I don't work for my computer, and I don't accept fixing a problem AFTER it has already occurred, for anyone to run HFS out on the Internet are wide open to brute force attacks until (preferably) HFS userid logon lockout can be implemented, and I suggest it be the highest priority for new HFS features.  HFS is great, but it can't be safely used on the Internet until an automatic userid suspension (time limited a la Windows preferably) is implemented.

So I was just unclear as to the relationship of "this HFS" versus the non SSL HFS.

9
HFS ~ HTTP File Server / Re: For testing purpose (HFS including SSl tools)
« on: February 03, 2015, 06:20:34 PM »
Questions:

1) I have a non self signed digital cert - how do I use it - I don't want to create a self signed
2) If someone tries to break in, can I ban their IP and how?  Standard HTTP HFS can't - it only sees the local 127.0.0.1 IP from STUNNEL
3) Can I run this version like I do HFS as a Windows Service using SRVANY?

10
The issue is this:  someone could try and try and try and finally break in; finding a break in AFTER THE FACT is unacceptable; I come from Mainframes - we don't let accidents happen and then clean up the mess - we don't let it happen in the first place.  You've never seen a mainframe break in.  Anyway, I'm new to STUNNEL and was wondering if there was a way for STUNNEL to pass the original IP address thru (can't see how architecturally) so that the original IP can be barred temporarily, but my first choice would be to like Windows, lock out a userid for a period of time after 3 invalid attempts at the password, and when locked out, the user attempting connection should not know whether it was an invalid password or if the userid is/was locked out.  I'm not in the habit of working for my computer (i.e. checking logs) - I believe strongly that if there IS suspicious activity, the computer should tell me.  As I use HFS to provide access to ALL of the files on my computer, I'm now concerned that I may have to find an alternative solution, due only to this problem.  Would there be a way to disable the target userid for a period of time anyone?  And I appreciate all responses.  And is the integrated HFS/Stunnel project - does that provide the source IP (still prefer a userid lockout though).

11
router & port problems / Re: HFS is working great... but not from work
« on: January 12, 2015, 12:23:38 AM »
I know this is late.  My ISP blocked Port 80 - so no go.  But my work had proxy servers that checked protocol vs port #.  These proxies only allow protocols on "standard ports", and that is Port 80 for HTTP.

But my ISP does NOT block Port 443, the STANDARD PORT for HTTPS, so because of the ISP and Work blockages, I HAD TO USE HTTPS.  So I added STUNNEL and all is well.  STUNNEL accepts connections on HTTPS standard port 443 and sends it to HFS on any whatever port I want.

12
I tried this - the problem is that I'm using STUNNEL, so all connections into HFS are from 127.0.0.1.  Any other ideas?

13
If a malicious user were to try repeatedly to login to HFS, trying one password after another - is there any way to "lock out" for a period of time, or any other suggestions on how to prevent someone trying password after password until eventually they get logged in.

Pages: 1