Let me start by saying both Juniper and Cisco have excellent publicly available documentation. However, just like with any vendor, documentation on interoperability is always lacking. Making two products work together peacefully is your job as the Network Engineer, and the manufacturer is only going to help you so far. That’s why you have years of experience under your belt!
Both Juniper and Cisco support Policy-based VPNs (more common) and Route-based VPNs (less common, but much more useful). More people know how to set up Policy-based VPNs and they are also more vendor-neutral. But there are plenty of reasons you don’t want a Policy-based VPN (from here on referred to as a PBVPN) and you should use a Route-based VPN.
More people know it, and therefore seems to be easier to setup
Most site-to-site VPNs that you see will be PBVPNs.
May run into NAT issues; May need to specifically bypass NAT on some devices
No support for traffic other than IP
No Dynamic Routing such as OSPF or RIP
In some cases may be difficult to troubleshoot
Need to have proxy-id match up properly on both sides of the VPN
Easy to setup and understand. Creates a virtual interface that you can route to
Supports traffic other than IP
Supports Dynamic Routing such as OSPF or RIP
Supports routing fail-over
No need to bypass NAT
Usually only supported between two devices of the same manufacturer. However, it is possible to get them to work, and work reliably. I have had success with Route-based VPNs between Juniper and Sonicwall; I have seen Cisco to Juniper Route-based VPNs.
In order to lock down the VPN to specific hosts/ports/etc, you have to define extra security policies/access lists.
Not as many people know Route-based VPNs
Now let’s cover what is needed to implement each type. I will use the codenames Alpha to refer to the local site, and Beta to refer to the remote site.
Alpha (local site)
Public IP: 18.104.22.168
Local Network: 192.168.1.0/24
WAN interface: ge-0/0/0.0 or ge0/0 (22.214.171.124)
Make sure the two policies are at the TOP of the policies in their zones. Policies are matched in a top-down fashion, and if the traffic matches something before the VPN policy it will NOT be encrypted. This can be achieved via: