[j-nsp] SRX - policy based vpn question in a hub-spoke configuration

[Ben Dale]

Matt,

Route look-ups occur before security policies are evaluated, so this is probably to case - I've never tried it, but for a hub site you'd need a whole bunch of intra-zone policy and it would be a real mess even if it did work.

I might be showing my ignorance here, but I struggle to find a reason to use policy-based site-to-site VPNs at all on the SRX, even in a multi-vendor environment (except maybe at large scale).  

If you need proxy-ids to match, then specify them manually in your vpn tunnel configuration.  

If you want to limit traffic traversing the tunnel, specify it in your security policy.

Having the tunnel configuration/crypto-map dictate the traffic flow seems short-sighted to me - if you need to add a subnet to a remote site in the future, then this forces you to either establish a second SA, or re-configure the tunnel which brings it down.  

Route-based VPNs on SRX give you that nice clean separation of VPN traffic into it's own security zone (or zones if you're so inclined), and traffic flow just makes sense on the routing side.

For everything else, there's GRE over IPSEC ; )

Cheers,

Ben (who's just spent far too much of my week wrestling with the insanity that is ASA IPSEC configuration)

On 28/05/2011, at 1:43 AM, Matt Yaklin wrote:

> 
> 
> Hi all,
> 
> Is it still a true statement that SRXs cannot properly do a policy based
> vpn in a hub and spoke configuration? As in, if the SRX is in the hub
> position it fails to route packets from a remote site to another remote
> site when using policy based VPNs?
> 
> I found a post on juniper.net's forum and I wanted to double check this
> statement below with folks here.
> 
> "Aweck is correct. Policy-based VPNs don't work in hub and spoke precisely due to no way to perform two policy lookups for same packet traversing the box. Also you can do a route-based on one side and a policy-based on the other. The method that is used is primarily to determine what traffic needs to be encrypted and each endpoint may make that determination which ever way it needs to. So you can do route-based on SRX side and keep Cisco as policy-based. Just remember that SRX will use proxy-id as all zeroes. So you will need to manually specify the proxy-id in VPN configs to match what Cisco is expecting."
> 
> If that is still true I have to wonder why TAC did not tell us that from
> the get go. I also find it sad that one cannot just replace a Cisco ASA
> head end unit with a SRX as a drop in replacement due to the fact some
> customers use cheaper remote vpn routers like netgear which support
> policy based vpns but not route-based.
> 
> Does anyone know of a work around to make it work?
> 
> thanks,
> 
> matt
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>