Juniper to Cisco VPN

In order for a VPN to work between Cisco and Juniper, each subnet needs to be defined on the Juniper firewall as a proxy-id. The juniper firewall also requires “policies” to be created to allow all of this traffic. Two policies are necessary for each local to remote subnet – one for each direction the traffic will need to flow. ┬áHere is a short sample of how to configure this on the Juniper firewall running at least ScreenOS 6.3.0

Below is a sample configuration from a Juniper NetScreen device to connect to a Cisco ASA. Throughout the example the following is true:

  • The “Trust” and “Trust2” zones are both on the “inside” of the Netscreen
  • The “Untrust” zone is the on the outside of the Netscreen.
  • “Local_MGMT” is a subnet in the “Trust” zone and is 10.10.1.0/24
  • “Local_servers” is a subnet in the “Trust” zone and is 10.10.2.0/24
  • “Local_DMZ” is a subnet in the “Trust2” zone and is 10.10.3.0/24
  • “Remote_DMZ” is a subnet in the “Untrust” zone and is 192.168.1.0/24
  • “Remote_Servers” is a subnet in the “Untrust” zone and is 192.168.2.0/16

The following lines define the basic VPN configuration. Lines 1 & 2 define a tunnel interface to allow the VPN to be bound to this interface. Lines 3 & 4 define custom phase 1 and phase 2 proposals to match the proposal chosen on the Cisco side of the VPN. The last lines define the remote peer address, specifies the preshared key, P1/P2 proposals to use and binds it to the tunnel interface.

set interface "tunnel.1" zone "Untrust"
set interface tunnel.1 ip unnumbered interface ethernet1/1
set ike p1-proposal "pre-g2-3des-sha-24h" preshare group2 esp 3des sha-1 second 86400
set ike p2-proposal "nopfs-esp-3des-sha-24h" no-pfs esp 3des sha-1 hour 24 kbyte 4194303
set ike gateway "RemoteGateway" address 4.4.4.4 Main outgoing-interface "ethernet1/1" preshare "*****" proposal "pre-g2-3des-sha-24h"
set vpn "VPN" gateway "RemoteGateway" no-replay tunnel idletime 0 proposal "nopfs-esp-3des-sha-24h"
set vpn "VPN" bind interface tunnel.1

This section defines the proxy-id’s that are used to define “interesting traffic” for the VPN. As noted, each local subnet needs one line for each remote subnet. Also note that the traffic is coming from 2 different zones on the “inside” of the Netscreen.

set vpn "VPN" proxy-id local-addr "Trust" "Local_MGMT" remote-addr "Untrust" "Remote_Servers" "ANY"
set vpn "VPN" proxy-id local-addr "Trust" "Local_MGMT" remote-addr "Untrust" "Remote_DMZ" "ANY"
set vpn "VPN" proxy-id local-addr "Trust" "Local_servers" remote-addr "Untrust" "Remote_Servers" "ANY"
set vpn "VPN" proxy-id local-addr "Trust2" "Local_DMZ" remote-addr "Untrust" "Remote_Servers" "ANY"

This section defines the policies (or ACL’s if you are more accustomed to Cisco) to permit the traffic across the tunnel. Notice that a policy is necessary for each local and remote subnet, and for each direction that the traffic will be initiated from. If the tunnel will be unidirectional, only one direction of policies is necessary. The first 4 policies are to allow traffic from the local subnet out of the Netscreen to the remote subnet. The last 4 policies allow the opposite direction.

set policy id 1 from "Trust" to "Untrust" "Local_MGMT" "Remote_Servers" "ANY" permit
set policy id 1
exit
set policy id 2 from "Trust" to "Untrust" "Local_MGMT" "Remote_DMZ" "ANY" permit
set policy id 2
exit
set policy id 3 from "Trust" to "Untrust" "Local_servers" "Remote_Servers" "ANY" permit log
set policy id 3
set log session-init
exit
set policy id 4 from "Trust2" to "Untrust" "Local_DMZ" "Remote_Servers" "ANY" permit
set policy id 4
exit

set policy id 5 from "Untrust" to "Trust" "Remote_Servers" "Local_MGMT" "ANY" permit
set policy id 5
exit
set policy id 6 from "Untrust" to "Trust" "Remote_DMZ" "Local_MGMT" "ANY" permit
set policy id 6
exit
set policy id 7 from "Untrust" to "Trust" "Remote_Servers" "Local_servers" "ANY" permit log
set policy id 7
set log session-init
exit
set policy id 8 from "Untrust" to "Trust2" "Remote_Servers" "Local_DMZ" "ANY" permit
set policy id 8
exit

The static routes are necessary to tell the Netscreen how to find the subnets on the remote side of the VPN tunnel. The route directs the traffic to the tunnel.1 interface which is bound to the VPN.

set route 192.168.1.0/24 interface tunnel.1
set route 192.168.2.0/24 interface tunnel.1

Adding additional subnets to the VPN

To add additional subnets (local or remote) to the VPN, 2 things will need to be accomplished. First, defining a proxy ID for each of the subnets that you expect the new subnet to be able to reach, and second to define the policies to allow the traffic between each of the subnets. In the web interface, you will find the proxy-ID’s under VPNs > AutoKey IKE and then click the link for Proxy ID for the tunnel to be modified. The policies are added under Policy > Policies. Ensure that you have specified the From and To zones before trying to add a new policy.

Leave a Reply