Ok, I think I've finally gotten to the bottom of this.  When the first tunnel gets established, I have two SAD entries, like so:

a.b.c.d x.y.z.w, spi=1
x.y.z.w a.b.c.d, spi=2

this is for communicating from my server a.b.c.d/32 to the remote network 192.168.0.0/21.

When the next tunnel gets established, I have two more:

a.b.c.d x.y.z.w, spi=3
x.y.z.w a.b.c.d, spi=4

these are for communicating from my server a.b.c.d/32 to the remote network 10.2.2.0/24

Now the problem is the dumb vpn (fortinet router) on the other side uses the new spi, 4, regardless of the host I'm connecting to.  So if I connect to 10.2.2.7, it uses spi 3 for outgoing and spi 4 for incoming, which is correct.  But if I connect to 192.168.0.7, it uses spi 1 for outgoing and spi 4 for incoming!

So the Fortinet router blindly uses the latest SA that has been established, spi #4, even though it is for a different tunnel!  It never goes back to using spi #2.

But my LAN computers ( 192.168.8.0/24) continue to work, probably because MASQUERADE filter is so smart that it dynamically decides that SPI 4 goes with SPI 1.

So my question is, how can I fix this?  I can't tell my workplace to change what they are doing.  If there was someway to just use a single association for both tunnels, that would do the trick.  Or if there were someway to tell the kernel not to drop my packet because even though the spi isn't the matching one, that would probably do it too.

Ideas?

Thanks,
Phillip