I've certainly had no issue with stability using route-based VPN. As far as multiple subnet (proxy-id / traffic selectors) support, as of 12.1X46-D10 this is now native in Junos -
http://kb.juniper.net/InfoCenter/index?page=content&id=KB28820 and is dead simple to configure. If you're a little gun shy on 12.1X code and are still running old-faithful builds like 11.4RLate, then there are a couple of options: - If your subnets are contiguous, just widen the mask to include them in a single crypto-map on the Cisco side (even if that means widening the mask a LOT) - If your subnets are arbitrarily selected from different RFC1918 blocks (DOH!), then create separate P2 bindings for each subnet: http://kb.juniper.net/InfoCenter/index?page=content&id=KB20543 just be aware that this will only work if the multiple subnets are on the Cisco side (which seems to be true in your case) There are a few other hacks out there using FBF as well. J-NET has some good material: http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on-route-based-VPN-with-multiple-local/td-p/172002/page/2 Cheers, Ben On 16 Oct 2014, at 8:35 am, Andy Litzinger <andy.litzin...@theplatform.com> wrote: > I'd happily use route-based vpns if they are supported in my use case. > Based on Kbs and internet lore, it seemed policy based was the best bet > for stability. > > My two tunnel endpoint devices are the SRX and a Cisco ASA. > On the SRX side I've got a single subnet but on the ASA side I've got two > subnets. I would happily use a simple policy on the ASA side like 'permit > ip any <SRX side IP subnet> <SRX side mask>' if i was confident I wasn't > going to have squirrely issues with connectivity. > > What do you think? > > -andy > > On 10/15/14 3:22 PM, "Ben Dale" <bd...@comlinx.com.au> wrote: > >> Hi Andy, >> >> I have come across this exact issue using the feature. >> >> There was a good reason why we didn't use default address selection that >> escapes me just now, but I had a slight advantage in that I was using >> route-based VPNs, so I was able to number the st0 interface with a /32 >> from the corporate range and source my queries from there. >> >> Unfortunately policy-based VPNs are extremely limiting when it comes to >> things like this. I can't think of too many scenarios where I'd even use >> them any more. If you don't have too many sites, I'd seriously consider >> migrating them across. >> >> Cheers, >> >> Ben >> >> On 16 Oct 2014, at 1:28 am, Andy Litzinger >> <andy.litzinger.li...@gmail.com> wrote: >> >>> Hello, >>> is anyone out there using the dns-proxy feature for the branch SRX? Are >>> there any clever tricks for specifying the source address the SRX uses >>> to >>> query name servers? It does not appear to be a config option. >>> >>> with the default config it appears to use the IP of the outbound >>> interface. If I add the config statement 'set system default address >>> selection' i can influence it to use the lo0.0 address, which can solve >>> my >>> issue, but not in a way i prefer. >>> >>> my exact problem is the following: >>> I have an SRX 220H in a remote office. It has an trust and untrust zone. >>> users sit on the trust zone and receive dhcp from the SRX and use the >>> SRX >>> as their default gateway and dns server. There is a policy based vpn >>> that >>> connects from the untrust zone to our corp HQ. I have the dns-proxy >>> config >>> set up so that if a dns request is going to an intranet zone, e.g. >>> corp.example.com, then it should use DNS servers that live across the >>> tunnel in our corp HQ. If they are looking up anything else, they use >>> google dns servers. >>> >>> here's the relevant config: >>> dns-proxy { >>> interface { >>> <interface facing users>; >>> } >>> default-domain * { >>> forwarders { >>> 8.8.8.8; >>> 8.8.4.4; >>> } >>> } >>> default-domain corp.example.com { >>> forwarders { >>> <corp hq name server1>; >>> <corp hq name server 2>; >>> } >>> } >>> } >>> >>> the problem is without the 'default address selection' set the SRX >>> tries to >>> use the untrust interface IP as the source IP to query our corp HQ name >>> servers, but the traffic doesn't enter the tunnel because it doesn't >>> match >>> the vpn policy. And I can't change the policy to allow it because the >>> untrust interface IP is the endpoint of the tunnel. It looks like the >>> source zone of the dns query is junos-host- is it possible maybe to set >>> up >>> a junos-host zone to untrust zone NAT when going to corp-hq IP space? >>> >>> or is there another clever solution? >>> >>> thanks! >>> -andy >>> _______________________________________________ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp