Through the creation of a VPC and its associates objects automatically, I get a SG with an Inbound Rule I cannot update using as source my IP :
SecurityGroup:groupId=sg-065cba0045348c4af
INBOUND RULES :
SecurityGroupRuleID=sgr-017bacfbd03e63fa7
In the Field Source of the SecurityGroupRuleID = sg-065cba0045348c4af / default
It means that the source of the INBOUND RULE = the SG’s ID to which the RuleID belongs to
And when I try to update it with my IP I get this error : “You may not specify an IPv4 CIDR for an existing referenced group id rule.”
Just to emphasize that when I create manually everything (VPC, SUBNET, RTB, IGW, ACL, SG …) I have no problem using CIDR in the SOURCE of an INBOUND RULE.
Thanks for any idea which could help to fix this problem.
Hello Didier, if i get you well here you are trying to update an inbound rule ? why you not try and add a new inbount rule and specify your IPv4 CIDR to that same seguriy group.
If I add a rule, indeed I can use a CIDR as the source.
But the rule will be at the second position.
And the first position allows all trafic with source as the SG.
And I don’t know what includes the SG as a source.
I would like to understand why in that case , the INBOUND RULE of this SG contains a rule which references as the source the SG to which the INBOUND RULE belongs to.
As I know it is really complicated to understand the context when you are not in front of the screen, I provide some screen captures :
This is what I get when I access the EDIT INBOUND RULES :
When an SG rule references the source as the SG to which the rule belongs, it is known as self-reference. In simpler terms, the rule allows inbound traffic from the same security group. By allowing inbound traffic from the same security group, instances within the group can communicate with each other.
The order of the rules in a security group is important because the rules are evaluated sequentially. When an inbound connection is received, the security group evaluates the rules from top to bottom and applies the action of the first matching rule. Therefore, if the first rule allows all traffic from the security group itself, it will take effect for inbound connections initiated by instances within the same security group.
The second position rule that you mentioned, which allows a CIDR as the source, would only come into play if there are specific IP ranges or subnets that need to be allowed access to the instances in the security group. The CIDR rule would be evaluated after the rule allowing traffic from the security group itself
