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:
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.