Windows Clients cannot access the internet, very strange unexpected DNS problem.
-
@johnpoz Thank you, appreciate you are joining thread.
To be clear, The 64.29 is the clients ip address part of a local route (L), the subnet it resides on is in a /30 subnet, so 10.216.64.29-10.216.64.30. If you advertise it into ospf, it gets routed.
Between the ospf router (ASBR) and pfsense I have a /30 subnet, so 10.216.64.17-10.216.64.18, that's the network that directly connects to pfsense which has the LAN interface IP of 10.216.64.18. I have static route configured in the form of a summary route (which includes all possible internal routes) pointing back to the internal ospf network and uses 10.216.64.17 as its downstream gateway address.
On the ASBR (router that point to the pfsense), I have configured a null route ip route 0.0.0.0 0.0.0.0 10.216.64.18 and propagated the route to every downstream ospf routers.
Routing works from the client to the firewall and vice-versa, it it just that dns anomaly, it just doesn't make sense.Actully I am doing nothing special, it's just routing, how can it possibly be that I am stuck with this for so long.
I did the whole config of psense into mottballs and started from scratch with a /30 subnet connecting to a laptop directly, then DNS works and I can access the internet, it doesn't make sense.
Either I am stupid, or there definitely some issue with pfsense, It did work in the past with some similar cisco routing with no DNS issues, don't remember what the version that time.
I survived a lot of network troubleshooting, but this silly horseshit problem cannot be, really come on. It should work out of the box.
I think pfsense doesn't like cisco material and OSPF.Feel free to ask me questions, I hope the above is clear enough,
Waiting for more possible answers,
Actually it is the same principle as in the diagram, advertise all routes and that's what I did.
-
@IrixOS said in Windows Clients cannot access the internet, very strange unexpected DNS problem.:
10.216.64.29-10.216.64.30.
If unbound is listening that .17/30, then any downstream network be it a /24 or another /30, etc.. you would need to make sure the ACLs allow for queries from that downstream network.
I disabled the auto acls, and set my own... You can see here I just made it easy on myself and created a acl that allows all of rfc1918 space... So I could fire up a network on any rfc1918 and be able to query unbound from it.
-
@IrixOS
To amplify what @johnpoz is saying --The ACL (access control list) for
unboundlimits what IP addresses can ask for DNS lookups. Think of it as a type of "firewall" forunbound. pfSense will automatically create ACL entries forunboundto cover all of the directly attached networks. But if you have downstream networks that are not defined directly on pfSense that are attempting to queryunboundon pfSense, then you will need to create custom ACL entries to allow that traffic (in addition to pfSense firewall rules that allow those downstream IP addresses past the pfSense firewall). -
@bmeeks I just filled in the fields of the ACL, already gone through that, I won't budge. My summary route is 10.216.0.0./17 so I filled in that, disabled the auto-rules.
Any other ideas?
Feel free to ask me any question,Thank you,
-
@IrixOS I am not sure if the manual ACLs work, if you have auto acls set... So its quite possible if auto is still enabled and you create your own that it might not be working.. Did you restart unbound after creating the acls?
A simple directed query would be easier to see if your getting refused, acl not allowing.. or a servfail?
$ dig @192.168.9.253 www.bing.com ; <<>> DiG 9.16.48 <<>> @192.168.9.253 www.bing.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55311 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.bing.com. IN A ;; ANSWER SECTION: www.bing.com. 18539 IN CNAME www-www.bing.com.trafficmanager.net. www-www.bing.com.trafficmanager.net. 539 IN CNAME www-bing-com.dual-a-0001.a-msedge.net. www-bing-com.dual-a-0001.a-msedge.net. 539 IN CNAME dual-a-0001.a-msedge.net. dual-a-0001.a-msedge.net. 539 IN A 13.107.21.200 dual-a-0001.a-msedge.net. 539 IN A 204.79.197.200 ;; Query time: 1 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Mon Feb 26 11:52:32 Central Standard Time 2024 ;; MSG SIZE rcvd: 184 -
@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.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
@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...
-
-
-
@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.
