Site to Site Vpn is not stable

[#1]

Hi, we have 2 srx devices on both sides

Local: 50.208.33.177  <->   Remote: 64.13.163.35

During the day a few times  the VPN does down, we have a few site to site VPNs but just one goes down every day

When I check :

>> show security ike security-associations

the state seems to be as DOWN

Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   

2853423 DOWN   8ad07f60fc6c2500  ccc8ba940b4cf03e  Any            104.196.42.142     

2853427 DOWN   edd10fce18408325  25379263dc240f3a  Any            104.196.42.142  

2853421 DOWN   7d9ee01a946476dc  4c8fb92a02fd9ceb  Any            104.196.42.142 

2849279 UP     94651e0d5a9d7d86  972a87d367a9e54a  Main           104.239.188.167 

2853387 UP     8d2418279585930e  2282d9643421dc8d  Main           64.13.163.35    

Here are the logs from both sides :

Remote Site SRX logs :

Jan  3 18:37:31  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is down.

Jan  3 18:38:24  srx240-02a kmd[33482]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=M-^M$^X'M-^UM-^EM-^S^N"M-^B?d4!?M-^M, src_ip=<none>, dst_ip=50.208.33.177]

Jan  3 18:38:34  srx240-02a kmd[33482]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=M-^M$^X'M-^UM-^EM-^S^N"M-^B?d4!?M-^M, src_ip=<none>, dst_ip=50.208.33.177]

Jan  3 18:38:34  srx240-02a kmd[33482]: IKE Phase-2 Failure: IKE Phase-2 negotiation retry limit reached [spi=21d29865, src_ip=64.13.163.35, dst_ip=50.208.33.177]

Jan  3 18:38:34  srx240-02a kmd[33482]: IKE Phase-2: Negotiations failed. Local gateway: 64.13.163.35, Remote gateway: 50.208.33.177

Jan  3 18:39:21  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is down.

Jan  3 18:39:26  srx240-02a kmd[33482]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=M-^M$^X'M-^UM-^EM-^S^N"M-^B?d4!?M-^M, src_ip=<none>, dst_ip=50.208.33.177]

Jan  3 18:39:36  srx240-02a kmd[33482]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=M-^M$^X'M-^UM-^EM-^S^N"M-^B?d4!?M-^M, src_ip=<none>, dst_ip=50.208.33.177]

Jan  3 18:39:36  srx240-02a kmd[33482]: IKE Phase-2 Failure: IKE Phase-2 negotiation retry limit reached [spi=a6ef2584, src_ip=64.13.163.35, dst_ip=50.208.33.177]

Jan  3 18:39:36  srx240-02a kmd[33482]: IKE Phase-2: Negotiations failed. Local gateway: 64.13.163.35, Remote gateway: 50.208.33.177

Jan  3 18:40:29  srx240-02a kmd[33482]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=M-^M$^X'M-^UM-^EM-^S^N"M-^B?d4!?M-^M, src_ip=<none>, dst_ip=50.208.33.177]

Jan  3 18:40:39  srx240-02a kmd[33482]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=M-^M$^X'M-^UM-^EM-^S^N"M-^B?d4!?M-^M, src_ip=<none>, dst_ip=50.208.33.177]

Jan  3 18:40:39  srx240-02a kmd[33482]: IKE Phase-2 Failure: IKE Phase-2 negotiation retry limit reached [spi=6e368fc4, src_ip=64.13.163.35, dst_ip=50.208.33.177]

Jan  3 18:40:39  srx240-02a kmd[33482]: IKE Phase-2: Negotiations failed. Local gateway: 64.13.163.35, Remote gateway: 50.208.33.177

Jan  3 18:41:11  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is down.

Jan  3 18:43:02  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is down.

Jan  3 18:44:52  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is down.

Jan  3 18:46:42  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is down.

Jan  3 18:48:32  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is down.

Jan  3 18:48:32  srx240-02a kmd[33482]: IKE Phase-1: (Initiator) The symmetric crypto key has been generated successfully [local_ip=64.13.163.35, local_port=500, remote_ip=50.208.33.177, remote_port=500]

Jan  3 18:48:32  srx240-02a kmd[33482]: IKE Phase-1: Negotiation completed; SA expires on Fri Jan 04 2019 18:48:32 { 701272be 02fb954f - b0a532b3 92687e2a } - [local_id=64.13.163.35, local_ip=64.13.163.35, local_port=500, remote_id=50.208.33.177, remote_ip=50.208.33.177, remote_port=500, Exchange Mode:main]

Jan  3 18:48:32  srx240-02a kmd[33482]: KMD_VPN_UP_ALARM_USER: VPN INSTANCE-hq_0012_0015_0000 from 50.208.33.177 is up.

Jan  3 18:48:32  srx240-02a kmd[33482]: KMD_PM_SA_ESTABLISHED: Local gateway: 64.13.163.35, Remote gateway: 50.208.33.177, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Direction: inbound, SPI: 0xa8748b89, AUX-SPI: 0, Mode: Tunnel, Type: dynamic

Jan  3 18:48:32  srx240-02a kmd[33482]: IKE Phase-2: Completed negotiations, connection established with tunnel-ID:12 and lifetime 28196 seconds/0 KB - Local gateway: 64.13.163.35, Remote gateway: 50.208.33.177, 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: sha256, Encryption algo: 3des-cbc, Direction: inbound, SPI: a8748b89, AUX-SPI: 0, Type: dynamic

Jan  3 18:48:32  srx240-02a kmd[33482]: KMD_PM_SA_ESTABLISHED: Local gateway: 64.13.163.35, Remote gateway: 50.208.33.177, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Direction: outbound, SPI: 0x4ce1aa51, AUX-SPI: 0, Mode: Tunnel, Type: dynamic

Jan  3 18:48:32  srx240-02a kmd[33482]: IKE Phase-2: Completed negotiations, connection established with tunnel-ID:12 and lifetime 28196 seconds/0 KB - Local gateway: 64.13.163.35, Remote gateway: 50.208.33.177, 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: sha256, Encryption algo: 3des-cbc, Direction: outbound, SPI: 4ce1aa51, AUX-SPI: 0, Type: dynamic

Jan  3 18:48:32  srx240-02a kmd[33482]: IKE Phase-2: (Initiator) The symmetric crypto key has been generated successfully [local_ip=64.13.163.35, local_port=500, remote_ip=50.208.33.177, remote_port=500]

LOCAL Side Srx Logs : 

Jan  3 16:52:29  srx240-01 kmd[1447]: KMD_VPN_DOWN_ALARM_USER: VPN svcolo from 64.13.163.35 is down. Local-ip: 50.208.33.177, gateway name: gw_svcolo, vpn name: svcolo, tunnel-id: 131073, local tunnel-if: st0.0, remote tunnel-ip: Not-Available, Local IKE-ID: 50.208.33.177, Remote IKE-ID: 64.13.163.35, XAUTH username: Not-Applicable, VR id: 0

Jan  3 16:56:07  srx240-01 kmd[1447]: IKE negotiation failed with error: SA unusable. IKE Version: 1, VPN: svcolo Gateway: gw_svcolo, Local: 50.208.33.177/500, Remote: 64.13.163.35/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0

Jan  3 16:56:37  srx240-01 kmd[1447]: IKE negotiation failed with error: SA unusable. IKE Version: 1, VPN: svcolo Gateway: gw_svcolo, Local: 50.208.33.177/500, Remote: 64.13.163.35/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0

Jan  3 16:57:07  srx240-01 kmd[1447]: IKE negotiation failed with error: SA unusable. IKE Version: 1, VPN: svcolo Gateway: gw_svcolo, Local: 50.208.33.177/500, Remote: 64.13.163.35/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0

Jan  3 16:57:39  srx240-01 kmd[1447]: IKE negotiation failed with error: SA unusable. IKE Version: 1, VPN: svcolo Gateway: gw_svcolo, Local: 50.208.33.177/500, Remote: 64.13.163.35/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0

Jan  3 16:58:09  srx240-01 kmd[1447]: IKE negotiation failed with error: SA unusable. IKE Version: 1, VPN: svcolo Gateway: gw_svcolo, Local: 50.208.33.177/500, Remote: 64.13.163.35/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0

Jan  3 16:58:39  srx240-01 kmd[1447]: IKE negotiation failed with error: SA unusable. IKE Version: 1, VPN: svcolo Gateway: gw_svcolo, Local: 50.208.33.177/500, Remote: 64.13.163.35/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0

Jan  3 16:59:11  srx240-01 kmd[1447]: IKE negotiation failed with error: SA unusable. IKE Version: 1, VPN: svcolo Gateway: gw_svcolo, Local: 50.208.33.177/500, Remote: 64.13.163.35/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0

Anybody had an issue like this or any idea about it ?

Thanks

[#2]

Have a quick look at the following article:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB30548

Sounds like the phase 1 negotiations have failed.... normally due to a mismatch somewhere....

Can you post the config both ends please (Hide the sections that may contain sensitive information)

[#3]

Does the remote side have more than one ISP?

The messages on the local side indicate getting the tunnel request from an unknown peer gateway address.  Meaning the ip address of the request is different from the configured ip address on the gateway locally.

[#4]

Here, i ve attached the config on both ends... Today I ve realized that, from my hq fw I can ping the remote end , which is 64.13.163.35..

But from remote fw, I can not ping my local endpoint which is  50.208.33.177..  I should ping both IPs , right ?

I dont have 2 ISPs as of know 

[#5]

Hello,

Thanks for sharing the config.

The issue is that in HQ the peer IKE ID is IP address while in Remote the Local ID is explicitly specified as hostname

In HQ:

>> show security ike gateway gw_svcolo

ike-policy ike_pol_svcolo;

address 64.13.163.35;     <<< Remote IKE ID = IP Address

dead-peer-detection;

external-interface ge-0/0/0.0;

Remote:

>> show security ike gateway hq

ike-policy hq;

address 50.208.33.177;

local-identity hostname srx240-02.prod.comp.com;   <<< Local ID = hostname  

external-interface reth0.1298;

- Please remove above statement and the Local IKE ID will default to IP address.

- I also noticed that in the branch ipsec vpn configuration the bind-interface st0.0  is missing

- In addition please confirm st0 is having family inet configured and assigned to a zone

I am attaching a sample config from the lab for your reference.

Regards,

Juniper CFTS Security

[#6]

In addition to what Vikas notes being different, this local-identity / remote-identity parameter is usually used when one side of the vpn has a dhcp address for the gateway.  Is the remote site dhcp?  That could also generate the message I was seeing aobut unknown gateway address.  If this is the case the vpn needs to be aggressive and not main mode as well.

I also note that you are using the gateway address as the vpn monitor address.  This is normally an ip address that goes across the encrypted tunnel to test that the tunnel itself is working and not the outside gateway address.  And since you note the hq site cannot ping the remote site this vpn monitor would keep the tunnel down.

As to why ping is not accepted, confirm in the untrust zone on the remote site that ping is allowed for the interface.  And of course that the ip address matches the interface address too.

Another paramter to note is that both sides have the establish tunnels immediately set.  This should only be configured on one side.  If both sides try to be initiators at the same time it can cause the tunnel to to come up as they both wait for the other be the responder.

[#7]

Hi,

thank you for all the answers and suggestions. Here s what I did :

- cleared the "local-identity hostname srx240-02.prod.comp.com "

- deleted vpn monitor

- deleted "establis tunnels immideately " just from ONE side.

I will inform you with the latest updates but I am still confused with zones and the binded interfaces with that . Isnt it possible configuring VPN without st, this is why i am asking because remote side has already configured by someone else ? Here are the zones  but it seems to be different kind of interfaces bound to different zones

show security zones
security-zone untrust {
address-book {
address addr_192_168_237_0_24 192.168.237.0/24;
address addr_10_33_0_0_16 10.33.0.0/16;
address addr_172_16_4_0_22 172.16.4.0/22;
address addr_172_16_0_0_24 172.16.0.0/24;
address addr_172_16_1_0_24 172.16.1.0/24;
address addr_10_17_0_0_16 10.17.0.0/16;
address addr_192_168_239_0_24 192.168.239.0/24;
address addr_192_168_234_0_24 192.168.234.0/24;
address addr_10_34_0_0_16 10.34.0.0/16;
}
host-inbound-traffic {
system-services {
ping;
traceroute;
}
}
interfaces {
reth0.295 {
host-inbound-traffic {
system-services {
ping;
traceroute;
}
}
}
reth0.298;
reth0.1298 {
host-inbound-traffic {
system-services {
ike;
ping;
traceroute;
}
}
}
}
}
security-zone trust {
address-book {
address addr_192_168_10_0_24 192.168.10.0/24;
address addr_10_0_10_0_24 10.0.10.0/24;
address addr_10_0_98_0_24 10.0.98.0/24;
address addr_10_18_0_0_16 10.18.0.0/16;
address addr_192_168_238_0_24 192.168.238.0/24;
address addr_192_168_11_0_24 192.168.11.0/24;
address 10.18.0.0/16 10.18.0.0/16;
address 192.168.10.0/24 192.168.10.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
reth1.100;
reth1.198;
reth1.211;
reth1.1801;
reth1.1805 {
host-inbound-traffic {
system-services {
dhcp;
ping;
traceroute;
}
}
}
reth1.1812;
reth1.1806 {
host-inbound-traffic {
system-services {
dhcp;
ping;
traceroute;
}
}
}
reth1.1807;
reth1.1811;
reth1.1808;
reth1.1809;
reth1.1810;
reth1.1831;
}
}
security-zone newprod1 {
address-book {
address newprod1 10.18.64.0/22;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
reth1.1841;
}
}
security-zone untrust-vpn {
address-book {
address 10.240.0.0/16 10.240.0.0/16;
address 10.35.0.0/16 10.35.0.0/16;
address 10.60.0.0/16 10.60.0.0/16;
address 10.38.0.0/16 10.38.0.0/16;
address 10.142.0.0/20 10.142.0.0/20;
address 10.36.0.0/24 10.36.0.0/24;
address 10.36.11.0/24 10.36.11.0/24;
address 10.36.12.0/28 10.36.12.0/28;
address 10.36.13.0/24 10.36.13.0/24;
address 10.36.14.0/24 10.36.14.0/24;
address 10.36.16.0/24 10.36.16.0/24;
address 10.36.15.0/27 10.36.15.0/27;
address 10.36.21.0/24 10.36.21.0/24;
address 10.36.22.0/28 10.36.22.0/28;
address 10.36.23.0/24 10.36.23.0/24;
address 10.36.24.0/24 10.36.24.0/24;
address 10.36.2.0/28 10.36.2.0/28;
address 10.36.3.0/24 10.36.3.0/24;
address 10.36.4.0/24 10.36.4.0/24;
}
interfaces {
st0.0;
st0.1;
st0.2;
st0.3;
st0.5;
st0.4;
}
}

---------------

# show interfaces

.

.

.

reth0 {

    description "outside interfaces ge0/0/8,0/0/9,5/0/8,5/0/9";

    vlan-tagging;

    redundant-ether-options {

        redundancy-group 1;

        lacp {

            passive;

            periodic slow;

        }

    }

    unit 295 {

        vlan-id 295;

        family inet {

            address 38.90.97.1/27;

            address 38.90.97.2/27;

            address 38.90.97.3/27;      

            address 38.90.97.4/27;

            address 38.90.97.5/27;

            address 38.90.97.6/27;

            address 38.90.97.7/27;

            address 38.90.97.8/27;

            address 38.90.97.9/27;

            address 38.90.97.10/27;

            address 38.90.97.11/27;

            address 38.90.97.12/27;

            address 38.90.97.13/27;

            address 38.90.97.14/27;

            address 38.90.97.15/27;

            address 38.88.46.10/29;

            address 38.90.97.18/27;

            address 38.90.97.19/27;

        }

    }

    unit 298 {

        vlan-id 298;

        family inet {

            address 64.13.153.17/27;

            address 64.13.144.65/27;

            address 64.13.153.18/27;

            address 64.13.153.29/27;

            address 64.13.153.30/27;

        }

    }

    unit 1298 {

        vlan-id 1298;

        family inet {

            address 64.13.163.35/26;

            address 64.13.163.36/26;

            address 64.13.163.37/26;

            address 64.13.163.38/26;

            address 64.13.163.39/26;

            address 64.13.163.40/26;

            address 64.13.163.41/26;

            address 64.13.163.42/26;

            address 64.13.163.43/26;

            address 64.13.163.44/26;

        }

    }

}

st0 {

    unit 0 {

        family inet;

    }

    unit 1 {

        family inet;

    }

    unit 2 {                            

        family inet;

    }

    unit 3 {

        family inet;

    }

    unit 4 {

        family inet;

    }

    unit 5 {

        family inet;

    }

}

[#8]

Hello 

Thanks a lot for sharing this. 

> I am pretty sure the bind-tunnel has been missed at the remote end

> Yes, its possible to create VPNs without st0 binding (policy based VPN)

> In that case you would need to associate the VPN in a security policy

> If you have the entire config from the remote end, I can verify if the intention is to do policy based VPN

> However I doubt the same, since there are a bunch of st0 interfaces configured

> If its possible to upload the entire config from both ends, it would greatly help to quickly pinpoint any missing parameters

Regards,

Vikas

[#9]

Hi, i was pretty hopeful  about the 'establish-tunnels immediately' but the tunnel was down again for 10 minutes.

Is it possible to configure remote device with policy based vpn and the local device with route-based VPN ?

I think local device has been configured with route-based VPN however remote-device has been configured with policy-based vpn, does it work this way ? 

I am attaching the both sides configs, hope it is clear enough

[#10]

Sorry, i tried to upload just the related vpn configs to prevent confusing.. if you need more config please let me know

[#11]

Hi

Thanks for sharing the config. Yes, you are right, remote end is configured for policy based VPN while HQ is configured for route based.

> Configuration looks fine

> I suggest you change the dpd config to always-send in HQ- set security ike gateway gw_svcolo dead-peer-detection always-send

> If possible also have the remote end configure dpd to always-send - set security ike gateway hq dead-peer-detection always-send

Regards,

Vikas

[#12]

Hi 

thank you for the suggestion but I think this did not work.. after I applied this to both devices, the VPN tunnels on the remote device started going down for more then 10 minutes during the day and more frequently. However, what is interesting is, the policy based VPN tunnels were up and they are never going down, so I reverted back..

Is it ok if I try to configure a route-based VPN on the remote device ? As you remember my local is route based and remote site is confiigured as policy-based.. if I configure a route based VPN on the remote site, do they work together ?

I dont want to delete the current policy based VPN config ?

Also, is this normal that i am getting these VPN down messages so frequently like every 3 minutes in kmd-logs :

kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-MPROD from 35.237.186.169 is down.

Jan 10 03:21:33  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP from 35.196.82.3 is down.

Jan 10 03:21:33  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-BOOT from 35.231.81.165 is down.

Jan 10 03:21:33  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP2 from 35.237.127.226 is down.

Jan 10 03:21:33  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-PROD from 35.227.37.137 is down.

Jan 10 03:21:33  srx240-02a kmd[33482]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-DEV from 35.196.237.124 is down.

Jan 10 03:21:33  srx240-02a kmd[33482]: IKE Phase-2: (Responder) Negotiation initiated [local_ip=64.13.163.35, remote_ip=35.231.81.165]

Jan 10 03:21:33  srx240-02a kmd[33482]: KMD_VPN_UP_ALARM_USER: VPN VPN-GCP-RTB-BOOT from 35.231.81.165 is up.

Thank you

[#13]

Hello 

Thanks for the update.

> Yes, I believe this is good option to move to route based on the remote side

> Policy based and route based cannot co-exist. We need to choose one way of configuring the VPN

> I am not sure about the logs in the kmd. It seems to be normal, But looks like one of the monitored VPNs is down and kmd is constantly reporting the same

Regards,

Vikas

[#14]

sorry for keep posting about the issue but the problem seems to be evolving ... how can I get more detail about the port down issues .. in log messages I realized that the all the st are during the problem.. is this a reason or a result ?

Jan 10 16:46:03  srx240-02a kmd[64311]: IKE Phase-2: (Responder) The symmetric crypto key has been generated successfully [local_ip=64.13.163.35, local_port=500, remote_ip=35.237.186.169, remote_port=500]

Jan 10 16:46:03  srx240-02a srx240-02a IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.3"

Jan 10 16:46:03  srx240-02a srx240-02a IFP trace> ifp_ifl_chg: IFL chg: "st0.3 ifl_id 160"

Jan 10 16:46:03  srx240-02a srx240-02a IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation

Jan 10 16:46:04  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:46:22  srx240-02a last message repeated 9 times

Jan 10 16:47:36  srx240-02a last message repeated 37 times

Jan 10 16:47:36  srx240-02a /kernel: KERN_ARP_DUPLICATE_ADDR: duplicate IP address 64.13.163.36! sent from address: 00:01:d7:eb:5a:47 (error count = 2486)

Jan 10 16:47:36  srx240-02a /kernel: KERN_ARP_ADDR_CHANGE: arp info overwritten for 64.13.163.31 from 00:23:e9:47:2d:c7 to 00:01:d7:eb:5a:47

Jan 10 16:47:38  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:47:40  srx240-02a kmd[64311]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-DEV from 35.196.237.124 is down.

Jan 10 16:47:40  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:47:48  srx240-02a last message repeated 4 times

Jan 10 16:47:50  srx240-02a kmd[64311]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP from 35.196.82.3 is down.

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT <UpDown> st0.0 index 118 <Broadcast PointToPoint Multicast>

Jan 10 16:47:50  srx240-02a kmd[64311]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-BOOT from 35.231.81.165 is down.

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT UpDown st0.0 index 118 <Broadcast PointToPoint Multicast Localup>

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT <UpDown> st0.2 index 158 <Broadcast PointToPoint Multicast>

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT UpDown st0.2 index 158 <Broadcast PointToPoint Multicast Localup>

Jan 10 16:47:50  srx240-02a kmd[64311]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-MPROD from 35.237.186.169 is down.

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT <UpDown> st0.3 index 160 <Broadcast PointToPoint Multicast>

Jan 10 16:47:50  srx240-02a kmd[64311]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP-RTB-PROD from 35.227.37.137 is down.

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT UpDown st0.3 index 160 <Broadcast PointToPoint Multicast Localup>

Jan 10 16:47:50  srx240-02a mib2d[1430]: SNMP_TRAP_LINK_DOWN: ifIndex 677, ifAdminStatus up(1), ifOperStatus down(2), ifName st0.0

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT <UpDown> st0.4 index 162 <Broadcast PointToPoint Multicast>

Jan 10 16:47:50  srx240-02a mib2d[1430]: SNMP_TRAP_LINK_DOWN: ifIndex 575, ifAdminStatus up(1), ifOperStatus down(2), ifName st0.2

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT UpDown st0.4 index 162 <Broadcast PointToPoint Multicast Localup>

Jan 10 16:47:50  srx240-02a kmd[64311]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-GCP2 from 35.237.127.226 is down.

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT <UpDown> st0.1 index 120 <Broadcast PointToPoint Multicast>

Jan 10 16:47:50  srx240-02a rpd[1408]: EVENT UpDown st0.1 index 120 <Broadcast PointToPoint Multicast Localup>

Jan 10 16:47:50  srx240-02a mib2d[1430]: SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName st0.3

Jan 10 16:47:50  srx240-02a mib2d[1430]: SNMP_TRAP_LINK_DOWN: ifIndex 546, ifAdminStatus up(1), ifOperStatus down(2), ifName st0.4

Jan 10 16:47:50  srx240-02a mib2d[1430]: SNMP_TRAP_LINK_DOWN: ifIndex 541, ifAdminStatus up(1), ifOperStatus down(2), ifName st0.1

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.0"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_chg: IFL chg: "st0.0 ifl_id 118"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.2"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_chg: IFL chg: "st0.2 ifl_id 158"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation

Jan 10 16:47:50  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.3"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_chg: IFL chg: "st0.3 ifl_id 160"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.4"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_chg: IFL chg: "st0.4 ifl_id 162"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.1"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_ifl_chg: IFL chg: "st0.1 ifl_id 120"

Jan 10 16:47:50  srx240-02a srx240-02a IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation

Jan 10 16:47:52  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:47:53  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:47:53  srx240-02a /kernel: KERN_ARP_ADDR_CHANGE: arp info overwritten for 64.13.163.31 from 00:01:d7:eb:5a:47 to 00:23:e9:47:2d:c7

Jan 10 16:47:54  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:48:23  srx240-02a last message repeated 17 times

Jan 10 16:48:49  srx240-02a last message repeated 13 times

Jan 10 16:48:50  srx240-02a kmd[64311]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=^O)M-^BAqU?>M-^A#?$?Zk?, src_ip=<none>, dst_ip=35.196.82.3]

Jan 10 16:48:50  srx240-02a kmd[64311]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=^]^YMtA??M-^N*?{M-^ENM- -b, src_ip=<none>, dst_ip=35.231.81.165]

Jan 10 16:48:50  srx240-02a kmd[64311]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=q)?a?M-^UM-^_?^M??N?%?^U, src_ip=<none>, dst_ip=35.237.186.169]

Jan 10 16:48:50  srx240-02a kmd[64311]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=h/OAaM-^E??ZM-^A^Y??|^D?, src_ip=<none>, dst_ip=35.227.37.137]

Jan 10 16:48:50  srx240-02a kmd[64311]: IKE Phase-1 Failure: ISAKMP negotiation retry limit reached [spi=?^S^F?M-^A8???M-^^^R"EAM-^Lj, src_ip=<none>, dst_ip=35.237.127.226]

Jan 10 16:48:51  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:48:53  srx240-02a srx240-02a nh_walk_chek_max_num_tag: unexpected NH type 17

Jan 10 16:48:59  srx240-02a last message repeated 3 times