It is, in fact, a firewall rule that is preventing our iBGP peers from establishing.
Phew, that is a lot easier to explain than what else I could imagine. Glad you found it.
My question is, why does this block the iBGP connection between our internal peers, and not the eBGP connection from our routers to our eBGP Peer? The /29 our eBGP connection is using is not referenced in any access list or firewall rule to my knowledge.
I suspect that's because the outbound eBGP TCP session from your router gets in the conntrack table via the output chain not the input chain. I imagine if the remote eBGP peer initiates the connection first it would fail, but fortunately both sides will try if they're configured. That doesn't happen in the iBGP instance because presumably both of your routers have that on their input chains, so neither direction works.