SRX

 View Only
last person joined: 12 hours ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA

    Posted 04-12-2019 11:46

    I am trying to connect a Juniper SRX300 (running 15.1X49-D170.4) to a Cisco ASA using a route-based VPN but getting the following error:

     

    Apr 12 18:37:40 jnx kmd[1883]: KMD_VPN_TS_MISMATCH: Traffic-selector mismatch, vpn name: VPN-NAME, Peer Proposed traffic-selector local-ip: ipv4(192.168.0.11),ipv4(192.168.0.0-192.168.0.255), Peer Proposed traffic-selector remote-ip: ipv4(10.1.100.1),ipv4(10.1.0.0-10.1.255.255)
    Apr 12 18:37:40 jnx kmd[1883]: IPSec negotiation failed with error: Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA. Negotiation failed.. IKE Version: 2, VPN: VPN-NAME Gateway: VPN-NAME, Local: X.X.X.X/500, Remote: Y.Y.Y.Y/500, Local IKE-ID: X.X.X.X, Remote IKE-ID: Y.Y.Y.Y, VR-ID: 0
    Apr 12 18:37:48 jnx kmd[1883]: KMD_VPN_TS_MISMATCH: Traffic-selector mismatch, vpn name: VPN-NAME, Peer Proposed traffic-selector local-ip: ipv4(192.168.0.17),ipv4(192.168.0.0-192.168.0.255), Peer Proposed traffic-selector remote-ip: ipv4(192.168.2.148),ipv4(192.168.2.0-192.168.2.255)
    Apr 12 18:37:48 jnx kmd[1883]: IPSec negotiation failed with error: Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA. Negotiation failed.. IKE Version: 2, VPN: VPN-NAME Gateway: VPN-NAME, Local: X.X.X.X/500, Remote: Y.Y.Y.Y/500, Local IKE-ID: X.X.X.X, Remote IKE-ID: Y.Y.Y.Y, VR-ID: 0
    Apr 12 18:37:48 jnx kmd[1883]: IPSec negotiation failed with error: No proposal chosen. IKE Version: 2, VPN: VPN-NAME Gateway: VPN-NAME, Local: X.X.X.X/500, Remote: Y.Y.Y.Y/500, Local IKE-ID: X.X.X.X, Remote IKE-ID: Y.Y.Y.Y, VR-ID: 0

     

    Phase 1 comes up with just fine:

     

    Index State Initiator cookie Responder cookie Mode Remote Address
    320684 UP 40b2cdbb9208bedb 379b3b93cef1d7b7 IKEv2 Y.Y.Y.Y

     

    Local configuration:

     

    set security ipsec proposal PROPOSAL protocol esp
    set security ipsec proposal PROPOSAL authentication-algorithm hmac-sha-256-128
    set security ipsec proposal PROPOSAL encryption-algorithm aes-256-cbc
    set security ipsec proposal PROPOSAL lifetime-seconds 3600
    set security ipsec policy PROPOSAL proposals PROPOSAL
    set security ipsec vpn VPN-NAME bind-interface st0.0
    set security ipsec vpn VPN-NAME ike gateway VPN-NAME
    set security ipsec vpn VPN-NAME ike ipsec-policy PROPOSAL
    set security ipsec vpn VPN-NAME traffic-selector AGGREGATE local-ip 192.168.0.0/24
    set security ipsec vpn VPN-NAME traffic-selector AGGREGATE remote-ip 10.1.0.0/16
    set security ipsec vpn VPN-NAME traffic-selector LEGACY local-ip 192.168.0.0/24
    set security ipsec vpn VPN-NAME traffic-selector LEGACY remote-ip 192.168.2.0/24
    set security ipsec vpn VPN-NAME traffic-selector DMZ local-ip 192.168.0.0/24
    set security ipsec vpn VPN-NAME traffic-selector DMZ remote-ip 192.168.253.0/24
    set security ipsec vpn VPN-NAME establish-tunnels immediately

     

    The other side is a Cisco ASA 5515 with the following configuration:

     

    crypto map outside 2001 match address ACL-REMOTE-PEER
    crypto map outside 2001 set peer X.X.X.X
    crypto map outside 2001 set ikev2 ipsec-proposal AES256

    access-list ACL-REMOTE-PEER; 4 elements; name hash: 0x9132bea2
    access-list ACL-REMOTE-PEER line 1 extended permit ip 192.168.2.0 255.255.255.0 192.168.0.0 255.255.255.0 (hitcnt=32138) 0x9dd1206f
    access-list ACL-REMOTE-PEER line 1 extended permit ip 10.1.0.0 255.255.0.0 192.168.0.0 255.255.255.0 (hitcnt=96254) 0xb8676dd0
    access-list ACL-REMOTE-PEER line 1 extended permit ip 10.3.0.0 255.255.0.0 192.168.0.0 255.255.255.0 (hitcnt=7222) 0x59e24aa9
    access-list ACL-REMOTE-PEER line 1 extended permit ip 192.168.253.0 255.255.255.0 192.168.0.0 255.255.255.0 (hitcnt=7263) 0x6c631e57

     

    Has anybody been successful in connecting Juniper with Cisco with multiple traffic selectors?

     

    Any hints ?



  • 2.  RE: Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA

    Posted 04-12-2019 16:41

    Hi dmickovic

     

    The SRX has a problem with the format in which the traffic-selectors are sent by the ASA:

     

     

    Apr 12 18:37:40 jnx kmd[1883]: KMD_VPN_TS_MISMATCH: Traffic-selector mismatch, vpn name: VPN-NAME, Peer Proposed traffic-selector local-ip: ipv4(192.168.0.11),ipv4(192.168.0.0-192.168.0.255), Peer Proposed traffic-selector remote-ip: ipv4(10.1.100.1),ipv4(10.1.0.0-10.1.255.255)

     

     

    Because the ASA sends the subnets (proxy-ids) plus the IP address of the hosts that originated the tunnel negotiation (in this case 192.168.0.11 and 10.1.100.1), the SRX detects multiple traffic-selectors attributes being sent by the ASA:

     

     

    Apr 12 18:37:40 jnx kmd[1883]: IPSec negotiation failed with error: Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA. Negotiation failed.. IKE Version: 2, VPN: VPN-NAME Gateway: VPN-NAME, Local: X.X.X.X/500, Remote: Y.Y.Y.Y/500, Local IKE-ID: X.X.X.X, Remote IKE-ID: Y.Y.Y.Y, VR-ID: 0

     

     

    The format used by the ASA doesnt seem to be incorrect based on the RFC:

     

    Ref: https://tools.ietf.org/html/rfc5996#section-2.9

     

    To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TSiand TSr a very specific Traffic Selector including the addresses in the packet triggering the request.  In the example, the initiator would include in TSi two Traffic Selectors: the first containing the address range (198.51.100.43 - 198.51.100.43) and the source port and IP protocol from the packet and the second containing (198.51.100.0 -198.51.100.255) with all ports and IP protocols.  The initiator would similarly include two Traffic Selectors in TSr.  If the initiator creates the Child SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other.  In that case, the first values in TSi and TSr can be ranges rather than specific values.

     

    As a workaround we could set the SRX to always be the initiator of the tunnel negotiations.

     

    I can see that your SRX is configured with "establish-tunnels immediately" already which should do the trick. Is it possible to configure the ASA to always perform as responder only?

     



  • 3.  RE: Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA

    Posted 04-13-2019 01:18

    Try to configure ikev1 on both sides and remove addional network 10.3.0.0/16 Cisco ACL:

    set security ike gateway <Gteway Name>  version v1-only

    Cisco:

    ++++++++

    access-list ACL-REMOTE-PEER line 1 extended permit ip 10.3.0.0 255.255.0.0 192.168.0.0 255.255.255.0 <-- Extra config

     

     

     



  • 4.  RE: Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA

    Posted 04-13-2019 17:57

    I'd like to keep it as IKEv2.

     

    Does anybody know (and I'll check with Cisco Forums as well) how to modify the proxy-id's on the Cisco's side so that is not sending the "specifics" ?



  • 5.  RE: Peer proposed unsupported multiple traffic-selector attributes for a single IPSec SA

    Posted 04-13-2019 18:21

    dmickovic,

     

    I will assume that the format used for sending the traffic selectors is already bulit in the OS of the ASA and cannot be changed, however let us know if you are able to confirm this with Cisco.

     

    As for now, I suggest to remove the VPN configuration on the ASA and apply it again in order to try to make the ASA responder of the IKE negotation and confirm if the tunnel comes up. Leave the "establish-tunnels immediately" option on the SRX to make it the initiator. Let us know if this way you can bring up the VPN.