1

I am currently facing an issue with Azure's managed PostgreSQL Database. I've set up the database and associated resources according to several Microsoft guides, but when I connect to the VPN, I am still unable to resolve the address of the database.

The PostgreSQL database is part of a Virtual Network (VNET), namely myVNET-db, with a private DNS zone (myDB.private.postgres.database.azure.com). This VNET is peered with another VNET named myVNET.

Here are the subnets within myVNET:

default (10.224.0.0/16)
GatewaySubnet (10.225.0.0/24)
AzureBastionSubnet (10.225.1.0/26)
snet-inbound (10.225.2.0/28)
snet-outbound (10.225.3.0/28)

I've configured a VPN with point-to-site, and I've also set up a Private DNS resolver. The resolver is linked with both snet-inbound and snet-outbound subnets and has a ruleset added to its outbound endpoint (myDB-endpoint) that maps myDB.private.postgres.database.azure.com to 10.1.0.4.

However, despite the configurations, when I connect to the VPN, I am unable to resolve the address of the database. It seems that the DNS resolution isn't working as expected.

Here are the Microsoft guides I followed for setting up the environment:

What could be the issue here? How can I successfully resolve the PostgreSQL database address over the VPN? I'm keen to ensure that the database isn't accessible publicly for security reasons.

I'd appreciate any insights or recommendations to troubleshoot and resolve this issue.

Thanks in advance!

asCii88
  • 23
  • 6

1 Answers1

0

I tried with the Azure PostgreSQL Database - Flexible server. I don't know if this might be of help. Look at the DNS resolution and verify if it functions correctly within the VNET itself. You can test this by spinning up a VM within the VNET and attempting to resolve the PostgreSQL database address from there. This will help determine if the DNS resolver and private DNS zone is functioning as expected within the VNET. Again, kindly double-check your VPN configuration to ensure it is correctly set up for point-to-site connectivity. The VPN client must be configured to use the DNS resolver associated with the VNET. The following documentation might help. Documentation LINK 1 Documentation LINK 2

iamgoddey
  • 37
  • 1
  • 11
  • I've created two VM's, one in each VNET. Looking further into my private DNS zone, I see several records listed. However, an observation that is adding to my confusion is the behaviour when pinging test-vm and test-vm2. From both VMs (myVNET and myVNET-db), I am able to successfully resolve test-vm and test-vm2, but I can't ping them from my local machine, even when connected to the VPN. – asCii88 Jun 10 '23 at 16:02
  • The real challenge remains with pinging myDB.private.postgres.database.azure.com - this does not work from either VM. This is perplexing as the connection string for the PostgreSQL Flexible Server shows this address as the server address, not just the DNS. What am I missing here? Why can't I resolve the PostgreSQL Flexible Server's address? Is there a particular setting or configuration that might be causing this issue? Any further advice on how to diagnose and resolve this problem would be greatly appreciated. – asCii88 Jun 10 '23 at 16:02
  • I've managed to resolve the database from the VM in the myVNET and was able to establish a connection. I'm not entirely sure why it wasn't working before, but that seems to be functioning correctly now. However, the main issue remains. I'm still unable to resolve the database through the VPN connection from my local machine. Despite the peering and seemingly correct DNS resolver configuration, I can't seem to make this work. – asCii88 Jun 10 '23 at 16:14
  • Try clearing the DNS cache on your local machine to ensure that you're using the updated DNS resolution `ipconfig /flushdns`. Then, on your local machine, try directly resolving the `FQDN` of the database using the private `DNS` zone. Use `nslookup .private.postgres.database.azure.com` to directly query the DNS resolver to see if it can resolve the `FQDN` of the database. Check if the IP address returned is correct. And check if no firewall rules are blocking the incoming connections. – iamgoddey Jun 10 '23 at 17:37
  • Thanks for that suggestion. It hasn't helped, though. – asCii88 Jun 10 '23 at 22:33
  • hey @asCii88 did you find any way of debugging this? or a solution, having the same issue right now – zoluxero Aug 13 '23 at 23:08
  • No, sadly I haven't found the solution. Quite rubbish of you ask me. – asCii88 Aug 24 '23 at 16:34