I'm having trouble getting packets form a road-warrior system to show up on a system 2 tunnels away with it's own
internal IP address, I can make it reach the destination if I SNAT it with the first hop's  internal IP, but I can't
figure out why it's not making it to the second. Any insight you could give me would be much appreciated.

########################################################################################################################
# Here's what works:
########################################################################################################################
Given 3 systems and 2 IPSec tunnels,

[ System A ]<---------->[ Systtem B ]<---------->[ System C ]

Such that:

System A: (road warrior, passes all traffic to System B)
  internal: 172.16.0.128
  external: 1.1.1.1
  security policies:
    - spdadd 0.0.0.0/0       172.16.0.128/32 any -P in  ipsec esp/tunnel/2.2.2.2-1.1.1.1/unique;
    - spdadd 172.16.0.128/32 0.0.0.0/0       any -P out ipsec esp/tunnel/1.1.1.1-2.2.2.2/unique;

System B: (acts as a gateway for system A, and has a persistent tunnel to System C)
  internal  172.16.0.2
  external: 2.2.2.2
  security policies:
    - spdadd 0.0.0.0/0       172.16.0.128/32 any -P in  ipsec esp/tunnel/1.1.1.1-2.2.2.2/unique;
    - spdadd 172.16.0.128/32 0.0.0.0/0       any -P out ipsec esp/tunnel/2.2.2.2-1.1.1.1/unique;
    - spdadd 172.16.0.1/32   172.16.0.2/32   any -P in  ipsec esp/tunnel/3.3.3.3-2.2.2.2/unique;
    - spdadd 172.16.0.2/32   172.16.0.1/32   any -P out ipsec esp/tunnel/2.2.2.2-3.3.3.3/unique;
  snat:
    - target 172.16.0.1 from source 2.2.2.2/32     SNAT to 172.16.0.2
    - target 172.16.0.1 from source 172.16.0.0/12  SNAT to 172.16.0.2
    - target !172.16.0.1 from source 172.16.0.0/12 SNAT to 2.2.2.2

System C:
  internal  172.16.0.1
  external: 3.3.3.3
  security policies:
    - spdadd 172.16.0.1/32   172.16.0.2/32   any -P in  ipsec esp/tunnel/3.3.3.3-2.2.2.2/unique;
    - spdadd 172.16.0.2/32   172.16.0.1/32   any -P out ipsec esp/tunnel/2.2.2.2-3.3.3.3/unique;
  snat:
    - target 172.16.0.2 from source 2.2.2.2 SNAT to 172.16.0.1


If I send a Source packet (say ICMP) from 1.1.1.1 to 172.16.0.1, it reaches it, but appears to come from 172.16.0.2.
(which is exactly what one would expect, since it's SNAT'ed) And any packet not headed for 172.16.0.1, goes out to
the big internets with an IP of 2.2.2.2 (again, works perfectly as one would expect.)

########################################################################################################################
# Here's what's "broken"
########################################################################################################################

If I remove the SNAT [ target 172.16.0.1 from source 172.16.0.0/12 SNAT to 172.16.0.2 ] and add some SPs to:

System A: (road warrior, passes all traffic to System B)
  internal: 172.16.0.128
  external: 1.1.1.1
  security policies:
    - spdadd 0.0.0.0/0       172.16.0.128/32 any -P in  ipsec esp/tunnel/2.2.2.2-1.1.1.1/unique;
    - spdadd 172.16.0.128/32 0.0.0.0/0       any -P out ipsec esp/tunnel/1.1.1.1-2.2.2.2/unique;

System B: (acts as a gateway for system A, and has a persistent tunnel to System C)
  internal  172.16.0.2
  external: 2.2.2.2
  security policies:
    - spdadd 0.0.0.0/0       172.16.0.128/32 any -P in  ipsec esp/tunnel/1.1.1.1-2.2.2.2/unique;
    - spdadd 172.16.0.128/32 0.0.0.0/0       any -P out ipsec esp/tunnel/2.2.2.2-1.1.1.1/unique;
    - spdadd 172.16.0.1/32   172.16.0.2/32   any -P in  ipsec esp/tunnel/3.3.3.3-2.2.2.2/unique;
    - spdadd 172.16.0.2/32   172.16.0.1/32   any -P out ipsec esp/tunnel/2.2.2.2-3.3.3.3/unique;
    - spdadd 172.16.0.1/32   172.16.0.128/32 any -P in  ipsec esp/tunnel/3.3.3.3-2.2.2.2/unique; *line added*
    - spdadd 172.16.0.128/32 172.16.0.1/32   any -P out ipsec esp/tunnel/2.2.2.2-3.3.3.3/unique; *line added*
  snat:
    - target 172.16.0.1 from source 2.2.2.2/32    SNAT to 172.16.0.2
                                                                                                 *line removed*
                                                                                                 *line removed*
System C:
  internal  172.16.0.1
  external: 3.3.3.3
  security policies:
    - spdadd 172.16.0.2/32   172.16.0.1/32   any -P in  ipsec esp/tunnel/2.2.2.2-3.3.3.3/unique;
    - spdadd 172.16.0.1/32   172.16.0.2/32   any -P out ipsec esp/tunnel/3.3.3.3-2.2.2.2/unique;
    - spdadd 172.16.0.128/32 172.16.0.1/32   any -P in  ipsec esp/tunnel/3.3.3.3-2.2.2.2/unique; *line added*
    - spdadd 172.16.0.1/32   172.16.0.128/32 any -P out ipsec esp/tunnel/2.2.2.2-3.3.3.3/unique; *line added*
  snat:
    - target 172.16.0.2 from source 2.2.2.2 SNAT to 172.16.0.1


And send the same packet, I see the packet [src: 172.16.0.128 -> dst: 172.16.0.1 ] attempt to leave System B;
But I never see it on System C.

########################################################################################################################
# The question:
########################################################################################################################

In the second case, should the packet not be encapsulated, passed through the tunnel/1.1.1.1-2.2.2.2/ to System B,
then decapsulated, and re-encapsulated and sent through the tunnel/2.2.2.2-3.3.3.3/ to System C?

Barring any iptables problems, should this traffic be reaching System C? Or do I have some order of operations wrong,
and something's being encapsulated twice? or not at all because of when encapsulation/decapsulation occurs?

I'm obviously missing something...