NS204 in Hosting Enviorment - Vlan/Subinterfacing

  • Hi All,

    I have a NS-204 that i would like to setup for my managed hosting customers. Each customer has their own subnet (public routeable ips) and vlan.

    I would like to setup about 5 customers behind the firewall, each with their own set of policies, vpn, etc. They should each have their own internal subnet also.

    I would like some insight on how to set this up. I am assuming i would subinterface my untrust interface and assign each subif a vlan, and do the same on my trust if.



  • Sure, source-nat. If you have a policy that says: Server-zone -> Untrust HTTP/HTTPS. Just Edit the rule, hit advanced and tick source-nat with the egress interface IP. That should do the trick.


  • I have it all configured and everything appears to be working. I have one LAST question.

    I used a /26 for the e3 interface and for the e1 interfaces, i am doing… --> customer 1 --> zone "customer name" --> customer 2 --> zone “customer name”

    The only issue i have it the servers cannot get out to the internet unless is use a MIP and bind a external ip to a internal. This is fine, but not every server needs its own external ip. Is there a way to have every ip except those i map a MIP to use the e3 interface ip?

  • In my post further up there was two networks, one small network between the ISP router and the firewall, (this could have been anything really, a /27, /28, /30 net). Then you had a route for the /24 network pointing at your untrust IP on the Netscreen/SSG. Now, in your configuration the small sevice net between the ISP router and Firewall isn’t needed. You only need a route saying that the /24 network exists behind the ISP router at your location. Your firewall will answer on all IP’s in the /24 range (if you create the MIPS, VIPs). This means your untrust interface should have a /24 mask.

    On your trust interface create any sub-interfaces you want. Create any custom zones you want and bind them to any sub-interface you want.


  • Makes perfect sense…

    Now what would be the proper way of doing this?

    Would i put a /30 on the interface and route the /24 to it? Then i can just add MIP addresses from the /24?

    Then on my trust interface, i can create subinterfaces with their own vlan and zone? Because i still have to keep the customers seperate.

  • Brendan,

    If you aren’t going to route any public IPs behind your firewall, then don’t split up the /24 network. Just create the MIPs/VIPs for your customers. This way you have the ability to give a customer 25 MIPs if you want and only 3 to the next one. Make any sense?

    This way the configuration is simple, clean and versatile.


  • Hi, thanks for your continued patience…

    Your latest example makes sense, but that forces me to use external ips for each piece of equipment the customer has. A routeable ip is not always needed. So i just preferred if the internal interfaces where private ips. This is why i am trying to split the external interface. Maybe this is not the way.

    So if each customer should get a /29 of routeable ips externally, then i will assign each piece of equipment a internal ip and use VIP/MIP for the devices that need external access.

    Does this make sense to do?


  • First off, yes you can split the netwok the way you mentioned in your post. This would give you 32 subnets holding 6 hosts each.

    But… and here is my concern. You have focused a great deal on spliting up the untrust interface with different subnets, why?

    In my example I routed the /24 network behind my firewall! Example:

    ISP Router                                                    NS Firewall
    IP: ---------------------------- Untrust IP: (eth3)
    Route config:                                                Cutomer1 IP: (eth1.1) gw                        Cutomer2 IP: (eth1.2)

    As you see in my post the customers network exists on some other physical interface behind the netscreen. The net is routed too the Netcreen untrust IP. Then the Netscreen breaks up/divides the network in smaller subnets. In general its good leaving the untrust interface alone. Else you will get NAT problems.


  • Hi, thank you for your replys, they have helped.

    Now i would like to have the customer behind the firewall using private ips, like you mentioned. So if i route a /24 to the e3 on the firewall, and i break it up into /29 subnets for each customer, do i subinterface like this…

    customer1 = e3.1 - first /29
    customer2 = e3.2 - second /29
    customer3 = e3.3 - third /29

    and so forth…?

  • When creating sub-interfaces on a physical port you only need to configure your switch with those VLANs on the port the firewall is connected. Just tag the VLANs on the port and you’ll be off and running.

    No, subnets have nothing to do with interfaces (physical or logical).

    You can put the subinterfaces in their own zone if you want. Or you could use one zone and maybe use intra-zone block. As mentioned before, you have several options.


  • How do i make the e3 (untrust) and e1 (trust) ports on the firewall be a 802.1Q trunk port for my VLAN aware switches on either side of it?

    Or by subnetting the interfaces, will this happen automatically?

    And i should put each sub-interface into its own zone since each subif will represent a single customer?


  • Lets say you have the following public IP-range at your disposal routed from your ISP too your firewalls public (untrust) interface that has the following IP: ->

    This means the entire net resides somewhere behind your firewall. Now it’s possible to split this net in smaller pieces (subnets). Lets say you split up the net the following way:

    Sub-interface: eth1.1 zone: Customer1
    Sub-interface: eth1.2 zone: Customer2
    Sub-interface: eth1.3 zone: Customer3
    etc, etc

    All in all you would have 8 subnets that spans 30 IPs each. This could then be 8 customers in 8 different custom zones…

    Now, this was just one example. another way might be to have a range of public IPs that are not routed behind your firewall. This means customers have to use a private IP-address that needs to be NATed (MIP, VIP) before it can be reached publicly.

    …or maybe you have all your customers private networks in the trust zone on different VLANs but with intra-zone blocking turned on and then all the customers DMZs built the same way, each with a small chunk of public IPs.

    What I’m getting at is, there are several ways to solve your problem. You’ll have to try and figure out what suits you (and the customers) best.