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

[Crist Clark]

If the SRX box was at the same site as I am, it would be at risk
of physical assault. This just seems so wrong and broken. If I look
at the IPsec logs (kmd), the Phase 2 negotiations with the peer look
totally correct,

  Jul 19 06:21:05 Phase-2 [responder] done for p1_local=ipv4(udp:0,[0..3]=<local_IP>) p1_remote=fqdn(any:0,[0..26]=<remote_name>) p2_local=ipv4_subnet(any:0,[0..7]=172.18.3.0/30) p2_remote=ipv4_subnet(any:0,[0..7]=<remote_net>.0/24)

But after using those remote and local subnets in Phase 2, when I
look at the security association on the SRX says,

  cclark at covfw# run show security ipsec security-associations detail 
    Virtual-system: Root
    Local Gateway: <local_IP>, Remote Gateway: <remote_IP>
    Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
    Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)

Now is it just me, or is that completely broken? The system knows which
addresses it is negotiating about in Phase 2, but then puts wide open
identities in the local database?

On 7/16/2010 at  2:57 PM, "Crist Clark" <Crist.Clark at globalstar.com> wrote:
> 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?