Jweb Config Example Policy Based VPN
Jweb Config Example Policy Based VPN
This configuration example shows how to configure a policy-based IPsec VPN to allow data to be securely transferred
between a branch office and the corporate office using J-Web.
The hierarchical steps and screen outputs in this document are based on the Junos 12.1X44 release.
NOTE: This section contains the prerequisite steps for the VPN configuration. If your LAN/WAN interfaces, static route,
security zone, and local address book are already configured, then jump to the Section B to configure the VPN related
configuration.
1. Select Configure>Interfaces>Ports
2. Select ge-0/0/0 in the left pane
3. Click Add>logical interface.
4. In the Add Interface box,
a. Add the following attributes:
Unit: 0
b. Select IPv4 Address box>Enable address configuration
Click Add. Provide the address attributes:
IPv4 Address: 10.10.10.1
Subnet: 24
5. Click OK
1. Select Configure>Interfaces>Ports
2. Select ge-0/0/3 in the left pane
3. Click Add>logical interface.
4. In the Add Interface box,
a. Add the following attributes:
Unit: 0
b. Select IPv4 Address box>Enable address configuration
Click Add. Provide the address attributes:
IPv4 Address: 1.1.1.2
Subnet: 30
5. Click OK
6. Configure an address book entry for the Sunnyvale network and attach a zone to it.
1. select Configure>Security>Address Book
2. Click Add
3. In the Add Address Book box,
a. Add the following attributes:
Address Book Name: book1
b. Click Address TAB and provide the following attributes :
Address Name : Sunnyvale
Address type : IP address
Value : 10.10.10.0/24
c. Under Attach zone section,
Select trust from the pool of Available zones.
d. Click OK
1. Specify ‘ike’ to be allowed under interface ge-0/0/3.0 under security zone ‘untrust’.
1. In the Add Zone box,
a. Select Security>Zones/Screens
b. Select security zone ‘untrust’ and click ‘Edit’
c. Under Host Inbound traffic –Zone tab,
Select the services ike from the pool of Available services.
d. Click OK
Important: Step 1 is mandatory because if ‘IKE’ is not enabled on the external interface, then the SRX will not accept
inbound ike packets. The IKE packets will be dropped, and IKE negotiations will not proceed further.
2. Configure address book entry for the remote network and attach a zone to it.
1. Select Configure>Security>Address Book
2. Click Add
3. In the Add Address Book box,
a. Add the following attributes:
Address Book Name: book2
b. Click Address TAB and provide the following attributes :
Address Name : Chicago
Address type : IP address
Value : 192.168.168.0/24
c. Under Attach zone section,
Select untrust from the pool of Available zones.
d. Click OK
C. Configure IKE:
The IKE Phase 1 proposal, IKE policy, and IKE gateway are created in this section.
c. Click OK
After selecting ike-phase1-proposal, you must click the right arrow key to move interface to selected
column.
c. Click OK
e. Click OK
3. Create an IKE Phase 1 gateway. Specify the IKE policy (phase 1), external (outgoing interface), and the peer IP
address/FQDN:
Note: The address/FQDN should be the remote peer’s public IP address. It is important also to specify the
correct external interface. If either the peer address or external interface is incorrect, then the IKE gateway is not
identified during phase 1 negotiation.
The IPsec Phase 2 proposal, IPsec policy, and IPsec VPN are created in this section.
2. Create an IPSec policy and specify the IPSec Phase 2 proposal created above, along with perfect-forward-secrecy
(PFS).
a. Under IPSec Policy TAB, click Add.
Provide the following attributes:
name: ipsec-phase2-policy
perfect-forward-secrecy: group2
After selecting ike-phase2-proposal, you must click the right arrow key to move interface to selected
column.
3. Create the IPSec VPN specifying the Remote gateway, IPsec policy, and tunnel interface.
b. Under Auto Key VPN TAB, click Add.
Provide the following attributes:
name: ike-vpn-chicago
Remote Gateway : gw-chicago
Ipsec Policy : from the drop-down list select ‘ipsec-phase2-policy’
b. Click OK
The security policies are configured for tunnel traffic in both directions in this section.
Note: The security policies include zone information configured in the previous steps.
1. Create the security policy to permit traffic from the trust zone to the untrust zone.
a. Click ‘Add’
b. Under ‘Add Policy’ Window, provide the following details :
policy name: vpn-tr-untr
c. Under policy context,
From zone: from the drop-down list select ‘trust’
To zone: from the drop-down list select ‘untrust’
d. Under Source Address,
Select ‘Sunnyvale’ from the list of available Address-book entries.
Under Destination Address,
Select ‘chicago’ from the list of available Address-book entries.
e. Under Applications,
Select ‘any’ from the list of available Applications/Sets entries.
f. Under Policy Action, select ‘permit’ from the drop down list.
g. Click ‘OK’
h. Click “Permit Action”
Under ‘Tunnel’ window,
i. Provide the name of IPSEC VPN
Select “ike-vpn-chicago” from the list of available VPN entries.
j. Under ‘Pair Policy ‘window,
Provide the name of Pair Policy
Pair Policy Name: vpn-untr-tr
k. Click OK
2. Create the security policy to permit traffic from the untrust zone to the trust zone.
a. Click ‘Add’
b. Under ‘Add Policy’ Window, provide the following details :
policy name: vpn-untr-tr
c. Under policy context,
From zone: from the drop-down list select ‘untrust’
To zone: from the drop-down list select ‘trust
d. Under Source Address,
Select ‘chicago’ from the list of available Address-book entries.
Under Destination Address,
Select ‘Sunnyvale’ from the list of available Address-book entries.
e. Under Applications,
Select ‘any’ from the list of available Applications/Sets entries.
f. Under Policy Action, select ‘permit’ from the drop down list.
g. Click ‘OK’
h. Click “Permit Action”
Under ‘Tunnel’ window,
i. Provide the name of IPSEC VPN
Select “ike-vpn-chicago” from the list of available VPN entries.
3. Create the security policy to permit traffic from the trust zone to the untrust zone.
a. Click ‘Add’
b. Under ‘Add Policy’ Window, provide the following details :
policy name: permit-any
c. Under policy context,
From zone: from the drop-down list select ‘trust’
To zone: from the drop-down list select ‘untrust
d. Under Source Address,
Select ‘any’ from the list of available Address-book entries.
Under Destination Address,
Select ‘any’ from the list of available Address-book entries.
e. Under Applications,
Select ‘any’ from the list of available Applications/Sets entries.
f. Under Policy Action, select ‘permit’ from the drop down list.
g. Click ‘OK’
4. Reorder the security policies so that the vpn-tr-untr security policy is placed above the permit-any security
policy.
To configure the Chicago SRX, follow the configuration steps for the Sunnyvale SRX, replacing the parameters from the
topology.
For CLI :
From operational mode, enter the show security IPSec security-associations command.
user@host> show security ike security-associations
Index Remote Address State Initiator cookie Responder cookie Mode
4708557 2.2.2.2 UP d77t81e85fe7e7e3 8bbae363d59cc85f Main
For J-Web :
The steps and tips to check the IKE Phase 1 status are below. (The steps to check the IPsec Phase 2 status are in the
section that follows this.)
This screen lists all the active IKE Phase 1 SAs. Each SA contains the following information:
Index—This value is unique for each IKE SA, which you can use the CLI command, ‘show security ike security-
associations <index> detail’, to get more information about the SA.
Remote Address—Verify that the remote IP address is correct.
State
o UP—The Phase 1 SA has been established.
o DOWN—There was a problem establishing the Phase 1 SA.
Mode—Verify that the correct mode is being used.
1. In the ‘show security ike security-associations’ command output, notice that the remote address is 2.2.2.2 and
the state is UP.
If the State shows DOWN or if there are no IKE security associations present, then there is a problem with phase
1 establishment. Confirm that the remote IP address, IKE policy, and external interfaces are all correct. Common
errors include incorrect IKE policy parameters such as wrong mode type (Aggressive or Main) or mismatched
preshared keys or phase 1 proposals (all must match on both peers). An incorrect external interface is another
common mis-configuration. This interface must be the correct interface that receives the IKE packets.
2. If the configurations have been checked, then check the kmd log for any errors or use the traceoptions option.
Note: KMD Logs can be downloaded via J-Web for viewing by going to Maintain Tab->Files->Click on Log Files.
Locate KMD line and click on Download.
For CLI:
From operational mode, enter the show security ipsec security-associations command.
user@host> show security ipsec security-associations
For J-Web:
The steps and tips to check the IPsec Phase 2 status are below.
The ID number is 131073. Use this value with the CLI command ‘show security ipsec security-
associations <index>’ to get more information about this particular SA.
There is one IPsec SA pair using port 500, which indicates that no NAT-traversal is implemented. (NAT-
traversal uses port 4500 or another random high-number port.)
The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The
2862/ unlim value indicates that the Phase 2 lifetime expires in 2862 seconds, and that no lifesize has
been specified, which indicates that it is unlimited. Phase 2 lifetime can differ from Phase 1 lifetime, as
Phase 2 is not dependent on Phase 1 after the VPN is up.
Things to check:
1. The local identity and remote identity make up the proxy ID for the SA.
A proxy ID mismatch is one of the most common reasons for a Phase 2 failure. For policy-based VPNs,
the proxy ID is derived from the security policy. The local address and remote address are derived from
the address book entries, and the service is derived from the application configured for the policy. If
Phase 2 fails because of a proxy ID mismatch, you can use the policy to confirm which address book
entries are configured. Verify that the addresses match the information being sent. Check the service to
ensure that the ports match the information being sent.
Note: For some third-party vendors, the proxy ID must be manually entered to match.
Example:
Apr 19 11:47:54 rng kmd[1319]: IKE Phase-2: Completed negotiations, connection established with
tunnel-ID:131073 and lifetime 2992 seconds/0 KB - Local gateway: 172.22.135.251, Remote gateway:
24.6.221.146, Local Proxy ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote Proxy ID:
ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Protocol: ESP, Auth algo: sha1, Encryption algo: 3des-cbc, Direction:
inbound, SPI: 93eb6df3, AUX-SPI: 0, Type: dynamic
Note: Message Logs can be downloaded via J-Web for viewing by going to maintain Tab->Files->Click on
Log Files. Locate MESSAGES line and click on Download.
If the tunnel still fails to come UP, jump to the Troubleshooting section.
If you see packet loss issues across a VPN, you can adjust the refresh interval and then monitor the statistics to confirm
that the encrypted and decrypted packet counters are incrementing. You should also check whether the other error
counters are incrementing.
Troubleshooting
For help with configuring traceoptions for debugging and trimming output, refer to:
http://kb.juniper.net/KB16108