05-05-2023 06:05 AM
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.
05-05-2023 06:22 AM
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:
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.
05-05-2023 06:44 AM - edited 05-05-2023 06:54 AM
@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...
05-05-2023 07:38 AM
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.
05-05-2023 07:54 AM
@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.
05-05-2023 08:32 AM
@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?
05-05-2023 08:49 AM
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.
05-05-2023 09:26 AM
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.
05-05-2023 10:48 AM
@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.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!