One remote network - two VPN tunnels.???

Yes.

How the remote end routes the network is only of interest if it interferes with the proper return of packets.

[See, however, the notes below.]

In IPSec, there are two different levels that might be referred to as "tunnels".

When two peers connect to each other, they negotiate a "isakmp phase 1" tunnel that authenticates the peers and communicate various options, and after that is used mostly to securely build the other level of tunnels. Phase 1 does not carry payload data: it carries information

-about- the payload tunnels.

When there is data (payload) to communicate via the peers, a "phase 2" tunnel is built. Each of those payload tunnels is known as a "security association" (SA). You can have a number of different Security Associations within one peer-to-peer tunnel. Typically in IPSec, a different Security Association is built for each combination of source and destination.

For example, peer X might be communicating with peer Y, and within the single phase 1 tunnel between them, there might be one Security Association for all traffic from 10.15.11.0/24 to 10.16.0.0/16, and a different Security Association for traffic from 10.15.11.0/24 to

10.15.174.0/24. If there was a second network at X, say 10.15.8.0/24, then traffic from it to 10.16.0.0/16 would probably go over a different Security Association.

Essentially each specified source (which might be a complete subnet or might be a single host) would use a different Security Association for each specified destination (which might be a complete subnet or might be a single host).

IPSec does *not* attempt to be "smart" about re-using Security Associations: if you had for some reason configured a distinct source of host 10.15.11.98 and there was some traffic to go to

10.16.0.0/16 and there was an active Security Association between 10.15.11.0/24 and 10.16.0.0/16, then IPSec would still go ahead and build a distinct Security Association for the 10.15.11.98 -> 10.16.0.0/16 traffic. Maybe ;-( What it does for new traffic is run *in order* through the list of rules of what traffic flows are permitted, and determines which rule applies, and each distinct rule active results in a different Security Association. So if the rule about 10.15.11.98 -> 10.16.0.0/16 happened to occur before the rule about 10.15.11.0/24 -> 10.16.0.0/16 then the more specific rule would sit inactive with no corresponding Security Association built until there happened to be traffic matching it, which would trigger building the more specific Security Association. If, however, the rule about 10.15.11.98 -> 10.16.0.0/16 happened to occur after the rule about 10.15.11.0/24 -> 10.16.0.0/16 then the more specific rule would never be reached.

If the two ends do not happen to have the exact same trigger conditions in the exact same order, the two ends can end up disagreeing about which Security Association to use for particular traffic, and Then You Have A Problem.

In your question, you indicated that one of the tunnels would carry traffic from 10.15.11.0 to 10.15.0.0, but you did not indicate the "width" of the destination. If the 10.15.0.0 was intended to indicate 10.15.0.0/24 then there is no problem, but if you are trying to use a tunnel from 10.15.11.0/24 to 10.15.0.0/16 then you are likely going to have routing difficulties: when the far end of the tunnel sees traffic destined for 10.15.11.0/24, how is it to know whether to send that traffic "inward" to the internal 10.15.0.0/16 network, or "outward" to the 10.15.11.0/24 network at the peer? It is tricky to configure tunnels between overlapping subnets, and it should be avoided as much as practical. You would probably run into less grief by renumbering every host in 10.15.11.0/24 to

10.17.11.0/24 to avoid the overlap, then you would run into attempting to get the tunnels to work properly with the overlap in place.

Anyhow, summarizing what I was talking about earlier: you asked for having different "tunnels". That is handled automatically if you have different peers (VPN devices) for the two different destinations: in that case, different Phase 1 and Phase 2 tunnels would be used. If both flows are going to the same peer, then in a technical sense of the word "tunnel", different tunnels would be used for the two flows if the rules distinguish between the two destinations, thus resulting in different Security Associations (Phase 2 tunnels) being used for the two flows. Different Security Associations that are within the same Phase 1 tunnel will use different encryption session keys, so if you managed to break the encryption security for one of the Security Associations, the other would remain intact. [On the other hand, if you have technology sufficient to break the encryption on individual Security Associations, you'd probably attack the Phase 1 process and track the session keys of the Security Associations as they got built...]