I have a scenario where I have a Windows VM in windows Azure that needs to connect to an external customer network (and connect to a database that is not in Azure).
This traffic is uni-directional in that it is only my VM that needs to connect to the customer's databases and not the other way around. Site to site is managed on Azure, which I cannot really test locally.
Conceptually, connecting to the customer's network via a point-to-site VPN seems more suitable (by creating the VPN connection in Windows itself via the network config).
The customer prefers site-to-site even though they don't need to connect to my VM. Am I missing something?
In point-to-site, you have to connect to the network you want to access manually. Usually, if you log-off or restart the workstation it loses connection, and you have to reconnect every time. It's common to use this type of VPN when we are working remotely, and we need to access our company assets. The channel is bi-directional, but it's 1-to-many.
Site-to-site is used when you want to connect two networks and keep the communication up all the time. It's also bi-directional, but it's many-to-many and stays up no matter if your server/workstation is running or not because the connection is established through a network gateway and not from the computer operating system.
In Azure, the Virtual Network Gateway is the platform providing both functionalities. You can configure site-to-site to connect to your customer network. If this network is not running in Azure, they usually have an appliance to establish dedicated tunnels. As long as it supports IPsec IKE, you are good to go.
If you are using the VM in Azure as a workstation, then point-to-site may be enough, but if your application needs to get data from the customer database automatically with or without someone logged in the VM, then site-to-site is a better approach.
A better explanation can be found here
Related
So, I've encountered a weird situation and am wondering whether you may have some suggestions as to how to investigate it...
I have a C# app that connects to Azure Blob Services using the latest SDK and TLS 1.2. When I am at home and on the Internet, I am able to upload files to blob storage without any issues. However, when I go into our office, using the same app on an office computer, I get a connection failure. I am able to access the Internet through a browser.
The networking is as simple as at my home... ISP connection, router/firewall, my computer.
I cannot imagine why enabling TLS1.2 would suddenly make my app not work in the office, but still work at home. Based on these tests, it seems like a NIC issue or an infrastructure issue at the office, but I have never heard of a NIC or router blocking TLS 1.2 outside of a VPN connection. There is no VPN involved.
I am planning on directly connecting my computer to the company's Internet connection, configuring the nic for the wan, and see what happens. If it works, then there must be something strange going on with the company's router (nothing elaborate; netgear, or such).
Has anyone encountered this issue? Seems really odd to me...
Thanks for your time and interest,
Mike
• It is not an issue with enabling of TLS 1.2 on your office network or your home network or even your Azure blob storage, it is basically related to the communication over SMB TCP port 445 from your local system to the mapped Azure blob storage on your system.
On your home network, you were able to access the blob storage and able to upload files in it because your ISP has enabled outbound communication over SMB TCP port 445 on his firewall and gateway server over the internet and thus, you were able to access the mapped Azure blob storage and upload files in it. But the same case is not valid for in your office network as it being a protected one, outbound communication over SMB TCP port 445 is restricted and not allowed.
• To test whether communication over TCP SMB port 445 can happen or not, I would request you to execute the below powershell command and check the results thereafter: -
Test-NetConnection -Port 445 -ComputerName somestoragexxx.file.core.windows.net
If this TCP 445 connectivity fails, then you could check with your ISP or your on-premises office network security is blocking communication over outbound port 445. Please note that you should open the outbound port instead of inbound port 445.
Kindly refer to the documentation link below for details to know the different ways to access files in Azure files: -
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-faq#general
Also, refer to the link below for knowing the Azure routing mechanism to reach the resources hosted on Azure: -
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#default
I am getting connection time out when I try to ssh to my Azure VM on a specific ISP provider, not any other ISP provider. I did notify them about this issue but they do not know what might seem to be the issue.
Also tried to create a new rule to open port 22 on windows Machine, followed all Azure troubleshooting methods, disabled my Firewall, but nothing seems to work, Only when I connect to a different ISP provider.
Please take note that the ISP through which you were trying to connect to your Azure VM over port 22 through SSH is blocked over public internet owing to various server side vulnerabilities. The vulnerabilities that the SSH server side is prone to includes Port forwarding, unauthorised SSH access, vulnerable SSH configuration, pivoting and unpatched SSH software. Along with Port 22, most ISPs also block SMB port 445 also on the public internet owing to frequent and hot instances of brute force as well as software manipulation attacks. Since, users are not known to take care or take appropriate security measures for avoiding such attacks, so the ISPs block the inbound as well as the outbound traffic on these ports overall.
You can check by connecting through some other ISP or using cell phone internet in that case as these ports are not blocked over there.
I have a client who is remote. I need to debug some weird problem that none of my other clients are having. Before I try and set up a conference with this client, I would like to know if there is some way of remotely debugging our application.
I see that there are remote debugging tools available for Visual Studio, but from what I've read, I need to be on the same subnet. As the person is remote, this is not a possibility. Also, as I'd like to keep our connection secure, I would need to connect up some sort of encrypted tunnel (this is where I'm a little fuzzy as my networking skills are mostly theoretical).
As I understand it, an encrypted tunnel is a bridge to another (different) subnet. This is to ensure that those computers on the other side won't interfere with the local subnet computers.
So, because the client's computer is on a different subnet, I think that this is not possible. Or is it? Should there not be a way of making the client's computer show up as a virtual computer on my subnet, by forwarding packets from one subnet to another? I would think that this is theoretically possible, but I'm not exactly sure how I would go about this.
Also, at the moment, my current way that we connect to clients is through GoToMeeting, but I don't think that it supports tunneling. If not, then I may need some way of generating a tunnel, so I was also thinking of maybe using some SSH programme like PuTTY.
As I have said before, my knowledge of networking is quite theoretical, so if the tools that I am suggesting are not the correct ones, please correct me. (I'm a programmer, damm it! Not a network engineer!)
Both computers are Windows boxes. Windows 10 (client) and Windows 8.1 (development).
If you can connect to an ssh server in the remote network, you can (subject to configuration on the server) create a tunnel such that you connect to a socket on your local pic and the connection appears from the server to an endpoint on the remote network.
You'll want to investigate the -L command of OpenSSH, which combined with the PuTTY docs, should help explain what's required.
By default, the endpoint would be a port on the ssh server, but it could be a port on a different host that the remote server can connect to.
I'm not familiar with the current state of Windows SSH servers, but even if there isn't a system server to hand, you should be able to have on run 'on demand' - if you run it on a non-privileged port and by the user you want to connect in as, it shouldn't even need Admin privileges.
I'm not familiar with GoToMeeting, but the one thing with SSH tunnelling it that IT depts should be familiar with SSH. If trying that, focus on getting a working connection in, then setting up the tunnel, then connecting through it as separate steps.
Once you have an SSH connection, then it doesn't need to do something itself, and you can then investigate connecting while specifying the port forwarding, but will will need to get the basic connection working correctly first.
I'm a little stuck when trying to configure an Azure site-to-site network. I'm using this to connect from Azure into another site for remote management of multiple devices there.
Currently, I believe the majority of the set up to be completed but I now need to secure public IP address for the external site so that they can add these to their firewall rules. Does anyone know how I am meant to acquire the public IP of the VM (which changes each time it is shut down and restarted) or the sites public IP connection to the external site?
Alternatively, what's the best way of doing this? I feel like a site-to-site network doesn't quite fit in with what I'm trying to do but I'm only being offered this solution from the external site (not necessarily just using Azure, though).
You can assign a static IP to your VM:
http://azure.microsoft.com/blog/2014/04/22/static-internal-ip-address-for-virtual-machines/
Azure Connect is a service found on the older Azure.com portal and allows connectivity between on-premise and cloud servers/roles/resources. It creates a virtual IP (overlay) network - pretty much a VPN.
Azure Virtual Network (found on the new Azure portal) is ALSO touted as a VPN solution for also the same purpose however the configuration seems a lot twisted (although with a pretty UI).
I'm confused how these two product stack up against each other. Googling and searching MSDN didn't reveal much information either.
What are the differences between them and the target use-cases? Are they expected to be merged into one product down the road?
The use case for us is a WebRole that's running as a cloud service, whose REST/Web API services are consumed by machines on a private network. Azure Connect or Azure Virtual Network would (should?) provide the underlying connectivity between them.
Azure Connect allows users to connect Azure applications with on-premise servers in a super simple and quick way. It does not require VPN devices, it does not require user to have network knowledge, it does not require/assume user have access to network infrastructure (e.g. ability to configure the firewall at company's edge firewall). You express your connectivity intent (e.g. Azure service x should connect to a set of machines (machine group) y on-premise) in the management portal, Azure Connect does the rest for you. It is also very flexible in that you can change the network and connectivity policy at any time via the portal, without requiring redeployment of your app or any change on-premise. e.g. you can make Azure service x to connect to machine group z on-premise instead of y, once you make that change in portal, the rest happens automatically, machines in y are not long accessible to/from Azure. Azure Connect uses endpoint software to manage all the network connectivity for users, so you do have to install endpoint software. But it supports many different automatic deployment options including using Microsoft Update.
Azure Virtual Network allows user to extend part of their on-premise infrastructure to your Azure virtual network via standard site-to-site IPSEC connection. You must have an internet facing VPN device at on-premise side. The solution also assumes you have network knowledge - you will be asked to specify the network address range you will be using at both Azure and on-premise sides, you will must launch a VPN gateway at Azure side and manage the IPSEC connection. It does not require install endpoint software on servers, you are responsible for setting up routes to route the traffic from VPN device to servers and vice versa.
The two technologies complement each other, they are suitable for different scenarios.