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.  IPSec between SRX'es becomes one-way after certain time.

    Posted 17 days ago
    Good afternoon,

    I've got a IPSec tunnel setup between an SRX cluster and a singular SRX, the setup is as follow:

    Site A:
    SRX300 [18.2R3.4] cluster in datacenter - 10.0.0.1 on WAN interface
    Cluster is in a private network behind a router that has a static NAT: 1.1.1.1 > 10.0.0.1 which allows UDP 500, UDP 4500, ESP and AH.

    Site B:
    SRX300 [15.1X49-D190.2] at the customers site - 172.16.0.1 on the WAN interface
    This SRX  is placed in their WAN environment, there is a Cisco router in front somewhere and we can see 2.2.2.2 as public IP when the VPN is up.

    VPN is configured as followed:

    Site A:
    
    set interfaces st0 unit 0 family inet mtu 1425
    set interfaces st0 unit 0 family inet address 10.239.4.141/30
    
    set security ike proposal pre_dh5_sha2_aes256_28800 authentication-method pre-shared-keys
    set security ike proposal pre_dh5_sha2_aes256_28800 dh-group group5
    set security ike proposal pre_dh5_sha2_aes256_28800 authentication-algorithm sha-256
    set security ike proposal pre_dh5_sha2_aes256_28800 encryption-algorithm aes-256-cbc
    set security ike proposal pre_dh5_sha2_aes256_28800 lifetime-seconds 28800
    
    set security ike policy SiteB_ike_pol mode aggressive
    set security ike policy SiteB_ike_pol proposals pre_dh5_sha2_aes256_28800
    set security ike policy SiteB_ike_pol pre-shared-key ascii-text "$9$-bV24JGDkmfZGCt0BEh24oaikFn/9tu"
    
    set security ike gateway SiteB_ike_gw ike-policy SiteB_ike_pol
    set security ike gateway SiteB_ike_gw dynamic hostname SiteB.vpn
    set security ike gateway SiteB_ike_gw dead-peer-detection interval 10
    set security ike gateway SiteB_ike_gw dead-peer-detection threshold 3
    set security ike gateway SiteB_ike_gw local-identity inet 1.1.1.1
    set security ike gateway SiteB_ike_gw external-interface reth0.0
    
    set security ipsec proposal esp_sha2_aes256_3600 protocol esp
    set security ipsec proposal esp_sha2_aes256_3600 authentication-algorithm hmac-sha-256-128
    set security ipsec proposal esp_sha2_aes256_3600 encryption-algorithm aes-256-cbc
    set security ipsec proposal esp_sha2_aes256_3600 lifetime-seconds 3600
    set security ipsec policy dh5_esp_sha2_aes256_3600 perfect-forward-secrecy keys group5
    set security ipsec policy dh5_esp_sha2_aes256_3600 proposals esp_sha2_aes256_3600
    
    set security ipsec vpn SiteB_ipsec_vpn bind-interface st0.0
    set security ipsec vpn SiteB_ipsec_vpn ike gateway SiteB_ike_gw
    set security ipsec vpn SiteB_ipsec_vpn ike ipsec-policy dh5_esp_sha2_aes256_3600​


    Site B:
    
    set interfaces st0 unit 0 family inet mtu 1425
    set interfaces st0 unit 0 family inet address 10.239.4.142/30
    
    set security ike proposal pre_dh5_sha2_aes256_28800 authentication-method pre-shared-keys
    set security ike proposal pre_dh5_sha2_aes256_28800 dh-group group5
    set security ike proposal pre_dh5_sha2_aes256_28800 authentication-algorithm sha-256
    set security ike proposal pre_dh5_sha2_aes256_28800 encryption-algorithm aes-256-cbc
    set security ike proposal pre_dh5_sha2_aes256_28800 lifetime-seconds 28800
    
    set security ike policy SiteA_ike_pol mode aggressive
    set security ike policy SiteA_ike_pol proposals pre_dh5_sha2_aes256_28800
    set security ike policy SiteA_ike_pol pre-shared-key ascii-text "$9xxxxx"
    
    set security ike gateway SiteA_ike_gw ike-policy SiteA_ike_pol
    set security ike gateway SiteA_ike_gw address 1.1.1.1
    set security ike gateway SiteA_ike_gw dead-peer-detection interval 10
    set security ike gateway SiteA_ike_gw dead-peer-detection threshold 3
    set security ike gateway SiteA_ike_gw local-identity hostname SiteB.vpn
    set security ike gateway SiteA_ike_gw remote-identity inet 1.1.1.1
    set security ike gateway SiteA_ike_gw external-interface ge-0/0/1.0​
    
    set security ipsec proposal esp_sha2_aes256_3600 protocol esp
    set security ipsec proposal esp_sha2_aes256_3600 authentication-algorithm hmac-sha-256-128
    set security ipsec proposal esp_sha2_aes256_3600 encryption-algorithm aes-256-cbc
    set security ipsec proposal esp_sha2_aes256_3600 lifetime-seconds 3600
    
    set security ipsec policy dh5_esp_sha2_aes256_3600 perfect-forward-secrecy keys group5
    set security ipsec policy dh5_esp_sha2_aes256_3600 proposals esp_sha2_aes256_3600
    
    set security ipsec vpn SiteA_ipsec_vpn bind-interface st0.0
    set security ipsec vpn SiteA_ipsec_vpn ike gateway SiteA_ike_gw
    set security ipsec vpn SiteA_ipsec_vpn ike ipsec-policy dh5_esp_sha2_aes256_3600
    set security ipsec vpn SiteA_ipsec_vpn establish-tunnels immediately

    Once in a while, it becomes impossible to get return traffic for traffic initiated from Site B. For instance i can ping 10.239.4.142 from Site A, but not 10.239.4.141 from Site B. In the logs and flow debug i can see pings go through the VPN from Site B to Site A, but the return traffic never arrives back. This happens with other traffic originating from Site B too.

    What i notice in the debug flow logs from Site A is:
    - when working the hex ID for the tunnel is the same for outbound traffic (ping 10.239.4.142 from Site A) and inbound (ping 10.239.4.141 from Site B)
    outbound: "going into tunnel 201326593 (nsp_tunnel=0x8d8d6a0)"
    inbound: "flow_first_complete_session, pak_ptr: 0x2088e58, nsp: 0x810edc8, in_tunnel: 0x8d8d6a0"

    - when faulty the hex ID for the tunnel is the different for outbound traffic (ping 10.239.4.142 from Site A) and inbound (ping 10.239.4.141 from Site B)
    outbound: "going into tunnel 201326627 (nsp_tunnel=0x89c84e0)"
    inbound: "flow_first_complete_session, pak_ptr: 0x2088e58, nsp: 0x9784bc8, in_tunnel: 0x8a76f60"

    I have no idea what this means, but i suspect something is going wrong with NAT on Site B's end, possibly related to sessions timing out on their public Cisco router

    I thought it might be a good idea to have VPN monitoring setup at Site B, to keep traffic from Site B flowing and preventing any timeouts:

    set security ipsec vpn-monitor-options interval 2
    set security ipsec vpn-monitor-options threshold 10
    set security ipsec vpn SiteA_ipsec_vpn vpn-monitor destination-ip 10.239.4.141
    set security ipsec vpn SiteA_ipsec_vpn vpn-monitor source-interface st0.0
    But when i commit this, the VPN becomes faulty and i cannot ping from Site B to 10.239.4.141 once more. The weird thing is that the VPN stays up and VPN monitoring says UP as well. But i cannot see any ICMP from the VPN monitor in the "security flow session" (spamming this command) or with "monitor traffic interface st0.0" at Site A.

    Can anybody help me troubleshoot this?

    ------------------------------
    Jeroen
    ------------------------------


  • 2.  RE: IPSec between SRX'es becomes one-way after certain time.

    Posted 10 days ago
    The problem has occured again, and it seems that other VPN's from Site A have the same problem, but those are IKEv2 VPN's with 3rd party controlled endpoints where i can only do troubleshooting from my side. Also, the problem occurs seemingly less often on those VPN's.

    That is why I am focusing on the VPN in the example above, where i have control of the hardware on both sides.

    Any pointers how to further troubleshoot this? Is this something JTAC could assist with?

    ------------------------------
    Jeroen Rijs
    ------------------------------