SRX

Expand all | Collapse all

SRX VPN failover

Jump to Best Answer
  • 1.  SRX VPN failover

    Posted 08-16-2018 02:28

    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?







  • 2.  RE: SRX VPN failover
    Best Answer

     
    Posted 08-16-2018 04:55

    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



  • 3.  RE: SRX VPN failover

    Posted 08-16-2018 07:50

    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.



  • 4.  RE: SRX VPN failover

    Posted 08-16-2018 08:05

    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