This article describes the issue of being unable to build a VPN tunnel, when the SRX/J-Series device is the IKE responder in a dynamic endpoint configuration (which also includes Dynamic-VPN).

• The SRX/J-series device is the IKE responder in a VPN tunnel
• The SRX/J-Series device is a dynamic endpoint (initiator has an IP address, which is dynamically changing, either via DHCP or PPPoE or other dynamic IP)
• The SRX/J-series device is the responder in a Dynamic-VPN environment.
• The IKE external interface is bound to a non-default routing-instance.

Any VPN, in which the SRX/J-Series device is the responder in a dynamic endpoint environment and the external-interface is in a non-default routing-instance, will not successfully negotiate for an IPSec VPN tunnel. This is as per design. There are currently no plans to address this limitation.

For any dynamic endpoint environment, the external-interface must be part of the default inet.0 routing instance. Any dynamic endpoint configuration, in which the external interface is in a custom routing instance, will fail in the IPSec VPN negotiation. It is recommended to re-configure the VPN, so that the external-interface is in the default inet.0 routing-instance.

Scenarios in which dynamic endpoints are involved:

• Remote peer connects via a dynamically changing IP address (the IKE configuration will be based on using local-id configuration).
• Dynamic-VPN environments, in which the Juniper Access Manager or Juniper Pulse clients connect to the SRX for Dynamic-VPN connections.