I have a non-azure, non-Windows, non-microsoft site-to-site tunnel set up between an Azure cloud environment and an on-premise LAN; at the azure end, the proprietary (non-microsoft) S2S host sits behind an Azure load balancer.
The proprietary tunnel is route-based and as such, I'd like to route connections all the way from our on-premise network to various resources in Azure.
e.g.
OnPrem Server -> OnPremFw -> (tunnel) -> CloudFW -> LB -> vNET1 -> vNET2 -> VMtarget
When packets hit the CloudFW, they are being "Hidden NAT'd", so the source IP address is translated from its On-premise IP address to an IP address recognised by Azure as directly associated with an Azure subnet range. In this case, things work as expected.
However, if I turn off the H-NAT, so that packets carry their original on-prem source IP address in to Azure, then no matter what security or routing rules I apply, nothing works.
Is it plausible that Azure is passively dropping these packets, or is silently screening them out, something like address spoofing?
I can't find any Azure documentation confirming this, but the behaviour I am seeing strongly implies this must be the case. Could anyone confirm?
I would like to know if essentially, it isn't possible to use "non-Azure" IP addresses in Azure routing and security configurations.
thanks
The answer to this question is No.
It is possible to use non-Azure-defined IP addresses in Azure route table rules and in Azure nsg rules.
Related
Configuring a VNet-to-VNet connection is the preferred option to easily connect VNets if you need a secure tunnel using IPsec/IKE. In this case the documentation says that traffic between VNets is routed through the Microsoft backbone infrastructure.
According to the documentation, a Site-to-Site connection is also possible:
If you are working with a complicated network configuration, you may prefer to connect your VNets using the Site-to-Site steps, instead the VNet-to-VNet steps. When you use the Site-to-Site steps, you create and configure the local network gateways manually.
In this case we have control over the configuration of the virtual local network address space, but we need expose public IPs. Documentation don´t says nothing about where the traffic goes (azure internal or public internet)
My question is, in this scenario, S2S between VNets, the traffic is routed through azure infrastructure as in the case of VNet-to-VNet or the comunication is done through public internet?
edit
The traffic in an S2S between VNets is routed through Microsoft backbone network. See this doc.
Microsoft Azure offers the richest portfolio of services and
capabilities, allowing customers to quickly and easily build, expand,
and meet networking requirements anywhere. Our family of connectivity
services span virtual network peering between regions, hybrid, and
in-cloud point-to-site and site-to-site architectures as well as
global IP transit scenarios.
For the scenario where a firewall/proxy doesn't support IoT Hub's FQDN.
The recommended approach is to script the updating of the firewall's whitelist - not going to happen in our case.
My plan B is to introduce a "gateway" on the IoT Hub side to provide a static IP address, and forward traffic to IoT Hub. I can see a few azure appliances which might serve here:
Azure Application Gateway
Azure Firewall
Azure Load Balancer
Proxy Server on VM
Has somebody been through this? What was your experience, and where did you land?
I have implemented something like this by building an HA proxy solution (based on Squid proxy) on a VM Scale Set with a Load Balancer in front. You can find the full solution here: https://github.com/sebader/azure-samples-collection/tree/master/VmssProxySolution
This one uses an internal LB (private IP) but you can also easily modify this to expose a static, public IP.
I have a Web App (Azure App Service) and I have an Azure SQL Database that this Web App talks to. I have two questions regarding communication between the two.
When connecting from the Web App to the Database (using the connection string), does the communication go out to the internet and then back into Azure or does Azure know to keep the traffic locally in Azure?
I have been looking into V-Net Service Endpoints as a possible way to improve speed of communication between the two. It is said that when connecting from a VM on V-Net with Service Endpoints enabled to a SQL Database, that Azure knows to keep the traffic internal to the Azure network and not go out to the internet, is this the same for Azure App Services?
Is it possible to keep traffic between an App Service and SQL Database internal to Azure? If so, how do I go about doing this? Any guidance on this is greatly appreciated.
It knows to keep it local on the "Azure backbone" (as per Azure doco). It doesn't go out to the public internet
Yes
Yes. It is already internal to the "Azure Backbone"
Having said that.... networks are really complicated.
As I understand it the main benefit of V-Net is that you can define your own network and add things to it like firewalls, security groups, subnets, peering between networks. Also it helps when setting up a hybrid network - i.e. connecting Azure resources to an on-premises network. When you can set up the same kind of structures as on premise, it's easier to 'transparently' make it part of the on-premises network. Lastly (rereading the doco), you can remove any incoming public IP firewall rules. These are "Azure backbone" IP addresses but they are also "public internet" addresses
There may be a performance improvement if the App Service and Azure SQL are on the same V-Net.
Azure SQL service endpoints are a bit mysterious. They "connect" to the VNET but you still need to connect to a public address. They don't actually take a up a local IP adress.
Depending on what you are really doing, you might want to look into private endpoint, which actually assigns a private IP to your Azure SQL.
Yes, communication between Azure App Service and Azure SQL Database is "local" within the Azure Virtual Network and does not go out to the public internet.
I have question around DLP (data leakage prevention) from a corporate network.
I have a Virtual Machine on a corporate network. The VM can access an Azure SQL DB in the cloud: aaa.database.windows.net through a connection over port 1433.
However, I don't want that same VM to connect to bbb.database.windows.net.
Azure offers no guarantees on the public IP (both servers could appear as the same IP) - what technology can I use on the corporate's perimeter network/firewall to permit access to aaa but disallow access to bbb?
The attack I am concerned about is someone internal to the company querying data out of aaa and inserting it in to bbb. For example, if the one server is ourcorporatedate.database.windows.net and the other is somerandom.database.windows.net the someone internal to the company could take corporate data and write it to some random database.
Thanks
You can use Virtual Network service endpoints and rules. Virtual network rules are one firewall security feature that controls whether your Azure SQL Database or SQL Data Warehouse server accepts communications that are sent from particular subnets in virtual networks. Learn how to use it and benefits/limitations on this documentation.
If database aaa and bbb have the same public IP address. I think there is not a good way to set in the on-premise firewall to permit access to aaa but deny access to bbb. From the same client, the firewall rule will have the same source IP, protocol, port, and destination IP for outbound traffic.
If you want to selectively grant access to just one of the databases in your Azure SQL server, you can only create a database-level rule for the required database. Also, Specify an IP address range for the database firewall rule that is beyond the IP address range specified in the server-level firewall rule, and ensure that the IP address of the client falls in the range specified in the database-level rule. Server level rules allow access to the Azure SQL Server. Which means that the client will have access to all the databases stored on that SQL Server. Refer to this doc.
The current VPN feature in SQL Azure does not directly prevent this (but please look for future updates where this is planned for the service endpoints feature for SQL Azure). However, there are various mitigations you can use to detect or reduce the ability to do this:
You can enable auditing on the aaa database. This can detect all logins and major state changes to the DB. (Detect)
You can reduce the permissions for various kinds of users on the database to the bare minimum and use features which further reduce the size of the data that a customer can copy out of the database at all. This includes row-level security, data masking, always encrypted (which you would lock down to a specific app/user to be able to decrypt sensitive data in the client - other clients without the key just get cypertext), etc.
Use firewall rules (as stated in the other answers) to restrict which clients can connect to the database at all - then you can restrict where they can connect with permissions.
Please note that SQL Azure's logical servers do not generally imply that every customer database in that server has the same IP. Currently there is a knob in service endpoints (docs page is currently down so I can't get you a link atm) to configure whether you go through the per-region gateway or not. If you don't (recommended), you would see the IP of the hosting node and this can change over time. The Service endpoints feature will give VPN users more control for network-level rules going forward, but some of these features have not yet landed in production. I encourage you to mitigate with other steps (above) until that is available to you.
Our product has software-managed virtual networks and has multiple local IP addresses from which network communications could be routed. One of the requirements we have is to ensure that outgoing traffic is routed from a specific, desired local IP when communicating with the Azure blob storage endpoint.
The Azure SDK does not seem to expose any means of specifying which local IP address to use for communications to the Azure blob endpoint. Please let us know if you think the SDK does expose and if so how we can utilize the facility.
If not, we are evaluating making changes to the azure-storage-java SDK source in order to support the local IP binding requirement.
Has this kind of situation been brought to your attention before? Do you have any suggestions as to how this might be accomplished?
Thanks,
Sowmya.