[2.2.6] Another ActiveSync issue
-
Hi,
I have 2 pfSense 2.2.6 boxes with CARP addresses. I am having issues to get ActiveSync working through pfSense. OWA works fine. I use Microsofts 'reverse proxy', Web Application proxy together with ADFS. The WebApp proxy is in a DMZ network. When I give ADFS an additional nic with the public IP associated with the DNS everything works fine. OWA has actual pre-authentication through ADFS, for ActiveSync and Outlook Anywhere that's not supported and that has to be set to passthrough. For that reason I think Outlook Anywhere isn't working either but I've not confirmed that yet.What my intention was is to NAT port 443 (the only required port) from the pfSenses public ActiveSync IP to the WebAppProxy machine. As said for OWA that works fine, for ActiveSYnc it doesn't. I don't get any logs in pfSense at all for these rules, not even the 'passed' logs when I explicitely enable logging on those rules. I've tried to both enable and disable NAT reflection as I've read some posts on the forum mentioning that. Split DNS is at this moment not an option for us; in addition that won't solve our issue I think as unfortunately my internal domain name is different than the external one. If I split DNS I'd to route internal requests to keep internal, I'd get certiciate issues.
I am coming from TMG 2010, where I have to set a specific setting for ActiveSync and Outlook Anywhere:
'Requests appear to come from the Forefront TMG computer' HAS to be ticket. In my understanding that means that the TMG would terminate the connection and rebuild it towards Exchange (hence it's called 'proxy requests' I guess). I think there's the crux.
Can pfSense do that? I know I can setup Squid but I don't really need the reverse proxy-setup in pfSense as I have Microsofts WebAppProxy for that. If I still need Squid, is there a manual to do so for this setup, or a guideline? I've searched so many forums I'm a bit blindsighted now.
-
I've read your post about five times and still can't be sure what you're trying to do. Are you saying you can't get ActiveSync to work from remote clients coming in from the internet, or that it won't work coming in from the LAN side? Certificates will work with split DNS (I do it myself), even with internal domains that are different from the external domain. You just create a zone in your internal DNS server to match the external zone and duplicate the records.
A little clarification would help. A network diagram would help a lot.
-
Sorry, I mean from WAN side. I don't need ActiveSync from LAN as this is a hosted exchange service, and therefore no users reside in LAN. I'll put up a network diagram tomorrow, but for now:
internet –> pfsense WAN --> WebAppProxy in DMZ --> Exchange host in LAN.
Sorry if I wasn't clear, as said I'll put up a diagram.
-
Here is a overview with IP's masked. I'm a disaster with Visio by the way. I only kept the relevant servers in this view. It's al pretty straight-forward with basically just a WAN –> DMZ --> LAN. Nothing special.
So in DMZ I have the WebApp Proxy (WAP), which is Microsofts reverse proxy now. PFSense is configured to NAT the external ActiveSync/OWA IP TCP 443 to the WAP which is the only required port. WAP is configured to allow OWA (with preauthentication, works fine), Outlook Anywhere (untested as of yet) and ActiveSync. WAP proxies the request to the Exchange 2016 server. The traffic does get there, if I use a browser to connect to https://<wap external="">/Microsoft-Server-ActiveSync I get an XML response, of course with an error but at least it responds. Still I cannot get ActiveSync to work.
We only have external users. So no users are on LAN, only WAN. My internal domainname is unfortunately not available externally. Split DNS could still work but I'd have to reconfigure a lot as I'd have to have Exchange configured with the external certificate, while it's now configured with a certificate for it's internal name. I wonder if that all has to do anything with it though, as with a browser I can actually get as far as on the Exchange server. Owa works as well, so routing as well as firewall rules seem to be correct. To get OWA to work it needs some additional AD ports as WAP does preauthentication, but OWA itself is 443 only as well.
If you need any additional information, just shoot.</wap>
-
I'm not all that familiar with ActiveSync, but a certificate error could well be the problem. I would certainly make sure your certificate matches the external DNS name for the server. This really shouldn't be all that big a problem. Just set the hostname to match the name given in the certificate and create either a split-DNS arrangement internally or put in a DNS override for that host in your internal DNS configuration.
-
Thanks for the reply but certificates is not the issue here, at least not as far as I am concerned. I am publishing the exact same environment through TMG again now (which I am migrating to pfSense bit by bit) and it works perfectly fine there using the same certificates. So therefore I think this is an issue with pfSense, or at least with the way I configured it :)
-
You mention that OWA works fine. Since both WAP and OWA share 443, and only the URL makes the difference, then the problem lies not in the pfSense setup, but elsewhere.
-
Again, when I publish the exact same environment (ie. just port 443) through TMG, without making any change to the Exchange setup at all, it works fine. My external URL's are setup to match the certificate and as such I can use OWA, ActiveSync and OutlookAnywhere when I publish it through TMG. Therefore I believe it's not in certificates or URL's. OWA is published through WAP as well, for Exchange only WAP is accesible from the WAN. WAP proxies the request to Exchange when preauthentication is used and forward it when no preauthentication is used.
I'll fiddle around a bit and try to get some traffic captures. Thanks so far.
