Pi Hole not matching IP and not able to ads block (lack of network knowledge)

locnguyen · January 1, 2020, 9:41pm

pi@Pihole:~ $ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.0.10  0.492 ms  0.499 ms  0.477 ms
 2  10.72.32.1  6.207 ms  10.912 ms  10.594 ms
 3  68.4.12.128  11.064 ms  10.747 ms  10.384 ms
 4  100.120.104.0  11.547 ms  11.233 ms  10.867 ms
 5  68.1.1.167  10.815 ms 68.1.1.171  10.583 ms  14.712 ms
 6  72.14.242.92  14.714 ms 72.14.196.240  14.702 ms 72.215.224.175  13.335 ms
 7  * 108.170.247.225  14.603 ms  11.200 ms
 8  8.8.8.8  10.897 ms  15.672 ms  14.981 ms

pi@Pihole:~ $ ip r

pi@Pihole:~ $ ip r
default via 192.168.0.10 dev eth0 proto dhcp src 192.168.0.190 metric 203 
192.168.0.0/16 dev eth0 proto dhcp scope link src 192.168.0.190 metric 203

Here's the new token https://tricorder.pi-hole.net/hc8sy1fko4

locnguyen · January 1, 2020, 9:43pm

I'm not even sure if my LAN is suppose to be on that IP.. This makes me wants to wipe my router or factory reset it.(probably my last option)

Edit:
There's also this page..

deHakkelaar · January 1, 2020, 9:46pm

Looks good.
What if you run below one on a client device (Win/Mac/Linux):

nslookup pi.hole 192.168.0.190

And without the Pi-hole address on a client ?

nslookup pi.hole

And did gravity update already ?

nc localhost 4711 <<< $'>stats'

If domains_being_blocked still zero, try run below to run gravity:

pihole -g

And remove the 8.8.8.8 Secondary DNS address on the router or ads will still leak through!

Ps. if you change DHCP settings, you have to disconnect and reconnect client devices for the new settings to propagate!

locnguyen · January 1, 2020, 9:51pm

Locs-MacBook-Pro-2:~ LocNguyen$ nslookup pi.hole 192.168.0.190
Server:		192.168.0.190
Address:	192.168.0.190#53

Name:	pi.hole
Address: 192.168.0.190

Locs-MacBook-Pro-2:~ LocNguyen$ nslookup pi.hole
Server:		192.168.0.190
Address:	192.168.0.190#53

Name:	pi.hole
Address: 192.168.0.190

Locs-MacBook-Pro-2:~ LocNguyen$ nc localhost 4711 <<< $'>stats'
Locs-MacBook-Pro-2:~ LocNguyen$ echo ">stats" | nc localhost 4711
Locs-MacBook-Pro-2:~ LocNguyen$ curl -i http://pi.hole/admin/api.php
HTTP/1.1 200 OK
Content-type: application/json
Set-Cookie: PHPSESSID=glr9r31l2vsp4avssfcunpq4h3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-Pi-hole: The Pi-hole Web interface is working!
X-Frame-Options: DENY
Content-Length: 484
Date: Wed, 01 Jan 2020 21:49:21 GMT
Server: lighttpd/1.4.53

{"domains_being_blocked":113661,"dns_queries_today":53714,"ads_blocked_today":797,"ads_percentage_today":1.483784,"unique_domains":1466,"queries_forwarded":26457,"queries_cached":26460,"clients_ever_seen":11,"unique_clients":11,"dns_queries_all_types":53714,"reply_NODATA":126,"reply_NXDOMAIN":9,"reply_CNAME":743,"reply_IP":436,"privacy_level":0,"status":"enabled","gravity_last_updated":{"file_exists":true,"absolute":1577867058,"relative":{"days":"0","hours":"13","minutes":"25"}}}Locs-MacBook

You know what's the craziest part? it sometimes work like

