Squid/squidguard kills connexion client
-
Hello All,
pfSense 1.2.3-RELEASE
squid
squidGuardWe are a school. Have set up two pfSense machines, one each at two school buildings.
All of the squid/squidGuard features are working very well/effective,,,,except;
Now the school librarian needs to use a connexion client to connect to a library resource. This connexion client uses port 80, FYI. I have done packet capturing on the pfSense when trying to connect to 'their' server. I have also used Wireshark on the workstation while trying to connect. Bottom line I can not honestly tell what is causing the no connection to their server. I can of course take this same laptop home and connect fine.
Also if I simply disable both squid & squidGaurd on the pfSense then the connexion client works.
This works identical at either school building and the second school building has only minimum firewall rules.
Also the librarian also uses another connection client to another server for another resource and it works fine. It does of course connect on a proprietary port.(Not port 80)
I have tried adding the URL of the library server to the "allowed" URL's in the proxy server and whitelisted in squidGaurd and did not make any difference.Sorry for long post.
thanks,
Barry -
Have you tried creating an entry for the URL in destinations then allowing it in the default destination ruleset? If you are using ACLs you would need to do it there depending on how you have it configured. Squid can create havok on applications that use port 80 for communication
-
g4m,
Thanks for the info. Here is what I have entered.( before my posting).
entered the domain name in the whitelist of squid.
entered the domain name in the destinations whitelist of squidGuard.I have NOT entered the domains IP address in the unrestricted IP's of squid.
I have NOT entered the IP addess of the domain and put it into the ACL's ( and probably put it to the top of the list) of squidGaurd?Strange all other URL's are working, being filtered correctly. Just seems the connexion client is little quirky with this version of squid/squidGuard. This same connexion client worked fine with the previous firewall setup which was squid/squidGuard as well. Actually this company has now a web based that does almost everything this client will do but of course any teacher doesn't want to have to learn anything new,,,:). The web browser based service of the same thing, pulls up fine on her machine, FYI.
Thanks,
Barry -
Here is a tutorial that helped me configure squidguard. I would have been lost with out it.
http://diskatel.narod.ru/sgquick.htm
http://diskatel.narod.ru/pfSense/doc/squidGuard/squidGuardQuick.htmFYI I don't think the Whitelists in the squid section work when squidguard is in place. You have to add the domain to a list on the destintions tab then have allow it in your categories. Only other thing you can do is give the box a static IP and put it in unrestricted IPs
I have screenshots of what I am talking about.
-
Hello All,
Just wanted to post a few more findings to this,so it is documented for possibly someone else to use.
Have tried adding entries to both Squid/SquidGuard ACL's for this machine to 'pass all' traffic past Squid. The connexion client (port tcp 80) that we are trying to make work will simply not connect to the remote server with Squid/transparent proxy enabled.
This connexion client hooks in with the web browser somehow,in that if I hard code the proxy server into the web browser the connexion client will not connect to remote server. As soon as I take away the proxy setting in IE out( with transparent proxying disabled in Squid) The connexion client does connect after this.
We HAVE to have transparent proxying enabled in our network, setup to cut down on maintenence,bottom line.
Bottom line,I honestly don't think this snafoo is necessarily a Squid/SquidGuard problem,but appears the connexion client simply can not route correctly(for some reason) with this particular version of Squid.I can reproduce this at a second school building with pfSense 1.2.3-RELEASE ,with the exact same results.
Sidenote: This connexion client does use Microsoft .NET as its core.
Edit: Wanted to add just a bit more information for completeness.
When doing a packet capture on the pfSense machine I never see any packets going back and forth between 'our' server and the remote server on either of the two WAN interfaces. I do see packets being sent/received on the LAN interface though. That seems very odd,and this is only when using the connexion client of course. If I do a simple ICMP ping request I do see activity on one of the two WAN interfaces between the two servers.
Thanks,
Barry -
Hi Barry,
We had this same issue w/ Connexion. Entering the IP of the staff computer in "Bypass proxy for these source IPs" under Services > Proxy server allowed the client to connect properly. Hope this helps -
clutch68,
Thank You for posting your setup.
This is exactly what I wound up doing to make this teachers connexion client work as you mentioned.
Squid> ByPass/Unrestricted IP Address.
At least I know someone else with pfSense encountered the exact same problem.
After looking deeper into it , oclc has lots of documentation on how to get IE7 to work correctly with the web based version of oclc. It appears you have to change darned near every default setting in the security settings of IE7 to something non-default to make various entities of oclc function?I don't like having this teachers workstation "outside" of the firewall for sure as we have so may possibilities of viruses in a school setting. Kids are just 'trying' to kill every system on the lan, it goes without saying.
At least the connexion client is usable with this cludge,,,:).Take Care,
Barry -
clutch68,
I don't like having this teachers workstation "outside" of the firewall for sure as we have so may possibilities of viruses in a school setting. Kids are just 'trying' to kill every system on the lan, it goes without saying.
At least the connexion client is usable with this cludge,,,:).Hi Barry, glad to be of help. I could certainly be wrong here, but simply bypassing the proxy should not further expose the client PC. Although a local firewall is prudent, your staff client should also still be "behind" the firewall protection of the pfsense box, just as it was before the proxy bypass. In other words, a squid bypass doesn't necessarily = firewall bypass. The client is simply not routing outbound web traffic through squid.
This post is begging for correction if anyone has further thoughts on this.