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?
Solved! Go to Solution.
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.
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
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.
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
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.
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.
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.
For a more in-depth explanation of virtual systems and communications between them, please see this tech note on our public website:
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?
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.
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.
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.
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!