Well with pixelserv-tls in the mix you should still be able to see the https being served(it would appear returning as the blocked domain), but it should return as a pixel. It would still be normal to see the A record being blocked.
I am using pixel tls and the up is 192.168.50.2. I turned in dnsfilter, and set it to router. Do I need to do anything else? I see blocks for non https
You should be doing fine. The https traffic you see being returned for the "blocked" domains should be pixelservtls responding with its pixel obviously it would be as if you did not see an ad appearance wise because where the ad would have been you would have a tiny pixel. Any non https should be blocked as A.
I think pixelserv is a combo of two things. Only 1-2% of my https requests pointed to pixelserv complete with the single pixel; the rest I think are being rejected by the page ad code and result in a blank ad space. The difference is that pixelserv responds immediately to the request rather than the request timing out.
That is exactly what I have been saying. However in my case pixelserv tls has majority of the time supplied its pixel. Seldomly it returns no-data, which means nothing gets loaded. I have yet to see the blank ad space, those must be from AAAA responses since dnsmasq blocks with standard :: for AAAA responses. However, if diversion mapped AAAA (eg. ::ffff:192.168.1.2) responses to the ipv4 block address, you wouldn't see any random blank ad space.
Gotcha, the reason I asked is because I have yet to see that pixel that it was blocked. I didn't know that if that doesn't block it then diversion will with a blank space
I wonder if we can convince @thelonelycoder to map the AAAA responses for blocked domains to A (eg. ::ffff:192.168.1.2) so they can fully leverage pixelserv-tls, instead of using :: for ipv6 blocks. (call it an experimental feature kinda like youtube adblock.)
The https would show allowed, since the https is loading the pixel of the blocked domain. pixelserv-tls acts as a middle man, using pixel certificates. it serves the blocked https domain back as a pixel response. therefore you would see the https response. As long as you are not seeing the https response returning as a big giant advertisement when loading a web page, then pixelserv-tls is doing its job.
The pixel is so tiny it will appear as a empty space where a ad would normally reside on the webpage..
Let me check that, sounds like a good idea in theory.
That helps. But I am seeing ads where there shouldn’t be. Stuff is getting blocked, but I am also seeing ads that I know are on the block list also. That is why I am confused
Post some examples of what you see in the logs and in the browser.
As @dave14305 has pointed out, it is not only important to be seeing ads, but it is also important to tie those ads to the log itself, one of the best way of probably doing that would be screenshots, logs, and if possible actual times. Also, it would be important to reproduce the issue. What block list are you using, maybe share whitelisted entries as well. Also what browser are you using? is your traffic being diverted by a browser DNS server? Do a www.dnsleaktest.com to confirm your traffic is actually traversing the proper DNS servers. Also make sure you are not using alternative ad blocking scripts that might hinder how Diversion+pixelservtls process's the blocked domain.
I am using Safari. I checked and I don't see this option for Safari unless I missed it
This could also be an issue specific to iOS and their policies for handling certificates (specifically pixelserv-tls uses user made certificates.).
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!
