Cannot connect to Azure DB for PostgresSQL flexible from different vnet

Question

Hi, we cannot connect from an AKS pod running in one VNET to an Azure DB for PostgreSQL flexible server running in a different VNET. We can connect from an AKS pod running in the same VNET. The error is demonstrated by running curl from the pod:

curl -v redactedname.postgres.database.azure.com:5432*
** Trying 10.77.0.212:5432...*
** connect to 10.77.0.212 port 5432 failed: Connection timed out*

We have configured private access to the Azure Database for PostgreSQL flexible server according to the documentation https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-networking-private#virtual-network-concepts. Our setup is similar to that shown in diagram (attached) from the article, where the green arrow shows a successful connection from an AKS cluster in the same VNET, whereas the red arrow shows unsuccessful (timed out) connection from AKS cluster in another VNET. The VNETs are peered using a hub and spoke model and we know this is working for other use-cases between the same VNETs, so we do not think this is the problem.  The private access to the Flexible Server has been configured according to the documentation link above:

• Delegated subnet
• Subnet configured with CIDR range of /28 to give 16 IP addresses.
• There are no Route Tables associated to the subnet.
• HA is not configured
• The Network Security Group associated to subnet has been configured to allow inbound traffic on from AKS cluster  to the server on port 5432

The problem seem to be when the request reaches the subnet of the PostgreSQL server (or the server itself) since the flow logs of the NSG associated to subnet show initial connections being established, but without packets being sent:

"rule": "UserRule_postgres_allow",

                        "flows": [

                            {

                                "mac": "6045BDF210A3",

                                "flowTuples": [

                                    "1718283991,10.76.0.180,10.77.0.212,57622,5432,T,I,A,B,,,,",

                                    "1718284008,10.76.0.180,10.77.0.212,32802,5432,T,I,A,B,,,,",

                                    "1718284041,10.76.0.180,10.77.0.212,36740,5432,T,I,A,B,,,,"

                                ]

                            }

                        ]

                    }

Any help with this would be greatly appreciated.

Thanks,

Andy.

Answer 1

Yes by raising a support request. Here's a summary of the findings:

Issue:  Transitive between spokes is not possible, reviewing the configuration it appears that we have it partially configured based on our documentation:

https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke?tabs=cli#spoke-connections-through-azure-firewall-or-nva

 Summary:  Route Tables with specific UDRs for both Spoke VNETs are needed to facilitate a path to the HUB VNET

Solution: Customer’s Network team was successful in updating the Spoke VNET’s Route tables to send traffic for the neighboring spoke to a common virtual appliance, in our case it was the Azure Firewall in the Hub VNET.

Answer 2

Hi @Wilde, Andrew I am glad issue was fixed. Thank you for sharing the solution with the community.

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer. Accepted answers show up at the top, resulting in improved discoverability for others.

Issue:  Transitive between spokes is not possible, reviewing the configuration it appears that we have it partially configured based on our documentation:

https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke?tabs=cli#spoke-connections-through-azure-firewall-or-nva

 Summary:  Route Tables with specific UDRs for both Spoke VNETs are needed to facilitate a path to the HUB VNET

Solution: Customer’s Network team was successful in updating the Spoke VNET’s Route tables to send traffic for the neighboring spoke to a common virtual appliance, in our case it was the Azure Firewall in the Hub VNET.