[j-nsp] SSG or J-series for virtual firewalling services?

[Ben Dale]

Hi Mike,

On 22/09/2010, at 5:13 AM, TCIS List Acct wrote:

> The J-series specs (which run JunOS) did seem to list a specific # of VRs, not sure if that is a license limit or just a "capacity" type of rating.  This PDF is quite handy for specs like that:
> 
> http://www.juniper.net/us/en/local/pdf/datasheets/1000265-en.pdf
> 
> For instance, it lists the J-6350 as having 30 VRs.

My experience with the JUNOS data sheet numbers is that they are the maximum "supported" from a JTAC perspective, however the box will continue to take configuration until it runs out of memory.  I just had a quick look back through the j-nsp archives for an old post of mine, where in JUNOS 8.4 I wrote a script that built 300 VRs (which was an arbitrary number) for a customer trying to do almost exactly what you are doing.  There certainly is no licensing on the J-Series (or SRX) for the number of VRs.

> It isn't clear from your answer if if I can have 192.168.1.x exist as a remote network for multiple customers (each with their own VR).. can you clarify?

>From a routing perspective, yes - all VRs are logically separate routing domains, so you can have overlapping prefixes without any issues.  Similarly, your firewall rules will be applied to zones which contain interfaces, which are placed in these VRs, so different zones can have overlapping address objects and your rulesets will all work as expected.  

Where things become difficult is when you have multiple customers in their own zones/VRs and you want them to egress through a single zone/interface - if anyone out there has a solution (elegant or otherwise) for this scenario, I'd love to hear about it.

In the next week or so, I've got some IPSEC work that needs to be done for a customer who would like tunnels split between VRs as well, so I'll come back with my findings there.


> Ben Dale wrote:
>> Hi Mike,
>> In ScreenOS you can achieve all of your requirements using VSYS, however you will find this is a fairly expensive road to go down with large numbers of clients (VSYS are licensed).
>> In JunOS you should be able to meet all of your requirements without any licensing issues - VRs are "free" and will do most of the same functionality. The only limitation is IPSEC tunnelling from within a VR which is currently in a state of flux (currently the interface the IKE gateway is bound to has to live in the global routing table), but I imagine this will be fixed in time.
>> Cheers,
>> Ben
>> On 21/09/2010, at 5:02 AM, TCIS List Acct wrote:
>>> We are looking to provide "virtual firewalling/VPN" services to customers hosted in our VMware and Hyper-V hosting environments (trying to avoid dedicating a physical NIC port for each customer on the host and hanging a firewall appliance off of each).  In a nutshell, each customer gets their own VLAN subinterface (which will cascade all the way down into their virtual machine), and we can define unique firewall rules (as well as establish IPSec VPN tunnels) on a per-customer basis.
>>> 
>>> I'm looking at the following platforms:
>>> 
>>> SSG-500 (ScreenOS)
>>> Juniper J-series (JunOS)
>>> 
>>> It is not clear if I simply need the VR (virtual router) or VSYS (virtual system) feature(s) to do this -- I need a unique routing table, a unique set of firewall rules/zones, and the ability to define VPN tunnels even if there are overlapping VPN endpoint networks among multiple customers (e.g. both Customer "A" and Customer "B" use 192.168.1.x on their side).
>>> 
>>> Any insight would be much appreciated.
>>> 
>>> --Mike
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
> 
> -- 
> 
> -----------------------------------------
> Mike Bacher / listacct at tulsaconnect.com
> TCIS - TulsaConnect Internet Services
> http://www.tulsaconnect.com
> -----------------------------------------
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>