Certificate Error when accessing email on optional Interface
-
Hi Guys,
I have a strange problem with a firewall I have deployed.
It has 1 WAN and 3 LANs
LANs are as Follows:
LAN - 10.0.0.0/16
DMZ - 192.168.1.0/24 (OPT1)
WIFI - 172.16.0.1/16 (OPT2)When users are connected to the LAN, they have no issues and can get to internet and email fine.
When connected to the Wifi interface they are able to browse the internet but cannot get to their email (Exchange 2010 on site), in the case of iphones it will not provide an error and does not download any new email. With the laptops/PCs using outlook they are getting a certificate error.
Strangely the certificate lists the correct autodiscover domain but reports that it is issued by pfsense, it matches the webconfigurator SSL cert.
I have checked the rules on the wifi interface and they seem correct to me.
(Please ignore the 2nd allowed rule, that was due to some faulty thinking, I realise it is using autodiscover not internal IPs.)
Is there some kind of SSL redirect or capture that happens for optional interfaces? Any help would be appreciated, I'm left scratching my head.
If you guys need more info or if I have left something out please let me know.
Thanks!
-
Your DNS records are broken, plain and simple. NAT reflection will never work around SRV records. Point LAN clients to where Exchange is running and NOT to your WAN. (You could also move your pfSense webGUI out of 443, that won't make your DNS any less broken though.)
-
/16 on your WAN?? How does that make sense.. Same goes for your 172.16 with /16
Do you have that many machines on the same network?
Client internally should not nat reflect to get to your servers.. This is a HACK at best.. As dok already stated fix your dns to point to the local rfc1918 space your servers are on for machines that are also on this rfc1918 networks..
-
Your DNS records are broken, plain and simple. NAT reflection will never work around SRV records. Point LAN clients to where Exchange is running and NOT to your WAN. (You could also move your pfSense webGUI out of 443, that won't make your DNS any less broken though.)
Of course! that makes much more sense, I'll set my DNS record to direct to the LAN IP of exchange.
Thanks
-
I have checked the rules on the wifi interface and they seem correct to me.
Besides rule 2, you can also ignore rule 3 and 4 right now.
Rule "1" will be valid for ALL TCP connection - rule 2 is just a subset of 1.
If you want to have rule 3 and 4 working for you, put them on position 1 and 2. -
Yes. ^
Rule #2 should probably be moved to the top. Rules 3 and 4 should probably be below that. And what you have as rule #1 should probably be last. And protocol TCP should probably be changed to protocol any in #3 and #4.
The general scheme for guest networks is:
Pass specifically the local assets you want guests to be able to access (DNS, Exchange, Email, etc)
Block less-specifically the local assets you don't want them to access (LAN net, This firewall, etc)
Pass everything else (The internet)https://doc.pfsense.org/index.php/Firewall_Rule_Basics
https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
-
Rule 2 should be moved to the bin.. What point is it if you already allow wifi net to go anywhere.. Is that address on a different segment than wifi net? If on same as wifi net also pointless.
As to 3 and 4 they could be removed by making 1st rule a ! alias that includes your other networks.
