Cannot access internal mail server after upgrade to iOS 14
-
For some reason after updating my iPhone from iOS 13 to iOS 14 I cannot access my (internal) mail server anymore. Nothing changed on the pfSense side but if I open up the mail server by dns name (mail.domain.com) I'm getting a DNS rebind attack from my pfSense interface, so it's actually connecting to my pfSense box. But when I do a DNS lookup on my iPhone I'm getting the correct (internal) IP of the mail server. I'm pretty lost here now...
Private MAC address (on the iPhone) has been disabled for the WiFi network.
For some reason when using the DNS name of my mail server (mail.domain.com) the iPhone is redirecting to the pfSense box.
If I create a rule "Block - port 443/https - this firewall" and put this on top of all rules the problem is gone.
Any help is appreciated. Been pulling hairs, there is not much hair left. ;-)
-
Any one have a clue what's going on?
-
@panja said in Cannot access internal mail server after upgrade to iOS 14:
when using the DNS name of my mail server (mail.domain.com) the iPhone is redirecting to the pfSense box.
and
@panja said in Cannot access internal mail server after upgrade to iOS 14:
do a DNS lookup on my iPhone I'm getting the correct (internal) IP of the mail server.
These tow operation are the same.
So, one of the two is 'false'.Which one ?
Btw: you did put up a host over ride on the Resolvers setting page, right ??
Your iPhone is using pfSense / the Resolver, right ? ( and not some mess-it-up-"8888" comparable ?) -
Thanks for the reply!
I wish my statements were false. That's the strange thing...
But let me explain it more clearly (I hope).If I go to Safari (browser) and put in
https://mail.domain.comit will go to my pfSense box web interface. Getting a DNS rebind error message (of course because the hostname is not correct for the pfSense box).If I use an app called
Net Analyzer, which can do all sorts of network related task (ping, dns lookups etc), and do a ping or A record lookup formail.domain.comI'm getting the correct internal IP address for my mail server (192.168.1.10).I'm using Pihole as my DNS server and using DNS overrides.
-
Sounds like your browser is using doh from what you have explained.
If your hitting your pfsense IP, assume wan when you using your browser.. But locally you resolve it correct to your local IP.. Yup sounds like your browser is using some dns, most likely via doh that you don't want to use when locally..
-
It's not only the browser.
Also the native email app is giving me a cert error (because it's getting the pfSense cert instead mail server). Tried a different browser as well, same problem. -
@panja said in Cannot access internal mail server after upgrade to iOS 14:
If I go to Safari (browser) and put in https://mail.domain.com it will go to my pfSense box web interface
So when Safari resolves 'mail.domain.com' it gets back your (probably) WAN IP. Tjis means its not using the DNS that has the over ride setup.
It should be setup up with a host over ride, so it returns "192.168.1.10".The domain 'mail.domain.com' is probably also set up on some public dns server (the one used for your domain name) : Safari winds up consulting that public name server, thus funding the WAN IP.
Check on your iPhone what DNS it's using (see below the wifi details).
-
It's using my internal (Pihole) DNS server.
There is only 1 DNS server configured in wifi settings.Also on the pfSense side I have setup a redirect (NAT) rule to only allow DNS (port 53) to the Pihole server.
-
Well here is the thing - if all your device are using your dns - that you say its pointing to the local IP of your mail server. Then how would it end up on pfsense IP??
Not POSSIBLE!!! Your not using your dns like you think your using..
It simple - mail.domain.tld resolves to 192.168.1.10 or it doesn't - what this has to do with pfsense, I have no idea..
Some app or software or device using doh - bypasses redirection.. Because it does it on 443..
The problem with doh - is these companies think they users are too stupid to use the dns they want. So since they are so much smarter than the user -- lets just use the dns we want the user to use - without even freaking asking them!!
That doh is a thing is some of the worse thing to ever happen to user privacy or security.. Yet they tell the users they are doing it for their own good - and their "security and privacy"... Its a LOAD of SHIT!!! They know it, everyone knows it that has 2 brain cells to rub together knows it.. But still it happens..
If your dns points something.domain.tld to 192.168.1.10 - then that is where it would go. So either your dns is not doing that.. Or your device is not using your dns..
I don't have a problem with these companies running a PR campaign to have users send them their dns.. But what I have a problem with is having to freaking go out of my way to make sure that some software or app or OS doesn't freaking do it anyway.. Even though I clearly point to the dns I want to use..
Which is why 853 is blocked (dot). And why I have a ever updating list of doh IPs and fqdn that are also blocked. And have to check my freaking browser that its NOT set to use doh..
dot would be fine to use, it runs on port 853... Easy Peasy to make sure its not use... But sneaking dns queries out standard ssl port is just WRONG!!! Hey if they want to use a.b.c.d for dns - android love to use 8.8.8.8 for example.. Sure ok you can try - but I can block that easy enough as well.. But the sneaky BS that is doh is just horrible horrible way forward..
An application shouldn't be able to use its own dns - its should use what my OS says to use..
Sorry but this doh nonsense is one of the things that blows my skirt up.. And I don't like the draft ;)
-
Your reply makes sense.
Probably there is some setting in iOS 14 that uses DOH because I'm blocking DOT (853) as well.That can be the only logical explanation.
Will dive in to this. -
For what it's worth : iOS 14 came out since the "iPhone 12" was launched, that was last year.
I've an iPhone and Pad : no DOH is used (maybe it does when you use this).
My iPhone uses the DNS server given to it by DHCP. In my case, that's my pfSense (192.168.1.1 or 2001:470:dead:beef:2:1)
I can see traces of the DNS traffic on my pfSense Resolver log (when I crank up the verbosity).Btw : I'm using also the captive portal of pfSense. If my iPhone was using DOH, this would totally break. Or, it works fine.
-
Thx GJ!
It seems to be a really odd problem with Pihole.
I just switched my iPhone to the DNS resolver of my pfSense box. Problem solved...Though the problem only seems to be with iOS 14 devices and my Pihole instance. Other devices (Android tablet, Windows and Linux laptops) don't seem to have this problem.
-
@panja said in Cannot access internal mail server after upgrade to iOS 14:
I just switched my iPhone to the DNS resolver of my pfSense box. Problem solved...
Your iPhone wasn't using DHCP (for the DNS) what was set statically ?
If you setup up parameters yourself parameters, and then forget about it, setup DNS server side options , but your device is using another DNS, then, yeah .... things go down hill fast.
That's why : what ever happens : never change the DHCP mode of a client device. If settings need to be changed, do it on the (centralized) DHCP server : tell that one what DNS to be given to client devices. -
My iPhone is using DHCP.
I have set DHCP reservations on the pfSense side.
I push DNS server through DHCP to the clients and have setup a NAT rule to redirect all DNS traffic which does not go to the Pihole to redirect to the Pihole.What I meant with the above post that I changed DNS (and removed the NAT redirect rule) as a test. To filter out where the problem relies.
