I have deployed my ASP.NET WebForms application (Azure Web Role) on Azure virtual network. I have been told by the IAAS team that the subnet which I have used needs Proxy XX.XX.XX.XX:8080 for accessing the application from the internet. If it's a virtual machine I can add proxy xlass, but I am not able to add the proxy class in service configuration file and added it in application web.config, but still it's opening from public internet and not able to connect to RDP.
Please help me with this.
Thanks
RDP wouldn't require a proxy that I'm aware. I imagine you match the same config as mentioned here to set your ACLs (too many images and not enough text to copy here)
http://blogs.msdn.com/b/walterm/archive/2014/04/22/windows-azure-paas-acls-are-here.aspx
If you really are trying access for RDP check out the following. If just web access, the above should work.
http://www.cloudcomputingadmin.com/articles-tutorials/windows-azure/azure-virtual-networks-and-cloud-services-part3.html
As per
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-rdp-detailed-troubleshoot/
Source 3: Cloud service endpoint and ACL
To eliminate the cloud service endpoint and ACL as being the source of issues or misconfiguration for virtual machines created using the Service Management API, verify that another Azure virtual machine that is in the same cloud service or virtual network can make Remote Desktop connections to your Azure virtual machine.
If you do not have another virtual machine in the same cloud service or virtual network, you can easily create a new one. For more information, see Create a virtual machine running Windows in Azure. Delete the extra virtual machine when you are done with your testing.
If you can create a Remote Desktop connection with a virtual machine in the same cloud service or virtual network, check for these:
The endpoint configuration for Remote Desktop traffic on the target virtual machine. The private TCP port of the endpoint must match the TCP port on which the Remote Desktop Services service on the virtual machine is listening, which by default is 3389.
The ACL for the Remote Desktop traffic endpoint on the target virtual machine. ACLs allow you to specify allowed or denied incoming traffic from the Internet based on its source IP address. Misconfigured ACLs can prevent incoming Remote Desktop traffic to the endpoint. Examine your ACLs to ensure that incoming traffic from your public IP addresses of your proxy or other edge server is allowed. For more information, see What is a Network Access Control List (ACL)?.
To have public internet connectivity into your worker role you need one of the following:
A public IP address (https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-instance-level-public-ip/) associated to the worker role instance (or)
A public endpoint configured to expose a specific port (https://azure.microsoft.com/en-us/documentation/articles/load-balancer-overview/)
If you use Network Security Group, please ensure that you have appropriate ACLs opened up to allow connection from Internet.
Thanks
Related
I have a Virtual Box VM hosted on my desktop, using bridged mode.
On that VM I have installed a one node Service Fabric cluster (secured with a self-signed x509 cert).
I have setup my router to send ports 19000-19100 to that guest machine IP Address.
I am on AT&T Fiber so I am forwarding those ports to a router and then the router forwards them on to the guest OS at a specific IP address.
From my host machine I am able to get to the service fabric explorer and I can deploy services to it from visual studio.
I am not able to deploy to it from azure devops. My friend is not able to see the explorer either.
In DevOps I have configured a service connection, put the certificate in it, etc. In my pipeline I am writing to the hosts file (my public IP and the host name I need sit.mysite.com as an example). One thing to note is that I was previously able to deploy to SF when I had the cluster running on my main machine (as opposed to in a VM as it currently is)
A friend (living in another state) is not able to view my service fabric explorer. I provided the cert to him, he's imported it. He has an entry in his hosts file also. When he goes to https://sit.mysite.com:19080 (the SF explorer address), he gets a 403, not authorized. But it is correctly picking up the cert. He can also ping my IP address so we have connectivity.
Whatever is stopping him from hitting my SF is likely what is preventing me from the ability to deploy from azure devops, but I have no idea what it would be...
Any ideas?
Figured it out. Turns out my cluster config file was referencing localhost for the node as opposed to the IP (or a dns name) and that made the fabric not respond to requests from outside.
"nodes": [
{
"nodeName": "vm0",
"iPAddress": "IP_ADDRESS_HERE",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD0"
}
],
Currently I'm using ngrok.io to expose local service (ex. localhost:3000) to the outside world. What can I do to expose internal company service that is only accessible within VPN to the outside world.
That depends on the network in which your service is located.
If it's a home network, you need to make sure you're not behind your internet provider's NAT (in other words, that you have a dedicated public IP address), then log into your router and configure port forwarding to your machine. If you don't have a dedicated public IP, or just want your service to work independently from your personal machine, consider hosting it on a VPS.
If it's a company network, your system administrator should be able to handle this (after deciding whether it's appropriate).
The use case is the following:
Private network for the GCP project
VPN on the local computer that seems to be blocking SSH connections
A VM that has a webapp to be accessed but we don't want to expose the IP to the public network
What are the best practices to keep it private and to access it eg. with OAuth authentication?
What are the steps to make and to follow?
Appreciate your help with this.
There are several methods in Google Cloud. The second method is the recommended method based upon the requirements in your question.
If the users have defined public IP addresses, use Google Cloud VPC firewall rules to only allow access from approved IP addresses.
Do not assign a static public IP address to the instance. Add an HTTP(S) Load Balancer and enable IAP. Add each user's identity to IAP for identity-based access control.
Additional methods suitable for developers:
My favorite is to use WireGuard (VPN) and use peer-based access control.
I have an web app deployed in Azure App Service which uploads file to a blob container. Both App service and blob are in same resource group and region. After uploading a file successfully when I check the diagnostic logs of storage container I see a different IP address. This IP address does not belong to the list of outbound IPs mentioned in the App Service.
Why is it like that? Where does this IP come from?
Update:
The IP address is shown as private IP address if I search for it.
Regards
Binil
Generally, when web app makes an outbound call to the internet, it uses a set of predefined IP addresses. A storage account could have public or private endpoint to accept the request.
First, you could ensure that if the specific private IP you mentioned is the client request IP from app service to the storage account.
In this case, one of the possible reasons is that you have integrated your app with an Azure virtual network and enabled the integrated vnet service endpoint for Microsoft.Storage. This allow web app access an Azure storage account from a virtual network. See how Azure select a route for more details.
Edit
From this document,
Services deployed in the same region as the storage account use
private Azure IP addresses for communication. Thus, you cannot
restrict access to specific Azure services based on their public
outbound IP address range.
thus, it's properly using a private IP address from apps service to your Azure storage account in the same region over the Azure backbone network. To validate it, you can use a storage account in a different region than the app service.
We are currently using Openstack newtown. We can access the API using client on public endpoint from any computer, but the vm don't have access to it, they can ping the IP and dns name but can't curl or access using openstack-client. How can we allow connection from VM to API ?
Assuming your public API endpoint is externally accessible, the network on which your virtual machine resides will need external access. This can be achieved in a few different ways, depending on your current configuration. You can create a Neutron provider network/subnet which will provide access to a physical network and gateway to the outside world. You can then boot your instance directly on the provider network. More information on Neutron provider networks can be found at docs.openstack.org.
The problem is that floating IP don't give the route of my external network.
I add route using neutron and now all is working perfectly. for info the command is:
neutron router-update demo-routeur --routes type=dict list=true destination=192.168.0.27/27,nexthop=10.0.0.1