none
WHS Remote Access - Web page visible remotely but "Log On" fails RRS feed

  • Question

  • Here's the required part:

     

    1.        Which version of Windows Home Server are you running?
    PP3

    2.       What is the make/model of your router? Have you upgraded to the latest firmware?

    2Wire 2701HG-B (yes, it sucks and no, it does not support UPnP)

    3.       Who is your Internet Service Provider? If you are using DSL, who is your provider and what is the make and model of your DSL modem?

    AT&T DSL, modem is same as above (built in)

    4.       What is your external IP Address as displayed in your router?
    (removed - problem fixed)

    5.       Can you connect to http://yourname.homeserver.com from:
    a.       Inside your home - No
    b.       Your office or other workplace - N/A
    c.       An additional location (coffee shop, friend’s house) - Yes, from my iPhone via 3G

    6.       What is the error message you receive when attempting to access your Remote Access website?
    None - website displays fine, but returns a "Internet Explorer cannot display the webpage" (when connected locally to http://server) or "Cannot open this page" (via iPhone) when clicking on the "Log On" button

    7.       When you do an nslookup or ping yourname.homeserver.com, does it resolve to your actual external IP address?
    Yes, see here: http://domaintoip.com/ip.php?domain=xxxxxxx.homeserver.com

    8.       Inside your homenetwork, can you successfully visit http://servername ? If not, what is the error message you receive?
    Yes, but see above about the error on attempting to Log On

    9.       Is UPnP enabled on your router? If not, please turn UPnP on and retry the Remote Access Configuration wizard.
    Nope, AT&t's POS router does not support UPnP

    10.   Have you tried to manually forward ports 80, 443, and 4125 through to your Windows Home Server?
    Yes, and they seem to work - ShieldsUp! reports 80 as open and 443 and 4125 as closed

    11.   From a PC on your home network, can you successfully complete the Internet Connectivity Evaluation Tool without errors? If there are errors, what are they?
    Only error is the UPnP Support Test, which returns "Not supported."

     

    Feel free to try connecting to my WHS and attempting to logon and see if you get the same error.  Not sure what to do with this one, any help appreciated.  Thanks!

    • Edited by mattwhs Tuesday, June 1, 2010 5:42 PM hiding my IP & domain since problem is fixed
    Sunday, May 23, 2010 10:12 PM

Answers

  • btw. if https://yourshortservername fails, it is a local problem in your home network and not related to the ISP. Either a firewall, settings in the router or misconfigured IIS on the server are the most likely reasons for this happening.

    For checking IIS, login locally or via Remote Desktop to your home server.
    Click Start/All Programs/Administrative Tools/Internet Information Services (IIS) Manager.
    In the Websites node right click Default Website and select Properties.
    Check, if 443 is set as SSL port.

    While you are logged on on the server, you can also check the IIS logfiles, which you find in C:\Windows\system32\Logfiles in subfolders like W3SVC....

    Best greetings from Germany
    Olaf

    • Marked as answer by mattwhs Tuesday, June 1, 2010 5:26 PM
    Tuesday, May 25, 2010 6:27 AM
    Moderator

All replies

  • If port 443 is anything but OPEN at Shields Up!, it's likely your ISP is blocking that port for your connection. If that's the case, remote access won't work.
    I'm not on the WHS team, I just post a lot. :)
    Monday, May 24, 2010 1:03 AM
    Moderator
  • I will contact them and find out - still, if it's a port issue, strange that A) the web page comes up and B) it won't work locally ...
    Monday, May 24, 2010 1:39 AM
  • Take a look at mine:
     
    Hmm - you can't, exactly:
     
    My ISP blocks port 80, so you can't see the fact that when you hit the login button, the URL which comes back to collect the credentials, is an HTTPS url, so port 443 has to be open for this to work.
     
    I'd be very surprised if your ISP were blocking that port, but it won't hurt to ask.
     
    Since it also fails locally, I'd say there's something else going on--is there a 3rd party firewall of some sort on the WHS machine?
     
    "mattwhs" wrote in message news:f750d0eb-e06c-4e7e-9a3c-a213c624e195...
    I will contact them and find out - still, if it's a port issue, strange that A) the web page comes up and B) it won't work locally ....

    Bill Sanderson
    Monday, May 24, 2010 3:32 AM
  • No 3rd party firewall, and I tried disabling Windows Firewall via Remote Desktop, no dice.  After thinking about how the HTTP (port 80) part works and the HTTPS (port 443) part does not I am actually thinking it may be a port issue after all.  I have not contacted my ISP yet (always fun to spend an hour on the phone with someone who knows nothing, yes?) but I will do that ASAP, and when I get the chance I may also try assigning a different port (also a fun procedure) to see if that fixes it.

    Any further suggestions welcome, of course.

    Also, another question - any of the error logs (or similar) that I could check on the machine to see if it's returning an error when I attempt remote access?

    Tuesday, May 25, 2010 1:47 AM
  • What happens, if you enter https://yourservername.homeserver.com (and internally https://yourshortservername)?
    What, if you redirect another port to port 443 of your server, i.e. port 444 and http://yourservername.homeserver.com:444?

    Port forwarding of port 443 in the router still points to the proper IP address?

    Best greetings from Germany
    Olaf

    Tuesday, May 25, 2010 6:13 AM
    Moderator
  • btw. if https://yourshortservername fails, it is a local problem in your home network and not related to the ISP. Either a firewall, settings in the router or misconfigured IIS on the server are the most likely reasons for this happening.

    For checking IIS, login locally or via Remote Desktop to your home server.
    Click Start/All Programs/Administrative Tools/Internet Information Services (IIS) Manager.
    In the Websites node right click Default Website and select Properties.
    Check, if 443 is set as SSL port.

    While you are logged on on the server, you can also check the IIS logfiles, which you find in C:\Windows\system32\Logfiles in subfolders like W3SVC....

    Best greetings from Germany
    Olaf

    • Marked as answer by mattwhs Tuesday, June 1, 2010 5:26 PM
    Tuesday, May 25, 2010 6:27 AM
    Moderator
  • Thanks for your suggestions Olaf - I was out of town and unable to work on this for a bit.

    Checked with AT&T and they are not blocking port 443.  Forwarding was set to the server in the router, but the tech suggested I try their DMZ mode (DMZplus) - ShieldsUp showed 443 still closed and remote access does the same thing in DMZ (and plus I can't access the server via LAN so that doesn't help!).

    It's looking more like a software issue.  If I can't resolve it by checking the IIS settings & logfiles, I will just perform a reinstall - I've got an external drive that can back it up safely.

    Tuesday, June 1, 2010 5:09 PM
  • What happens, if you enter https://yourservername.homeserver.com  (and internally https://yourshortservername )?
    What, if you redirect another port to port 443 of your server, i.e. port 444 and http://yourservername.homeserver.com:444 ?

    Port forwarding of port 443 in the router still points to the proper IP address?

    Best greetings from Germany
    Olaf


    Forgot to mention - attempts at either of these result in connection timeout ("The server at server is taking too long to respond.")

    This router does it by computer name (not IP) so the forwardings are always to the right computer.

    I can try forwarding another port - how exactly would that work?

    Tuesday, June 1, 2010 5:17 PM
  • IIS settings fixed it!  I had switched the ports to different ones when I had a different ISP - I switched them back but had entered "433" for the SSL port instead of "443".

    Thanks Olaf - mission accomplished!!

    Tuesday, June 1, 2010 5:26 PM