- J-Net
- :
- Forums
- :
- SRX Services Gateway
- :
- Site to Site Vpn is not stable
- Application Acceleration 
- BLOG: Community Talk 
- BLOG: Information Experience (iX) 
- Community Feedback 
- Contrail Platform Developers 
- Ethernet Switching 
- Identity & Policy Control - SBR Carrier & SRC 
- Intrusion Prevention 
- Junos 
- Junos Automation (Scripting) 
- Junos Space Developer 
- Junosphere 
- Management 
- Routing 
- ScreenOS Firewalls (NOT SRX) 
- SRX Services Gateway 
- Training, Certification, and Career Topics 
- vMX 
- vSRX 
- Wireless LAN 
- Juniper Open Learning 
- Day One Books Archive 
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Site to Site Vpn is not stable
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
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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)
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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.
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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
Attachments
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
[ Edited ]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
Attachments
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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.
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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;
}
}
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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
Attachments
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
Sorry, i tried to upload just the related vpn configs to prevent confusing.. if you need more config please let me know
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Site to Site Vpn is not stable
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