If it's taking multiple minutes to timeout, then that's actually not respecting the stream timeout that PHP would be using. That is set to 45 by the ES interaction stuff, which in the scope of indexing is certainly long. (It's generally long when it comes to searching, though if it has to load a lot of data off a disk with resource contention, it could be triggered.) At best, we could lower the timeout when on the indexing side of things, but if it's going longer than that, it's a moot point. We may be able to adjust the timing of the indexing operation. Ideally, we may be able to move the actual indexing code to be outside of a transaction, but I don't think that's necessarily something that will be done in the short term.
It sounds like your firewall setup was set to just silently drop packets rather than sending a refused response. This isn't an unreasonable setup in the common case, but it creates a situation where services have to wait as they have no idea if a response has been received, so you end up waiting or potentially retransmitting the packet before eventually giving up. If Elasticsearch actually errors out (eg, isn't running), this is handled gracefully -- it's really the determination of failure taking significant time and causing issues here.
On a side note, if additional applications are being brought in to run XenForo (Elasticsearch, Memcached, etc), they do need to be treated at the same level of importance as your web server and MySQL to ensure they're running healthily as there will be application-level issues if they're not.