Locs-MacBook-Pro-2:~ LocNguyen$ nslookup flurry.com
Server:		192.168.0.190
Address:	192.168.0.190#53

Name:	flurry.com
Address: 0.0.0.0

deHakkelaar · January 1, 2020, 9:53pm

Sorry, the last two commands from previous posting should be run on Pi-hole.

Thats probably because of the secondary DNS IP address 8.8.8.8.

locnguyen · January 1, 2020, 9:55pm

I see should I set second DNS as 190.168.0.189?

no worries man, you're helping me a lot! I'm also learning a bunch

deHakkelaar · January 1, 2020, 10:02pm

No.
If the router firmware doesnt allow you to leave this field empty, try put in the same IP 192.168.0.190 twice.

locnguyen · January 1, 2020, 10:12pm

I realized when testing that nslookup flurry.com I had my dns manually set on my mac.
Sorry for the confusion
now running it

Locs-MacBook-Pro-2:~ LocNguyen$ nslookup flurry.com
Server:		2001:578:3f::30
Address:	2001:578:3f::30#53

Non-authoritative answer:
Name:	flurry.com
Address: 212.82.100.153
Name:	flurry.com
Address: 98.136.103.26
Name:	flurry.com
Address: 74.6.136.153

This is the pi

pi@Pihole:~ $ nslookup flurry.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	flurry.com
Address: 0.0.0.0
Name:	flurry.com

This is my mac DNS settings automatically. I dont know what those two other IP are I really want them out of here...

deHakkelaar · January 1, 2020, 10:15pm

Try to disable anything IPv6 related on the router and disconnect and reconnect the client again to check DNS servers assigned.

EDIT:

Tesserax · January 1, 2020, 10:27pm

Those are IPv6 addresses being assigned to your Mac by your ISP. It appears that you are getting IPv6 service. To "remove" them here, as @deHakkelaar has already mentioned, you will need to do so at your router. That could be in a couple of ways:

One would be to disable IPv6 altogether.
The other would be not allow IPv6 traffic to enter your local network.
Actually, a third way is to reconfigure your Mac to use Link-local only for the IPv6 mode in System Preferences > Network ... and may be the simplest option of all to try.

locnguyen · January 1, 2020, 10:30pm

Got it installed. I got this after

