Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] Function of the ScreenOS 6.3 feature "Multiple Proxy ID support on a Route-Based VPN"



Article ID: KB16008 KB Last Updated: 13 Mar 2020Version: 4.0

This article describes the function of Multiple Proxy ID support on a route-based VPN.


When configuring a VPN to a non-ScreenOS device that has multiple subnets behind it, it is necessary to define a separate set of proxy IDs to match each network that is behind the other side of the VPN. Support for multiple proxy IDs is only available beginning with ScreenOS 6.3.0.



Per IKE RFC2409, proxy IDs are used to identify and direct traffic to the appropriate tunnel in cases where multiple tunnels exist between two peers, and also to allow for unique and shared SAs with different granularity.

Releases prior to ScreenOS 6.3 use the route-based VPN design and routing information to direct traffic to a tunnel instead of the proxy ID.; thus it can leverage the dynamic routing protocols to deploy the VPN easily. One tunnel works fine if both peers are ScreenOS with route-based VPNs because only one proxy ID can be configured in the current implementation, which is by default

However, there is a problem if the peers are non-ScreenOS devices like Cisco/Checkpoint, which may set up multiple tunnels and use proxy IDs to direct traffic to tunnels. Currently, only one tunnel can be negotiated because online one proxy ID is allowed. The new Proxy-ID feature supports multiple proxy IDs over a route-based VPN to inter-operate with third party vendors.

When inter-operating with other vendors using a route-based VPN, the non-ScreenOS VPN device rejects unexpected traffic because ScreenOS does not perform a proxy ID check before sending traffic into the tunnel.

The current practice in such scenarios is to use a policy-based VPN with appropriate policy matching the remote gateways proxy-id. But there are limitations when using policy-based VPN in-terms of using routing, NAT flexibility and traffic control.

To summarize, this new feature holds good only for the route-based VPN setup with multiple phase 2 VPNs and a single tunnel interface (tunnel.1).



The impact of the new Multiple Proxy-ID feature on other components of a VPN is listed below.

Policy-based VPN :

Not supported.  This new feature is designed only for route-based VPNs.

Dialup VPN:

Dialup user is supported.

All remote proxy IDs must be

Dialup group is supported:

  1. At configuration time, the template tunnel is only allocated for each proxy ID.
  2. The real tunnel is allocated dynamically when P2 negotiation is successful.
  3. All remote proxy IDs must be

Manual VPN:

Not supported. Manual VPN does not allow configuration of a Proxy ID.


No impact.

IKE Heartbeat and DPD:

No impact.

VPN Monitor :

If single proxy ID is the current design, one tunnel interface points to one tunnel/ “P2 SA”. The tunnel interface status can be easily determined.
If multiple proxy IDs are configured on the VPN, one tunnel interface points to multiple tunnels/ “P2 SAs”. It is necessary to define a mechanism to determine the tunnel interface status.
The rule is:
  1. To treat the interface as UP if one of the tunnels/ “P2 SAs” is ACTIVE.
  2. To treat the interface as READY if one of the tunnels/ “P2 SAs” is INACTIVE.
  3. To treat the interface as DOWN if all the tunnels/ “P2 SAs” are DOWN.
If peer gateway is non-ScreenOS product, the VPN monitor must ping a host behind peer gateway. In this case, the ping packet can only pass through the tunnel with a matched proxy ID, so this matched tunnel status can only be used to determine the tunnel interface status. The other tunnels will drop the ping packet by the non-ScreenOS gateway. The ping results of the other tunnels will be ignored. The rule is:
  1. To treat the interface as UP if the matched tunnel/ “P2 SAs” is ACTIVE.
  2. To treat the interface as READY if the matched tunnel/ “P2 SAs” is INACTIVE.
  3. To treat the interface as DOWN if the matched tunnel/ “P2 SAs” is DOWN.



Prior to ScreenOS 6.3, the implementation behaved as follows:

               |                                               |------
               | -------GATEWAY-1--->INTERNET<---GATEWAY-2-----||                                               |------

  • Gateway-1 is a ScreenOS device and has two networks: and
  • Gateway-2 is a non-Juniper device and has two networks: and
  • Gateway-1 has a requirement to configure a route base VPN with a single tunnel interface
  • Gateway-2 is a non-Juniper device which uses a concept of policy-based VPN or Proxy-id strictly to build the SA and pass traffic


