I'm using some hosted 2008R2 servers for testing scenarious in the Azures cloud and they seem to be working well for most things.
I need clients to directly access the server via VPN such that they have full IP access to the server, for, say, SMB NET USE drive mappings, which otherwise would not be available over the Internet.
Normally, you'd just install RRAS and configure VPN.
But on these VMs, the connection from a remote VPN client fails. I'm forwarding the correct endpoints (I believe), 47 & 1723 for PPTP and 50/51/500 for IPSEC. But they aren't getting through.
The server is listening on these ports.
All my searching seems to suggest you need to use "Azures connect" for VPN access, so does this mean you can't go direct to the server for clients? I don't want to go for the Azures Connect route as I'm just playing/testing and don't want to use any proprietory methods.
Confirmation that this is impossible would be useful to save me going mad.
Azure Connect is a very good way to start; it is an Azure service so I am not sure why you are reluctant to use it. I would keep an eye on performance; VPN could very well be faster. Here is my blog post on how Azure Connect works and the steps I took to make it work: http://geekswithblogs.net/hroggero/archive/2012/10/18/how-to-create-a-virtual-network-with-azure-connect.aspx
Regarding VPN, only certain devices are supported for the preview. Please refer to MSDN for a complete list of supported devices and protocol requirements: http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx
Related
We are migrating our website on Azure platform in PaSS model. our website needs to communicate to our back office system using web services.
Currently the Back Office system is in a providers data center. and we have a firewall which enables web service communication for specific IP's
Now website going to be hosted on Azure with PaSS model, can some one please advice which IP address we need to add in whitelist of our Back office firewall.
Please note we want to set up our web app to be out-scaled to multiple instances.
will each instance will be able to communicate with out Back office ?
Regards
Umesh Deshmukh
can some one please advice which IP address we need to add in
whitelist of our Back office firewall. Please note we want to set up
our web app to be out-scaled to multiple instances. will each instance
will be able to communicate with out Back office ?
For a long-term, Hybrid Connection is much better. If you still want to know whitelist the outbound IP of web app service, you could find these possible outbound IP addresses in additional outbound IP addresses setting of the web app properties. You can't know beforehand which IP address a given app instance will use to make the outbound connection, so your back-end service must open its firewall to all the outbound IP addresses of your app. You could get more details about Inbound and outbound IP addresses in Azure App Service.
You could use Azure Service Bus Relay to connect your web app to your on-premises database that's behind the firewall. Azure service bus relay uses internet port 80 so there should be no firewall issues. Hope it helps.
Within an App Service is a feature called a Hybrid Connection, which can be found under the Networking section of the App Service you want to connect to your back office.
You will create a new Hybrid Connection via the Portal.
Complete the form with the information that pertains to the back office system you want to connect to. You should always use a Fully Qualified Domain Name for all your back office systems. If you are connecting to multiple back office systems, you will need one Hybrid Connection for each one.
A Hybrid Connection relies on a Service Bus Relay to communicate with your on-premises resources.
You will install the Hybrid Connection Manager in your on-premises systems and connect it to the Service Bus Relay you created in the portal.
Once the Hybrid Connection you create in the Portal has been connected to a Hybrid Connection Manager (called a Listener), the connection will show as Connected in the Portal.
Once connected, an application running in an App Service will be able to communicate with your on-premises resources as if they were sitting right next to each other. There is going to be some inherent latency involved with using a Hybrid Connection and this should be planned for. The latency we have seen using Hybrid Connections have been minimal and are usually barely noticeable. I have even heard that people are streaming media from on-premises systems using Hybrid Connections.
More information about Hybrid Connections can be found here.
Just after a bit of advice please. We currently have a series of local access databases which reside on our field workers tablets. Work is assigned to these field workers using our server side web application. The workers then receive their work to their local tables using a code which sends and receives data to and from our internal domain server.
We are planning on moving away from our internal domain server to MS Azure. In order to do this we would like to be able to route all the traffic from the mobile devices to a proxy and allow one address (the proxy) to connect to Azure as it will be near impossible to whitelist all IP's in use on the cellular network.
I was wondering if anyone could shed any light on the best way of achieving something like this please? How would a proxy be set up and how could be only route the traffic trying to access MS Azure via the proxy whilst maintaining normal traffic using a direct route?
Any advice would be greatly appreciated.
Thanks,
Tony
Honestly, you would probably be in better shape to setup a VPN (Your security appliance or firewall should have one but if you want a dedicated one, look at OpenVPN). Then you just have all the tablets connect to the VPN and then as far as Azure is concerned, you only need to whitelist the office. Windows and Android can both connect to a VPN out of the box.
Good luck on the migration.
We have a setup where we have both VMs and Web Apps in Azure connected to our on-premise resources via a point-to-site virtual network.
We have an folder on premise with access to Everyone open (both on the share and NTFS) and the Azure VMs that are on that virtual network are able to browse to the share without difficulty.
The web apps are not able to access them however.
I'm assuming the following line in this article explains the reason, but I'm looking to confirm this is not possible:
The work required to secure your networks to only the web apps that need access prevents being able to create SMB connections. While you can access remote resources this does not include being able to mount a remote drive.
Coming out of the logs from the attempt from the website to access it:
Taking the C# code out of the picture, trying to get the directory listing from the powershell console on the web app:
I've also tried this with Hybrid Connections, and am getting closer - once it's setup and attached to the Web App, I'm able to tcping the SMB port from the powershell console (which is further than I can get when using the VNET), but it's still unable to list a directory:
Any thoughts? Anyone doing anything similar?
The tcping result is actually misleading - you are really pinging a local port hosted on your web app (hence why the tcping has results of ~1ms). Tcping doesn't actually test the full tunnel for Hybrid Connections because the tunnel is a TCP level data relay only (that is, it does not send TCP headers, etc., over the tunnel, only payload) and tcping does not send any data, only simply verifies that the TCP handshake succeeded.
Unfortunately, the article is correct - SMB will not work at all in your Web App. There are security layers in place that will block the attempt.
I don't know how to begin on the following. I will explain with the picture below what i want to do.
Like you so you have 2 parts. The local part and the azure part. The azure part is my part. The local network could be a customer, ....
What i went to do is running a service on the pc's and send that data to the local server/gateway. But how can i detect to what server it needs to connect. I don't install any service on the local pc's, that does the customer itself. But i don't want that he needs to do configuration. Just like they install the server/gateway part.
I will run a webservice on azure that gets information from the server/gateway on the local network. So thats no problem. On azure there are some other application that will process the messages.
Also how can you send some message back to the local network? When you say on azure ping the other local computer on the network. You should send a message to the server/gateway on your local network. But how?
So i have 2 questions(see above for more information):
Connecting from the clients to the server/gateway
Send some information back to the local netwerk
You can use Virtual Network, Azure Connect to create a "connection" or "hybrid cloud" between the PCs and the Azure cloud. However, if you are talking about web based/simple messaging and the PCs have internet connectivity why not just route the messages through a secure (SSL/TLS) connection to the cloud?
For broadcasting/push-type notifications, please look at SignalR (http://signalr.net/). Microsoft is making that part of the ASP.NET platform: http://channel9.msdn.com/Events/Build/2012/3-034
It has some real nice functionality like gracefully, falling back on multiple mechanisms if advanced things like WebSockets are not supported by the server/client. This is an ideal solution and super scalable, since it is server based and very light on the client.
If you need to connect only one or more services running on you local network and make them available publicly via azure cloud.
The most straight forward solution i found was to use the services bus. Its require nearly no modification to you business network.
We integrate with a third-party service where we can run queries which is right now secured using HTTPS encryption and username/password. We send our queries from a service running on the Windows Azure cloud.
The third-party provider wants to migrate towards better security and they have asked us to either
Setup a VPN - which is problematic because for we'd need to use Azure Connect and they'd have to install the client endpoint service on their part.
Provide some IP address where the queries will come from so they can filter out anyone else at the firewall level - which is problematic because AFAIK you cannot fix the IP addresses of the Windows Azure Compute nodes.
Suggest another secure alternative - the only thing I could think of is to set up the VPN with them on a non-Azure server and then tunnel the requests through using Azure Connect - which is obviously extra work for us and also defeats the point of hosting the service on a cloud if it depends on a non-cloud service.
Any ideas?
Can they install the Azure Connect endpoint on another server on their DMZ network? i.e. not the actual server which hosts their service?
Can we somehow provide them with static IPs for incoming queries?
Any other solution that is scalable?
Thanks
If I understand the scenario correctly, your Azure service is a client to a 3rd party service. This scenario may be solved through the use of the Windows Azure AppFabric Service Bus. You would need to install a proxy app in the 3rd party's datacenter that would be responsible for establishing the connection to the service bus. The connection comes from inside the 3rd party's datacenter, so no new incoming holes in the firewall. The connection can handle WCF connections with all its security strengths, and users can be authenticated with ACS.
Here is a starting point: http://msdn.microsoft.com/en-us/library/ee732537.aspx
There is a hands on lab in the Windows Azure Platform Training Kit that explains most of the details that you'll need.
IMHO, HTTPS is already very good; and I don't exactly see how a VPN would make the system any more secure. In particular, VPN is no silver bullet, if your VM is compromised then the VPN connection is compromised too (same for HTTPS). On the other hand, the IP restriction would indeed reduce the attack surface.
Then, using a server outside the cloud is a poor idea indeed. Not only it defeats most of the benefits of the cloud (been there, done that and suffered a lot), but also it also makes the whole thing less secure with more complexity and more attack surface.
Windows Azure does not provide anything that look like a static IP at this point. In our experience, IP addresses for a given service change once in a while even if the service is only upgraded (and never deleted). Static IP addresses have been an important feature request for a long time, Microsoft will probably provide it at some point, but it might still take many months.