Migration to new Security Groups behaviour

With AWS-compatible SecurityGroups migration process we’ll start applying all existing Access Rules at the level of the instances’ interfaces, connected to Virtual Networks (a.k.a. “subnets”).

Note

Virtual Switches functionality won’t be affected. In case you use Virtual Switches only, this article is not relevant to you.

Security Groups function with a principle “all that is not allowed is prohibited”. To avoid network traffic disruption, you’re highly recommended to review all existing Access Rules in terms of their applicability to instances’ interfaces.

We’ve described some configurations, which require paying attention before moving to new Security Groups.

Interfaces IP addressing different from subnet CIDR

If you have configured IP addressing on instances’ interfaces other, than subnet CIDR, you should stop using it. Earlier such configurations were not supported, but they worked. With new Security Groups mechanics such trick would not work.

Access to instances through VPN server

In case you use one of the instances as a VPN server-router and want to have access to other instances on the same subnet

When you have VPN server on your instance and you require network connectivity from VPN client to instances in the same subnet as VPN server resides, you should add new access rules based on VPN network CIDR with appropriate protocol and port.

Example with requirement of SSH access from VPN client to some instance is illustrated on the diagram below. The bold cursive font shows the new rule, required to have access from VPN client to instances.

../../_images/vpn.png

Access to instances through router-VM

In case you have configured instance for network traffic routing, using subnets and virtual switches, such situation is similar to configuration with VPN server on the Instance.

When you need access from instance which is connected to virtual switch only to instance in the subnet, connected to router-vm, you must add appropriate access rules.

For instance, if your application initiates connection to 8080/tcp port from 192.168.0.10 to 172.31.0.5, then 8080/tcp from 192.168.0.0/24 rule can be added to allow this connection.

../../_images/routed.png

Access to instances through External Networks from CROC Datacenter colocation

In case you use External Network and route your network traffic outside the CROC Cloud, you should add appropriate access rules.

There is an example which shows requirement to have access from traditional server to instance with MySQL server in the cloud. Bold cursive font shows a rule, which must be added to have 3306/tcp access from network 192.168.0.0/24.

../../_images/vtep.png

Access to instances through External Networks from Internet via some ISP and CROC DC Colocation

For instance, your application requires public access from all networks to 80/tcp, 443/tcp. Also, you want to have administrative SSH access from colocation infrastructure and access to MySQL server inside to cloud. Such configuration is illustrated on the scheme below and all new rules are written with bold cursive font. There are rules for 80 and 443 ports with public access (0.0.0.0/0) and 22, 3306 ports with restricted access from 192.168.0.0/24.

../../_images/vtep-internet.png

Access between instances with elastic IP addresses

In case you want to have access between instances using elastic IPs, the source IP on the destination node will be also elastic. So, this requires adding a special rule.

For example, you have two instances with associated elastic IPs 185.x.x.x and 185.y.y.y. Let’s say, your application requires to have access from first instance to the second using elastic IPs. So, you must add rule 80/tcp from 185.x.x.x/32. The diagram below illustrates such configuration.

../../_images/elastic-ips.png