We are having a site to site main mode VPN between two devices.

Clients are trying to connect through dynamic VPN to one of the sites and the connection is failing.

Assume that the following firewalls are directly connected:

IPsec established between site A and Site B.
Users on site B WiFI netowrk might need to access some resources on site B that are not permitted on the site to site IPsec.

Site's A SRX300 IP address 1.1.1.1 and Site's B IP address 2.2.2.2 is already being used to establish a VPN, the site to site one.

The JSC negotitation will use the same interfaces and IP addreses to be negotiated.

Apr 13 23:59:09 iked_pm_id_validate id NOT matched.
Apr 13 23:59:09 iked_pm_ike_spd_select_ike_sa failed. rc 1, error_code: No proposal chosen
Apr 13 23:59:09 ikev2_fb_spd_select_sa_cb: IKEv2 SA select failed with error No proposal chosen (neg c21800)

On increasing the level of traceoptions further,  the following messages appear in the logs:

The JSC VPN connection IKE negotiation is failing as the device is treating the negotiation request coming in for dynamic VPN for the already configured site to site main mode VPN gateway instead of the dynamic VPN gateway. The device first does address lookup for gateway, and if no match is found it then moves to ID based lookup (i.e. it first does main mode lookup and then aggressive mode) . Since in this case the dynamic VPN packets will come with the same source IP for which we have already made a site-to-site main mode VPN,  it will match the main mode gateway. In main mode, device matches the identity sent (which is fqdn "testdynvpn") with IP address i.e. 2.2.2.2, which results in a mismatch and thus IKE negotiation fail for dynamic VPN connections.

Solution is to change the site to site main mode VPN into aggressive mode. On changing VPN mode into aggressive mode we will see that address based lookup will fail and it will move to ID based lookup for which our correct aggressive mode dynamic VPN gateway will be found resulting into correct ID validation and thus the VPN will be established:

Oct 5 01:26:57 Address based phase 1 SA-CFG lookup failed for local:172.27.201.22, remote:172.27.201.23 IKEv1
>>>>>No main mode gateway found for dynamic VPN negotiation
Oct 5 01:26:57 iked_pm_phase1_sa_cfg_lookup_by_id called with id type 2 >>>>>It moves to aggressive based gateway lookup and finds the gateway
Oct 5 01:26:57 ikev2_fb_idv2_to_idv1: Converting the IKEv2 payload ID ID(type = fqdn (2), len = 10, value = testdynvpn) to IKEv1 ID
Oct 5 01:26:57 ikev2_fb_idv2_to_idv1: IKEv2 payload ID converted to IKEv1 payload ID fqdn(any:0,[0..9]=testdynvpn)
Oct 5 01:26:57 Gateway dyn-vpn-local-gw: number of connections=0, limit=2
Oct 5 01:26:57 id based lookup successful: Sa_cfg:INSTANCE-dyn-vpn_0002_0004_0000 Gateway:dyn-vpn-local-gw
Oct 5 01:26:57 ikev2_fb_idv2_to_idv1: Converting the IKEv2 payload ID ID(type = fqdn (2), len = 10, value = testdynvpn) to IKEv1 ID
Oct 5 01:26:57 ikev2_fb_idv2_to_idv1: IKEv2 payload ID converted to IKEv1 payload ID fqdn(any:0,[0..9]=testdynvpn)
Oct 5 01:26:57 iked_pm_id_validate called with id fqdn(any:0,[0..9]=testdynvpn) >>>>>>>>>>Now ID validation will not fail

 

Adding here the links for the aggresive mode configuration change:

https://supportportal.juniper.net/s/article/SRX-Configure-site-to-site-IPsec-VPN-where-remote-site-has-dynamic-IP-address-and-SRX-has-static-IP-address

https://supportportal.juniper.net/s/article/SR-Configure-site-to-site-IPsec-VPN-where-the-SRX-has-a-dynamic-IP-address-and-a-remote-side-firewall-has-a-static-IP-address

Updating article with new details for JSC