Guidance on swinging an Exchange 2016 On-Prem server from ASA to PA 820 (vWired currently)

[s.Konowalchuk]

Hello everyone, currently I've about 3 publicly available servers still running through an old ASA5510 that I would like to move to the PA 820 that we have. 2 of them will be easy as they're basically web servers but its the Exchange server that has me concerned. I'm looking for a guide or some assistance in helping pre-create the security policies and NAT rules to allow the traffic to flow. Is there any such guide out there?

I am running the ASA traffic through a vWire on the 820 so I can see all the traffic but again just looking at something to help me pre-configure most of this so as to minimize the downtime.

Thanks in adanvance!

[BPry · Accepted solution]

@s.Konowalchuk,

This changes depending on if you have a security gateway handing traffic prior to it reaching your Exchange servers, if you're just sending it directly to your Exchange server, and if you are going to decrypt traffic. If you're already running things in a virtual-wire deployment you should already see exactly how the firewall will identify the traffic via your existing traffic logs. 

If you're running a 2016 or higher Exchange server, you'll see the following App-IDs if you decrypt that inbound traffic. Obviously allow smtp as well if you don't terminate that on a security gateway. 

                    <member>activesync</member>
                    <member>mapi-over-http</member>
                    <member>ms-exchange</member>
                    <member>office365-enterprise-access</member>
                    <member>outlook-web</member>
                    <member>rpc-over-http</member>
                    <member>soap</member>
                    <member>ssl</member>
                    <member>web-browsing</member>

Your internal client communication will look slightly different and really depends on your own deployment. For example I won't see activesync internally because we don't have folks phones joined to our internal network, that might not be the case for you. You may also allow people to send email directly through an SMTP connection outside of Outlook to the server while I limit and control that traffic through additional individual rules. You'll also need to think about other devices in your network, such as printers, that use SMTP directly to the Exchange servers.

Additionally you'll need to allow SMTP traffic between your security gateway and your Exchange environment if you're using a security gateway.

While Exchange is a standard thing to deploy, each deployment isn't exactly the same so you'll run across some variations. Your existing virtual-wire deployment should be able to allow you to build out those rules looking at your logs. I would spend some time identifying traffic and building out rules while your still in the virtual-wire deployment to get your security rulebase built out. 

[s.Konowalchuk]

Thanks for that BPry, we're using a cloud hosted mail filter so most (if not all) of the SMTP traffic should be to/from those IPs. Some things you've given me to think about there particularly with the printers (which we have a few that we allow to relay out).

Did you ever stumble across any check lists or other tools that might help?

[BPry]

@s.Konowalchuk,

I've never seen any sort of checklist or anything like that, and it wouldn't really make any sense to have one. Everyone's environment is going to look slightly different depending on a number of factors, so it doesn't really make much sense to create something like that.

If you're in virtual-wire mode though you can already see ever bit of traffic flowing through though right. So what I would personally do it start building out your security rulebase from the logs from your intrazone-default rule and ensure you override that logging to log at session end. 

This will allow you to build out the security rulebase until the point that you don't have much/any traffic hitting that intrazone-default entry that you don't have a security rulebase entry setup for, or that you at least aren't already aware of. Then once everything is accounted for and you're getting ready to switch away from the old ASA completely, the only thing you have to do from a security rulebase aspect is update the security zones. Then all you need to worry about is routing and NAT rulebase entries during the cutover. 

[s.Konowalchuk]

@BPry 

I actually created a Zone and security policy for that vWire traffic so I've been using that to filter on to start working on a proper rulebase.

I put together this really high level "check list" for any of my public facing servers.

1. Create network object for internal server
2. Create network object for external IP
3. Create the security policy (leave disabled)
4. Create the NAT policy (leave disabled) 
5. Check to see if it requires a PBF rule 

Some things I'm still trying to sort out - once I pull the old ASA out and just run the traffic through the PA I'm going to have to update my default route on my core switch stack. At that point everything should default out the PA. When its time to cutover I'm thinking I'll just run the WAN connection from my ASA directly into "WAN" port (e1/11) on my  PA. Either that or have my ISP route all that traffic to my "new" public IP address space so that everything comes in on e1/1 in which case I don't have to worry about updating any security zones because all the traffic will be coming in from the same zone.?

Can you see any flaws here with my logic or think of anything maybe that I'm forgetting?