Database connection timeout when accessing Db2 across VPC peering link

Cloud Platforms IBM Cloud
, , , , , , , ,
1

We’re experiencing intermittent connection timeouts when our application in VPC-A tries to connect to a Db2 database hosted in VPC-B. The VPCs are peered, and we’ve verified the peering connection is active. Our application logs show:


COM.ibm.db2.jdbc.app.DB2Exception: [jcc][t4][2043][11550]
Connection authorization failure occurred. Reason: ERRORCODE=-4499, SQLSTATE=08001
Connection timeout after 30000ms

The connection works about 60% of the time, but fails randomly throughout the day. We’ve checked our VPC peering configuration and it appears correct, but we’re not sure if our security group rules for the Db2 instance are properly configured for cross-VPC traffic. The routing tables seem to have the correct CIDR blocks, but we’re wondering if there’s something we’re missing in the network path between VPCs.

2

You definitely need to allow the source VPC CIDR in your security group rules for cross-VPC communication to work reliably. If you want to be more restrictive, you can limit it to the specific subnet CIDR where your application instances run rather than the entire VPC CIDR. For example, if your app runs in subnet 10.240.1.0/24, use that instead. Also verify your routing tables have the peering connection as the target for the remote VPC CIDR - this is critical for the traffic to actually route through the peering connection. Without proper routes, packets won’t know where to go even with correct security groups.

3

Thanks for the suggestion. I checked our security groups and found that the Db2 security group only has inbound rules for specific IP addresses, not the entire CIDR range of VPC-A. The CIDR for VPC-A is 10.240.0.0/16. Should I add an inbound rule allowing TCP port 50000 from that entire range? I’m concerned about opening it too wide from a security perspective.

4

Great catch on the network ACLs! I found that our Db2 subnet ACL was missing the outbound rule for ephemeral ports. After adding that rule, the connection success rate improved to about 90%. Still seeing occasional timeouts though. Could this be related to the Db2 instance itself? We’re running a small instance profile with 2 vCPUs and 8GB RAM.

5

Let me provide a comprehensive solution based on the troubleshooting thread. The connection timeout issue stems from multiple networking layers that need proper configuration for VPC peering to work reliably.

VPC Peering Configuration: First, ensure your peering connection status is “active” in both VPCs. Even if it shows active, verify the peering connection ID is correctly referenced in your routing tables.

Security Group Rules for Db2: The Db2 instance security group needs these inbound rules:


Type: TCP, Port: 50000, Source: 10.240.1.0/24 (app subnet CIDR)
Type: TCP, Port: 50001, Source: 10.240.1.0/24 (SSL if used)

The application security group needs outbound rules:


Type: TCP, Port: 50000, Destination: 10.241.2.0/24 (Db2 subnet CIDR)
Type: TCP, Port: 50001, Destination: 10.241.2.0/24 (SSL if used)

Routing Table Management: In VPC-A routing table:

  • Destination: 10.241.0.0/16 (VPC-B CIDR), Target: peering-connection-id, Priority: 1

In VPC-B routing table:

  • Destination: 10.240.0.0/16 (VPC-A CIDR), Target: peering-connection-id, Priority: 1

Network ACL Configuration: Db2 subnet ACL:

  • Inbound: Allow TCP port 50000-50001 from 10.240.1.0/24
  • Outbound: Allow TCP ports 1024-65535 to 10.240.1.0/24 (ephemeral ports for return traffic)

App subnet ACL:

  • Outbound: Allow TCP port 50000-50001 to 10.241.2.0/24
  • Inbound: Allow TCP ports 1024-65535 from 10.241.2.0/24 (ephemeral ports for return traffic)

Additional Checks:

  1. Verify DNS resolution if using hostnames - consider using private IPs directly for cross-VPC connections
  2. Check Db2 MAXAPPLS setting: db2 update dbm cfg using MAXAPPLS 200 (adjust based on your needs)
  3. Implement connection pooling in your application with proper timeout settings
  4. Monitor connection metrics in IBM Cloud Monitoring to identify patterns in the failures

The key is ensuring symmetric rules at all layers: security groups, network ACLs, and routing tables. The intermittent nature of your issue suggests incomplete configuration at one of these layers. After implementing all these changes, you should see 100% connection reliability. If timeouts persist, they’re likely application-layer issues (connection pool exhaustion, application timeout settings too low) rather than network infrastructure problems.