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? _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp