We’ve been using ESC for quite a while, the single peering to a single VNET on our side made sense at the time but we’ve been wanting to split it up.
Since we can only create one peering from an Azure hosted ESC to a VNET on our side, the idea is to peer the ESC to a so-called Hub VNET and peer other VNET’s to the Hub network so that resources running in other VNET’s may also access the EventStore instance.
So, another VNET was created and a peering created between the VNET which is peered to the ESC, and a VM was set up in the new VNET.
We see that the hostname of the EventStore can be resolved to an actual IP address, however every subsequent attempt to ping/curl/telnet the resolved IP address or hostname fails with a timeout. Seeing as we don’t have any blocking rules in the communication between the two VNET’s we were starting to wonder if we’re missing something on the EventStore side and need some additional config?
Are the routing between all those networks setup ?
Yes, a peering was created between the two VNETs on our side, with the default Azure settings. Hence the fact that we see that the hostname can be resolved to an IP address. Any communication between subnets in the two VNET’s is completely open
.
Now, we are able to ping the EventStore using a VM in the VNET which is directly peered with the EventStore, but a VM running in the 2nd VNET is just getting timeouts.
Should we add remote address of every additional VNET to the peering created in ESC?
Edit: We’re also able to ping the private IP of the VM in the first VNET from the VM in the 2nd VNET, so routing should be okay
from what I read the routing between directly connected vnet is ok .
< Eventstore Vnet > – < your Vnet 01 > ok
< your Vnet 01 > – < your Vnet 02 > ok
Is the routing from < your VNET2 > to < EventStore vnet > through < your vnet01 > defined ?
Hostname resolution is entirely different : it’s DNS resoltuion and nothing to do with VNETs themselves
It’s probably related to the known Azure peering limitation. There are certain options in the Azure peering setup that needs to be enabled to allow passing traffic to remote network. It used to be one checkbox, now it’s like three different options. We have this in the roadmap with high priority, but it still can be some time before we can get it right.