WPAD: DNS(Unbound) + DHCP

johnpoz

where are you hosting your pac file?? ie your pac file would be called wpad.dat where is this hosted?

So you would create a A record in the domain your using like wpad.yourdomain.tld that points to the IP address of the server hosting the wpad.dat file.

with dhcp you would create an option 252 that has the url of where wpad.dat file is, ie http://wpad.domint.tld/wpad.dat

if you don't know what your hosting your pac file that is called wpad.dat then hard to setup either dns or dhcp ;)

kklouzal

I've created 3 files with the following script:

function FindProxyForURL(url, host) {
	if (dnsDomainIs(host, "pfsense.localdomain")) return "DIRECT";
	else return "PROXY 192.168.1.1:3128;
}

/usr/local/www/wpad.dat
/usr/local/www/wpad.da
/usr/local/www/proxy.pac

I've successfully created a Host Override within the DNS Resolver:

And setup a custom option within the DHCP server to point to the script at our host override:

Restarted my computer and the firewall yet still according to Squid's Real-Time Monitoring page I'm still not utilizing the Proxy Server.
I've double checked my machine is set for automatic detection.

This test application also fails to see me behind a proxy - http://www.lagado.com/proxy-test
@'wikipedia':

the Web server must be configured to serve the WPAD file with a MIME type of "application/x-ns-proxy-autoconfig".

How can this be done for pfSense Web Server?
I've edited the following file:

/usr/local/etc/nginx/mime.types

And added this line to accommodate our WPAD/PAC file MIME Types

    application/x-ns-proxy-autoconfig     dat da pac;

Restarted my computer and the firewall, still not able to use the proxy server..

kklouzal

All is working now, after doing everything in my previous post I decided to try a different PAC script. Low and behold it's working now!

function FindProxyForURL(url,host)
{
  if (isPlainHostName(host) ||
    shExpMatch(host, "*.localdomain") ||
    isInNet(dnsResolve(host), "192.168.1.0",  "255.255.255.252") ||
    isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0")) {
    return "DIRECT";
  } else {
    return "PROXY 192.168.1.1:3128";
  }
}

Only small issue it seems that I can't quite get the filtering down properly inside my PAC script. For whatever reason it seems like ALL traffic is being forwarded to the proxy. In my script I thought I defined that if the requested domain is within the "192.168.1.0" address space or the domain is "*.localdomain" then it wouldn't forward through the proxy. Its not doing that, just sending everything into the 'else' block..

Can anyone share their scripts?

chris4916

instead of RegEx, you should rather try

dnsDomainIs(host, "locadomain")

although what you wrote looks ok so far ;)

johnpoz

Glad you got it sorted, but can't help but make a point. You can run squid without having wpad setup.. And it would be proper..

How many clients do you have that will be using this proxy? You can just explicitly point your browser your proxy you do not need auto configuration to work, etc.

kklouzal

This is the PAC script I ended up using.

function FindProxyForURL(url,host)
{
	if (isPlainHostName(host) || isInNet(dnsResolve(host), "192.168.1.0", "255.255.255.252") || isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0")) {
		return "DIRECT";

	} else {
		return "PROXY 192.168.1.1:3128";

	}

}

I've got around 35 devices, not sure if all of them are even capable of WAPD. I love the idea of a transparent proxy without all this scripting nonsense however I do not like breaking SSL which is what happens with Man-In-The-Middle filtering… I would still like to set some firewall rules up to catch clients that don't get auto-configured but I think I'll only be able to catch HTTP and not HTTPS traffic like this. Please correct me if I'm wrong! :)

Thank you all for your help ^.^

chris4916

Your understanding is correct: transparent proxy will not catch HTTPS unless you configure SSL-Bump.
You're correct again thinking that some devices may not benefit from WPAD (although you should ensure first that you have deployed all the mechanisms suggested by WPAD RFC (still draft BTW)
I don't share you comment about "scripting non-sense": this has nothing to do with WPAD (which is only the discovery mechanism) but proxy.pac (would it be automatically configured or manually set) is very usefull as it permits to make some decision based on various criteria to decide whenever one or another proxy has to be used (or no proxy, of course).

This being said, the idea of transparent proxy is not that nice and it also has a lot of side effects like DNS resolution or security issues.
Bassicaly, with transparent proxy, browser is not aware that proxy is in the middle.

What are you using your proxy for? That's the main question. 8)

kklouzal

My ISP quietly imposes a 200GB per month bandwidth cap, so my main purpose of running squid is for its web caching abilities. Aside from that I'm using LightSquid to occasionally check and see if the internet really is just for porn :D

I'd like to explore the option of using SquidGuard to impose Ad-Blocking, from what I can gather it's not as trivial to setup as say pfBlockerNG's DNSBL Feeds.

I tried to create the following Port Forward to redirect all HTTP traffic on the LAN interface into our Proxy Server but it isn't actually doing anything:
Source Address: *
Source Ports: *
Destination Address: WAN Net
Destination Port: 80
NAT IP: 127.0.0.1
NAT Port: 3128

I'm using Manual Outbound NAT because we have a few Xbox One's and require a static outbound port to achieve 'Open NAT' status..
Do I have to create any more Outbound rules to do this HTTP redirect into the proxy? Or should a Port Forward be enough?

chris4916

2 points you have to keep in mind:

Squid will not cache HTTPS
DNSBL works very différently than squidguard: DNSBL works at domain level while Squidguard can filter at URL level

Deploying Squidguard is quite simple once you have Squid already deployed.

Another important aspect: if proxy is running in transparent mode, then name resolution is done at client level while explicit proxy will shift this task at proxy level, meaning centralized and shared.

kklouzal

Thank you very much for this valuable information, a lot of my assumptions have been corrected and for that I am thankful.

I've decided to let WPAD be the only deciding factor weather not a client uses the proxy. The port forwards just aren't working for some reason. I wanted to use the port forward as a sort of 'fail-over' for devices that don't support auto-detect.

I was aware SSL could not be cached, it's a shame since a good majority of traffic uses a secure socket.

I feel like filtering at the DNS level is…more accurate?...than filtering at the URL level?
I had to uninstall pfBlockerNG today, all of a sudden nobody could access any webpages, uninstalling it remedied the issue. Needless to say I'm crossing my fingers that SquidGuard can achieve the same level of ad filtering DNSBL could.