Windows Clients cannot access the internet, very strange unexpected DNS problem.

IrixOS

@johnpoz I created a rule, might be wrong don't know.

Is this correct?

IrixOS

johnpoz

@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.253

See 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..

bmeeks

@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.

IrixOS

@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?

IrixOS

@bmeeks Yes I desperately waiting for that square on the taskbar to appear,...

johnpoz

@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

@johnpoz

johnpoz

@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..

bmeeks

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.

IrixOS

@johnpoz So is NAT then root causeand how to properly configure it?

johnpoz

@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??

johnpoz

@bmeeks said in Windows Clients cannot access the internet, very strange unexpected DNS problem.:

for some reason pfSense does not know about some of the downstream networks

Yeah auto will auto add the nat rules for any downstream networks you create a route to in pfsense via some gateway you create.. There rarely is any reason you would even need to do manual, unless you had something really odd setup.. Even if you were doing some odd stuff, hybrid should normally be able to cover what you need..

You really should never need to use manual nat..

This points to something else out of wack.

Pfsense running unbound should always be able to resolve its lan IP to its name you set in general..

So either that 10.216.64.18 is not pfsense lan IP? Or something else going on other than nat issues or acls, etc.. when you do a nslookup it does a PTR for the IP to get its name.. Your is coming back unknown, that should not happen.

192.168.9.253 is my pfsense lan IP..

IrixOS

@johnpoz said in Windows Clients cannot access the internet, very strange unexpected DNS problem.:

eah auto will auto add the nat rules for any downstream networks you create a route to in pfsense via some gateway you create.

I disabled the MODEM NAT rule and activated the auto add NAT rules, I can see the downstream networks in the rule, but the world icon on windows still doesn't change into a square.

bmeeks

@IrixOS said in Windows Clients cannot access the internet, very strange unexpected DNS problem.:

I disabled the MODEM NAT rule and activated the auto add NAT rules, I can see the downstream networks in the rule, but the world icon on windows still doesn't change into a square.

It can take Windows a few minutes to update the icon in my experience. And every now and then a reboot might be required.

A quick test is this:

ping 8.8.8.8

If that works, you have Internet access from the Windows client.

Next, you can try pinging google.com from both pfSense and that Windows client to see if DNS queries are working.

johnpoz

@bmeeks exactly - and if he is still having dns problems? That might not show globe, etc. I do not remember if it has any fallback to just checking if can get to an IP.. I believe it does a dns lookup, the exact fqdn eludes me at this moment, but then it tries to actually open that and wants to see an OK... Unless they have drastically changed how they do that in latest windows 11 or something?

IrixOS

@bmeeks No that flyer doesn't go up, it's useless.

Dit you remember the thread about the lagg0 port, you said something about choose an other free port, well I configured the lagg0 port with a vpn tunnel on the wan, that's plain stupid but it did work. So you fix something inside from the outside, that's pretty lame.

And now this problem, did I mention pfsense working before with a bunch of cisco ip routing behind it and it did work, did the version change in the mean while? What happened, it did work in the past with the same config you know
Poor lord, this pfsense thing is harder than cisco IOS, how can that ever be?

You know, I really really appreciate your time solving this problem but I am pulling my hair out at this moment ,reallly.

I have a great idea, let's combine pfsense and OPNsense together, pfsense for openVPN roadwarrior but I doesn't offer more than that obviously and use OPNsense for firewalling internal windows server machines. The servers have their protection with OPsense, and pfsense to access the network from outside, period. So everybody is happy.

Lets test OPNsense, see if it has the same anomaly under the same network conditions, if it doesn't, me and the CEO of Netgate gonna have some serious words!

I would like to hear more possible solutions, thank you so much for your time,

IrixOS

@johnpoz I think we are iiiiiiiiiiiiiiiiiiiiiiiiiiin yipppieeeeeeee

bmeeks

@IrixOS said in Windows Clients cannot access the internet, very strange unexpected DNS problem.:

Dit you remember the thread about the lagg0 port, you said something about choose an other free port, well I configured the lagg0 port with a vpn tunnel on the wan,

No, I don't recall a thread about a lagg0 port, but I get involved in quite a few conversations on here and tend to get them confused sometimes .

I would do this on the Windows client --

Configure the DNS server to be 8.8.8.8 in the TCP/IP settings in Windows. That will take pfSense completely out of the picture for DNS.
Now try to ping something by name (www.bing.com or google.com, for instance). Does that work? If yes, then you know the client has Internet access and you can concentrate on why DNS on pfSense is failing or not working.
If steps #1 and #2 fail, then try a simple ping to 8.8.8.8 from the Windows client. That drops DNS out of the loop and directly tries to ping the Google DNS server. If that fails, then you still have a basic connectivity problem you need to work out.

IrixOS

@johnpoz Poor lord , it didn't expect it to work, yes indeed it became a square after the reboot of windows and pfsense.
I thinkt it was the NAT rule and changed it to automatic like you mentioned.