Windows Clients cannot access the internet, very strange unexpected DNS problem.
-
@johnpoz that IP you are mentioning, is that your clients IP?
Auto-rules disabled and added 10.217.0.0/17 (summary) to the ACL,
When doing dig this is the output:
-
@IrixOS said in Windows Clients cannot access the internet, very strange unexpected DNS problem.:
@johnpoz that IP you are mentioning, is that your clients IP?
Auto-rules disabled and added 10.217.0.0/17 (summary) to the ACL,
When doing dig this is the output:
Is that 10.217.0.0/17 the entry you added to the ACL? If so, then by my calculations the IP that is querying (10.216.64.29) is not within that subnet. Is 10.216.64.29 one of the Windows clients?
-
Yeah 10.217/17 would be 10.217.0.0 - 10.217.127.255, so you are correct 10.216.64.x would not be allowed.
But that error looks like firewall rule with a reject or something, not unbound acl refusing you.. which would look like this..
Here I temp removed 192.168/16 from my ACL, and then did a query..
Your getting an error that you couldn't even talk to 64.29, and from your sniff thought your dns your .29 client was asking was .18..
In that command your asking 64.29, isn't that your windows client? So yeah I would expect him not to answer a dns query.
-
@johnpoz:
Duh! You are correct. I didn't even notice he appears to have run the DNS query from a pfSense session (if the 10.216.64.29 client is in fact a Windows machine).@IrixOS:
Now, if the 10.216.64.29 Windows target is a Microsoft AD Controller/DNS server, then you also may have an issue with the Windows firewall on the server. It will automatically drop inbound traffic that is not from the local subnet (if the firewall is enabled, which it is ON by default in Windows these days). I don't think you can fully troubleshoot your problem at the pfSense firewall. You need to run a DNS query vianslookupordigfrom a client on the network where you are having DNS problems. The returned error code will then be the clue to the real problem.By the way, since the default pfSense firewall rules allow the firewall to go anywhere, that "connection refused" message is likely coming from the target device (the 10.216.64.29 machine). I would initially suspect a local firewall to be the cause of the refused connection.
-
@bmeeks Yes 10.216.64.29 is the ip address of the client, the Local Route (L) in routing table is the /30 subnet 10.216.64.29-10.216.64.30 and this subnet is advertised into ospf.
Pardon me, it is 10.216.0.0/17 not 217 (summary route of al internal ospf routes) is in the ACL and that didn't work.
-
@johnpoz Sorry my mistake it is 10.216.0.0/17 I configured in the ACL, didn't work, wireshark outputs the error.
-
@IrixOS well you still did a query to .29 which no I wouldn't expect that to answer unless you were running dns on it.
lets see s basic nslookup from this windows client.
And then you could put it into debug mode to get more info..
Here
$ nslookup Default Server: sg4860.home.arpa Address: 192.168.9.253 > www.bing.com Server: sg4860.home.arpa Address: 192.168.9.253 Non-authoritative answer: Name: dual-a-0001.a-msedge.net Addresses: 13.107.21.200 204.79.197.200 Aliases: www.bing.com www-www.bing.com.trafficmanager.net www-bing-com.dual-a-0001.a-msedge.net > set debug > www.bing.com Server: sg4860.home.arpa Address: 192.168.9.253 ------------ Got answer: HEADER: opcode = QUERY, id = 7, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 0, additional = 0 QUESTIONS: www.bing.com.home.arpa, type = A, class = IN ------------ ------------ Got answer: HEADER: opcode = QUERY, id = 8, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 0, additional = 0 QUESTIONS: www.bing.com.home.arpa, type = AAAA, class = IN ------------ ------------ Got answer: HEADER: opcode = QUERY, id = 9, rcode = NOERROR header flags: response, want recursion, recursion avail. questions = 1, answers = 5, authority records = 0, additional = 0 QUESTIONS: www.bing.com, type = A, class = IN ANSWERS: -> www.bing.com canonical name = www-www.bing.com.trafficmanager.net ttl = 16365 (4 hours 32 mins 45 secs) -> www-www.bing.com.trafficmanager.net canonical name = www-bing-com.dual-a-0001.a-msedge.net ttl = 1665 (27 mins 45 secs) -> www-bing-com.dual-a-0001.a-msedge.net canonical name = dual-a-0001.a-msedge.net ttl = 1665 (27 mins 45 secs) -> dual-a-0001.a-msedge.net internet address = 13.107.21.200 ttl = 1665 (27 mins 45 secs) -> dual-a-0001.a-msedge.net internet address = 204.79.197.200 ttl = 1665 (27 mins 45 secs) ------------ Non-authoritative answer: ------------ Got answer: HEADER: opcode = QUERY, id = 10, rcode = SERVFAIL header flags: response, want recursion, recursion avail. questions = 1, answers = 0, authority records = 0, additional = 0 QUESTIONS: www.bing.com, type = AAAA, class = IN ------------ Name: dual-a-0001.a-msedge.net Addresses: 13.107.21.200 204.79.197.200 Aliases: www.bing.com www-www.bing.com.trafficmanager.net www-bing-com.dual-a-0001.a-msedge.net > -
@IrixOS:
The next step in my opinion is to attempt annslookupordigquery from one of the impacted clients. You can't run thedigcommand from the pfSense box and target that Windows machine. Unless that Windows machine is a DNS server, it will never respond to the query.Edit: see @johnpoz beat me posting a reply by a few seconds...
-
@johnpoz I created a rule, might be wrong don't know.
🔒 Log in to view 🔒 Log in to view
Is this correct?
-
-
@IrixOS yeah your rule on your lan looks right to allow any traffic from a downstream network on 10.216/17.. But that outbound looks wrong.. Why would you have a "modem" interface, is this not pfsense wan? What would 172.16 have to do with dns working if you ask pfsense IP?
Be it your device is natted to get to the internet has little to do with some client behind pfsense asking it for dns, that dns would resolve..
If you go to dns lookup under diagnostics and put in www.bing.com what do you get?
Why are you in manual for outbound nat? When you create a gateway in pfsense, and then create routes to that gateway.. Pfsense would automatically add those outbound nat rules to allow these downstream networks to be natted to pfsense wan IP.. I have no idea what your modem interface is, and how that would have to do with getting to the internet, because your only going to be natting to destinations in that 172.16.1/24 to whatever that modem interface IP is on pfsense.. Not sure how that gets a client to the internet? Client trying to get to the internet say 8.8.8.8 would not be 172.16.1 for destination.. So you wouldn't be natting anything..
Well can tell you right now you have something wrong with unbound, because your not even returning the ptr for pfsense own IP... Which would always be a given.. So either 192.168.1.1 is not pfsense? Or its dns is borked.. because it wold always return the IP of the name you setup for pfsense.. Is that 192.168.1.1 not pfsense lan IP?
What is this 192.168.1.1 address.. You would think you would point your clients to pfsense IP on your transit network?
Is that 192.168.1.1 address is a pfsense other IP and you want to query it for dns, you should prob setup a host override for it.. etc..
example, here I changed server in nslookup to use a different IP of pfsense.
> server 192.168.3.253 ------------ Got answer: HEADER: opcode = QUERY, id = 11, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 1, authority records = 0, additional = 0 QUESTIONS: 253.3.168.192.in-addr.arpa, type = PTR, class = IN ANSWERS: -> 253.3.168.192.in-addr.arpa name = sg4860.dmz.home.arpa ttl = 3600 (1 hour) ------------ Default Server: sg4860.dmz.home.arpa Address: 192.168.3.253See how it returns slightly different name, 192.168.3 I call my dmz segment.. But a client should always be able to resolve stuff you have local on pfsense, like pfsense name.. if it can't then you got something really wrong..
-
@IrixOS:
I agree with @johnpoz and don't understand the purpose of the manual outbound NAT rule going to the Modem Address (and with that 172.16.x.x destination). You can tell by the little globe icon on the right side of the Windows client's Task Bar that it does not have Internet access. That globe icon means "no Internet". It will be a little square box looking icon when the client can ping a certain Microsoft address. -
@johnpoz Ah I thought you knew, the pfsense is connected with a VDSL modem which is in bridged mode. According to the handbook this NAT rule is necessary, please correct me?
-
@bmeeks Yes I desperately waiting for that square on the taskbar to appear,...
-
@IrixOS not that rule should not be necessary... If you take some device and connect it to pfsense, be it you bridge a public IP to pfsense or whatever.. That would still be pfsense wan..
While I don't have a lot of experience with however you seem to be setup for a "modem" that rule makes zero sense at all.. As I stated why would you nat your clients to some "modem" interface... Isn't your device connect to pfsense wan? And your only going to nat traffic dest for that 172.16 network... Which would be why.. If you maybe want to connect to its web gui? But that would have zero to do with internet access for your clients..
And you have it setup where pfsense can not even do dns, that would also explain your servfail responses... What does dns lookup on pfsense show for www.bing.com - per my example above.
-
-
@IrixOS well yeah then dns is never going to work.. if pfsense itself can not look up www.bing.com, how would you expect a client asking it to lookup www.bing.com would get an answer..
-
I'm using Automatic Outbound NAT on my firewall, but that should work for you as well so long as you have all the routes defined in pfSense. Here is my Outbound NAT rule:
Notice I NAT to the pfSense WAN address. I think that's how your rule should look. In fact, I think Automatic should work for you unless for some reason pfSense does not know about some of the downstream networks. That would be the only case for manual, and for that I would use the Hybrid mode.
-
@johnpoz So is NAT then root causeand how to properly configure it?
-
@IrixOS am I going insane? Did you change the picture or something - thought I saw a 192.168.1.1 address, but now not seeing it??