I have seen this question several times on the Juniper Forums, so I decided to post a quick write up on how to build a route-based VPN to a 3rd party device, such as a Cisco ASA, with multiple subnets on each side. The answer is more straightforward than you think.

Take the example below, where the SRX has a network of 192.168.1.0/24, and needs to access 192.168.10.0/24 and 192.168.11.0/24 which is behind a Cisco ASA.

The Cisco Administrator specifies interesting traffic via an Access Control List to intercept traffic to be sent down the vpn tunnel. This ACL essentially creates what the SRX identifies as a proxy-id. By default the SRX will send the following proxy-id to any remote peer:

        proxy-identity {
            local 0.0.0.0/0;
            remote 0.0.0.0/0;
            service any;
        }

So, we will need to create multiple VPN’s with differing proxy-id’s that reference the same ike-gateway:

vpn abc1 {
    bind-interface st0.0;
    ike {
        gateway ike-vpn;
        proxy-identity {
            local 192.168.1.0/24;
            remote 192.168.10.0/24;
            service any;
        }
        ipsec-policy ipsec-policy;
    }
}

vpn abc2 {
    bind-interface st0.0;
    ike {
        gateway ike-vpn;
        proxy-identity {
            local 192.168.1.0/24;
            remote 192.168.11.0/24;
            service any;
        }
        ipsec-policy ipsec-policy;
    }
}

The tricky part is handling next-hop-tunnel bindings:

st0 {
  unit 0 {
   multipoint;
   family inet {
     next-hop-tunnel 172.31.255.2 ipsec-vpn abc1;
     next-hop-tunnel 172.31.255.3 ipsec-vpn abc2;
     address 172.31.255.1/24;
   }
  }
}

The st0.0 address must use a subnet for its local address, and the NHTB address are ephermal (they don’t exist on the cisco side); they just need to be unique for each vpn.

Routing is pretty straightforward – just specify the ephermal NHTB address as the next-hop:

routing-options {
    static {
        route 192.168.10.0/24 next-hop 172.31.255.2;
        route 192.168.11.0/24 next-hop 172.31.255.3;
    }
}

There is still one slight caveat here:

If you have multiple source subnets headed to the same destination then you will need to perform policy-based VPNs. This is because there is no way to specify the same destination subnet across two separate interfaces. In the case above we are using a single source subnet so this above configuration should work.