SRX

Expand all | Collapse all

Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.

Jump to Best Answer
  • 1.  Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.

    Posted 10-04-2019 07:34

    Hello!

    We have 2 SRX100's that are configured with policy based VPN.

    The tunnel is open, the IKE negotiations are done, a static route is configured to the IF but every 100 seconds the SRX drops the static route and a 'ping -t' stops, to then continue after 30 seconds when the route is active again.

    On the "other" side there is an dynamic IP so IKE is configured with FQDN 'larm-branch'.

    There are 8 other VPN connections with static IP's and without aggresive mode that are fully functional.

    How do we go about troubleshooting?

    policy ike_pol_STHLARM {
    mode aggressive;
    proposal-set standard;
    pre-shared-key ascii-text "$u812u0..........."; ## SECRET-DATA
    ------
    }
    gateway gw_STHLARM {
    ike-policy ike_pol_STHLARM;
    dynamic hostname larm-branch;
    dead-peer-detection;
    external-interface ge-0/0/1.0;
    version v2-only;
    }

    set security ike policy ike_pol_STHLARM mode aggressive
    set security ike policy ike_pol_STHLARM proposal-set standard
    set security ike policy ike_pol_STHLARM pre-shared-key ascii-text "$342fasfasd............"
    set security ike gateway gw_STHLARM ike-policy ike_pol_STHLARM
    set security ike gateway gw_STHLARM dynamic hostname larm-branch
    set security ike gateway gw_STHLARM dead-peer-detection
    set security ike gateway gw_STHLARM external-interface ge-0/0/1.0
    set security ike gateway gw_STHLARM version v2-only
    set security ipsec policy ipsec_pol_STHLARM perfect-forward-secrecy keys group2
    set security ipsec policy ipsec_pol_STHLARM proposal-set standard
    set security ipsec vpn STHLARM bind-interface st0.11
    set security ipsec vpn STHLARM vpn-monitor
    set security ipsec vpn STHLARM ike gateway gw_STHLARM
    set security ipsec vpn STHLARM ike ipsec-policy ipsec_pol_STHLARM
    set security ipsec vpn STHLARM establish-tunnels immediately
    set security policies from-zone trust to-zone trust policy policy_out_STHLARM match source-address any
    set security policies from-zone trust to-zone trust policy policy_out_STHLARM match destination-address NETLARM
    set security policies from-zone trust to-zone trust policy policy_out_STHLARM match application any
    set security policies from-zone trust to-zone trust policy policy_out_STHLARM then permit
    set security policies from-zone trust to-zone trust policy policy_in_STHLARM match source-address NETLARM
    set security policies from-zone trust to-zone trust policy policy_in_STHLARM match destination-address any
    set security policies from-zone trust to-zone trust policy policy_in_STHLARM match application any
    set security policies from-zone trust to-zone trust policy policy_in_STHLARM then permit

    set security zones security-zone trust address-book address NETLARM 192.168.253.0/24



    set routing-options static route 192.168.253.0/24 next-hop st0.11 (STHLARM)


    root@JRF-SW03> show interfaces st0.11 detail
    Logical interface st0.11 (Index 80) (SNMP ifIndex 538) (Generation 145)
    Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
    Traffic statistics:
    Input bytes : 4125797
    Output bytes : 4351933
    Input packets: 91060
    Output packets: 98347
    Local statistics:
    Input bytes : 69190
    Output bytes : 58540
    Input packets: 548
    Output packets: 487
    Transit statistics:
    Input bytes : 4056607 5728 bps
    Output bytes : 4293393 5352 bps
    Input packets: 90512 14 pps
    Output packets: 97860 14 pps
    Security: Zone: trust
    Allowed host-inbound traffic : bootp dns dhcp finger ftp tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip r2cp
    Flow Statistics :
    Flow Input statistics :
    Self packets : 1221
    ICMP packets : 3897
    VPN packets : 0
    Multicast packets : 0
    Bytes permitted by policy : 3788871
    Connections established : 0
    Flow Output statistics:
    Multicast packets : 0
    Bytes permitted by policy : 4320402
    Flow error statistics (Packets dropped due to):
    Address spoofing: 0
    Authentication failed: 0
    Incoming NAT errors: 0
    Invalid zone received packet: 0
    Multiple user authentications: 0
    Multiple incoming NAT: 0
    No parent for a gate: 0
    No one interested in self packets: 0
    No minor session: 0
    No more sessions: 0
    No NAT gate: 0
    No route present: 0
    No SA for incoming SPI: 0
    No tunnel found: 0
    No session for a gate: 0
    No zone or NULL zone binding 0
    Policy denied: 10
    Security association not active: 0
    TCP sequence number out of window: 0
    Syn-attack protection: 0
    User authentication errors: 0
    Protocol inet, MTU: 9192, Generation: 159, Route table: 0
    Flags: Sendbcast-pkt-to-re
    Addresses, Flags: Is-Preferred Is-Primary
    Destination: 192.168.1.32/30, Local: 192.168.1.33, Broadcast: Unspecified, Generation: 158








  • 2.  RE: Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.

     
    Posted 10-06-2019 14:58

    Note that this is a route based vpn since you are configuring both a phase 2 interface and a static route.

     

    The first task be to validate that all settings for both phase 1 gateway and phase 2 ipsec are identical on both sides.  A slight mismatch in settings could cause this, especially not the dead peer detection and vpn monitor setup.

     

    Next will be to try to determine why the connection is bouncing and whether this is phase 1 or 2 at issue.

    When you look at the security associations see which one is reseting wit the bounce you can tell from the length of time they are active for the site.

    show security ike security-associations

    show security ipsec security-associations

     

    Have a look for the corresponding log messages 

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

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

     



  • 3.  RE: Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.

    Posted 10-07-2019 01:24

    Hi Spuluka!

    First of all, big thanks to your reply!
    Great references and explanation!

    I can confirm that the configs are the same on the devices and it's phase 2 thats going down.

    When the ICMP replies stops i can no longer see the following:
    <268173313 ESP:3des/sha1 XXXXXXX 3531/ unlim U root 500 95.192.214.166
    >268173313 ESP:3des/sha1 XXXXXXX 3531/ unlim U root 500 95.192.214.166

    And i get the following messages from the log config you sent:

    Oct 7 09:42:06 JRF-SW03 kmd[1427]: KMD_VPN_DOWN_ALARM_USER: VPN instance-STHLARM_268173313 from 95.192.214.166 is down. Local-ip: 212.112.166.157, gateway name: gw_STHLARM, vpn name: STHLARM, tunnel-id: 268173313, local tunnel-if: st0.11, remote tunnel-ip: Not-Available, Local IKE-ID: 212.112.166.157, Remote IKE-ID: larm-branch, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
    Oct 7 09:42:36 JRF-SW03 kmd[1427]: KMD_PM_SA_ESTABLISHED: Local gateway: 212.112.166.157, Remote gateway: 95.192.214.166, 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: 0xfc2742ca, AUX-SPI: 0, Mode: Tunnel, Type: dynamic, Traffic-selector:
    Oct 7 09:42:36 JRF-SW03 kmd[1427]: KMD_PM_SA_ESTABLISHED: Local gateway: 212.112.166.157, Remote gateway: 95.192.214.166, 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: 0xd5fe95ac, AUX-SPI: 0, Mode: Tunnel, Type: dynamic, Traffic-selector:
    Oct 7 09:42:36 JRF-SW03 kmd[1427]: KMD_VPN_UP_ALARM_USER: VPN instance-STHLARM_268173313 from 95.192.214.166 is up. Local-ip: 212.112.166.157, gateway name: gw_STHLARM, vpn name: STHLARM, tunnel-id: 268173313, local tunnel-if: st0.11, remote tunnel-ip: Not-Available, Local IKE-ID: 212.112.166.157, Remote IKE-ID: larm-branch, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)

    How can i get further information about the reason for it going down and then immediatly up again?



  • 4.  RE: Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.
    Best Answer

     
    Posted 10-07-2019 03:05

    This set of messages can be caused by the vpn monitor configuration.  Please review the setup of vpn monitor optimize here.

     

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

     

    you can verify that vpn monitor is the source of the issue by temporaily removing it on both sides and see of the issue clears.

     



  • 5.  RE: Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.

    Posted 10-07-2019 04:07

    Hi Spuluka, it was indeed the vpn-monitor configuration that caused the issue.

    Now the Tunnel isn't going down anymore, do you want me to configure 'vpn-monitor optimized' and see if the problem shows up again?
    Im happy to scourage the forum if anyone has found the specific issue and solution.

    Best Regards
    Andreas



  • 6.  RE: Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.

     
    Posted 10-07-2019 17:22

    Yes, adding optimized option may allow the vpn monitor to work without bouncing the tunnel and you can check that.  VPN monitor is most helpful when you have multiple paths to get to the resources via another link or tunnel.  The vpn monitor will bring down an interface on an inactive tunnel so that the alternate path can take over.

     

    If you only have one path than it is not really going to do anything for you.

     



  • 7.  RE: Policy Based VPN, OnPrem-SRX to SRX with 4G drops static route.

    Posted 10-08-2019 13:54

    Thanks spuluka for the explanation, we opted for disabling vpn-monitor completely and instead configure a check with Nagios.

    Thanks for all your help!