SonicWall won't forward web proxy login
My customer uses an outside web proxy provider that has two methods of authenticating users: 'IP Range Authentication' and 'Explicit User Authentication'. Up until recently, this customer has just wanted to apply a single default web policy to all users, so we enabled 'IP Range Authentication' on the proxy service provider's console, provided the outside IP of the SonicWALL router, and configured the 'Web Proxy' option in the SonicWall (TZ 190 running SonicOS Enhanced 3.6.0.1-23e) to forward all web traffic to the provider's server (port 8080), which meant we didn't have to bother with all the proxy settings on the individual stations. This has worked just fine until now that the customer would like to have more granular control and reporting.
So the problem is that we switched from 'IP Range' to "Explicit User Authentication', but for some reason the login prompt from the proxy server doesn't come up when a user opens their browser. Instead it's a 'Cache Access Denied' error page coming from the proxy server (squid). I first thought it was a problem on the service provider's end, but I found that if I enable the proxy server on a machine inside the network instead of the Web Proxy page on the SonicWall it seems to work fine (i.e. login dialog box comes up when a user opens the browser, enters their username and password, and can continue to browse the Internet).
Something important to note: I'm aware that an LDAP-integrated solution is better in some circumstances, but aside from the fact that this form of authentication is what the customer wants, they are also in the middle of a domain migration from an underdeveloped Active Directory. This is also why I'm not going to just be able to setup a simple group policy as they have several thin clients that aren't even members of any domain yet. The web proxy forward mechanism on the SonicWall works well to solve this problem, but for some reason won't pass the login dialog prompt onto the user when we enable it on the proxy server.
In an effort to get something going I actually tried enabling the Premium CFS filter on the SonicWall to see if I could just move filtration to it to get around the problem, but found a totally new problem in that when I enable it on the SonicWall for some reason it seems to do nothing at all - no dialog prompt but no error either... just lets you browse the Internet as though there's no filter or authentication mechanisms at all.
So the problem is that we switched from 'IP Range' to "Explicit User Authentication', but for some reason the login prompt from the proxy server doesn't come up when a user opens their browser. Instead it's a 'Cache Access Denied' error page coming from the proxy server (squid). I first thought it was a problem on the service provider's end, but I found that if I enable the proxy server on a machine inside the network instead of the Web Proxy page on the SonicWall it seems to work fine (i.e. login dialog box comes up when a user opens the browser, enters their username and password, and can continue to browse the Internet).
Something important to note: I'm aware that an LDAP-integrated solution is better in some circumstances, but aside from the fact that this form of authentication is what the customer wants, they are also in the middle of a domain migration from an underdeveloped Active Directory. This is also why I'm not going to just be able to setup a simple group policy as they have several thin clients that aren't even members of any domain yet. The web proxy forward mechanism on the SonicWall works well to solve this problem, but for some reason won't pass the login dialog prompt onto the user when we enable it on the proxy server.
In an effort to get something going I actually tried enabling the Premium CFS filter on the SonicWall to see if I could just move filtration to it to get around the problem, but found a totally new problem in that when I enable it on the SonicWall for some reason it seems to do nothing at all - no dialog prompt but no error either... just lets you browse the Internet as though there's no filter or authentication mechanisms at all.
appears it's wanting some open ports to allow the proper auth protocol through. you might try creating an address object for your external proxy (if you don't already have one) and create firewall access rules and NAT policies accordingly...as a test:
access rule:
WAN > LAN Allow
source: external_proxy; destination: Any; Service: Any
NAT Policies:
WAN > LAN
source: external_proxy; translated: original; destination: WAN IP; translated: Any; service: any; translated: original
LAN > WAN
source: Any; translated: original; destination: external_proxy; translated: original; service: Any; translated: original
you'll need to select the interface of the respected WAN and LAN zones are assigned to
access rule:
WAN > LAN Allow
source: external_proxy; destination: Any; Service: Any
NAT Policies:
WAN > LAN
source: external_proxy; translated: original; destination: WAN IP; translated: Any; service: any; translated: original
LAN > WAN
source: Any; translated: original; destination: external_proxy; translated: original; service: Any; translated: original
you'll need to select the interface of the respected WAN and LAN zones are assigned to
ASKER
I'm giving this a try right now, however in the drop-down for 'Translated Destination' in setting up the WAN>LAN NAT Policy, the option for 'Any' doesn't exist. Am I misinterpreting that part of your instructions? I haven't gotten to the LAN>WAN policy yet so I'll let you know what I find there. For now I'm going to set that field to 'All Interface IP', which seems to be the most of inclusive and/or close to 'Any' I can see.
ASKER
OK - I was able to complete the rest of that setup without any problems but I'm still experiencing the same issue. So I'm not sure if I got that first NAT policy wrong or not, but I'm still seeing the event log showing dropped inbound activity from the proxy server on port 8080 destined for my inside test machine... seems like it's blocking the inbound authentication request. Maybe I have something conflicting with that, like maybe the admin interface, or...? I'm going to keep poking for now.
ok...here's another option: run the public server wizard. the public server wizard will setup all the firewall access rule and NAT policies and address objects for you. then, you can go back and change the services to include "Any" for ingress/egress rules and policies. make sense?
ASKER
I think so - I actually found another article on a similar topic and tried that, although I didn't make the modification you suggested. Instead, I simply ran the public server wizard and mapped port 8080 to my test server. And yet, for some unknown reason, the log still says TCP Connection Dropped. It's very frustrating not know why it's doing that - there's nothing listed in the 'Rule' column of the event log entry. I'm actually trying to setup Viewpoint on this firewall right now to try to see why it's doing this. I certainly don't see any firewall rules preventing this inbound traffic but that doesn't mean I'm not missing something, although any explicit rules would have had to have been added by me anyway, so I really doubt there are any in there. It's just a bit frustrating seeing the event log entry telling you 'what' it's done, but not 'why' it's done it.
to see that information, something simpler to setup is the syslogger. obtain kiwi syslogger and configure syslogger on the sonicwall. if memory serves, log the syslog.
ASKER
Well, now I think I've really messed it up. I tried to go back and just use the proxy in the browser and for some reason it would go out this time - just timed out. Not only that, but I'm also no longer able to log into the firewall itself. I have no idea if I locked it up or what. I'm still connected to the machines on the inside of it, so I know it's passing traffic, but I can't seem to get HTTP or HTTPS to work on anything at this point.
ASKER
Nevermind - it let me back in; must have just been hung up for a bit.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
hi...sorry you weren't able to find a solution here.
by the way, i was reviewing your closing comments and you indicate:
I'm only giving this a 'B' because I ended up having to use a workaround instead of solving the root problem, which I still don't know whether or not there even is a solution to.
which answer did you choose to give a 'B' to?
I'm only giving this a 'B' because I ended up having to use a workaround instead of solving the root problem, which I still don't know whether or not there even is a solution to.
which answer did you choose to give a 'B' to?
ASKER
Oh - I was giving my workaround a 'B' because it wasn't the actual solution. I really appreciate your help on this and I'm sure we probably could have solved it if we could have gotten the Sonicwall to stop arbitrarily dropping connections. Unfortunately I ran out of time to try to make that work that way.
i understand...gave it a good try.
by the way, when choosing your own solution, you don't typically give it a grade as you can't aware yourself points. now, if you'd chosen one of my solutions as a assisted solution, THEN you could have given that a B while choosing your final solution as the primary solution. Just FYI...
by the way, when choosing your own solution, you don't typically give it a grade as you can't aware yourself points. now, if you'd chosen one of my solutions as a assisted solution, THEN you could have given that a B while choosing your final solution as the primary solution. Just FYI...
ASKER
I'm only giving this a 'B' because I ended up having to use a workaround instead of solving the root problem, which I still don't know whether or not there even is a solution to.
ASKER
Message
TCP connection dropped
Source
OUTSIDE IP, 8080, WAN
Destination
INSIDE IP, 57948 (NAT Port), LAN