@godatum said in Unable to access internet on certain devices - trying to find root cause:

My brother turned on his laptop but could not access the internet.

Easy : whatever OS he uses, he changed something.
As any device (PC) uses a DHCP client these days, so the user can :
Order one.
Receive it.
Unbox it.
Putting it on.
Select a SSID or slide in the Ehernet cable.
Connected.

This is a 100 % no brainer.

On the pfSense side :
Do the initial set up. Change only the admin password.
And maybe, for very special cases : make the WAN work.
Done.
DHCP server on LAN works.

@godatum said in Unable to access internet on certain devices - trying to find root cause:

I went into PFSsense and did a DNS Lookup diagnostic. I got 127.0.0.1 unavailabl

That's a lucky shot. the resolver could be restarted ones or twice a day ? week ?
It will do so with a second or so.
You doing a "resolve' right at that moment, that a 10/(24*3600) chance.

The resolving (unbound) should always work.

3883e69c-b677-4ad6-b383-94ba33a652e9-image.png

Now who is "1.1.1.1" ?
I have only "127.0.0.1".
The resolver does all the work for me.

Btw : even if unbound was not running, this would not break Internet access.
Just the 'name resolving stops'.

@mickamickatchu said in No free lease on fresh install:

At this step if I enable DHCP on LAN1 interface, a machine plugged to the LAN2 interface can get an IP from LAN1 DHCP

Well then your setup is broken.. And you don't actually have isolation between your networks. Your 2 networks should be either physically isolated, or isolated via vlans. There should be no way lan 1 interface would ever see a discovery from lan 2 network since they should be isolated at layer 2. And vise versa, 2 should never see discovery broadcasts from network 1

I have 8 different networks, all correctly isolated at layer 2.. dhcp on network A, never sees broadcast from any other network, etc. Trying to isolate devices by just using different IP space when they sit on the same network is not valid from a security point of view. You can isolate at layer 2 even if everything is virtual. You just need to setup your vitual network and how it connects to your physical network correctly to do so.

@viktor_g
Perfect - learned something new and fixed the issue!

I have no idea why your seeing those - but has nothing to do with acme updating a dns record.. SOA of whatever domain your doing isn't going to be cloudflare-dns.com nor is it going to dns.google, etc..

Many of those queries your blocking out what the actual fqdn was.. and you local domain... And why and hell would you hide your rfc1918 address 172.20.x.x ?

anything using the api for cloudflare would be talking to api.cloudflare.com, godaddy would be either api.ote-godaddy.com or api.godaddy.com

Its quite possible whatever your doing with trying to filter is just breaking dns in general.. But if your updating anything with the apis of cloudflare or godaddy it sure would be trying to resolve the doh fqdn..

edit: btw I have domains with cloudflare, and use acme certs for those domains.. I have no issues renewing them.. And I specifically block doh domains by resolving them to a specific rfc1918 address, so I can see if any clients try and resolve them and access them..

;; QUESTION SECTION: ;cloudflare-dns.com. IN A ;; ANSWER SECTION: cloudflare-dns.com. 120 IN A 172.19.19.19

So if acme needed to talk to cloudflare-dns.com for some reason it wouldn't be able to.. I also have their real IPs blocked..

the fqdn or IP of cloudflare-dns.com would not be used in renewing a cert via clouldflare and acme.. It just wouldn't - they are not related to the api, and or anything to do with actually resolving whatever you domain is.

@skilledinept It wasn't all that difficult putting the leases into a PowerShell script now that they're super tidy. :) Still, pfSense UI, which is rather clunky and slow beats from the oldest MMC, to IPAM, SCCM to the newest W Admin Center. PowerShell, surprisingly, the best because you can wipe all and load from a text file UNIX-style all within a VS Code window, RDS is still needed though. I thought it was going to be another couple of days copying MAC addresses. :/. It's mind blowing that this OS is a serious product.

If anyone knows how to fix it though, I'd still like to attempt that. :)

