You can limit network traffic to resources in a virtual network using a network security group (NSG). A network security group contains a list of security rules that allow or deny inbound or outbound network traffic. An NSG can be associated to a subnet or a network interface. A network security group can be associated multiple times.
subnets
You can assign NSGs to subnets and create protected screened subnets (also called a DMZ). These NSGs can restrict traffic flow to all the machines that reside within that subnet. Each subnet can have zero, or one, associated network security groups.
Network interfaces
You can assign NSGs to a NIC so that all the traffic that flows through that NIC is controlled by NSG rules. Each network interface that exists in a subnet can have zero, or one, associated network security groups.
Network Security Group Rules
Security rules in network security groups enable you to filter the type of network traffic that can flow in and out of virtual network subnets and network interfaces. Azure creates several default security rules within each network security group.
You can add more rules by specifying:
- Name
- Priority
- Port
- Protocol (Any, TCP, UDP)
- Source (Any, IP Addresses, Service tag)
- Destination (Any, IP Addresses, Virtual Network)
- Action (Allow or Deny)
Azure creates the default rules in each network security group that you create. You cannot remove the default rules, but you can override them by creating rules with higher priorities.
Inbound rules
There are three default inbound security rules. The rules deny all inbound traffic except from the virtual network and Azure load balancers.
Outbound rules
There are three default outbound security rules. The rules only allow outbound traffic to the Internet and the virtual network.
Create network security group rules:
It is easy to add inbound and outbound rules. You can select from a large variety of services. These services include HTTPS, RDP, FTP, and DNS.
Service. Service specifies the destination protocol and port range for this rule. You can choose a predefined service, like HTTPS and SSH. When you select a service, the Port range is automatically completed. Choose custom to provide your own port range.
Port ranges. Port ranges can include a single port, a port range, or a comma-separated list of ports. The ports designate the traffic will be allowed or denied by this rule. Provide an asterisk (*) to allow traffic on any port.
Priority. Rules are processed in priority order. The lower the number, the higher the priority. We recommend leaving gaps between rules to make it easier to add new rules. The value is between 100-4096 and unique for all security rules within the network security group.
virtual network peering
Perhaps the simplest and quickest way to connect your VNets is to use VNet peering. Virtual network peering enables you to seamlessly connect two Azure virtual networks. Once peered, the virtual networks appear as one, for connectivity purposes. There are two types of VNet peering.
- Regional VNet peering connects Azure virtual networks in the same region.
- Global VNet peering connects Azure virtual networks in different regions. When creating a global peering, the peered virtual networks can exist in any Azure public cloud region or China cloud regions, but not in Government cloud regions. You can only peer virtual networks in the same region in Azure Government cloud regions.
Benefits of virtual network peering
The benefits of using local or global virtual network peering, include:
- Private. Network traffic between peered virtual networks is private. Traffic between the virtual networks is kept on the Microsoft backbone network. No public Internet, gateways, or encryption is required in the communication between the virtual networks.
- Performance. A low-latency, high-bandwidth connection between resources in different virtual networks.
- Communication. The ability for resources in one virtual network to communicate with resources in a different virtual network, once the virtual networks are peered.
- Seamless. The ability to transfer data across Azure subscriptions, deployment models, and across Azure regions.
- No disruption. No downtime to resources in either virtual network when creating the peering, or after the peering is created.
Create virtual network peering:
Here are the steps to configure VNet peering. Notice you will need two virtual networks. To test the peering, you will need a virtual machine in each network. Initially, the VMs will not be able to communicate, but after configuration the communication will work. The step that is new is configuring the peering of the virtual networks.
- Create two virtual networks.
- Peer the virtual networks.
- Create virtual machines in each virtual network.
- Test the communication between the virtual machines.
To configure the peering use the Add peering page. There are only a few optional configuration parameters to consider.
Comments
Post a Comment