[j-nsp] Enumerate All Possible VPN Tunnels? Really?

[Crist Clark]

I've got what I think should be a fairly vanilla hub-and-spoke
VPN configuration. The hub is a Cisco ASA (really, it eventually
should be dual hub, but wait until I get one working before I
worry about that) and one of the spokes is a SRX (10.1).

I can get a single tunnel up between the SRX and the ASA without
much problem. However, we have a situation where there are
multiple non-contiguous networks at each site. At the hub and
other spokes, we just enumerate all of the networks at the remote
site and the networks at the local side, and the device builds
individual tunnels between the various networks as needed with
a single configuration entry.

Doesn't seem to work that way on the SRX (JUNOS). I started with
a route-based VPN. That's how I got my one quick tunnel up, but
the SRX side would always say the tunnels were associated
locally with 0.0.0.0/0 and remotely with the same. This lead to
the problem that the SRX would try to cram traffic from local_netX
and remote_netY down a VPN that had been negotiated in IKE Phase 2
as between local_netA and remote_netB.

I talked to JTAC about this, and their solution was going to be
to enumerate every possible combination of tunnels,

security {
    ipsec {
        vpn vpn_1-cfg {
            ike {
                proxy-identity {
                    local <local_netA>;
                    remote <remote_netB>;
                }
            }
        }
    }
}

Which does not scale. The tech said maybe policy-based would be
better. So I went to the site-to-site VPN tool on the Juniper
support page to see what it would say. I put two networks in
either side of the tunnel and it spit out a configuration with
EIGHT security policies, one in each direction for the four ways
you can pair the two networks at each site. And that's still not
really working right.

Neither of these is solutions is scalable. There's got to be a
better way to do this, right?