Wpad being ignored?
-
Current setup:
Internet <- squid3 <- dansguardian <- pfSense <- switch <- computer on VLAN2
Previous and alternate setup:
Internet <- squid3 <- dansguardian <- pfSense <- computer on LAN
Currently have no NAT rdr to dansguardian, although I have used it before. I'm relying solely on wpad at the moment.
pfSense with a dedicated lighttpd is serving wpad.dat/wpad.da/proxy.pac from pfSense's private IP : port 80. My browser is set to auto-detect proxy settings. When I read my file stats, wpad is often being hit (frequently enough that the last access time is always current). DG @ port 8080 is often being hit in the logs. Squid is updating with real time hits. But a lot of the time loading up a bunch of websites they try to go straight to the destination and my firewall logs are overwhelmingly blocked with my low priority "block http" interface rules.
Why would a browser (Chrome in this case) load up wpad and then ignore it and try to bypass its settings before finally giving up after timing out and falling back to the wpad settings and going to the DG proxy? Why not honour wpad and just go straight to DG? Am I doing something wrong?
The end effect is a lot of pages just fail to load for almost a minute and I do a lot of refreshing and so on. Frustrating. I just timed one page - https://www.google.com is for all intents and purposes instant, pfSense packages directory took ~55s and the firewall logs show multiple blocks of http.
Oh yeah, I'm currently doing nothing with https - just letting it go direct. I would hope everything would be as fast as that test.
Should I just go back to NAT and rdr all my http requests to DG that way?
-
how are you handing out the wpad info, via dhcp or dns - both?
Not sure about current versions of chrome or firefox - but I do believe in the past they did not support dhcp, etc. And chrome on other than windows does not support it.. Double check that.
If your doing it via dns, what is the search suffix for your dns on the clients, and what is the fqdn that resolves for your wpad.dat file? So for example if your clients are looking for wpad.yourdomain.tld and your serving it up off of wpad.otherdomain.tld you would not find it, etc.
Vs using autodetect you could put in the path on the browser to your proxy.pac file in the autoconfiguration script area on the browser. This can be pushed out via group policy for example in a windows AD network.
Depending how your browser and how its looking their might be some time for that to resolve - and until it does maybe the browser tries direct, etc.
I would prob do a sniff on your clients, fire up your browser and see what happens with your auto discovery of wpad.
-
I'm using both dhcp and dns.
Good point about the dns search domain, I'll check that when I get home. I might've changed it over time and it's stale.
The group policy stuff looks good, but pfSense is just a home router for me. Devices are Windows, Apple, Android and proprietary (PS3, TV, cable/DVR, etc). So there's no way I can administer configs like that and I don't have a "server" set up anyway. Just a home computer that is really more of a client.
I've got another question related to this issue but it's off-topic and worthy of its own thread.
-
Actually, I might have solved my problem. I had firewall rules allowing traffic within VLAN2 all over the place, but most stuff blocked on the VLAN2 interface from VLAN2 to LAN.
I was under the misapprehension (apparently) that the interface subnets have no idea of each other's range, and that wpad (and a whole bunch of other services) have to apply configs to their individual subnet. As a result, I'd duplicated e.g. rules, dhcp ips, monit, connections to the gui, ssh, everything basically on it's own subnet.
It seems all I have to do is add very specific rules allowing traffic from other interfaces to hit very specific IP:ports where my services reside.
As I've mentioned in other threads, networking noob.
But I'm still a bit confused. DNS requests from my VLAN2 subnet go to the VLAN2 interface address, not to pfSense's IP. Some other things are direct. So much to learn.
-
"DNS requests from my VLAN2 subnet go to the VLAN2 interface address"
Would depend on where you point your clients for where they go for dns.. You could point them to opendns or googledns as well.. If you brought dhcp up on your vlan, I would think it just defaults to pointing to its own address for dns.
Under dhcp server
NOTE: leave blank to use the system default DNS servers - this interface's IP if DNS forwarder is enabled, otherwise the servers configured on the General page.So if you leave dns blank there is your answer
-
Thanks. Didn't notice that fine print. Makes sense now.
Anyway, I've got other issues now. At the time of my last post DNS/DHCP/wpad was working fine. But I thought great, and went and changed a bunch of firewall rules based on my growing understanding (or so I thought). Now I've borked something, and DNS is resolving direct destinations (as it should) but bypassing my host override and dhcp doesn't seem to be doing anything. As a result loading pages are fully blocked and timing out.
More work ahead.
-
Love to help, but without seeing your rules its very difficult to know what you did wrong. But if you can query pfsense dnsmasq for dns, it should be resolving your over rides. If your over rides are not working - I would think maybe your not asking pfsense for dns?
-
I think it's possibly more a rule thing I've messed up. That, and I'm impatient with all the config changes I make. I change something and expect it to happen straight away and when it doesn't I go straight onto something else. I get the impression I need to relax a bit with networking and wait for changes to propagate through. I'll try again tomorrow.
nslookup resolves hosts, so dns is working OK. Devices configured to point straight to the proxy IP:port work great. NAT rdr works great. But for some stubborn reason I want to get wpad/dns/dhcp working and it is slooooow. To the point that pages are still "polling" five minutes+ after I load them when most of their content is served.
I log everything, so that probably adds to my worry. E.g. I was just looking at some stuff on VLAN2 where the subnet was being blocked to pfSense:22 by the magical hidden "default deny ipv4" rule. But I have explicit rules to allow pfSense:22 and it works fine - the log is obviously a "false negative". So maybe my logs full of blocks are not really so much of a problem. Maybe I just have to fall back to hardcoding proxy:port or NAT.
-
"But I have explicit rules to allow pfSense:22 and it works fine -"
on your vlan2? Again without seeing your rules I can not even guess to what your issue(s) are or are not.
