[WPAD] Need some help
-
9. Firewall rules :
- Block HTTP and HTTPS
IPv4 TCP * * * 80 * BLOCK HTTP IPv4 TCP * * * 443 * BLOCK HTTPSSomething that needs to be understood:
if one runs web server exposing proxy.pac file on pfSense, then one should ;) authorize access to this server from the LAN, otherwise clients will never download proxy.pac file.
In your case, it obviously works as you are able to download this file but what I want to highlight here, mainly for others reading this thread, is that these two firewall rules are not enough. another important rule before is required.In order to debug wpad behaviour, one way is to configure web server URL in your browser. This bypasses the "auto-discovery" step but accesses web server as it will be seen from clients when they will use the auto-discovery stuff.
Another point: to me, you test aiming at testing http://pfsense.localdomain/wpad.dat is irrelevant (unless I'm wrong, of course ;D)
The way it works is that WPAD process (when browser is configured to automatically discover this service) will search for
http://wpad.localsubdomain.localdomain/wpad.dat (if any)
then if not found, search for:
http://wpad.localdomain/wpad.dat
then if still not found, for:
http://wpad/wpad.dat (this been linked to DNS search options using default search domain settings)Again, I think you did it the right way as you do have configured DNS alias so that wpad.localdomain points to pfsense.localdomain 8) but the way you test (verifying pfsense.localdomain) doesn't reflect that way it will then work.
-
Another point: to me, you test aiming at testing http://pfsense.localdomain/wpad.dat is irrelevant (unless I'm wrong, of course ;D)
No, it's not irrelevant. One of the steps to validating a WPAD config is making sure you can fetch the wpad.dat file via http://autodiscover.yourdomain.ext/wpad.dat. If you can't get the javascript file then nothing will work.
-
@KOM:
Another point: to me, you test aiming at testing http://pfsense.localdomain/wpad.dat is irrelevant (unless I'm wrong, of course ;D)
No, it's not irrelevant. One of the steps to validating a WPAD config is making sure you can fetch the wpad.dat file via http://autodiscover.yourdomain.ext/wpad.dat. If you can't get the javascript file then nothing will work.
what I wanted to highlight with my comment, but apparently I failed :-[, is that autodiscovery will [b]not (once again unless I'm wrong, feel free to correct me) search for http://pfsense.yourdomain.ext/wpad.dat
of course it may help to check that accessing wpad.dat file works ;D what I suggest is to search with the right server name: wpad ;)
other either A records or CNAME will not be used by WPAD process.Am I correct ?
-
Am I correct ?
Yes, and I'm the dummy. I was thinking about autodisovery of Exchange and my eye skipped over that, but I suspect it was a typo on his part anyway since he followed ever other part of the guide exactly.
-
6. Configure DHCP :
enable DHCP
Add BOOTP/DHCP option
Code: [Select]
number: 252 type: string value: "http://192.168.1.1/wpad.dat"
number: 252 type: string value: "http://192.168.1.1/wpad.da"
number: 252 type: string value: "http://192.168.1.1/proxy.pac"I do not understand this step. I use the dhcp relay. How can choose the "Add BOOTP / DHCP"
-
I do not understand this step. I use the dhcp relay. How can choose the "Add BOOTP / DHCP"
Set up the options on the DHCP server you relay to instead. (And no, I don't think you should have 3 of them… one for wpad.dat or proxy.pac is just enough. If it ain't honored, then none of the other filenames will be honored either.)
-
@KOM:
but I suspect it was a typo on his part anyway since he followed ever other part of the guide exactly.
I think so ;)
Still there is room for further improvement in what he achieved, IMHO.
-
e.g. there is no need for multiple wpad.dat files in /usr/local/www/
One single file with logical links will ease maintenance. -
As highlighted by doktormotor, pushing one single DHCP option 252 is enough and here I would use fqdn instead of IP address (personal choice).
-
Some client side implementation may rely on DNS service. If goal is to ensure best WPAD coverage, DNS should look like something like this:
wpad IN A 192.168.1.1 (your wpad address here… if CNAME is not used)
IN TXT "service: wpad:http://wpad.yourdomain/proxy.pac"
_wpad._tcp IN SRV 0 0 80 wpad.yourdomain. -
-
- Some client side implementation may rely on DNS service. If goal is to ensure best WPAD coverage, DNS should look like something like this:
wpad IN A 192.168.1.1 (your wpad address here… if CNAME is not used)
IN TXT "service: wpad:http://wpad.yourdomain/proxy.pac"
_wpad._tcp IN SRV 0 0 80 wpad.yourdomain.Also - if using Windows DNS servers - it won't answer the wpad zone queries by default at all: Removing WPAD from DNS block list
-
- e.g. there is no need for multiple wpad.dat files in /usr/local/www/
One single file with logical links will ease maintenance.
My understanding was that different systems/apps rely on different standards, eg. WPAD vs Proxy AutoConfig, and that's why you need wpad.dat and proxy.pac at least. This is for situations where you don't know the clients. In a corp network where you do know the clients, you can select which method to support. I've also seen references to wpad.da for IE6 browsers, and wspad.dat.
- e.g. there is no need for multiple wpad.dat files in /usr/local/www/
-
@KOM:
- e.g. there is no need for multiple wpad.dat files in /usr/local/www/
One single file with logical links will ease maintenance.
My understanding was that different systems/apps rely on different standards, eg. WPAD vs Proxy AutoConfig, and that's why you need wpad.dat and proxy.pac at least.
I guess he's referring to symlinking instead of multiple copies of the file…
- e.g. there is no need for multiple wpad.dat files in /usr/local/www/
-
I missed the 'logical links'. I think I need to renew my Adderal prescription. I'm missing too many small clues lately.
-
@KOM:
I missed the 'logical links'. I think I need to renew my Adderal prescription. I'm missing too many small clues lately.
8) don't worry, I'm getting old too :P
-
Add this rule at the top of our lan network. Please refer the screenshot.
The ports Aliases is nothing but to disable the direct access on port 80 and 443.
