SRX

 I have the SRX 240H. I would like to create one WIFI vlan, access points will be connected to it. But that students and staff and teachers will connect via wifi - I would like to separate it somehow in order to be able to properly manage them and grant permissions or to prohibit access to something.
Would it be a good idea to create one vlan with an address pool, e.g. 192.168.80.0/22 which will give me 4 subnets (192.168.80.0/24 192.168.81.0/24 192.168.82.0/24 192.168.83.0/24) and then allocate in DHCP according to:
192.168.80.0/24 - students
192.168.81.0/24 - teachers
192.168.82.0/24 - employees
192.168.83.0/24 - guests
And then I could apply the appropriate per subnet restrictions.

Hello,

From my POV you are overcomplicating the situation, by trying to combine, what should be separated.

The SRX is a switch/router and FW, so I would create the individual VLANs per Department. Zone per functionality and IP Range per your needs.

Having a strong FW feature set (Zones) you should be in the position to create rules in the way you need.

Limiting the time/volume and speed of relevant departments 

BR,

Andrei

OK. Maybe you're right.

Scenario:  SRX--swich--AP

And how to transfer all these VLANS to Acess Points - I have UNIFI UBIQUITI LR + UBI KEY controller, I do not know if they will accept TRUNK - because the point is to be able to connect to all APs from different vlanes or subnets ...

I can of course set TRUNK between the SRX and the swich (to which the access points are attached) - but how do I extend all these vlans to individual ports? So it is as if several VLANs were available on one ACCESS port ...

I found something like this. https://forums.juniper.net/t5/Junos/SRX320-multiple-VLANs-on-same-physical-interface-1-untagged-2/td-p/299632

Hello,

Ok, now the picture looks better.

So step by step.

1. You do not need to have WIFI point to be able to handle  VLANs, you have switch in between.

The Switch will do this job it will have:

a). Access Port (VLAN WIFI) towards the WIFI AP

b). Access Port(s) (VLAN per department) facing the relevant CPEs/Users

c). Trunk Port (permitted all vlans or only set of - up to you) towards SRX

2. The SRX in your case will be able to handle this in a few ways. Unfortunately, the IRB interfaces were introduced in later releases, but you will have to deal with vlan interfaces (logic is same). 

I see min 2x ways to achieve it (all depends on how you are looking to use your SRX for the end customers)

1. Sub-Interfaces on SRX. The port facing the Switch will be "sliced" in subinterfaces. The port itself is the trunk based 

EX:

interfaces {
ge-0/0/0 {
description "Facing Switch";
vlan-tagging;
unit 100 {
description "[WIFI] IP used to reach the WWW";
vlan-id 100;
family inet {
address 10.10.10.1/27;
}
}
unit 200 {
description "[STUDENTS]";
vlan-id 200;
family inet {
address 10.20.20.1/27;
}
}
unit 300 {
description "[GUESTS]";
vlan-id 300;
family inet {
address 100.100.100.1/29;
}
}

This way will make a bit difficult to use the SRX as "switch" for those VLANs - as you will need to deal with bridge groups and overall setup will be a bit complicated. But your subinterfaces will be able to participate in routing (active) and other features.

2. The VLAN interfaces.

Your SRX port facing the Switch is a trunk (with all or selected members)

interfaces {
ge-0/0/0 {
description "Facing Switch";
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
}
}
}

And your VLAN interfaces are:

vlans {
Local-Lan {
vlan-id 100;
l3-interface vlan.100;
}
}

vlan {
unit 0 {
description "[WIFI]";
family inet {
address 10.10.10.1/27;
}
}

In this way, you will be able to re-use some ports on SRX as customer-facing ports. 

3. Now you have all components connected L2/L3 in between, and it's up to routing/nat to ensure the mapping between different clients and different WIFI points (if you have many) or any variety of this. + You have FW - to ensure the proper security approach. 

Please pay attention to the next development you are looking for your networks as VLAN interfaces vs sub-interfaces may have limitations under different feature sets.

BR

Andrei