Vlan – Should a server have it’s own VLAN

If I understand your topology correctly, you are using the SRX as a layer-2 device between your ISP router and the hosts in the branch (in place of the managed switch in the drawing).

In this case you will have to run the SRX in "Transparent Mode", in stead of the default "Routed Mode". This has a couple of caveats and limitations, so be sure to check the documentation first.

You have to do a couple of things to make this work.

First of all, get rid of all the "VLAN" configuration, and start using a bridge domain:

interfaces {
    ge-0/0/0 {
        uniy 0 {
            family bridge {
                interface-mode access;
                vlan-id 10;
            }
        }
    }
    ge-0/0/1 { ## and the same for all other ge- interfaces
        uniy 0 {
            family bridge {
                interface-mode access;
                vlan-id 10;
            }
        }
    }
    irb {
        unit 0 {
            family inet {
                address 10.20.30.99/24;
            }
        }
    }
}
bridge-domains {
    branch_vlan {
        domain-type bridge;
        vlan-id 10;
        routing-interface irb.0;
    }
}

Next, you must add interfaces to security zones. Normally I would recommend to put the "uplink" in a seperate zone, because that will make your policies much easier. I will assume that the uplink is in ge-0/0/0. If it really is impossible to predict in which port the uplink will be, you will have to put all interfaces in the same zone and figure it out with the policies.

security {
    zones {
        security-zone intranet {
            interfaces {
                ge-0/0/0.0;
            }
        }
        security-zone branch {
            interfaces {
                ge-0/0/1.0;
                ge-0/0/2.0;  ## etcetera for all other ge- interfaces
            }
        }
    }
}

Now you can set policies on traffic to and from the intranet

security {
    address-book {
        global {
            address allowed-subnet 10.0.10.0/24; ## just an example to illustrate the point
        }
    }
    policies {
        from-zone branch to-zone intranet {
            policy allow-some-traffic {
                match {
                    source-address any;
                    destination-address allowed-subnet;
                    application any;
                }
                then {
                    permit;

                }
            }
        }
        from-zone intranet to-zone branch {
            policy allow-some-traffic {
                match {
                    source-address allowed-subnet;
                    destination-address any;
                    application any;
                }
                then {
                    permit;

                }
            }
        }           
    }
}

These security policies have an implicit "deny", so all traffic not specified is dropped.

When you're this far, the SRX is working as transparent firewall, but unfortunately you can no longer manage it remotely since we didn't specify any rules for that. Assuming you would want to manage the device from the "Intranet" side only, we need to allow traffic to the SRX device (host-inbound-traffic) in the intranet zone:

security {
    zones {
        security-zone intranet {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
        }       
    }
}

You will need to reboot the switch after you commit the configuration (you'll get a warning to do this):

root# commit
warning: Interfaces are changed from route mode to transparent mode. Please reboot the device or all nodes in the HA cluster!
commit complete

Some simple guidelines that work most of the time:

Dividing your /29

• The standard size of your allocation from RIPE NCC is a /32
• A /32 is a well-accepted prefix size in the global routing table
• You can get a /29 just by asking for it
• Conclusion: Get a /29 and start using the a /32, save the other /32s for when you deploy to other countries, continents etc.

Determining per-site prefix size

• RIPE allows you to assign up to a /48 per site without having to explain anything. When you assign a shorter prefix (/47, /46 etc) you'll have to explain why you need more than a /48.
• A /32 contains 65,536 /48s.
• So no need to give a site anything smaller than a /48 (/49, /50 etc) either.
• Conclusion: /48 per site

Determining LAN prefix size

• The standards say to use a /64.
• So in your addressing plan always align on /64s
• Configuring a /127 on point-to-point links is common and can protect you against cache overflows, use x:y:z::a on one end and x:y:z::b on the other end for readability.
• Reserve a /64 for router loopback addresses, anycasted services etc. I usually choose the first /64 from the /48 for this so the addresses are nice and short to write with :: notation. Configure /128 addresses from this /64 on loopback interfaces etc.
• Don't even think about not using a /64 on a LAN or VLAN, things will break. If not today then very probably in the future.
• Don't change your LAN/VLAN architecture yet, just assign /64s to each existing LAN/VLAN.

The remaining bits

• There are still choices to be made:
  • How to use the bits on country-level between a /32 and a /48?
  • How to use the bits in a site between a /48 and a /64?
• In both places you could just use random numbers between 0000 and ffff, but that would create a mess that is hard to understand and remember, so do something useful with those bits!
  • Always split at multiples of 4 bits (nibbles) so your addressing plan structure matches the hexadecimal notation of IPv6 addresses (each character in an IPv6 address represents 4 bits)
  • What to use those bits for depends on your organisation. You might divide the country-level /32 into /36 blocks and use a /36 per province. Or you use a /40 for some structure that is important to your organisational or infrastructure architecture. Or both.
  • The same for the /48:
    • Maybe you want to give a /52 to each building on the site and give a /56 to each floor in each building. That works well with prefix aggregation in your routing protocols.
    • Or maybe you want to assign a /52 or /56 to each security zone in your security architecture. That makes maintaining firewall policies and rules a lot easier!
  • Whatever you choose to do: keep a balance. Don't just start assigning from 0 up to ffff sequentially without giving any thought to how to organise those numbers, but also don't over-engineer it. If you want to put too much information in the prefixes (building + floor + security zone + function of the server + what brand of server it is + etc etc) then your addressing plan becomes impossible to work with.
• Plug: I wrote a paper on this for SURFnet a couple of years ago. RIPE NCC has translated it to English: https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf