Purposes of public ports in Azure endpoints? - azure

Azure endpoints have to be implemented on VMs to let external traffic reach a VM inside a virtual network.
Such endpoints have public and private ports, which can be the same apparently.
What is the exact purpose of the public port? Is there any other purpose than simply hiding the private port of an application (say 1433 for SQL server for example)?

Endpoint are an old concept (dying our, really), with ARM you dont have those, you just have a public IP you attach to the VM (and you cant even do port mapping with public IP, you need load balancer for that)
There is no other purpose, only hiding the private port (which doesnt really change much against a port scan)

Related

Azure Private Endpoint - Listening restrictions

I'm experiencing some deeply frustrating issues when trying to connect to a SQL server Private Endpoint. Setting aside for a moment a complete specification of the problem, I'd like answers to the following questions
Is it the case that a SQL Server Private Endpoint will only listen to connections from an Azure Virtual Machine? I have seen it suggested by 3rd parties that this is the case but cannot find this explicitly documented by MS. (To clarify, if only VMs can connect, then this would mean, for example, that an Azure Load Balancer could not use Private Endpoint as a backend resource; and, for example, that an on-premise VM could not connect to a Private Endpoint through a VPN - is that correct?)
Presuming the answer to the above question is Yes, then does the restriction apply such as to prevent Private Endpoint from listening to connections forwarded from an Azure VM interface?
(For example, say a firewall in a VM in Azure. Inside the firewall VM, the IP 192.168.0.10 is configured. In Azure, the VM interface is associated with only a single IP address which is IP 192.168.0.6. In this scenario, the firewall VM will respond to ARP requests with ARP responses saying "I have 192.168.0.10", but 192.168.0.10 is not associated by Azure configuration with any Azure virtual network interface. In said case, will a connection to the Private Endpoint using source address 192.168.0.10 work? Or is it the case that the PE will listen for connections only with a source address 192.168.0.6?)
To answer your questions:
It's possible that use a private endpoint as backends in the Azure Load balancer because Azure LB supports NIC or IP address as the backend target. Also, the on-premise VM surely can connect to a private endpoint through VPN tunneling, read this document for more details.
A VM by default sends all outbound traffic to the IP address that's assigned to the primary IP configuration of the primary network interface. So it will use source address 192.168.0.6 when connecting to the private endpoint. Read the network interface constraints.

Outgoing ip using ACI in a VNET

I'm using the ACI in a private VNET. My problem is, the outgoing ip from this container is not my public IP used in Azure Gateway, is some random ip.
There's some way to fix somehow this outgoing ip from some container using ACI?
OBS: I tested with a public container, I had a public ip to incoming, but for outgoing was different :|
Thanks!
For your issue, when you create the ACI in the VNET, you just can access the resources inside the VNET and the outgoing IP is a private IP of the VNET, so the IP is static if you do not delete the ACI.
When you create a public ACI, it can access the Internet. This time, as I think, the ACI has two public IP, one is the public IP or the FQDN of the ACI to access from the Internet. And another is the public IP of the host machine that the ACI deploy in. When you access the ACI from the Internet, you need to use the public IP or the FQDN which Azure provide you. But when you access the Internet inside the ACI, the outgoing IP is the host machine's public IP. You cannot decide which host machine you can use, so does public IP of the host machine.
If you need to decide the outgoing IP and must be a static one. You can install the docker server in the VM with a static public IP, then create containers in the VM. Then the outgoing IP is the public IP of the VM.
Or you can use the AKS, create the pod and associated with a service that uses the Load Balancer type. Then the outgoing IP is also static and it's the service public IP.

Azure Virtual Network / VM's Setup to Share One Public IP

I've recently setup a point to site VPN on Azure. In doing so I have created:
Azure Virtual Network
Azure Virtual Network Gateway
Azure Virtual Network Gateway IP (static)
Azure VM
I was under the impression that any VM set to use the above said Virtual Network would all share the same public IP? However it appears that the Azure VM i setup is instead using its own dynamic public IP.
Is there a way to route any VM on the Custom Virtual Network I created through one public IP? IF so - how can I do this?
According to your description, you have create a point-to-side VPN. in this scenario, we can remove the public IP addresses from VMs, then you can access your VMs with private IP addresses via VPN.
You are correct - I have the VPN working correctly. My only concern is this, it'd be great that if any of those VM's in that private network shared the same static IP - that way I could grant access to that IP in my firewall to other systems i have in other hosting platforms (as they are all typically locked down by ip).
It sounds like your reference to availablity sets may be the phrase i was looking for to further google.. i will check it out and let me know
please let me know if anything I added above changes your answer/recommendations :)
I was under the impression that any VM set to use the above said
Virtual Network would all share the same public IP?
You are talking about Azure ASM module (classic). In ASM module, VMs can use the same public IP address(NAT).
However it appears that the Azure VM i setup is instead using its own
dynamic public IP.
In Azure resource module, we can create Azure VMs with different Public IP addresses.
Is there a way to route any VM on the Custom Virtual Network I created
through one public IP?
According to your description, you have create a point-to-side VPN. in this scenario, we can remove the public IP addresses from VMs, then you can access your VMs with private IP addresses via VPN.
If you want to access those VMs from Internet and use one public IP address, we can create VMs in the same availability set, and deploy a Internet facing load balancer, then add NAT rules to them, in this way, we can access those VMs use the same public IP address and different ports.

How does one setup two non-load-balanced VM web servers in Azure, capable of communicating on private ports?

I'd like to setup the below infrastructure in Azure. I have one possible solution, but it seems like it makes compromises in security architecture. Is there a better way to do this in Azure than in my compromised workaround?:
VM #1: Role: SQL Server and IIS. Server should have a unique public IP address. The hosted websites will be available through public port 80, and connect to local SQL Server.
VM #2: Role: IIS. Server should have a unique public IP address. The hosted websites will be available through public port 80, and will connect to SQL Server on VM #1.
This has been my experience so far:
No issues setting up VM #1.
With VM #2, I tried building it in the same cloud service as VM #1. When I did that, it was assigned the same public IP address as VM #1. Thus, in this scenario, hosting websites on port 80 on both machines doesn't work.
Next I tried building VM #2 in a different cloud service. This resulted in assignment of a unique public IP address. However, I was unable to obtain connectivity to SQL Server on VM #1.
Things I tried for the above: VM #1 SQL Server set as mixed mode, named SQL account provisioned (and connectivity confirmed locally), SQL configured to allow incoming remote TCP connections, firewall rule opened for incoming connections on TCP port that SQL runs under, but so far have not been able to connect to it from VM #2.
One architecture I believe would work is to open a public port on VM #1 and map that to the private SQL Server port. Then VM #2 could connect using the fully-qualifed public DNS name of VM #1. I believe Azure also would allow connectivity to be constrained to the public IP address of VM #2.
However, this seems less than ideal, because now SQL communication is being routed through a more public route than one would normally design for a data center, and an extra public port has to be opened on VM #1 (even if constrained by IP address, I'd rather not expose that surface area if not necessary). Additionally, sending the SQL Server data over a more public network hypothetically means transport security may need to be considered.
Research indicates connectivity between 2 VMs on different cloud services may not be possible using private ports, although the info I've found so far is not conclusive. So again, is there a better way to do this in Azure?
A single cloud service is a security boundary and the only way into it is through a public (input) endpoint on the unique public VIP of the service. A Virtual Network (VNET) can be used to host multiple cloud services and allow private visibility among them without going through a public endpoint.
A typical model would be to put an IIS website in a PaaS cloud service with a public VIP and the backend SQL Server in an IaaS cloud service with a public VIP but NO public endpoints declared on it. Both these cloud services would be hosted in the same VNET. This allows the front end web role instances access to the backend SQL Server instance over the private VNET. There is a hands-on lab in the Windows Azure Training Kit that describes precisely how to implement this.
In this case I would recommend separating the IIS/SQL Server combination so that the SQL Server box is in an IaaS cloud service with no public endpoint (although it will always have a public VIP). I would also recommend using either a Point-to-Site or Site-to-Site VPN which would allow you to access the VMs without exposing a public RDP endpoint. A point-to-site VPN is developer focused and very easy to configure. A site-to-site VPN is more of an IT thing since it requires configuration of a VPN router such as Cisco, Juniper or Windows Server.

Private Ports in Azure Virtual Machine

What is the concept of Private Ports in Azure Virtual Machines? What is its key advantage or use case. There scenarios I checked that for the RDP endpoint the Public Port is 3389 and private is takes up some random port number.
In order to access the VM via RD, I am forced to open that private port as well to access that. In few places I have seen for an HTTP endpoint both Private Port and Public port are made 80 for access?
What is the theory behind this?
Windows Azure places all of your Virtual Machines behind a load balancer. All of your virtual machines can open outbound connections. For inbound connections, you need to explicitly open ports in the firewall. These are input endpoints and instance input endpoints:
Input endpoints are used when you'll load-balance traffic across virtual machines (e.g. a web server)
Instance input endpoints would allow you to have a connection straight to a specific virtual machine (e.g. a database server)
Now, regarding public and private ports: Public ports are the port numbers exposed to the outside world. So for a web site, maybe that's port 80. You can then map that port to a port on the virtual machine itself. Maybe you run your web server on port 8000 for some reason. In this case, you can map public port 80 to private port 8000.
Now imagine SSH. SSH likes to listen on port 22. But if you have, say, 3 Linux vm's in a single service, there's simply no way to access all of them on port 22, since they all share an ip address. Therefore you'd need a specific port number for each machine. In this case, you'd assign, say, port 20000 to vm1, 21000 to vm2, etc. on the public port side, as an Instance Input Endpoint pointing to a specific virtual machine instance at port 22 on the private port side.
Hopefully that makes some sense... :)

Resources