OPT1 needs LAN DNS access
-
Those interfaces look fine. They have IP addresses but not gateways defined like the WAN does.
So you cannot even ping the OPT2 interface IP (192.168.254.1) from a client on LAN?
-
@stephenw10 said in OPT1 needs LAN DNS access:
So you cannot even ping the OPT2 interface IP (192.168.254.1) from a client on LAN?
Yes this is big question.. If your client on lan is using pfsense as its gateway. And it doesn't have a mask problem where it thinks 192.168.254.1 is on its own lan - you should be able to ping it.
You sure your clients on lan are not using say a /16 mask, they would think 192.168.x is local to them and never send it to pfsense. This would allow you to talk to your opt1 network since its 10.x but no you wouldn't be able to talk to another 192.168 network through pfsense, if your not sending pfsense the traffic in the first place.
-
Correct. Here is a test from a client on the LAN side.
# nmap -sP 192.168.254.0/24 Starting Nmap 7.70 ( https://nmap.org ) at 2021-12-27 17:43 MST Nmap done: 256 IP addresses (0 hosts up) scanned in 10.47 seconds # nmap -sP 10.0.0.0/24 Starting Nmap 7.70 ( https://nmap.org ) at 2021-12-27 17:44 MST Nmap scan report for 10.0.0.1 Host is up (0.00022s latency). Nmap scan report for 10.0.0.29 Host is up (0.00063s latency). Nmap scan report for 10.0.0.30 Host is up (0.00051s latency). Nmap scan report for 10.0.0.52 Host is up (0.00077s latency). Nmap scan report for 10.0.0.211 Host is up (0.00091s latency). Nmap scan report for 10.0.0.212 Host is up (0.0098s latency). Nmap scan report for 10.0.0.214 Host is up (0.00056s latency). Nmap done: 256 IP addresses (7 hosts up) scanned in 10.07 seconds -
@lewis what is the mask on your client on lan?
ipconfig on windows
Ethernet adapter Local: Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 192.168.9.100 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.9.253ifconfig on linux
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.2.12 netmask 255.255.255.0 broadcast 192.168.2.255 inet6 fe80::11:32ff:fe22:cc7d prefixlen 64 scopeid 0x20<link> ether 02:11:32:22:cc:7d txqueuelen 1000 (Ethernet) RX packets 13788691 bytes 7585716775 (7.5 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9887749 bytes 1520893783 (1.5 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 -
@johnpoz
Wait, you might have something.
Yes, the client I was testing from has a /16.
This is a test from another client with a /24.# nmap -sP 10.0.0.0/24 Starting Nmap 6.40 ( http://nmap.org ) at 2021-12-28 08:28 MST Nmap scan report for 10.0.0.1 Host is up (0.00023s latency). Nmap scan report for 10.0.0.29 Host is up (0.00066s latency). Nmap scan report for 10.0.0.30 Host is up (0.00066s latency). Nmap scan report for 10.0.0.52 Host is up (0.00052s latency). Nmap scan report for 10.0.0.211 Host is up (0.00062s latency). Nmap scan report for 10.0.0.212 Host is up (0.012s latency). Nmap scan report for 10.0.0.214 Host is up (0.00052s latency). Nmap done: 256 IP addresses (7 hosts up) scanned in 14.86 seconds # nmap -sP 192.168.254.0/24 Starting Nmap 6.40 ( http://nmap.org ) at 2021-12-28 08:28 MST Nmap scan report for 192.168.254.1 Host is up (0.00029s latency). Nmap scan report for 192.168.254.2 Host is up (0.00043s latency). Nmap scan report for 192.168.254.10 Host is up (0.013s latency). Nmap scan report for 192.168.254.11 Host is up (0.21s latency). Nmap scan report for 192.168.254.16 Host is up (0.24s latency). Nmap done: 256 IP addresses (5 hosts up) scanned in 26.94 seconds -
Yup, that would do it! Fix the mask on that client.
-
Wow, good catch folks!
It just happens that my go to Linux client and the Windows machine I'm on have a /16 because of some other work I was doing a while back.
Changing them both back to /24 fixes the problem :).
It was something tiny I wasn't seeing at this point. Now I'm able to reach devices on the 192.168.254.1 network.
-
And I think I used the wrong term about gateways above causing you some confusion. What I meant was the static ip4 config per interface.
This was like making a single character coding mistake and it takes a week to find that one thing that broke everything.
Thank you very much for sticking to this and helping me.
-
Did you leave the AP IP as DHCP?
I thought AP's needed Static IP.
If the AP is an AP I thought all of the stuff like DNS/DHCP was managed by the actual router. DNS/DHCP info passes from the PFSense router though the AP.
I have Asus AX86U with RMerlin's FW as an AP. But I did my PFSense LAN as a Bridge.
Glad its working of course. Just trying to connect the dots.
-
Yeah adding a gateway to an internal interface because you want clients on that subnet to use it as their gateway is a common setup mistake. If you hang around the forum for a while you will see people do that and it causes a number of fun problems.
-
@jsmiddleton4 said in OPT1 needs LAN DNS access:
thought AP's needed Static IP.
Why would that be? The IP on the AP is only used for management of the AP.. How it gets that IP makes no difference, and its not used in any fashion where anything other than management would need to talk to that IP.
-
So you can find the AP when needing to access it for setup.
-
@jsmiddleton4 said in OPT1 needs LAN DNS access:
Did you leave the AP IP as DHCP?
I thought AP's needed Static IP.
If the AP is an AP I thought all of the stuff like DNS/DHCP was managed by the actual router. DNS/DHCP info passes from the PFSense router though the AP.
I have Asus AX86U with RMerlin's FW as an AP. But I did my PFSense LAN as a Bridge.
Glad its working of course. Just trying to connect the dots.I had changed the AP to DHCP client to test it getting the correct network settings. It gets a static IP from the pfsense DHCP server and the AP clients get their DHCP settings from pfsense as well. All are static in fact so I can keep track of what is on the networks.
-
A+B=C. The IP for the AP stays the same.
Mine is assigned a static IP of its own yet outside the DHCP range of PFSense DHCP server.
-
Yeah a real AP (acting as only an AP) is a layer 2 device, it doesn't actually need an IP at all. Though not having one is very inconvenient if you ever want to change anything.
-
I have DHCP set on all networks so that I can see new devices when they pop up. I then nab their MAC address and create a static DHCP entry.
For me, it's just a convenient way to keep track of things. If a MAC changes for some reason, like a vm rebuild for example, I just update the MAC in my DHCP static list.
-
And if you need to access the AP directly as in LAN cable to the AP. While a static IP assigned via the router gets to nearly the same place, the IP stays the same, if for some reason the router is out of the picture, good luck accessing the AP without a factory reset turning the AP back into a router.
-
@lewis said in OPT1 needs LAN DNS access:
I then nab their MAC address and create a static DHCP entry.
Yeah I pretty much do the same thing, anything on my network other then guest devices normally have a reservation..
I'm not really a big fan of the term "static dhcp" maybe I am old school, its a dhcp reservation for me ;)
Any time someone says static - what comes to my mind is setting the IP on the device directly.
-
@johnpoz said in OPT1 needs LAN DNS access:
I'm not really a big fan of the term "static dhcp" maybe I am old school, its a dhcp reservation for me ;)
Any time someone says static - what comes to my mind is setting the IP on the device directly.That is of course correct. My bad....
-
@jsmiddleton4 its not you - pfsense calls it static as well..
Its not the term is "wrong" exactly - its just it can be a bit confusing if not spelled out exactly that it was via dhcp or set on the device, etc. Especially for us old timers that grew up with the term reservation for years and years..
