Does anyone know if its possible to have my corporate azure account to be assigned a block (e.g. subnet) of azure public IP within a region to make it easier to create firewall rules for my corporate firewall which blocks most outgoing ports.
Our customer does not want anyone sourced inside from the corporate .com account to have access to all 22 and 3389 ports out on the internet, but will limit them to a subnet if we can be assigned a subnet on which we will hang our bastion servers on.
I wouldn't know about blocks of IP's, but you can certainly create a virtual network in which you create all your resources in Azure, and hten configure a firewall in azure, which will have a permanent IP. This can then be used to set up a site-to-site VPN thing between your corporate network and the machines in Azure.
https://azure.microsoft.com/en-gb/services/virtual-network/
For public facing ports, you can add another virtual network card and rest assured that the traffic on one card cannot, in any way pass over to the other, network connected card.
This would also be a better strategy than to set up a range of VM's in Azure with public IP's.
Related
I have created the following Vnets
vnet-hub-poc-hubspoke is the Hub Vnet
and both the Vnets are peered as per the HUB-SPOKE model
vnet-hub-poc-hubspoke being a Hub Vnet, it has Azure firewall configured
both the Vnets are connected to Azure Private DNS
Azure Private DNS has a record pointing to the VM deployed on the vnet-prod-poc-hubspoke Vnet
and I could access the FQDN within the internal network
after adding the below rule in Azure Firewall, I could access the website using the firewall public IP
Now, instead of firewall public IP I want to use the domain name like
http://myfirstweb.private.landingzonedomain.com/ (for now, I have updated the hosts file in the client machine pointing to firewall public IP)
what should I do at the azure firewall level so that it would translate Internet URL to Internal/Intranet URL like
http://myfirstweb.private.landingzonedomain.local/
What you want is not possible, because you cannot assign a domain name to your Azure Firewall. What you could do is to create a DNS record at a domain name provider that translates a custom domain to your Azure firewall public IP.
Although I have seen people routing inbound traffic in their vnet, Azure firewall is mainly designed for controlling outbound traffic and traffic flowing between (peered) vnets. When you want to direct inbound traffic to a website or service inside your vnet, you can choose between:
Application Gateway
Frontdoor
Combination of both
All the options above allow you to add custom domains and certificates. On the other hand, when you want to access a virtual machine through rdp or ssh, your main options are:
Bastion host (i.e. jumpbox)
VPN
Cloud Shell
Again, I tried to create a VNet-to-VNet connection.
Briefly, I created
Gateway Subnet at East US Region
Gateway Subnet at West US Region
Virtual Network Gateway for East US Region and
Virtual Network Gateway for West US Region
Using Connection type VNet-to-VNet, I connected both Virtual Network Gateway from both sides.
I created connection between both Virtual Network Gateway.
The status of both connections says, Connected.
Windows Server Domain Controller is set up at East US and Windows 10 is installed at West US.
Windows 10 is unable to ping and join the Windows Server Domain Controller.
While joining the Domain Controller, the error message is
The issue is
I am able to connect both VMs which is at two different VNets using RDP with Public IP.
Both VMs’ virtual network gateways are also connected to each other through Connections.
I am able to connect one VM from another using RDP with Private IP.
But I am not able to join Windows 10 VM to Windows Server 2016 Domain Controller.
I request please go through the link https://1drv.ms/u/s!Ail_S1qZOKPmlgBU5fLviInoisrx?e=ImrqpL and help me to fix the issue related to VNet-to-Vnet Connection so that Windows 10 VM from one VNet can join the Windows Server 2016 Domain Controller VM which is at another VNet.
I hope you'll consider it positively.
Regards
TekQ
You might have to create routes, you are not using recommended private address space so routes are not created for you.
Azure automatically creates default routes
for the following address prefixes: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16: Reserved for private use in RFC 1918.
100.64.0.0/10: Reserved in RFC 6598.
Check the effective routes to seen next hop for traffic in the peering address space.
https://learn.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem
Additional Information on VNet Routing
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
Instead of rely on Vnet Gateway and VPN S2S, you could as well using Vnet Peering between region.
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview
I agree with the other answers. Global VNet Peering would remove the necessity of using a VPN GW, which greatly simplifies the environment and removes the monthly cost of hosting a pair of GWs. Assuming you need those GWs for other connections to VPN devices on-premises, then you can still use this design.
As Hannel pointed out, you're using public ranges for your private networks. That is also okay, but routing would be affected for VMs in those subnets if they attempted to go to actual public IPs in those ranges. Note that Hewlett Packard owns large parts of those ranges, so if your VM needed to get info from an HP website, you would have to create manual UDRs to route that traffic to Next Hop Internet.
So, please do check your Effective Routes on your NICs. You can check this from the NIC and also from Network Watcher. This should help you identify if another route is taking precedence or even if you have a route sending traffic to a virtual appliance.
Do make sure that you chose VNet-to-VNet when you set up your connection. If you chose IPSec, then you would need to have correctly configured your local network gateways.
I have a VMSS/svc fabric cluster on internal vnet (not public). The only inbound connections to the VMSS is from on prem through a Azure VPN Gateway.
How do I control the outbound IP address the VMSS go through when accessing the internet? In this case I do not want this traffic routed through a random IP address or through the VPN connection.
Basically I want to secure my Azure SQL so that the outbound internet IPs of the VMSS is whitelisted. And I don't want to add all Azure datacenter IPs.
You could look to use Forced Tunneling which would ensure that your control where the data egress occurs in your on-premises environment, however this would force any data in your Virtual Network back over your VPN connection which may not be desirable (or helpful if you don't control egress from there).
Failing this you could add a software-based firewall running on an Azure VM with a public IP onto the same VNet and then use User Defined Routes (UDRs) to force all traffic bound for the Internet to go via that and then use the public IP address in your SQL firewall.
Longer term you will be able to connect Azure SQL DB to VNets (or at least restrict access to it from one) - see the Uservoice site (and add your vote!)
I have a case where I want to migrate on-prem servers to Azure, but I should still have the local IPs pointing to these VMs. I mean by the local IPs the country-range of IPs since these VMs should be accessed using country IPs for regulatory reasons.
I heard that this is possible, but I have no idea what type of resources I should use to allow this, VNET, VPN, ExpressRoute ?? And how to do it as I have no experience in networking what so ever.
Regards,
NAT is a method of remapping one IP address space into another by modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device.
You can setup a site-to-site VPN between on-prem and Azure Vnet, then deploy a server on-prem run as the NAT device.
It is possible, but with some complications and constraints:
You can run these servers/VMs in Azure using their public IP addresses. You need to create the Virtual Network using these address ranges, but it is possible. The catch here is that these public IP addresses are only accessible via cross premises connectivity solutions such as Azure VPN gateway or Azure ExpressRoute. You cannon access these VMs using their "public" IP addresses directly over the Internet. For this purpose, these public IP address ranges are really treated as "private addresses".
Once you create the virtual network with the public IP addresses (as private address space) in Azure, you will also need to make sure your routing in the on premises network is configured correctly to forward the traffic to these VMs over the VPN tunnels or MPLS/WAN network if you are using ExpressRoute.
If these servers/VMs need to accept requests directly from the Internet, the traffic from the Internet will still come to your on premises network because that's where your ISPs will direct the traffic. You will need to ensure these traffic will be routed correctly over the cross premises connectivity (VPN/ExpressRoute) to Azure.
Hope this helps a bit. Please let me know if this answers your question.
Thanks,
Yushun [MSFT]
I would like to use my internal exchange servers for email notifications from an azure Web Role. The role is set up on the west us region. I need to allow this role, with multiple instances, access my corporate smtp server on port 25. IS there an appropriate range of IPs that I could open up on my corporate firewall, or is there a more secure option.
We have experience setting up networks in Azure as well as VPN gateways, I am not sure that this would be part of the solution as my understanding is not broad enough to see how I could implement something that would allow secure access to corporate networks while continuing to be publicly available.
Any help or direction would be appreciated.
Thanks
Your web role has a single (and fairly static) ip address of the load balancer, but this is of no use to you as the source ip address for outgoing data will be the ip address of the particular instance. You can get hold of this address, but not easily, and it is subject to change — every time an instance recycles, or is added, the ip address will change (although the incoming ip address, of the load balancer, remains static). So you can't provide instance public ip address ranges for the corporate firewall.
If you are familiar with VPNs and private networks on Azure, then that will be your simplest option. Your worker role ip addresses will still change, but the range is more predictable, and is defined by your subnet configuration. A worker role on a private network (VPN) will have both public and private ip addresses, so will be publicly accessible, but will send to a VPN ip address via the gateway.
Another option is to do some sort of smtp relay, either on a VM in Azure, or a managed hosting service, where the ip address is more static. This would require that a machine is setup, maintained, and running, but could probably be easily done on an extra small linux vm.
Your web roles will be part of an Azure Cloud Service. That cloud service is assigned a static public IP address by Azure. No matter how many roles you add/remove from the service the public IP will remain unchanged. You can set your SMTP server to only allow requests from that IP address.