Knowledge Search


×
 

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

  [KB16008] Show Article Properties


Summary:

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

Symptoms:

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.



Cause:
 
Solution:

I. INTRODUCTION

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 granularities.

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 0.0.0.0/0.

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 interoperate with third party vendors.

When interoperating 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).

II.  IMPACT  ON OTHER VPN FEATURES

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 255.255.255.255/32.

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 255.255.255.255/32.

Manual VPN:

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

NAT-Traversal:

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.

III. PREVIOUS IMPLEMENTATION

Prior to ScreenOS 6.3, the implementation behaved as follows:

Scenario:

  10.1.1.0/24---|       
               |                                               |------20.1.1.0/24
               | -------GATEWAY-1--->INTERNET<---GATEWAY-2-----|
 10.1.2.0/24---|                                               |------20.1.2.0/24


  • Gateway-1 is a ScreenOS device and has two networks: 10.1.1.0/24 and 10.1.2.0/24
  • Gateway-2 is a non-Juniper device and has two networks: 20.1.1.0/24 and 20.1.2.0/24
  • 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

Behavior:

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.

IV.  CURRENT IMPLEMENTATION

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.

Behavior:

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 10.1.1.0/24 remote-ip 20.1.1.0/24 any
set vpn test proxy-id local-ip 10.1.1.0/24 remote-ip 20.1.2.0/24 any
set vpn test proxy-id local-ip 10.1.2.0/24 remote-ip 20.1.1.0/24 any
set vpn test proxy-id local-ip 10.1.2.0/24 remote-ip 20.1.2.0/24 any


Sample configuration on GATEWAY-1 :

set ike gateway "test" address 1.1.1.2 Main outgoing-interface "ethernet0/2" preshare "ZCdjDhjpNwL+2KseIdC1udfpQnn1RyIfBg==" 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 10.1.1.0/24 remote-ip 20.1.1.0/24 any
set vpn test proxy-id local-ip 10.1.1.0/24 remote-ip 20.1.2.0/24 any
set vpn test proxy-id local-ip 10.1.2.0/24 remote-ip 20.1.1.0/24 any
set vpn test proxy-id local-ip 10.1.2.0/24 remote-ip 20.1.2.0/24 any

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

set route 20.1.1.0/24 interface tunnel.1
set route 20.1.2.0/24 interface tunnel.1

In the above configuration,  when there is interested traffic hitting the firewall, for example, for 20.1.1.0/24 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<         1.1.1.2  500 esp:3des/sha1 aec2a23a   159 unlim A/U    -1 0
00000001>         1.1.1.2  500 esp:3des/sha1 aec2a23a   159 unlim A/U    -1 0
00000002<         1.1.1.2  500 esp:3des/sha1 aec2a23c  1670 unlim A/U    -1 0
00000002>         1.1.1.2  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.

Related Links: