- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-10-2011 03:18 AM
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?
10-18-2011 01:04 PM
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
02-21-2013 03:36 PM
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?
02-21-2013 04:21 PM
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.
02-21-2013 04:30 PM
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
03-01-2013 08:21 AM
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?
03-11-2013 02:59 PM
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
03-11-2013 05:01 PM
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
03-11-2013 05:05 PM
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
03-12-2013 02:21 PM
Thanks Nick. I think that makes sense!
03-15-2013 05:02 AM
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
03-15-2013 08:24 AM
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
03-15-2013 08:31 AM
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.
03-15-2013 08:55 AM
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
03-26-2013 07:12 AM
Hi,
anyone an idea what my problem could be?
03-26-2013 07:23 AM
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
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!