You set the "Apply both directions" to false by clearing the "Apply Both Directions" check box when creating the subject. Once the subject is created, it can't be changed except by delete and add again.
As for "I can only guess a consumer cannot initiate a connection??" you are 180° out.
What you really want (and the way consumer/provider works) is that the provider connot initiate a connection. After all, what would the world be like if every web server out there COULD initiate a connection to your PC!!
I've cut-and-pasted the bit below from an answer I gave earlier see https://community.cisco.com/t5/application-centric/aci-contract/m-p/3856629 you will learn more if you read the discussion that follows too.
I hope this helps
Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem
Let's start with an example. Assume you have an EPG called Web providing a contract called HTTP being consumed by EPG User. The HTTP contract is built on a filter specifying Destination Port=80 - no specify source port.
The most straightforward way to apply this contract is with both the Apply Both Directions and Reversse Filter Ports options checked, as shown below:
The way the contract works is that the chosen filter is applied to traffic coming from the Consumer to the Provider, so traffic with a DP=80 is permitted. By checking the Apply Both Directions, the filter is also used for traffic travelling from the Provider to the Consumer, but because the Reverse Filter Ports option is checked, the contract will be allowing traffic with a SP=80 rather than DP=80.
By in large, this is what you want a contract to do - permit forward traffic from the Consumer to the Provider and return traffic in the opposite direction.
Now let's play with those options. Assume you remove the Reverse Filter Ports option. Now the contract is still applied in both directions, but with DP=80 in each direction - essentially removing the whole idea of Consumer and Provider as only traffic with DP=80 would be allowed. No return traffic would get through, unless you added another contract to allow say SP=80 to pass.
What you end up is with a pretty useless contract, and in my opinion, one that shouldn't even be supported in the GUI configuration.
However, the last possible variation (you clearly can't Reverse Filter Ports if you don't Apply in Both Directions) is to only apply in one direction. This option only uses a single TCAM entry rather than two as shown in the above examples.
Again, like the previous example, you will need a different contract and filter to allow the return traffic with SP=80, but there is more clever way of doing this using a special EPG called the vzAny EPG.
vzAny represents the collection of EPGs that belong to the same VRF. Instead of associating contracts to each individual EPG, you can configure a contract to the vzAny EPG which is found under your VRF configuration's EPG Collection for VRF. (Tenant > tenant > Networking > VRF > vrf > EPG > EPG Collection for VRF)
The idea is, you create a contract that allows all TCP traffic with the ACK flag set - there is a pre-defined filter for that you can use defined in the common tenant called est. You then make the vzAny EPG both a Consumer and a Provider of this contract which then allows every EPG in that VRF to accept traffic with the ACK flag set but uses only a single TCAM entry for all EPGs.
In the following diagram, the HTTP and SQL contracts allow traffic from the consuming EPGs to reach the providing EPGs, while the Established contract allows universal traffic between EPGs so long as the TCP session is established. Essentially, the HTTP and SQL contracts are only needed to allow the initial TCP SYN packet through to establish the session. all other traffic is handled by the vzAny EPG and its Established contract.
