Troubles connecting Azure App Service to a Bitnami Mongo ReplicaSet through Network Peering

0
votes

As per the title, I have 2 different resource groups:

  • App Service running 2 containers with our Node application. It has no VNet configured by default. Let's call it AS from now on.
  • MongoDB ReplicaSet by Bitnami, containing 2 instances. It has a VNet configured by default: address space 10.0.0.0/24, with instances having assigned addresses 10.0.0.4 and 10.0.0.5. Let's call it DB from now on.

I wanted to create a network peering in order to let App Service Plan talking with Databases. Since AS hasn't a VNet, I had firstly to create one. Here is the network topology before the peering:

  • AS: address space 10.1.0.0/24
  • DB: address space 10.0.0.0/24

I then created the peering AS => DB, so far so good. Azure Portal display the networks as an unique one, with flag "Connected". Also, the App Service Plan's Virtual Network Integration interface looks good. If you look at the bottom of the image, you'll see as Address routed to Vnet the DB's address space, that is 10.0.0.0 to 10.0.0.255.

enter image description here Despite the network peering seems configured correctly, my Node applications still can't connect to the databases. I got mainly two errors application-side so far:

  • [MongoError: connect ETIMEDOUT 10.0.0.5:27017]
  • [MongoError: connect EACCES 10.0.0.5:27017]

whereas Azure Container's tcpping gives me either:

  • An attempt was made to access a socket in a way forbidden by its access permissions 10.0.0.5:27017
  • Connection timed out

Any idea?

1
azurenetworkingazure-virtual-networkazure-app-service-envrmnt
Do you have a route pointing back to the point to site address space from the 2nd VNET? (e.g. 192.168.0.0/24 via 1st VNET). I don't believe the VNET peering will tell the 2nd VNET about the point to site address space by default. – evilSnobu

1 Answers

1
votes

Do you have a route pointing back to the point to site address space from the 2nd VNET? I don't believe the VNET peering will tell the 2nd VNET about the point to site address space by default.

There are some checkboxes in the VNET peering configuration which are a bit shady in their description, here's what works, meaning what will add that route for you:

VNET peering with point-to-site address space

Restart the Web App after you make the changes, give it a few seconds and test with tcpping. There's probably some BGP in this mix, so if it doesn't work right away just give it a minute.