Google Cloud cannot connect to reserve.dlt.go.th on TCP 443, while AWS and ISP networks can

Google Compute Engine instances and Google Cloud Shell are unable to establish TCP/HTTPS connections to reserve.dlt.go.th on port 443.

The connection consistently times out.

The same destination is reachable successfully from AWS Thailand and from a Thai ISP network. Other websites are reachable normally from Google Cloud.

This issue occurs from both Compute Engine and Cloud Shell, so it does not appear to be specific to a single VM or external IP.

Could this be a routing, peering, or destination-network filtering issue affecting traffic originating from Google Cloud?

Destination: reserve.dlt.go.th
Protocol: HTTPS / TCP 443
GCP Region: asia-southeast1

Anyone can help?

I tested this from GCE and confirmed it isn’t a Google Cloud routing or egress issue. reserve.dlt.go.th (58.64.41.195) responds to ICMP (ping) from GCE with 0% packet loss, and other *.dlt.go.th hosts in the same 58.64.41.128/25 subnet (www.dlt.go.th at 58.64.41.181 and eservice.dlt.go.th at 58.64.41.151) complete TCP/TLS handshakes on port 443 normally. This confirms forward and return BGP routing between Google Cloud and the upstream ISP in Thailand (AIS/AWN, AS45458) is working as expected.

Running a TCP traceroute on port 443 (traceroute -T -p 443 / mtr -T -P 443) to 58.64.41.195 vs. 58.64.41.181 shows that TCP SYN packets reach the destination network before being dropped:

# reserve.dlt.go.th (58.64.41.195) - TCP/443
TTL= 9: 49.231.251.204    (AIS/AWN demarcation hop)
TTL=10: 49.231.251.204
TTL=11: 58.64.41.195      (ICMP Time Exceeded from destination perimeter)
TTL=12+: * * *            (TCP SYN dropped)

# www.dlt.go.th (58.64.41.181) - TCP/443
TTL= 9: 49.231.251.204    (AIS/AWN demarcation hop)
TTL=10: 58.64.41.181      (ICMP Time Exceeded from destination perimeter)
TTL=11: 58.64.41.181
TTL=12: 58.64.41.181
TTL=14: 58.64.41.181:443  (TCP SYN-ACK received)

At TTL=11, the TCP SYN to 58.64.41.195:443 passes the ISP handoff (49.231.251.204) and hits the first hop inside the dlt.go.th perimeter, then times out at TTL >= 12. My assumption is that the firewall/WAF in front of reserve.dlt.go.th is dropping TCP traffic based on either 1) an outdated GeoIP database – Google Cloud’s asia-southeast3 (Bangkok) prefixes in cloud.json (34.3.32.0/20, 34.15.128.0/17, 34.183.6.0/23, 34.184.6.0/23) are carved out of Google’s ARIN 34.0.0.0/8 block, which still shows Country: US in raw WHOIS if the firewall doesn’t ingest Google’s geofeed – or 2) an explicit block on Google Cloud’s ASN (AS396982 / AS15169) to prevent automated booking scripts.

To resolve this, the dlt.go.th network team would need to allowlist your Cloud NAT / GCE external IP (or update their firewall’s GeoIP feed to include the asia-southeast3 prefixes above), or you would need to egress traffic for 58.64.41.195/32 through an on-prem connection or proxy on a local Thai ISP network.

Thank you very much