PFSense Query refused

Gertjan

@bingo600 said in PFSense Query refused:

But he could easily have done the query from a non pfSense attached Lan + CL.

True.
But look again, carefully.
This is what I make of the 'error' message :
It's 192.168.1.140 - the known DNS server = pfSEnse to nslookup said - that replies is refused (because it contains a syntax error).
So it did receive the request and answered. If @grantcurell was logging the DNS queries handled by the resolver, you could have seen this "192.168.1.5" DNS request in the DNS Resolver log !!
But "192.168.1.125" can't be resolved. As it is already resolved.

edit
I found this line in the Python / dns_repley.log file :

DNS-reply,Dec 10 11:43:19,local,PTR,PTR,Unknown,125.1.168.192.in-addr.arpa,2001:470:1f13:5c0:2::84,NXDOMAIN,unk

Unbound was trying to find the PTR ( !! ) == the reversed lookup.
As I do not have a 192.168.1.125 in my network, there was no answer.
When I use an IP from an existing device in my network, I do receive a reply :

Nom :    KMA98FA5.brit-hotel-fumel.net
Address:  192.168.1.5

which means you can use an IP as 'hostname' - I learned something : nslookup will ask for the hostname when an IP is givnn !
It should be known, of course.

Serveur :   pfsense.brit-hotel-fumel.net
Address:  2001:470:1f13:5c0:2::1

Réponse ne faisant pas autorité :
Nom :    google.com
Addresses:  2a00:1450:4007:80a::200e
          216.58.201.238

> 216.58.201.238
Serveur :   pfsense.brit-hotel-fumel.net
Address:  2001:470:1f13:5c0:2::1

Nom :    par10s33-in-f14.1e100.net
Address:  216.58.201.238

Si, I tend to say : the issue is not an ACL missing.

You're correct when you say that, when an OpenVPN server has been set up, the tunnel network should be added to the ACL - the ACL functionality should be activated - and then, of course, also the LAN interface 192.168.1.0/24 interface should be listed in the ACL.

edit : what I never understood :
pfSense is the gateway/router in a LAN network like 192.168.1.0/24
Why choosing an IP LAN like 192.168.1.140 - why not the default, more logic, 192.168.1.1 or, if you have to, 192.168.1.254 ?
Why an IP in the middle of the network range ?
Is there a already 192.168.1.1 ? What is that device ?
It's just a choice, I know, 192.168.1.140 isn't wrong technically.

bingo600

@gertjan said in PFSense Query refused:

edit : what I never understood :
pfSense is the gateway/router in a LAN network like 192.168.1.0/24
Why choosing an IP LAN like 192.168.1.140 - why not the default, more logic, 192.168.1.1 or, if you have to, 192.168.1.254 ?
Why an IP in the middle of the network range ?
Is there a already 192.168.1.1 ? What is that device ?
It's just a choice, I know, 192.168.1.140 isn't wrong technically.

I totally agree , if pfSense is def-gw .140 is strange.

I have DNS on .101 & .102 , but that's my linux bind servers (that pfSense forwards too).
My def-gw (fw) is on .1

/Bingo

grantcurell

@gertjan Unfortunately as mentioned in the OP neither the hostname or the IP resolve.

To answer the question of why 140, because in this case it isn't serving as the gateway.

Gertjan

@grantcurell said in PFSense Query refused:

or the IP resolve

I edited my post above.
If 192.168.1.125 is a device on your LAN that is known, for example, because it used DHCP to obtain a IP, and you are using one of these two :

then the hostname will be known.
And returned.

If the device 192.168.1.125 exists on your network, and you use a static IP setup, then the resolver wouldn't know about it.

johnpoz

@gertjan said in PFSense Query refused:

nslookup will ask for the hostname when an IP is givnn

Huh?? Nslookup will do the PTR for that IP..

set debug and see for yourself.

If your getting refused back, then yes that screams to ACL as problem.

Gertjan

@johnpoz : I just re discovered that, one hour ago.
I'm more a dig man.

johnpoz

Yeah same here - not sure why anyone would use nslookup ;)

grantcurell

@johnpoz

No ACLs set unless there is one out of the box. I was honest in the OP, I installed from ISO and the only changes made were the ones mentioned.

johnpoz

@grantcurell

Where are you doing the query from? A device on the pfsense lan? Or some downstream network, a vpn connection?

Out of the box yes ACLs are set for the networks directly attached to pfsense. If its a downstream network, or a vpn tunnel IP then no you would not be able to query unbound on pfsense.

Pfsense IP is what? 192.168.1.140, what is your client IP that your running nslookup from?

grantcurell

@johnpoz client is 192.168.1.6, same network, directly connected, only thing between them is a switch.

This is part of why I was so baffled by the problem. I've set this up a million times before, on this network, with that switch, with this pfsense config.

Worth mentioning when I used diagnostics to have PFSense query itself it worked fine

johnpoz

@grantcurell

Did you turn off the auto ACLs?

Under the resolver / advanced settings?

Do a query for pfsense name.. does that work?

grantcurell

@johnpoz I'll check that out! Thanks man!

Gertjan

@grantcurell said in PFSense Query refused:

I installed from ISO and the only changes made were the ones mentioned

and then you set up a network where :

@grantcurell said in PFSense Query refused:

in this case it isn't serving as the gateway

which means you left default (networking) settings.
That's perfectly fine.
And opens the door of all kind of situations.

Please understand : install pfSense from scratch.
Hook up the WAN.
Hook up a PC on LAN.
It works.
So, tell us what changed, and we'll tell you what to do or undo.

mbrownnyc

@bingo600 said in PFSense Query refused:

@grantcurell

Are you using unbound ?

I had to add my openvpn ranges to the access-lists section as allow , in order to be able to resolve DNS from those.

Seems like unbound default allows known nets (assigned to interfaces) , and refuses qureries from all other nets.

Add "unknown nets here" (Unbound settings)

/Bingo

Worth noting this occured with a VLAN interface srced traffic... It might be because I need to bounce the unbound daemon, or whatever... adding the ACL allowed me to src traffic from a macvlan hosted docker container bound to a subint on a synology NAS. The tagged traffic was arriving, and I was seeing refused responses from pfsense at the LAN interface of the pfsense. Adding the subnet for the VLAN interface resolved the issue. Thank you!