Routing between virtual systems

[PThomas]

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?

[reaper]

Hi Thomas

if you set up multiple vsys you have also set up multiple virtual routers, the way to route between virtual routers is to have the traffic pass externally (we don't currently support internal routing between virtual routers)

this can be accomplished by using an external router or by connecting 2 interfaces to each other via cable/switch and have the VR route to each other via that path

regards

Tom

[PThomas]

What is the external Zone configuration for then?

There is a whole paragraph on communicating among Virtual Systems as an internal traffic flow in the admin guide.......

Communications Among Virtual Systems
The virtual systems in the firewall are treated as separate entities. To support internal traffic flows between virtual systems, you must indicate which virtual systems are able to communicate with each other. You do so when configuring a virtual system by specifying the other virtual systems that are visible to it. Then when creating a zone, you can select the “external” type and specify the virtual systems to include in the zone. Refer to “Defining Security Zones” on page 97.
Each virtual system must have policies for sending and receiving traffic. For example, allowing Dept 1 VSYS to communicate with Dept 2 VSYS requires a policy in Dept 1 VSYS to allow traffic to go to Dept 2 VSYS and a policy in Dept 2 VSYS to accept incoming traffic from Dept 1 VSYS.

[reaper]

Hi Paul

This is also an option, this can be accomplished by sharing the virtual router

to do this, both vsys need to be configured so they are attached to some interfaces and these interfaces need to be connected to one VR

(in this scenario the VR field in the vsys config will state "none" while the VR in the network tab will hold the interfaces)

then you can move on by creating the external zones and creating policies on both vsys to and from these zones

the key to this scenario is using only one VR to do all the routing and have external zones in each VSYS' policy to allow traffic

regards

Tom

[ncampagna]

Hi Paul,

There are a few parts to this configuration.  One key point is that you must configure the interfaces to be in a single virtual router.  Next you have to make the virtual systems visible to each other.  Finally you have to create special zones to allow this traffic to flow.

VSYS Configuration

1. Navigate to Device Tab > Virtual Systems and create your two Virtual Systems (VSYS1 and VSYS 2).

2. When the virtual systems have been created, add VSYS2 to the "Visible Virtual Systems" list on VSYS1.  Repeat to add VSYS1 as a visible virtual system in VSYS2.

Zone configuration

1. Create a new zone in VSYS1 of type "External" and select VSYS2 in the Virtual System box.  Call it vsys2_ext_zone.

2. Create a new zone in VSYS2 of type "External" and select VSYS1 in the Virtual System box.  Call it vsys1_ext_zone.

For traffic moving from VSYS1 into VSYS2, a security rules is required in EACH VSYS:

In your VSYS1 security policy, you will have to create a rule from the source zone in VSYS1 to the external zone called vsys2_ext_zone.

In your VSYS2 security policy, you will have to create a rule from the external zone representing VSYS1 (vsys1_ext_zone) to the destination zone in VSYS2.

For traffic moving from VSYS2 into VSYS1, a security rules is required in EACH VSYS:

In your VSYS2 security policy, you will have to create a rule from the source zone in VSYS2 to the external zone called vsys1_ext_zone.

In your VSYS1 security policy, you will have to create a rule from the external zone representing VSYS2 (vsys2_ext_zone) to the destination zone in VSYS1.

Best regards,

Nick Campagna

[ncampagna]

Hi Paul,

For a more in-depth explanation of virtual systems and communications between them, please see this tech note on our public website:

http://www.paloaltonetworks.com/literature/techbriefs/Virtual_Systems.pdf

Best Regards,

Nick

[Mack]

Hi Nick,

I read the linked VSYS document and one of the statements that kept popping up is "Note that vsys’ that want to participate in inter-vsys communication need to belong to the same virtual router."  This might be a problem for me.

I have a scenario where I want to put the Internet gateway interface in its own VSYS with a vrouter so that an outside ISP can manage the vrouter BGP instance on the PAN device, and the customer manages everything else (including internal routing) via another VSYS.  The goal is obviously to prevent the ISP from seeing any details of the internal network/security configuration while letting them manage BGP.

I know that I can solve the inter-vrouter/inter-vsys problem by looping out one physical port and into another, but (imo) that's a waste of the limited number of ports on the PANs.  Is there another way I can engineer this?

[ncampagna]

Hi,

If you're main concern is ISP visibility into the inner workings of your firewall, you could simply create a special admin role for that ISP user.  In the screenshot below, I created an admin role that could be used to restrict visibility in the UI to the virtual router only.  You could then create the ISP admin account using this admin role.  Please let me know if your concerns aren't addressed here and we can explore other options.

Thanks,

Nick

[PThomas]

Nick,

Version 4 now allows you to configure statics routes that you can nominate a Virtual Router (VR) as the next hop!!!

This new 4.x function allowed me remove the physical cable that join the VRs is seperate Virtual System (VS) and move back to just virtual routers in a single VS.

My real base requirement is for multiple VRs to handle multiple Internet connections (8 in total). Internal networks with their own ISP link but then they decided they want to share each others printers so the ffirewall needed to allow comms between them.

The reason for employing VSs in the first place was because I found the policy engin could not track the connection propoerly (looping back through the physical cable to join VRs) unless I placed the virtual routers in different VSs. That is to say connecting virtual routers together using a physical cable did not work if the VRs were in the same VS. Put them in different VMs and everything worked fine.

I have succesfully used the new static routing to route directly between VRs in the same VS.

What you'll need to test is if you can successfully use statics to route directly to a VR in a different VS.

I know the routing will work. It's the policy that concerns me. You need to set up an external zone but there is no interface to associate it with (the static route is a bit of an auto-magic thing). Maybe you can try setting the zone to "Any".

I'd like to know the result if you do test this. It is on my to do list.

[Mack]

Hi Nick,

Using a special admin role is a good suggestion, I'd thought about   it earlier, I although  hadn't explored it enough to realize that I   could restrict the ISP to  just vrouter access.  However, I've had some   ISPs in the past refuse to be helpful  unless they have complete access (especially   CLI) which is why I think a  vsys would be a good way to go.

My understanding is that with  a vsys, I can  basically say, "Here, this is yours, you can do whatever  you need to  do," and I don't have to worry about information leakage.   Also, if they  mess with routes and break something, all they've have  done is break  Internet access, our internal network should continue to  work.

I  am a little unsure too on the relationship of  vrouters to vsys.  It  seems that it's possible to have a single vrouter  that is used in  multiple vsystems, and that it's also possible to have  a vsys that  contains multiple vrouters.  Is there a best-practice for  this?  One of PThomas' posts suggests that perhaps some configurations don't work as well as others.

[ncampagna]

Our virtual systems and virtual routers are built in a very flexible way so that we can service a number of different multi-tenant use cases.  In some cases, tenants use overlapping IP space (and therefore need independent VRs) while in others they use unique IP space and the management overhead is significantly reduced by using a single virtual router.  Can you explain in a bit more depth what you'd like to hide from the ISP personnel?  That would help drive us towards the best possible design.

Thank you,

Nick

[ncampagna]

Hi PThomas,

PThomas wrote:
I know the routing will work. It's the policy that concerns me. You need to set up an external zone but there is no interface to associate it with (the static route is a bit of an auto-magic thing). Maybe you can try setting the zone to "Any".

Regarding your question here.  The firewall will see one session in the source VSYS with an ingress zone of your ingress interface and an egress zone that is the external zone representing the destination VSYS.  The firewall will see an additional session on the destination VSYS with an ingress zone that is the external zone representing the source VSYS and a destination zone that is the egress interface on the firewall.  Try to think of the virtual systems and virtual routers separately.  The virtual router will move the packets where they need to go while the virtual system serves as the gate keeper for any boundaries that the virtual router causes the packet to cross.

Thanks,

Nick

[Mack]

Hi Nick,

Basically, I want it the same as if they had dropped a two-armed router on the edge of our premises.  I want to be able to let them in to manage the vrouter/BGP, the untrust and trust interfaces (obviously trust might be a virtual interface of some sort), various settings like multicast, etc...

[ncampagna]

The difficulty here is that you're looking for an admin that has access to both the UI and the CLI with a set of restrictions.  Today we can easily limit access in the UI based on the page where they should have permissions, but we can't limit access to the objects on that page if they're not part of a virtual system.  Since virtual routers are not contained in a virtual system, you cannot limit the list of virtual routers they have access to. 

We don't have granular role-based access permissions in the CLI.  You could give the admin read-only access to the CLI but they would still be able to see everything configured in the virtual systems.  It seems that for this case you won't be able to fully restrict the ISP admin to a particular virtual router. 

Thanks,

Nick

[Mack]

ncampagna wrote:
...
Since virtual routers are not contained in a virtual system, you cannot limit the list of virtual routers they have access to.  

Thanks for your responses, Nick.  You've clarified what I can and can't do with the ISP at this point.  The point that vrouters are not contained in a vsys seems to be the key architecturally.  I appreciate the information!

I'd asked earlier if there was a best-practices document for vrouter vs vsys deployment.  I've found a good vsys document, but nothing on vrouters, or on how to combine them in creative ways.