Use a kinit -R cronjob on the jumpboxes.
At the point when users run ssh while their ticket has already expired, nothing can be done – an expired ticket can't be renewed anymore; renewal needs to be done earlier than that.
Although in theory libkrb5 could proactively extend a valid TGT whenever the user runs ssh, in practice it wouldn't make much sense; there's nothing that would ensure the user will indeed run ssh at the right moment. So automated proactive renewal only makes sense on a schedule, i.e. cron or similar.
(Current versions of libkrb5 can automatically acquire new tickets off a client keytab, if the user has created one; but I suppose it wouldn't be desirable to store what's essentially their password on the jumpbox.)
Please note that users may have a number of sessions open on the same jumphost either through multiple ssh sessions or session managers like screen and byobu.
That would only be relevant if the jumphost automatically acquired Kerberos tickets for the user via PAM (e.g. if you used pam_krb5). But having to do a manual kinit strongly implies that the user has just the one "default" ticket cache on the jumphost, regardless of their session count – as, if they have no tickets, then it's almost guaranteed nothing has set $KRB5CCNAME for them either – so you most likely can use a cron job to handle renewal.
So if the TGT has been acquired with the Renewable flag, the user could just have a @hourly cron job (or systemd .timer, if your distribution supports that) which renews their TGT using kinit -R. The krenew daemon (which also needs to run at user level) can also perform the same task.
Though, even if users do have multiple ticket caches, having a cronjob that renews them all is really not much of a task: it's just a Bash for loop that runs kinit -R -c $cache for every cache it finds.
Note that ticket renewal is usually capped at 7 or 14 days (I am not sure what the FreeIPA defaults are, but I believe the underlying MIT Krb5 KDC has a hard limit of 14 days).
(Also, renewal will discard other non-TGT tickets from the cache, but that's not important – they aren't needed for already-active sessions and they'll be re-acquired when needed.)
Another option: Use the jumphosts as tunnel servers, not as interactive shell servers. That is, have the user do kinit on their system, then "directly" initiate SSH to the target using the jumphost as a raw TCP tunnel host (using ProxyJump). They will authenticate to both systems using their local tickets; their local system will handle renewal.
I know that the Kerberos tickets will be separate for each jumphost they connect to from their non-IPA machine(s).
That's not an issue, each copy of the TGT can be renewed independently.
