SRX

Hi folks.
I'm facing abnormal behavior of the SRX VPN failover when two peers configured.
Configuration looks like:

set security ike gateway gate_for_students ike-policy ike-policy
set security ike gateway gate_for_students address 1.1.1.1
set security ike gateway gate_for_students address 2.2.2.2
set security ike gateway gate_for_students dead-peer-detection always-send
set security ike gateway gate_for_students dead-peer-detection interval 10
set security ike gateway gate_for_students dead-peer-detection threshold 2
set security ike gateway gate_for_students external-interface fe-0/0/0

Where 1.1.1.1 is Juniper SRX5800
And 2.2.2.2 Cisco ASA5585
And this side is:

Model: srx100b
JUNOS Software Release [12.1X46-D77.1]

Both VPN tunnel work perfectly when configured individually.
So there is no problems with tunnel, IPSec, IKE, routing, etc.

But when I start testing failover...
Firstly I've tried to delete all VPN Peer configuration from 1.1.1.1 and wait untill SRX100 failover to 2.2.2.2. Nothing happens in this case. SRX100 doesn't even accept incoming VPN packets from 2.2.2.2 when I try to initiate IPSec from 2.2.2.2 Side.

But when I change configuration to this:

set security ike gateway gate_for_students address 1.2.3.4
set security ike gateway gate_for_students address 2.2.2.2

where 1.2.3.4 is any host that doesn't even configured for SRX100 IPSec but pinging. Failover occurs perfectly.
I've tried to change dpd to always-send, optimized  - No result.
Tried vpn-monitoring - Same.

I've tried change SRX100 junos version - No luck.

As I understood, dpd is for IKE tracking, vpn-monitoring is of IPSec traking. That's not where I have problem.

Do you have any idea how make SRX100 failoveer correctly when first peer is responsible but doens't able to build IKE?

Hello,

As long as you get a DPD response from 1.1.1.1, SRX will keep its existing VPN up.

So for some reason, despite you deleting all VPN configuration on 1.1.1.1 for SRX peer, somehow it still continues to respond to DPD.

This theory is confirmed by the fact that when you use non existance IP as first peer, SRX indeed falls back to second peer since it no longer receives the DPD.

Instead of deleting VPN configuration on 1.1.1.1 for SRX, you can simple bring that interface down or apply a filter or access list to block any traffic from SRX. This might be better simulation of failover scenario.

Regards,

Rushi

Hello Rushi. Thank you for your fast reply.

I've tried that  after your post - Failover occurs normally.

The reason that behaivor is still bad for me is that we have several thousand IPSec's and our L2 network support team may from time-to-time misconfigure one side of VPN HUB's. That bring us immideatly problem with main failover 1.1.1.1 side if they misconfigure prekey or something on that side but other 2.2.2.2 is still good. Or, the main 1.1.1.1 5800 cluster HUB may freeze for some JunOS bug or any reason and we will not get failover untill manually disable trafic to this site. It's pretty strange for me, that I can get pretty good network desight theme, good convergense time and many more amazing things that works... But that small dpd functionality little spoils everything.

I've thought I just missed some piece to make all thing perfect.

Hello,

DPD messages are sent and received over IKE SA regardless of IPSEC SA status on the receiving end. As long as IKE SA is up, DPD is answered.

If You need to probe IPSEC SA liveness, then You need another tool like VPN monitoring, or dynamic routing protocol running inside the IPSEC SA/tunnel.

HTH

Thx

Alex