pi@Pihole:~ $ sudo nmap -sU -p67 --script dhcp-discover 192.168.0.10
Starting Nmap 7.70 ( https://nmap.org ) at 2020-01-01 14:27 PST
Nmap scan report for 192.168.0.10
Host is up (-0.18s latency).

PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover: 
|   DHCP Message Type: DHCPACK
|   Server Identifier: 192.168.0.10
|   Subnet Mask: 255.255.0.0
|   Router: 192.168.0.10
|_  Domain Name Server: 192.168.0.190, 192.168.0.190
MAC Address: D4:6E:0E:42:40:48 (Tp-link Technologies)

Nmap done: 1 IP address (1 host up) scanned in 5.57 seconds

I will remove IPV6 from my router. I dont know how.. let me figure it out

locnguyen · January 1, 2020, 10:42pm

I believe I fixed the issue.
Sorry @Tesserax and @jfb I went the totally opposite way with this.
instead of disabling the IPV6. I used the IPV6 I got from Pihole /etc/pihole/setupvars.conf and used that in my Router as a IPV6 DNS. I think its working now!

Thank you so much guys for all the trouble. I truly appreciate you helping me!

EDIT: Please do let me know if there's something else I could test.

Locs-MacBook-Pro-2:~ LocNguyen$ nslookup flurry.com
Server:		192.168.0.190
Address:	192.168.0.190#53

Name:	flurry.com
Address: 0.0.0.0

Tesserax · January 1, 2020, 10:45pm

@locnguyen No need to be sorry for figuring out a solution ... and IPv6 is the "wave of the future" so you will be one-step ahead already. Good job!

locnguyen · January 1, 2020, 10:49pm

You guys really inspired me to contribute more to this community.
I only know js and python development but will definitely try

Have a great new year

shoka · January 2, 2020, 9:30pm

That is a BIG network if it's for a domestic network. Provision for 65536 hosts if my binary serves me.

Harry

locnguyen · January 2, 2020, 11:26pm

Hey @shoka thanks for the response.
Are you recommending to do a smaller subnet? Like 255.255.255.0?

I don’t exactly know what that means.. care to elaborate?

shoka · January 3, 2020, 12:58pm

It's not a significant issue, but can bite you in subtle ways.

That 255.255.0.0 is a decimal method to define a 32 bit binary "mask" to separate IP addresses into two parts, the network address and the host address.
This can also be specified by stating the number of bits in the network part of the address, so in this case 192.168.0.0/16.

You need a big enough 'host' part to cover all the hosts that will exist on the network. If we were talking public addresses, then it also matters that you do not claim more addresses than you need, since IP addresses are valuable.

Back in the dark ages of the internet only the /8 /16 and /24 netmasks were valid, but we have long since moved to what is known as "variable length subnet"

However 192.168.0.0/16 alternatively represented by 192.168.0.0 255.255.0.0 is one of address ranges reserved for private networks so will not propagate on the internet, all internet routers should drop traffic to or from that range of addresses (and 10.0.0.0/8 and 172.16.0.0/12).

So you are theoretically perfectly free to use the network setup you have.

The subtleties are things like the DHCP server needing to be able to allocate space for up to 65000 hosts, the arp tables needing to accommodate up to 65000 host addresses, scans of the network taking forever since to define the active hosts on the network you need to check 65000 possibilities.

192.168.0.0/24 is a slice of that private network range that defines an ip address range that provides for 253 hosts, which is usually sufficient for private networks.

I'd probably not pick exactly that one as it's the default for almost every private network set up automatically by domestic routers and and thus is an obvious target for scripted attacks.

Its only a minimal hurdle for an attacker if you pick a less popular range, but it costs you nothing in setting up or use, so why not?

Nice memorable ranges are 192.168.192.0/24 192.168.100.0/24 and similar sized slices out of the 10.0.0.0/8 or 172.16.0.0/12 ranges

Helpful ??

Harry

locnguyen · January 4, 2020, 1:00am

@shoka
helpful? you explained perfectly!

I read so many forums and pages explaining the concept of subnet I never understood it till now. Will bookmark this for sure.

Thanks Harry.
Yes sir definitely changing it to 255.255.255.0.

I also noticed a bit of latency while working from home during these past few days

shoka · January 4, 2020, 2:55pm

For added joy, not all implementations of subnetting require the netmask to be contiguous.
(all binary ones to the left, ergo no zero's in the network part)

Cisco do, so pretty much everyone does these days, but in the days when Novell was a force in networking, they supported non contiguous netmasks. Most if not all current routing protocols cannot cope with discontiguous netmasks.

So 192.168.0.0 255.255.254.128 would be to some implementations a valid netmask. Just not contiguous.

(binary mask 11111111:11111111:11111110:10000000)

You can't represent that as a /n mask, that's why the:
nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm notation exists.

The theory was that if you outgrew the network host size count, and your original network was bounded on both sides by other networks, you could pinch a few more bits from the network part and expand the number of hosts supported. Sounds reasonable, but in practical terms it was a nightmare, and only Novell's routing protocols supported it that I know of.

It's worth remembering though, that if you use the nnn.nnn.nnn.nnn mmm.mmm.mmm.mmm notation, that you can set netmasks that are not valid, and not all (though these days almost all) IP implementations will error on such a mask.

so if the configuration tool supports it using the /n notation is safer.

Both the netmasks discussed above 255.255.0.0 and 255.255.255.0 are contiguous.

Harry

system · January 25, 2020, 2:56pm

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.