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.
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.
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...
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.
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.
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.
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.
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.
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?
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!