SRX

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  VPN Redundancy using VPN Route Based

    Posted 03-26-2010 21:23

    Hi All,

     

    Is there any example configuration to done this? I've created 2 VPN tunnels (st0.0 and st0.1) with 2 ISPs if the first tunnel is down then the second traffic will be forwarded, but the problem is both 2 vpn tunnels is still "UP" (st0.0 and st0.1).

     

    I try using event automation

    http://www.juniper.net/us/en/community/junos/script-automation/library/event/enable-primary-nexthop/

     

    but still not running well..

     

    any advice?

     

    Thanks and Regards,

     

    Husni


    #vpn
    #redundancy


  • 2.  RE: VPN Redundancy using VPN Route Based

    Posted 03-27-2010 02:17

    The st-interface will be up as long as there is an SA. You can verify that there still is an SA with:

     

        show security ike security-associations

        show security ipsec security-associations

     

    How long it will take for the SA to time out depends on your settings for lifetime. But you can enable vpn-monitor to get a more active monitoring if a VPN tunnel goes down and a faster failover then.



  • 3.  RE: VPN Redundancy using VPN Route Based

    Posted 03-27-2010 05:38

    Hi TRUKonsult,

     

    Thanks for the reply, even there is no active tunnel st interface always UP

     

    Here's the information

     

    root@SRX210-Branch> show security ike security-associations    

    root@SRX210-Branch> show security ipsec security-associations  
      Total active tunnels: 0

    root@SRX210-Branch> show interfaces terse | match st             
    st0                     up    up  
    st0.0                   up    up   inet     10.10.10.2/30   
    st0.1                   up    up   inet     20.20.20.2/30   

    root@SRX210-Branch>

     

    it is weird why the st interface is always up...

     

    Any advice?

     

    THanks

     

    Cunny



  • 4.  RE: VPN Redundancy using VPN Route Based

    Posted 03-27-2010 06:34

    It's either a configuration error or you are running into some bug. But it's hard to tell with the given information. Maybe you could post some configuration?



  • 5.  RE: VPN Redundancy using VPN Route Based

    Posted 03-27-2010 06:46

    Hi,

     

    Here'e the configuration that I've made

     

     

    interfaces {
        ge-0/0/0 {      
            unit 0 {
                family inet {
                    address 192.168.30.1/30;
                }
            }
        }
        ge-0/0/1 {
            unit 0 {
                family inet {
                    address 192.168.30.5/30;
                }
            }
        }
        fe-0/0/2 {
            unit 0 {
                family inet {
                    filter {
                        input PBR;
                    }
                    address 10.1.32.1/22;
                }
            }
        }               
        fe-0/0/3 {
            unit 0 {
                family inet {
                    address 10.1.28.1/22;
                }
            }
        }
        st0 {
            unit 0 {
                family inet {
                    address 10.10.10.2/30;
                }
            }
            unit 1 {
                family inet {
                    address 20.20.20.2/30;
                }
            }
        }
    }
    event-options {
        policy enable-primary-nexthop {
            events ping_test_completed;
            within 10 {
                trigger on 1;
            }
            within 20 events ping_test_failed;
            then {
                event-script enable-primary-nexthop.slax {
                    arguments {
                        next-hop-interface st0.1;
                    }
                    output-filename foo;
                    destination foo;
                }
            }
        }
        policy enable-alternate-nexthop {
            events ping_test_failed;
            within 10 {
                trigger on 1;
            }
            within 20 events ping_test_completed;
            then {
                event-script enable-alternate-nexthop.slax {
                    arguments {
                        next-hop-interface st0.0;
                    }
                    output-filename zoo;
                    destination foo;
                }
            }
        }
        event-script {
            file enable-primary-nexthop.slax;
            file enable-alternate-nexthop.slax;
        }
        destinations {
            foo {
                archive-sites {
                    /var/tmp;
                }
            }
        }
    }
    routing-options {
        interface-routes {
            rib-group inet pbr;
        }               
        static {
            route 10.1.0.0/22 next-hop st0.0;
        }
        rib-groups {
            pbr {
                import-rib [ inet.0 PBR.inet.0 ];
            }
        }
    }
    security {
        ike {
            policy ike-policy1 {
                mode main;
                proposal-set standard;
                pre-shared-key ascii-text "$9$WzvXNb4aU.PQs2PQFnpu8X7-s2"; ## SECRET-DATA
            }
            gateway ike-gate {
                ike-policy ike-policy1;
                address 192.168.30.2;
                external-interface ge-0/0/0.0;
            }
            gateway ike-gate2 {
                ike-policy ike-policy1;
                address 192.168.30.6;
                external-interface ge-0/0/1.0;
            }
        }
        ipsec {
            policy vpn-policy1 {
                proposal-set standard;
            }
            vpn ike-vpn {
                bind-interface st0.0;
                ike {
                    gateway ike-gate;
                    ipsec-policy vpn-policy1;
                }
            }
            vpn ike-vpn2 {
                bind-interface st0.1;
                ike {
                    gateway ike-gate2;
                    ipsec-policy vpn-policy1;
                }
            }           
        }
        zones {
            security-zone trust {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                    protocols {
                        all;
                    }
                }
                interfaces {
                    fe-0/0/3.0;
                }
            }
            security-zone untrust {
                interfaces {
                    ge-0/0/0.0 {
                        host-inbound-traffic {
                            system-services {
                                all;
                            }
                            protocols {
                                all;
                            }
                        }
                    }
                }
            }
            security-zone vpn {
                interfaces {
                    st0.0;
                }
            }
            security-zone trust2 {
                interfaces {
                    fe-0/0/2.0 {
                        host-inbound-traffic {
                            system-services {
                                all;
                            }
                            protocols {
                                all;
                            }
                        }
                    }   
                }
            }
            security-zone untrust2 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
                interfaces {
                    ge-0/0/1.0;
                }
            }
            security-zone vpn2 {
                interfaces {
                    st0.1;
                }
            }
        }
        policies {
            from-zone trust to-zone vpn {
                policy vpn-tr-vpn {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
            from-zone vpn to-zone trust {
                policy vpn-vpn-tr {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
            from-zone trust2 to-zone vpn2 {
                policy vpn-tr2-vpn2 {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
            from-zone vpn2 to-zone trust2 {
                policy vpn-vpn-tr {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
            from-zone trust2 to-zone vpn {
                policy vpn-tr2-vpn2 {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
            from-zone vpn to-zone trust2 {
                policy vpn-vpn-tr2 {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
        }               
        flow {
            tcp-mss {
                ipsec-vpn {
                    mss 1350;
                }
            }
        }
    }
    firewall {
        family inet {
            filter PBR {
                term 1 {
                    from {
                        source-address {
                            10.1.32.0/22;
                        }
                    }
                    then {
                        routing-instance PBR;
                    }
                }
            }
        }               
    }
    routing-instances {
        PBR {
            instance-type forwarding;
            routing-options {
                static {
                    route 10.1.0.0/22 {
                        inactive: next-hop st0.1;
                        qualified-next-hop st0.0 {
                            preference 20;
                        }
                    }
                }
            }
        }
    }
    services {
        rpm {
            probe icmp-ping-probe {
                test ping-probe-test {
                    probe-type icmp-ping;
                    target address 192.168.30.6;
                    test-interval 1;
                }
            }
        }
    }

     

     

    Please advice...

     

    Currently I'm running on Junos 10.0R2

     

    THanks

     

    Husni



  • 6.  RE: VPN Redundancy using VPN Route Based
    Best Answer

    Posted 03-27-2010 14:16

    I would suggesting removing all of the code for the event-handling, since that shouldn't be needed and then enable the vpn-monitoring with some really short settings.

     

    Like:

     

    set security ipsec vpn-monitor-options interval 2 threshold 1

    set security ipsec vpn ike-vpn vpn-monitor

    set security ipsec vpn ike-vpn2 vpn-monitor

     

    and then verify routing with "show route 10.1.0.0"



  • 7.  RE: VPN Redundancy using VPN Route Based

    Posted 03-27-2010 23:28

    It works, thanks in a bunch....

     

     

     



  • 8.  RE: VPN Redundancy using VPN Route Based

     
    Posted 08-08-2012 07:42

    Hi All

     

    I walked into the same issue today. The workaround proposed by TRUKonsult worked,
    but the real problem seems to be the following. If VPNs are defined this way

     

    lab@srxB-2# show security ipsec 
    vpn vpn1 {
        bind-interface st0.0;
        ike {
            gateway gw1;
            ipsec-policy ipsec-pol;
        }
    }
    vpn vpn2 {
        bind-interface st0.1;
        ike {
            gateway gw2;
            ipsec-policy ipsec-pol;
        }
    }

     then st0 units are always up:

    lab@srxB-2# run show interfaces st0 terse 
    Interface               Admin Link Proto    Local                 Remote
    st0                     up    up  
    st0.0                   up    up   inet    
    st0.1                   up    up   inet  

     

    which is making VPN failover working incorrectly (traffic is easily black-holed).
    After adding "establish-tunnels immediately", the behavior changes. Only units
    that actually have phase 2 SA active are up:

    lab@srxB-2# show security ipsec 
    vpn vpn1 {
        bind-interface st0.0;
        ike {
            gateway gw1;
            ipsec-policy ipsec-pol;
        }
        establish-tunnels immediately;
    }
    vpn vpn2 {
        bind-interface st0.1;
        ike {
            gateway gw2;
            ipsec-policy ipsec-pol;
        }
        establish-tunnels immediately;
    }
    
    lab@srxB-2# run show interfaces st0 terse 
    Interface               Admin Link Proto    Local                 Remote
    st0                     up    up  
    st0.0                   up    up   inet    
    st0.1                   up    down inet 

     I am now going to ask a silly question. Is it by design? Any place where it is documented?

     

     

     



  • 9.  RE: VPN Redundancy using VPN Route Based

     
    Posted 08-17-2012 00:33

    JTAC confirmed this is by desing. They need to keep st0.x interface up to be able to establish tunnel on-traffic.