Using ISA for OWA

[TDC]

Hi All

I'm looking to replace our Fortigate 110c with a new PA-500 and I've managed to write the security and NAT policies which when tested seemed to work well apart from OWA.

We have an ISA 2006 server which publishes OWA and OMA on a public IP and have configured the NAT rule and security rule as I did for all the other sites (like Citrix etc) which work fine.

The NAT rule looks like:-

Source Zone:- DMZ

Destination Zone:- Internet

Source Address:- ISA_Server

Destination Address:- Any

Service:- service-https

Source Transalation:-     static-ip

                                       NAT_ISA_Server_Public

                                       bi-directional: yes

The associated security rule basicaly allows all https traffic to NAT_ISA_Server_Public from the Internet and I log at session start and end. This is basicaly the same as the Fortigate config.

When I try and connect to OWA I get a timeout. I jumped on the logs to see whats happening and saw that the NAT rule seemed to be working. I then checked the ISA firewall logs and was seeing connections being dropped for packet spoofing. So why would the packets forward by the PA-500 be seen by ISA as being spoofed when the packets forwarded by the Fortigate aren't? Putting the Fortigate back in place and OWA started working fine again.

I'm desparate to get rid of the Fortigate and get the PA-500 working in production (something I'm going to have to do on Tuesday 18th). So I guess my questions are:-

1. Can anyone see what I've done wrong in the config of the PA-500 that stops ISA from working?
2. Should I be using ISA? Can I just forward directly to Exchange? If so what are the best practices for doing this securely?

Any help or advise on OWA/OMA publishing would be appreciated.

Cheers

Alan

[mikand]

I assume you have your ISA on a dedicated DMZ.

Does this DMZ use the public ip-range or does it use a RFC1918 range (what is the ip address of the ISA box itself)?

When you setup security rules in PA for NATed traffic the guideline is:

srczone: <prenat srczone>

dstzone: <postnat dstzone>

dstip: <prenat dstip>

So given that you use RFC1918 addresses in your DMZ you will setup a DNAT rule such as:

srczone: outside

dstzone: outside

dstint: any

src: any

dst: <ip of your PA at outside zone>

service: TCP443 (or the list of ports you need to get translated for inbound connections)

srctrans:

dsttrans: <ip of your ISA>

and security rule like:

srczone: outside

dstzone: dmz

dstip: <ip of your PA at outside zone>

service: TCP443 (or a list of ports or application-default, I recommend to never use any)

appid: ssl (or which appids you need)

Personally I would avoid using "bidirectional" and instead manually setup DNAT and SNAT when I need (and limit to specific ports if possible). In your case are you sure your ISA needs to be able to on its own connect to Internet (or whatever you have on your outside)?

1) See above 😉

2) Im not sure how much ISA is involved in the OWA/OMA stuff. I think ISA is capable of do a first certificate verification which the Exchange doesnt do but that could have been changed (Microsoft seems to change this behaviour for every release).

Edit: Since most traffic for OWA/OMA is https-based I would strongly recommend you to use ssl termination in the PA in order to be able to inspect the content of the ssl sessions (and using the PA IPS, AV, FILE and such features).

[TDC]

First off, many thanks for your detailed reply - really appreciate it.

Yes I'm using a private addresses in the DMZ.

Thanks for the advice on using "bidirectional". The reason I set it up like this was because I'd got a NAT rule working for Citrix and decided to copy it and modify it to remove any NATting issues (it was 2am in the morning and wanted to remove any chance of config error). Taking your advise, I'll be changing the bidirectional rules to DNAT ones as in most cases the server doesn't initiate traffic to the Internet - ironicaly I've configured our email using DNAT and SNAT based rules rather than bidirectional.

I've now created the ISA DNAT rule and when I was checking the security rule noticed that the destination zone was set to LAN and not DMZ. I changed both the NAT and security rule so many times during the night that I don't know if this error was there at the start or end.

Anyway the config looks good now but I can't test it until tomorrow night when I can take the network down again. I'll update this post with the results.

Edit: Since most traffic for OWA/OMA is https-based I would strongly recommend you to use ssl termination in the PA in order to be able to inspect the content of the ssl sessions (and using the PA IPS, AV, FILE and such features).

I'm going to start looking into this now (thanks for the suggestion) as I really want to remove ISA from our network and save the cost of the license.

Cheers

Alan

[TDC · Accepted solution]

Hi

Got it working. I analysed a working session in ISA and noted that when the Fortigate unit was in place the source IP (according to ISA's logs) was that of the firewalls DMZ interface (in this case 192.168.20.1) and not the original source IP (obviously a public address).

I therefore concluded that the fortigate was somehow NATting the source address as well as the destination. Modifying my DNAT rule to include translating the source (dynamic-ip-and-port) to that of the DMZ interface caused ISA to work as before. I guess thats why ISA was dropping everything as being spoofed, it wasn't expecting to see the original source IP on a network of 192.168.20.0/24.

Anyway, a big thanks to Mikeand for his help and suggestions.

Cheers

Alan