Thanks for the reply. You're right with sk31692, I found that you could use implied_rules.def to force all sorts of gateway initiated traffic over the VPN. however, I actually used route based VPNs to achieve this...
...No matter how I went about it initially, there was no configuration that would cause the packet to get encrypted, and I think this is due to where gateway initiated traffic starts in the chain, it doesn’t enter from the start of the inbound chain like a normal traversal packet would.
At the early stages of the inbound chain a flag (or similar) must get attached to the packet to mark it for encryption so that when it reaches the end of the outbound chain it gets encrypted (at least, this is how it works in other firewall vendors, and the behavior seems similar based on what I’m seeing). However, this was not taking place due to the position gateway initiated packets enter the chain, thus not getting marked for encryption (or something like that).
Converting the tunnel to route based VPN worked perfectly as I thought. This pushes the packet via the VT interface which seems to apply all of the needed chain elements you’d get from a normal traversal packet (potentially full inbound chain, full outbound chain, but I haven’t checked on a kernel debug) thus it gets marked for encryption, encrypted, and sent out correctly - you can even use NAT to manipulate the source address it is sent with, if needs be. By default if using numbered VTIs it uses the “local” address on the VTI as the source and if using unnumbered VTIs it seems to use the gateway main IP as the source.
Either way - all sorted! Thanks for the reply.