Web Access - Not working on certain PC's

[gillis]

Hi,

Some of us routinely access email from remote PC's using web browser. I can also access the service within LAN by entering the localserverIP/servlet/webacc so no reason to believe the service isn't running properly.

However, on some laptops and even the GM's home desktop the browser eventually times out with "page cannot be displayed". Others, like myself, routinely use WebAcess without problems. When working, you get a "redirection" message that resolves to a certificate request prompt. Selecting Yes to accept brings you to the email login prompt. On the PC's where it's NOT working, you get the "redirection" message but that's all. After a time it gives up with page not found.

Since I don't believe it's a server/application problem my question is - what types of issues on the remote PC can prevent it from getting to the GW Web Access application? Is it possibly firewall or security-related? Java-related? I'm at a loss to why some work, some don't.

Thank you for any insight,

JGiles

 

[gillis]

In case anyone out there is still following this saga, here's an interesting twist!

After Novell convinced me the GW WebAccess application was working fine, I contacted Cisco to see if some problem may have affected our router/firewall system. During some troubleshooting with them I asked the tech to try our URL so he could see first-hand what happened at the browser level. He did and - it worked!!! Tried it a number of times and even had him send me a copy of the TraceRt path (he was in CostaRica) to see if there was some "hop" problem near us. However, now we've had numerous other folks try it from close and not-so-close geographic proximity and found that some get in, some do not.

The problem simply can't be on our end... we've tried flushing the IE browser cache, disabling popup blocker, etc... but those PC's that couldn't get in, still can't. Yet for some reason others can. Mind-boggling!?!?!?!?

JGiles

 

[michigan]

gillis -
Yeah, I'm still following this. I've tried a few things to see what I may discover. I too was able to trace (here in Michigan) just fine:

1 13 ms 12 ms 11 ms 10.186.232.1
2 12 ms 13 ms * 12.244.87.1
3 20 ms 19 ms 19 ms 12.124.15.121
4 67 ms 66 ms 66 ms gbr1-p70.dtrmi.ip.att.net [12.123.139.22]
5 72 ms 71 ms 70 ms tbr2-p012501.dtrmi.ip.att.net [12.122.12.177]
6 67 ms 67 ms 66 ms tbr2-cl1.cgcil.ip.att.net [12.122.10.134]
7 64 ms 69 ms 67 ms tbr2-cl1.st6wa.ip.att.net [12.122.10.62]
8 79 ms 67 ms 67 ms gbr1-p40.st6wa.ip.att.net [12.122.5.162]
9 66 ms 66 ms 66 ms gar2-p360.st6wa.ip.att.net [12.123.44.113]
10 70 ms 70 ms 68 ms oc3-pos510-att-bellingham.fibercloud.net [12.1
.173.18]
11 70 ms 70 ms 69 ms core1-vlan2.bellingham.fibercloud.net [216.57.
7.51]
12 73 ms 75 ms 74 ms 66.165.46.226
13 72 ms 71 ms 71 ms 216.57.192.3
14 136 ms 583 ms 91 ms cust57a.startouch.net [216.57.193.203]
Trace complete.

However, walking through a few other attempts this evening I got some very interesting results. Each time I entered the same IP 216.57.193.203

1st attempt - just sat there. No redirection. Looks like it was trying but no results.
2nd attempt - Again, just sat there.
3rd attempt - This is where it got interesting. I was redirected, but it wasn't to the typical WebAccess login screen, I was taken to "Welcome Site/Site Administrator" screen. I saved the screen shots if you'd like them for future reference. The URL it redirected me to was:

https://linhost01.isomedia.com:19638/webhost/rollout/site

I pretty much stopped at that point. Please keep us updated. I'm interested in the fix/resolution for this one.
Thanks.

 

[gillis]

Michigan,

It's even more interesting - if you can, please just try the DNS name webmail.swinomishcasino.com. We now are finding that people can get in once; subsequent attempts sit at the redirection page and don't go to the Certificate splash screen. Is it possible there's something wrong in the certificate process?

JGiles

 

[marvhuffaker]

This is why I think you should get rid of the redirection... That SIte administrator looks like a general page that any of ISOMedia's subscribers would use to login and manage their websites. Which also leads me to believe that their systems are failing, not yours.

All you'd need to do is create an A record and call it whatever you want, and point it to your real IP address. If your company owns the domain, you should be able to manage the DNS records. Or contact your ISP and see if they can help.



Marvin Huffaker, MCNE

http://www.redjuju.com

 

[michigan]

gillis -
Yeah, I would say anything is possible. You know, you can disable your Certificate/SSL (only temp) just to see if has something to do with the certificate. If nothing else, it would rule out that variable.
This TID explains how to do so. Their scenario & version is a little different but should react the same:

http://support.novell.com/cgi-bin/search/searchtid.cgi?10065695.htm

Also, you know how some AOL users can't get WebAccess to load? Perhaps you try their fix in this situation it may rule out various IP cache variables:
First, edit SYS:\NOVELL\WEBACCESS\WEBACC.CFG.
Change the line Security.UseClientIP.enable=true to Security.UseClientIP.enable=false.
Restart the WebAccess and web server.

And lastly, the following TID explains how to reset your WebAccess Timeouts. Personally, I don't think it's a timeout issue, however the steps involved also clears all WebAccess cache too - I didn't realize old connections (that didn't hit "LogOut") will continue to tax memory on the server -- GWINTER.NLM -- even after they've disconnected.

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10022625.htm