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.
Related
Is there any way to setup a static inbound IP for azure IoT hub? I'm not much experienced with networking. My client have a firewall, it is IP based. They need to set IP whitelisting. What should be the best way to achieve this?
The IP address prefixes of IoT hub are subject to change. These
changes are published periodically via service tags before taking
effect. It is therefore important that you develop processes to
regularly retrieve and use the latest service tags. This process can
be automated via the service tags discovery API. Note that Service
tags discovery API is still in preview and in some cases may not
produce the full list of tags and IP addresses. Until discovery API is
generally available, consider using the service tags in downloadable
JSON format.
IoT Hub IP addresses
In addition to the above, You can use IP filter to receive traffic only from a specified range of IP addresses and reject everything else.
By default, the IP Filter grid in the portal for an IoT hub is empty. This default setting means that your hub blocks connections from all IP addresses. This default setting is equivalent to a rule that blocks the 0.0.0.0/0 IP address range.
You can follow the documentation Use IP filters for more details.
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.
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.
The laptops of our company have a WCF sync/client installed which communicates with the Server.
The data transfer works as long as they do not connect with the VPN.
When they connect with the VPN, I can make the WCF client Sync again if I add the "proxyaddress" paramater to the .config file.
Question : how can I make it work in both scenario's? Is there a way the WCF client makes a "smart selection" of multiple endpoints?
This issue more relates to network, route, instead of WCF.
When we connect to VPN, an extra virtual network interface is created on the local machine. At the same time, the local routing table is changed, which caused the issue that the internal network address could not be accessed. We can solve this by setting up a proxy address. A more general way is to set a static route on the local machine.
Route add –p 172.17.10.0 mask 255.255.255.0 172.17.16.1
The first address is a destination network address. the last address is a local gateway, which can be routed by a local network interface. This will lead to the data packages sent to the destination network to be addressed from the specified network interface.
Here is a related link.
https://docs.oracle.com/cd/E53394_01/html/E54745/gmyag.html
Feel free to let me know if there is anything I can help with.