I have no problem migrating VPN tunnels built on the standard VPN template. I’m simply not sure what to do with these two. Do I rebuild them with the standard JUNOS VPN template or is there another method I should use?

How much of the VPN's need to be rebuilt? Is there work that will need to be done on both sides, or will only the pre-share key need to be changed on the remote side of the VPN?

Thank you for your help. Your answer has already given enough to get started. My predecessor could have used route-based VPN's for all our remote sites. It would have made this a little less confusing, but then it wouldn't be a good learning experience

In a normal policy based VPN the policy would point to a VPN tunnel instead of the "permit" statement. This configuration works, but does not seem to follow the rules for a normal policy based VPN. I am now just looking for some explanation of how and why they are setup this way.

I've done considerable research in the KB. I plan to engage JTAC to support my migration.

Re: Migrating confusing SSG-520 VPN to SRX-650

There will probably be a route in your configuration pointing down the GRE tunnel - something like:

172.20.6.0/24 next-hop 192.xxx.54.2

The GRE tunnel behaves exactly like a point to point link.

As to why they are set up this way, it's hard to say - your colleague may have just copied an existing Cisco to Juniper tunnel configuration from somewhere else, but I'd guess it has a lot to do with Cisco / Juniper interoperability.

In IOS you don't "route" traffic down a VPN tunnel, you match a crypto-map ACL (essentially the same as policy-based VPN in ScreenOS/Junos). IOS then uses the ACL you configure as a proxy-id when establishing the VPN tunnel. If you have configured multiple subnets at both ends in your ACL, IOS will automatically generate multiple proxy-ids.

In ScreenOS/Junos on the other hand, regardless of whether you configure route-based or policy-based VPNs, the proxy-id will always be set to wildcard 0.0.0.0/0. The wildcard proxy-id isn't recognised by IOS and needs to be manually configured on the Junos side to match whatever IOS is expecting (as per the crypto-map).

The next issue is that Junos/ScreenOS doesn't support multiple proxy-ids in a single VPN configuration, so if you have non-contiguous subnets on either end that don't summarise well, you will run into issues.

One way to address both of these issues is to use GRE over IPSEC. This essentially brings route-based VPN to IOS to avoid all these issues.

First you create an IPSEC tunnel with a crypto map/proxy-id that ONLY matches the source and destination IP address of the GRE tunnel (eg: the external IPs of both of your firewalls) and the application GRE.

Then you create a GRE tunnel as normal.

Now any subnets that you wish to route between sites you point at the GRE tunnel. This way your traffic is wrapped in GRE, and only the GRE traffic enters the IPSEC tunnel (which only allows traffic sourced or destined for your firewall interface IPs)

In your case though, it looks like you're only using the GRE tunnels, with no outer layer of IPSEC.