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.
Cons:
May run into NAT issues; May need to specifically bypass NAT on some devices
Limited QoS
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
Route-based VPN
Pros:
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 QoS
Supports routing fail-over
No need to bypass NAT
Cons:
Less vendor-neutral
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: 123.192.168.1
Local Network: 192.168.1.0/24
WAN interface: ge-0/0/0.0 or ge0/0 (123.192.168.1)
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:
Define your address objects (referenced in the policies above):
12
set security zones security-zone trust address-book address addr_ALPHANET 192.168.1.0/24
set security zones security-zone untrust address-book address addr_BETANET 10.0.0.0/24
Bypass NAT. I did you a favor and listed all private subnets, you may want to adjust to taste based on your NAT rules:
set security zone security-zone untrust interfaces ge-0/0/0.0
set security zone security-zone trust interfaces ge-0/0/1.0
set security zone security-zone trust interfaces st0.0
Define routing. Note that this will send the traffic out over st0.0, which is what we want:
1
set routing-options static route 10.0.0.0/24 next-hop 172.123.123.1
Much better!
Policy-based VPN and Route-based VPN on Cisco
I don’t have a Cisco ASA or ISR handy right now, so I will have to refer you to the excellent Firewall.cx Cisco article. You can also find the article in the See Also section below.