migrating ASA to Palo alto with inline deployment

[Bkrishnamoorthy]

We are planning to migrate firewall from ASA to Palo Alto . Instead of performing hot cutover  , we will install the Palo Alto firewall in-line along with existing ASA firewall using virtual wire interface type. Since we have many security zones on ASA  and there are policies to allow access between zones, where can i place the new firewall and  between on which ports  virtual wire should be configured. You can refer the below diagram and we need to monitor the policies configured to allow access between zones, as well polices to internet from every security zone on ASA firewall.

I read the documentation that outside interface IP can't be used for PAT for internet access  if those interfaces are virtual wire type. so need your suggestion on that, please advise. 

[BPry]

@Bkrishnamoorthy,

Think of vwire deployments as a bump in the wire. You would vwire interfaces setup for each connection coming into and out of the ASA. So from your example you would have a vwire connection setup between the DMZ->ASA, the CORE->ASA, PROXY->ASA, and then ASA->External. This would break down something like this:

* DMZ-PAN-ASA

* CORE-PAN-ASA

* PROXY-PAN-ASA

* ASA-PAN-External

The vwire will be configured within the same zone, so you'll have the benefit that all of your traffic will hit the intrazone-default policy and be allowed. Override the logging on the intrazone-default policy to log the traffic so that you have exactly what the PAN will be seeing once it's been deployed fully and use that to start building out your security rulebase so come cutover you can account for all of the traffic.

While running in a vwire deployment you can still setup NAT policies if you wanted to have the firewall NAT the external traffic if you want. The differences for vwire deployments are primarily that you can't NAT to an interface address (your vwire interface won't have one) and it won't proxy ARP for NAT addresses. You would need to ensure that upstream and downstream routing is configured properly if you were going to NAT on a vwire.

Personally I wouldn't perform NAT on a vwire interface. I primarily focus on building out and identifying the traffic flows and the rules that I'll need going forward. While that process is on-going I want the PAN to be as invisible as possible so that I'm effectively just a bump in the line collecting logs and building out security policies. 

[Bkrishnamoorthy]

@BPry  Thanks for your response, i don't have much exposure to Palo Alto firewalls, you mentioned "Override the logging on the intrazone-default policy to log the traffic " , could you elaborate more on how to do it.

I believe you referring the procedure mentioned in the link https://docs.paloaltonetworks.com/best-practices/9-1/data-center-best-practices/data-center-best-pra...

[BPry]

@Bkrishnamoorthy,

Correct. You'll want those logs so that you can view the traffic flows to build out what you'll need from a security standpoint. 

[Bkrishnamoorthy]

@BPry  But how to ensure NAT will work as expected without configuring it , and if we just logs the traffic and tune security polices as you suggest above. 

[Bkrishnamoorthy]

@BPry  Another question, please refer the below diagram where i have just mentioned a virtual wire only between ASA firewall and internet router for this specific case. Since both of PA interfaces are using same security zone due to virtual wire so it will allow by default, but since we want to log the traffic from DMZ to internet, do i need to create a specific rule from source zones as DMZ and destination zone outside? 

[BPry]

@Bkrishnamoorthy,

You need to determine what device you want to perform NAT while you're doing an inline deployment like this. You can keep it on the ASA and bring the NAT policies over once you fully cutover to the PAN, or you can cutover NAT responsibility to the PAN while you're running with a vwire deployment.

I personally wouldn't put the NAT policies on the PAN while doing a vwire deployment before the full cutover. That would be setup when you do the hard cutover solely over to the PAN and move the interfaces out of vwire and into layer2/layer3 connections. 

[BPry]

@Bkrishnamoorthy,

Hold up a minute on that diagram. If you plan on doing the vwire deployment like that you'll only see the traffic leaving the outside interface on the ASA and from the internet to the outside interface on the ASA. What do you have performing NAT, the ASA or the router? 

If you have the ASA performing NAT you'd want to move it to the PAN when you do the migration so you can get the proper source address without having to cross compare two logging sources to build out the security rulebase. I've found that it's generally easier to wait to put the NAT on the PAN until you do the hard cutover personally, and that waiting generally introduces less errors at that time.

In the current design you'll lose visibility of traffic traversing your current ASA security zones, so any traffic from your DMZ going to the CORE or PROXY connections as an example wouldn't be recorded in the current diagram. 

If you create a vwire for each security zone you'll get full visibility into the traffic flows, which is likely what you want to be working with. When you create the vwire you can decide to have the interfaces in the same zone and allowing the intrazone-default policy to allow all of the traffic traversing the vwire automatically or you can put the vwire interfaces into a different zone. 

If you put the vwire interfaces into a different zone, you'll need to create a security rulebase that actually allows the traffic or interzone-default will take effect and deny all of the traffic. The one reason that I don't personally tend to deploy a vwire into two different zones is because the networks that I deal with generally don't map the zones exactly. So for example if you put interface 1 in a DMZ security zone in the DMZ vwire deployment and put the interface 2 into a zone called internet as an example, any traffic that may traverse from your DMZ into the CORE switch or PROXY switch wouldn't have a proper zone mapping.

What I'll generally do is keep the vwires into the same zone (so your DMZ vwire in DMZ, CORE vwire into CORE, and so on and so forth) and simply use the logs to build out the final configuration for the cutover. I tend to use non-final zone names in the vwire setup (so maybe the DMZ vwire zone is DMZ-vwire instead of just DMZ) so that as I build out the security rulebase as I see the traffic I can include the final zone names so that cutover is as seamless as possible.

Hopefully that makes sense; obviously there's a lot of different ways to do things and part of the buildout will be personal preference. Obviously I like my way of doing things the most, otherwise I would do integrations separately, but there's a lot of ways to accomplish the same thing. 

If you have a simple setup where you don't have any cross-zone communication how you've diagramed a vwire deployment would work perfectly fine since it would capture all of the traffic you're controlling. I've generally found you'll have at least some cross-zone communication in most environments. 

[Bkrishnamoorthy]

@BPry I got it, i will focus on only to set up vwire for now, and then configure NAT on PA during cutover. Please refer the below diagram, i have depicted vwire for each zone with different firewalls for simplicity even though they are same box. Since i would configure vwire using same security zone within the intranet-zone and overwriting  default intranet policy will provide that option to see the logs, but will those logs show the traffic between zones. Do i need to create specific security policy or will intranet default policy itself provide those log details to confirm the security policy is allowed or not. for example if i want to check access from Core switch to Proxy switch is allowed or not.

If i want to create specific policy , what would be the source and destination zone i have to use.