Using a Partner Interconnect I'm trying to get the restricted.googleapis.com access to work and having some issues.
The BGP sessions needs to advertise 199.36.153.4/30 for that to work. Does it also need to advertise all the VPC networks? Just the region cloud router is in? None of them?
GCP allows you to advertise the 199.36.153.4/30 network on the cloud router, and it will apply for all the BGP sessions it has, or you can do it for specific ones. It depends on your needs. You only need to advertise this network in order to be known for your on-prem devices which need to know that network.
Consider that you need to define a static route for this same network for your VPC whose next hop is the default internet gateway in order to have that traffic forwarded to the correct destination. For your VMs you need to set firewall rules to allow egress/ingress traffic for this network.
If you require to refer to restricted.googleapis.com from the on-prem network, you can define in your on-prem DNS system A/CNAME records as needed.
You can read more about these topics here and here.
Related
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.
My business network is comprised of four locations across my farm, being my house, feed shed, cold storage and vet (animal welfare), due to the size of the property, the network is fibre to the house, then broadcasting a long range wifi signal with repeaters across the property to the other locations; to reach the feed shed this goes through two repeaters.
I have an R-PI running as a LAMP server, which is accessible on metrics.local and on its IP range 192.66.66.XXX (no idea why this range, that was what the original network engineer set up). The LAMP is hosting a wordpress website which captures internal metrics people record; such as feed used, we have no issues with this in the main residence. I have allowed port 80 without any restrictions as its an internal network through apache.
The problem is, whoever configured the network originally put other locations on separate domains, being 192.168.X.XXX, where the X is a different domain, so I have three LAN networks being 192.66.66, 192.168.1 and 192.168.2.
I have raised this with the network engineering team who have advised we have no firewalls blocking access between the networks and this is not a networking issue, but a server/apache config issue.
I've added routes to my LAMP server to allow the 192 range to connect to my server and I can ping the device from the computers on these other networks, however I cannot access metrics.local, with the browsers simply saying "cannot find the site".
I have reached the end of my ability to google the solution, with most routing topics being about adding additional domains to the LAMP, not allowing network access.
You are basically trying to route packets to a different networks.
192.166.66.XXX
192.168.1.XXX
192.168.2.XXX
All of these are different networks. For same network, packets can be routed by direct switches, but your network admins need the route all of the network t talk to each other using their own network gateway.
alternatively your network/sysadmin can forward your IP so it gets expose to other network, in this way it will be accessable to everyone using any one single assigned IP which works in all three network.
This is how routing works
In vnet-a, subnet-a there is aci-a.
In vnet-b, subnet-b there is aci-b.
If the virtual networks are peered both ways, shouldn't the containers be able to ping each other?
In my case, they can't. I've followed these pages:
Creating ACI in subnet:
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-vnet
Peering:
https://learn.microsoft.com/en-us/azure/virtual-network/tutorial-connect-virtual-networks-portal
Any help is appreciated!
If the virtual networks are peered both ways, shouldn't the containers
be able to ping each other?
Actually, No. And the Virtual network deployment is just the preview version. It seems that your containers just can communicate securely with other resources in the same virtual network.
Through the test, container groups just can communicate with each other in the same Subnet or different Subnets in the same VNet. Maybe they can communicate between different VNets with peering later in the new version.
Currently VNET regional and global peering are not supported by ACI. We're working on this and regional peering should be enabled in the next few months, with global peering later down the road. Your scenario you describe should be supported by regional peering if both of your VNETs reside within the same Azure region.
Check back with us at aka.ms/aci/updates for the latest news and leave us feedback at aka.ms/aci/feedback if peering is a requirement for you!
Thanks for using our service!
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.