Even though the ScreenOS device is configured for multiple phase2 vpn with proxy-IDs matching the remote gateway and create multiple phase2, the flow will still look to the route table only to forward the packet on the tunnel and not the Proxy-ID. Since there is only a single tunnel interface, it will be difficult to route the traffic on a specific SA, because the routing table says to send the packet to tunnel.1 and does not tell which VPN to use.

In this situation the packets can be forwarded on a wrong SA on the ScreenOS firewall, and as the remote gateways are very strict in allowing the traffic based on the Proxy-id, they will drop the packets since it arrived on a wrong SA

However as an option, the NHTB configuration could be used, but the NHTB holds good for a scenario where there are multiple phase1 and phase2 setups.


In ScreenOS 6.3, the implementation behavior is as follows.  It has the option to strictly obey the proxy-ID to build the SA and route the traffic, like other vendors.

Functionality :

  1. Support multiple proxy-IDs over route-based VPN.
  2. Support policy check for traffic based on proxy-IDs before going into the route-based VPN tunnel.
  3. For traffic matching different proxy-IDs, ScreenOS negotiates different P2 SAs and sets up separate tunnels automatically.


In the above scenario (in Section III), the ScreenOS device now has the ability to add multiple proxy-IDs on a single tunnel configuration.

When the traffic arrives in to the firewall ScreenOS strictly checks if the traffic is matching against the proxy-ID.

If  the traffic matches, then it creates a phase 2 SA with the remote gateway with the appropriate proxy-ID settings.

This way the interested traffic is always sent on the right SA.

Note: “Proxy-ID check “ is an option available to an administrator. With this command enabled, the traffic through the tunnel will be matched against the proxy-ID configured. As a result, traffic not matching the proxy-ID will be dropped. If this option is not enabled, the proxy-ID configured will be used only to build the SA. However, If more than one proxy-ID is defined for a VPN (Phase 2), a proxy-ID check is always performed, even if the proxy-ID check is not explicitly enabled/configured. By default, this option is disabled.


Configuration requirement:

IMPORTANT:  Additional commands are required to accomplish the multiple proxy-IDs.  For example, for the above scenario:

set vpn <name> proxy-id check

set vpn test proxy-id local-ip remote-ip any
set vpn test proxy-id local-ip remote-ip any
set vpn test proxy-id local-ip remote-ip any
set vpn test proxy-id local-ip remote-ip any


Sample configuration on GATEWAY-1 :

set ike gateway "test" address Main outgoing-interface "ethernet0/2" preshare "#ABC123" sec-level standard

set vpn "test" gateway "test" no-replay tunnel idletime 0 sec-level standard
set vpn "test" monitor rekey
set vpn "test" id 0x1 bind interface tunnel.1
set vpn "test" proxy-id check

set vpn test proxy-id local-ip remote-ip any
set vpn test proxy-id local-ip remote-ip any
set vpn test proxy-id local-ip remote-ip any
set vpn test proxy-id local-ip remote-ip any

set interface "tunnel.1" zone "Untrust"
set interface tunnel.1 ip unnumbered interface ethernet0/2

set route interface tunnel.1
set route interface tunnel.1

In the above configuration,  when there is interested traffic hitting the firewall, for example, for network, the route lookup is done, which says it will route the traffic to the tunnel.1.

Because the Proxy-ID check is enabled with the command set vpn <name> proxy-id check, the traffic will be checked if that matches the proxy-ID.

If the match is found, then the phase2 SA will be triggered automatically and no additional configuration is required.

get sa
total configured sa: 3
HEX ID    Gateway         Port Algorithm     SPI      Life:sec kb Sta   PID vsys
00000001<  500 esp:3des/sha1 aec2a23a   159 unlim A/U    -1 0
00000001>  500 esp:3des/sha1 aec2a23a   159 unlim A/U    -1 0
00000002<  500 esp:3des/sha1 aec2a23c  1670 unlim A/U    -1 0
00000002>  500 esp:3des/sha1 aec2a23b  1670 unlim A/U    -1 0

If the traffic is routed on the tunnel with the route look-up and no matching proxy-ID is found, then the packet will be dropped.

Modification History:
2020-03-13: minor non-technical edits.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search