Unable to connect to Minecraft Server

[SlamJammington 0]

Good afternoon,
I'm attempting to host a FTB minecraft server through AirVPN. When attempting to connect to the public server IP, Minecraft throws the error "Connection timed out: getsockopt". I've followed all the steps at this link and this link, and still receive the same error. I was able to connect using the local IP at the port I specified (not 25565). Here's a quick list of all the steps I've tried:

• Restarted PC & AirVPN
• Add all Minecraft authentication & API to outside the VPN tunnel
• Double checked the public exit IP
• Added firewall rule to the port (allow all)
• Tried different port
• Tried different server

Any input or further troubleshooting steps would be greatly appreciated.
Edited ... by SlamJammington
adding additional relevant tags

[OpenSourcerer 1450]

Entering a domain (= supplying a domain to OpenVPN's --route) does NOT do what you think it does. What it actually does is resolving those domains once at connect, then adding the retrieved IP address (only the first result for every domain!) to --route for the remainder of the session. If those records change (which happens often for load balancing and selecting the correct region), you're going through the VPN again. You must enter the IP address (range) of every domain.

[SlamJammington 0]

On 1/26/2025 at 4:52 AM, OpenSourcerer said:

Entering a domain (= supplying a domain to OpenVPN's --route) does NOT do what you think it does. What it actually does is resolving those domains once at connect, then adding the retrieved IP address (only the first result for every domain!) to --route for the remainder of the session. If those records change (which happens often for load balancing and selecting the correct region), you're going through the VPN again. You must enter the IP address (range) of every domain.

Ahhh that makes sense (I think), so I need to add the rest of the associated potential IP addresses for those domains to the list as well? What would be the best way of determining the correct ranges to add?

Thanks!

Update: used whois to find all IPs for those domains and sadly the issue still persists Edited ... by SlamJammington

[OpenSourcerer 1450]

On 1/26/2025 at 7:41 PM, SlamJammington said:

Update: used whois to find all IPs for those domains and sadly the issue still persists

Don't use IPs, use IP ranges (in CIDR notation). Also, you're fighting the same battle as everyone who wants to exclude only IPs of Netflix for example. Just, give up. Play outside the VPN.
For reference, the result for just one domain, for just one protocol version:

$ dig aaaa in api.mojang.com
[…]
;api.mojang.com.                        IN      AAAA

;; ANSWER SECTION:
api.mojang.com.         54      IN      CNAME   api-mojang-com-bxfdd0a4f8c6frfz.z01.azurefd.net.
api-mojang-com-bxfdd0a4f8c6frfz.z01.azurefd.net. 27 IN CNAME star-azurefd-prod.trafficmanager.net.
star-azurefd-prod.trafficmanager.net. 53 IN CNAME shed.dual-low.s-part-0017.t-0009.t-msedge.net.
shed.dual-low.s-part-0017.t-0009.t-msedge.net. 47 IN CNAME s-part-0017.t-0009.t-msedge.net.
s-part-0017.t-0009.t-msedge.net. 51 IN  AAAA    2620:1ec:bdf::45

api.mojang.com resolves to a CNAME to the Azure Cloud, which resolves to a CNAME to the Azure load balancer, which resolves to a CNAME to the server chosen for this particular request, which at the end resolves to just one IP address. Notice the :45, it probably makes sense to assume there are 44 others before that.
Now, if you exclude 2620:1ec:bdf::/48 for example, which is probably a large swath of Azure, you may capture all IPs the load balancer can put out (or not), but you may inadvertently route other things hosted by Azure outside the VPN without you noticing.