I suspect this is the same issue I reported here which has not been resolved as 21.05.1:

Every Reboot Requires Restart of DNS Resolver

Do a reboot and I bet you will need to follow it with an unbound restart to restore DNS resolution. Let us know…

Peter

@b_chris

There are a lot of things different in IPv6, compared to IPv4. One of these is having multiple addresses on the same interface. This was also possible in IPv4, with aliases, but it wasn't common. With pfsense, on the RA page, you can add several prefixes, if you wish.

From the authoritative nameserver, resolve vs forward. This is what pfsense does out of the box, it resolves vs forwards.

dnssec is how you can know the dns has not been manipulated because the records have been signed by the owners of the domain.. Not all domains do this - but they should.

https://dictionary.cambridge.org/us/dictionary/english/straight-from-the-horse-s-mouth

(straight) from the horse's mouth If you hear something (straight) from the horse's mouth, you hear it from the person who has direct personal knowledge of it.

https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

why DHCP dishes out no gateway as long as it is without WAN connection

Never seen such a thing.. Pfsense out of the box, will hand out its own IP on the interface your running dhcp on.. Unless you have set it up otherwise..

"The default is to use the IP on this interface of the firewall as the gateway. Specify an alternate gateway here if this is not the correct gateway for the network. Type "none" for no gateway assignment."

As to why it can do odd stuff with only 1 interface configured - is puts the default antilock out on this interface so you can get to it. How can it hand out dhcp on an interface set for dhcp, etc. So without full details of what you did in what order.. I am just saying that bringing up pfsense with only 1 interface, and then enabling another interface can cause some issues, as it flips the antilock rules and where your actually connected from..

Also - pfsense without dns, the web interface can be slow to respond - maybe took this as not working?

All I can say is in the prob 100's of pfsense I have setup - have never seen what your saying is happening.. If there is a lan, and you set its IP and turn on dhcp, it will hand out IPs with the gateway set as its IP on that interface. Unless you edit dhcp to hand out something else.

@kiokoman

Thank you for your quick and clear reply!
This helped me out a lot, I didn't realize we could add "Send options" in such a way!

I haven't managed to get a public IP yet but am getting closer and closer :)

Have a great day

@steveits said in Get DHCP IP for OPT1 from LAN:

The reason other WAN addresses are needed are so the routers can connect to the Internet, for example to install updates without forcing a failover.

If you have only one WAN IP there is a possible workaround with gateway groups to get internet access on the backup node as well.

You can create a gw group on both with the CARP VIP as tier 1 and the respective others LAN IP as tier 2. Then set this gw group as default gw.
You will have to disable XMLRPC sync of static routes settings.

So if the CARP is occupied by the master, the backup node uses the masters LAN for connecting to the internet.
Might be a bit tricky, but should work thus far.

Rebuilt the box from scratch with no config restore and all seems to be okay until Pfblocker-ng DEVEL was fully configured with all the block list feeds, shortly after the IP on the LAN interface changed again, this must be a bug?

The interface is now showing the IP of "0.0.0.1" on the dashboard page, and "100.64.0.3" in the interface page, however, DHCP is running so that's a bonus.

I may try removing all the feeds again to see if the issue stops

(I did submit a bug on the main reporting page however it was deleted as a bot..)

As a side note, i did export the config and search for "0.0.0.1" to see if it was being set somewhere however no luck finding such line in the config xml file.

https://nlnetlabs.nl/documentation/unbound/unbound.conf/

https://calomel.org/unbound_dns.html

@tiger-0

???

Do you mean on the LAN side, so that WiFi devices can connect? Or do you mean something on the WAN side? Normally, you just connect the AP to the LAN side. though you may add extra SSIDs via VLAN.

Here I have a guest WiFi set up on my AP, using a VLAN, with the main WiFi connected on the native LAN.

I found the issue, apparently it was my nic. It doesn't like Hardware Checksum Offloading. I disabled that and now everything is working.