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

TCIS List Acct listacct at tulsaconnect.com
Tue Sep 21 15:13:17 EDT 2010


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.

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?

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
-----------------------------------------


More information about the juniper-nsp mailing list