🚀 go-pugleaf

It's not so clear to me that your situation is hopeless.  As I
understand it, once encryption comes on, the packet won't look like
IP.  If you can guarantee that the Ethernet type code is something
other than IP, then you could set the gateways to bridge whatever type
code it is.  In that case what you'd want to do is to define a
separate subnet for all encrypted hosts, which would in effect be a
single bridged subnet spanning your whole network.  You would use
"route add <subnet> `hostname` 0" on each host that needed to do
encrypted communication, to tell it that this fake subnet is available
on its local Ethernet.  Doing this depends upon being able to get the
encryptors to change the Ethernet type code to something other than
IP.  Now the problem becomes handling ARP's.  The simplest solution
would be to hardwire the ARP table for these host.s You can certainly
do that for the Sun.  MVS I don't know about.  You can use any
4.3-based system to fake an ARP response.  You can use /etc/arp to add
an entry to the ARP table which is "published".  That means that any
machine asking for that IP address will get sent a response of the
EThernet address you specify.  So if you have a Sun or other Unix
machine on the same cable as your MVS system, it can do this.  It's
not unreasonable to hope that the cisco box might have a similar
capability, but I'm not sure whether that hack ever made it into the
code.

Frankly it sounds to me like the encryptors have a bad design.  You'd
hope it would be possible to set them so they left the IP header
alone.  Of course that leaves you open to traffic analysis, but it's
not clear to me that you could get much more traffic information than
by looking at the Ethernet addresses in a bridged configuration.