Squid3 transparent proxy - commodo cert?
-
You must have misunderstood ESF. All of what they said is true only when using a transparent proxy. If you are using a standard proxy then you don't have to play around with certs on every client.
Everything these days supports auto-detection of proxy. WPAD is what makes it happen. You will need to spin up an HTTP server(s) to serve the wpad.dat, wpad.da and proxy.pac files. Add a DNS entry for wpad.your_domain.whatever and point it to the web server hosting the proxy files. Add a DHCP 252 entry and give it the same URL. That's pretty much it. For those few users who can't properly detect the proxy, they will have to manually configure it.
If your multiple guest networks cannot touch a common host then you will have to supply an HTTP server for each network.
-
I thought I misunderstood too, but asked in several ways to make sure that's what they were saying. I'm sure Chris had originally told me like you are saying, though.
So with the DNS entry and different sites, etc. there is no one spot I can put a web server that can be hit on all corporate networks AND all guest networks from each site - any clue on how to set that DNS piece up? I've never had to do anything liek that with DNS before.
-
I thought I misunderstood too, but asked in several ways to make sure that's what they were saying. I'm sure Chris had originally told me like you are saying, though.
So with the DNS entry and different sites, etc. there is no one spot I can put a web server that can be hit on all corporate networks AND all guest networks from each site - any clue on how to set that DNS piece up? I've never had to do anything liek that with DNS before.
A better question is - how important is the "wpad.somedoamin.com" entry in this functioning?
I could possibly set up dns forwarders on each firewall to 8.8.8.8 my ISPs dns, then set the dns in dhcp options for the guest scopes to hit he firewalls for DNS, and make a dns overide entry for wpad to point to a web server in my wanedge subnets hosting wpad files only for guest networks, and for corporate networks point them all to my internal web server, because they would see the wpad entry there. In fact this may be what I need to do, due to guest subnets not using my internal dns anyway >_<. Sorry for asking a dumb question.
-
So with the DNS entry and different sites, etc. there is no one spot I can put a web server that can be hit on all corporate networks AND all guest networks from each site - any clue on how to set that DNS piece up?
If these networks can't talk then DNS won't save you. You will need to spin up a web server reachable by everyone if you want to implement WPAD.
A better question is - how important is the "wpad.somedoamin.com" entry in this functioning?
It is critical. The way WPAD works is the client will do a DNS lookup on wpad.domain, and then go to the IP address it gets back and asks for wpad.dat|proxy.pac (depending on the browser, or OS). I don't know if you could get away with just doing it only via DHCP because I've never tried, but it might work. You will still need HTTP servers that everyone can reach. Doesn't need to be the same server. If you have 4 LANs that can't talk to each other, you will need 4 HTTP servers, one on each LAN, to handle WPAD requests.
-
@KOM:
That's it. You need DNS and DHCP to fully cover it, but you can get away with just DNS. You also need an HTTP web server to serve the wpad.dat, wpad.da and proxy.pac files. You can use your pfSense box for this if you have WebGUI set to HTTP mode.
I'm 100% in line with your comments regarding use of WPAD :)
I really don't understand why one would ever use transparent proxy, neither, this is even worst, implement MITM SSL :o ::)This said, in term of implementation, when relying on DNS, at least using "Well Known Aliases" mechanism, I though it requires A record for "wpad.domain", at least according to RFC3040.
As you're not supposed to have multiple DNS "A records" for same IP, the only way you can achieve it is to set an additional IP to your LAN interface so that your http://wpad.domain URL points to it.Am I correct? ???
(WPAD is also described here)
-
I'm not sure. I have my alias as an A record and it seems to work fine. I don't know if it makes a functional difference if it's an A or a CNAME.
-
@KOM:
I'm not sure. I have my alias as an A record and it seems to work fine. I don't know if it makes a functional difference if it's an A or a CNAME.
I don't understand why it would make any difference neither. This is something strange to me and from functional standpoint, I don't see any difference.
However, if client side, DNS requests expects RR type 1 and do not accept type 5, it may fail.As I'm curious, I decided to look further at this because if client implements what RFC describes, then only A record should be supported.
This is what I found: (here) (yes this is only the draft but may explain my previous comment, also I still don('t understand reason behind this)
4.4.3. DNS A/CNAME "Well Known Aliases"
Client implementations MUST support this mechanism. This should be
straightforward since only basic DNS lookup of A records is
required. See RFC 2219 [5] for a description of using "well known"
DNS aliases for resource discovery. We propose the "well known
alias of "wpad" for web proxy auto-discovery.
The client performs the following DNS lookup:
QNAME=wpad.TGTDOM., QCLASS=IN, QTYPE=A
Each A RR, which is returned, contains an IP address which is used
to replace the <host>default in the CURL.
Each candidate CURL so created should be pursued as specified in
section 4.5 and beyond.</host>One step further, reading RFC 2219, I'm lost :-[ because this RFC explains rational using CNAME…
So no real progress here but this may explain why it doesn't always work.Anyone having better understanding ? ???
-
So no real progress here but this may explain why it doesn't always work.
Oh? You have clients that can't find the proxy on their own? I had a few Windows boxes like that and I had to set them to manual.
-
Not currently but I remember I had few some years ago and it pushed me to implement DHCP option 252 and SRV/TXT records.
-
@KOM:
For those few users who can't properly detect the proxy, they will have to manually configure it.
KOM,
How do you get wpad working on mobile devices? Most of my ignores the dns and dhcp config and try to access internet directly. SSL cert for a guest network is also really hard to handle with. -
How do you get wpad working on mobile devices?
I'm not a mobile guy, but it seems to work for me here with Android (5.0) but it is still dumb. While it supports auto-detection, you still must manually give it the URL to the proxy.pac|wpad.dat file. So stupid. Apparently they've never heard of WPAD. I don't have any experience with Apple or Microsoft.
-
@KOM:
Apparently they've never heard of WPAD. I don't have any experience with Apple or Microsoft.
Or don't care about it, the thread is open for years…
https://code.google.com/p/android/issues/detail?id=42696 -
Try this
https://datalogus.blogspot.com/2016/06/pfsense-231-security-explicit-squid.html
