Routing between virtual systems

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Routing between virtual systems

Not applicable

I have multiple virtual systems configured. They are visible to each other. I have policies and external zones in both systems. How do I get the firewall to recognise the packet is going to another virtual system?

The documentation shows communication on a diagram with no share gateway. Is a shared gateway need to route traffic between virtual systems? If not how is it done?

30 REPLIES 30

Palo Alto Networks Guru

You're quite welcome.  I'm not sure if we have any material on virtual routers in the works... if you let me know what sort of information you'd like to see, we can better focus a new write-up on that feature.

Thanks,

Nick

Nick,

Virtual routers have come around again for another client. I just need to have clarified how two vsys can be on the same router. You said they should be viewed as two different things, and I understand that. How is that configured in the vsys config? You cannot add the same vrouter to two vsys. Does it matter that it is not listed in the the second vsys?

You don't need to assign a virtual router to the vsys. That simply makes it visible to the vsys. Virtual routers are configured at device level and interfaces are then assigned to the virtual router. The interfaces can then be assigned into different vsys' and will be able to pass traffic between each other once the appropriate external zones and security policy have been configured to allow traffic to flow.

Palo Alto Networks Guru

SCoupland stated it well. The VR assignment to a VSYS (done on the Virtual Systems page) is only used to provide a visual association between the VSYS and VR. The important link between a VSYS and a VR is on the interface configuration.

Thanks,

Nick

I was just wanting to make this absolutely clear... Are you saying that in the Virtual Systems setup page, adding the VRs does nothing? It is just there to give you a reference that the VSYS uses that VR. If you removed the VR from the VSYS setup page, it would not remove it from the VR in the VR setup, or have any other effect?

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.

Nick,

I configured 2 vsys with a single router and the world is good. A customer engineer then applied the corporate default zone protection profile to all zones including the external zone.

This caused commit errors with the following syntax,

"In VSYS vsys1 from Zone1 of type layer 3 and to zone External_Zone of type zone-protection-profile are incompatible in security rule......."

Logically I could understand maybe zone protection isn't supported on an external zone however it does allow you to configure one. There is no zone type "zone-protection-profile".

So is it supported but we have a bug or should it not be an option in an external zone configuration?

Thanks,

Paul

Palo Alto Networks Guru

Hello craymond,

If you set the virtual system on the VR page, or the VR on the VSYS page, those settings will affect each other. My point was just that this is a loose association. You can attach VR1 to VSYS1, and still bind VR1 to VSYS2 on all of the interfaces that reside in VR1. That means that the VR1 to VSYS1 binding essentially had no effect.

Hope this helps,

Nick

Palo Alto Networks Guru

Hi Paul,

We can only perform zone protection on the ingress interface. We're unable to do so on an external zone. Have you filed a case by any chance? Although I'm not sure about our options in this specific case, we generally prefer to perform checking at the time of configuration rather than at commit time.

Thanks,

Nick

Thanks Nick. I think that makes sense!

The inherent vice of capitalism is the unequal sharing of blessings; the inherent virtue of socialism is the equal sharing of miseries.

Hi Paul,

I've got the same problem after creating an policy between two vsyses.

First I configured the visibility between the two vsyses and after that i've created two ext_zones

vsys9 => VSYS24_ext_zone

vsys24 => VSYS9_ext_zone

Policy:

src zone: VSYS24_ext_zone       dst zone: Trust    

Message after commit:

In VSYS vsys9 from zone VSYS24_ext_zone of type layer 3 and to zone Trust of type zone-protection-profile are incompatible in <policy-name>

Als in my case no protection-profile defined at the external zone.

Has anyone an idea what this could be?

Best Regards

Patrick

Palo Alto Networks Guru

Hi Patrick,

Could you please list out the types for each zone and the virtual system that contains each? The error message is a bit odd as there is no zone type called zone-protection-profile. It may just be a simple wording error so I'd like to see a bit more on the configuration before jumping to any conclusions.

Which version of PAN-OS are you running at the moment?

Thanks,

Nick

Also, one quick question. Are you running PAN OS 5.0.1 or 5.0.2? An XML ordering issue has been addressed in PAN OS 5.0.3 which could cause commit to fail with a similar message:

47133—Fixed a zone validation failure that occurred because the network zone was incorrectly recorded in the device configuration XML file.

The XML node for the zone expects the zone name to be of the form (in 5.0.1/5.0.2):

zone {

ZONE_NAME {

network {

layer3

If the XML equivalent for your zone "VSYS24_ext_zone" is generated differently, then the commit may fail.

Hello Nick,

I am running 4.1.9 in an Active/Active setup with panorama as management device for the policies.

Attached the requested information.

I have an workaround by configuring the zone as "any". But it would be nice if I can use the VSYSx_ext_zone.

By using the external zone works for me in other cases, but the strange thing that I can't use it within vsys9

Thanks.

Best Regards,

Patrick

Hi,

anyone an idea what my problem could be?

Palo Alto Networks Guru

Hi Patrick,

Sorry for the late response on this. I don't see anything wrong with your configuration. Could you please file a case with support so that we can take a closer look at the issue?

Thanks,

Nick

  • 23534 Views
  • 30 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!