Showing results for 
Search instead for 
Did you mean: 
Jonathan Tomlin

ASA to Juniper/Netscreen Site-to-Site Bidirectional vs Originate-Only

Cisco Community,

I've got an issue in establishing a basic Site-to-Site VPN tunnel with another organization.

I can't see to find an answer to why when I set my tunnel policy connection type to bidirectional it appears that neither peer will talk to each other, but when I set my ASA to originate only, we get phase 1 completion but phase 2 failure.

Now, I've been all up and down on the phase 2 failure, but I don't understand why a bidirectional VPN configuration setting is not working.  My other Cisco to Cisco VPN tunnels use bidirectional as their configuration.

As I understand it, originate only is generally used in redundant VPN configurations, or configurations with multiple peers.

I'm not particularly familiar with Juniper and Netscreen configurations, and I have noticed they have to jump through several more hoops to get a basic encrypted VPN tunnel configured.

ajay chauhan
Rising star

Yes this is in case of backup L2L-

bidirectional—This specifies that this peer can accept and originate connections based on this crypto map entry. This is the default connection type for all Site-to-Site connections.

originate-only—This specifies that this peer initiates the first proprietary exchange in order to determine the appropriate peer to which to connect.   

    I am sure some configuration would be missing which is not brining the tunnel UP. You should check for Netscreen configuration guide or sample on net.

    If you are not so sure about your cisco VPN config please post that here will try to have a look on that.



    What is odd to me is why an originate-only connection type will start the tunnel negotiations while a bidirectional connection type seems to do nothing.  I have nothing showing in the logs with bidirectional set as my connection type for the crypto mapping.

    The following is the relevant configuration for this particular VPN tunnel:

    access-list Outside_cryptomap line 1 extended permit ip host host

    crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

    crypto map Outside_map 3 match address Outside_cryptomap

    crypto map Outside_map 3 set pfs

    crypto map Outside_map 3 set peer

    crypto map Outside_map 3 set ikev1 transform-set ESP-3DES-SHA

    crypto map Outside_map 3 set security-association lifetime seconds 28800

    crypto ikev1 policy 50

    authentication pre-share

    encryption 3des

    hash sha

    group 2

    lifetime 86400

    crypto ikev1 policy 110

    authentication pre-share

    encryption 3des

    hash md5

    group 2

    lifetime 86400

    group-policy IBM_Enterprise_Extender_Policy internal

    group-policy IBM_Enterprise_Extender_Policy attributes

    vpn-idle-timeout none

    vpn-tunnel-protocol ikev1

    tunnel-group type ipsec-l2l

    tunnel-group general-attributes

    default-group-policy IBM_Enterprise_Extender_Policy

    tunnel-group ipsec-attributes

    ikev1 pre-shared-key *****

    Unfortunately I have no access to the Juniper configuration.  What I have asked for, I've received little.

    Couple of things you need to make sure if configured rest looks good.

    1) crypto ikev1 enable outside

    2) Nat Exempt

    3) PFS on for remote site.

    4) esp-3des esp-sha-hmac  <<

    5) does not have Ike config for remote so no comment on that.



    Thanks for the reply, Ajay.

    I checked off against your numbered list there and confirmed it against my configuration.

    1) Yup, it's there, as I already have active ikev1 tunnels in place

    2) I have a NAT exemption statement in place in the firewall code for the hosts defined in the ACL

    nat (inside,Outside) source static NETWORK_OBJ_10.22.2.22 NETWORK_OBJ_10.22.2.22 destination static NETWORK_OBJ_10.33.3.33 NETWORK_OBJ_10.33.3.33

    I must note though, nat-control is not enabled on this particular ASA, so an exemption statement may not even be necessary as the other two tunnels currently running are not using an exemption line.

    3) PFS has been confirmed to have been selected on the remote side, as far as I know.

    4) I have tried a variety of encryption protocols to get phase 2 up, but that is not the basis of this discussion.

    5) me neither

    Even after all of this, I don't think I've gotten a clear answer as to why bidirectional will not begin Phase1 negotiaions, but originate-only, will.

    Is it something in my configuration that's messing it up, or is it the other side?  What is the resolution?

    You can sometimes see what's preventing the IPSec tunnel from establishing by using:

    debug crypto condition peer

    debug crypto ipsec 7

    debug crypto isakmp 7

    Then introduce some interesting traffic. If Phase 1 or Phase 2 is failing the debug output will generally point out the mismatch.

    The Juniper Netscreen should have some statements like:

    set ike p1-proposal "pre-g2-3des-sha-86400" preshare group2 esp 3des sha-1 second 86400

    set ike p1-proposal "pre-g2-3des-md5-86400" preshare group2 esp 3des md5 second 86400

    set ike gateway "[name for your end]" address [your end's outside IP] Main outgoing-interface "[name of their outside interface]" preshare "[key hash]" proposal "pre-g2-3des-sha-86400" "pre-g2-3des-md5-86400"

    set vpn "[name for the vpn]" gateway "[gateway name defined earlier]" no-replay tunnel idletime 0 sec-level standard a couple of policies (one for inbound and one for outbound traffic to use that defined VPN).

    set policy id [number of first policy] from "Trust" to "Untrust" [trust source IP] [untrust destination IP] "ANY" tunnel vpn "[name for the vpn]" id [vpn id number] pair-policy [number of 2nd policy]

    set policy id [number of second policy] from "Untrust" to "Trust" [untrust source IP] [trust destination IP] "ANY" tunnel vpn "[name for the vpn]" id [vpn id number] pair-policy [number of 1st policy]

    They can extract the above info for your confirmation.

    There could be so many things just based on this configuration its very difficult to say what is causing problem.However just make sure acl is not blcking this traffic and initiate some traffic from local site to remote site - & follow the steps suggested by Marvin for debug.

    Post us the output for this.

    Nat exempt is required there might be situation the same network is getting nat/pat to reach internet.

    debug crypto condition peer

    debug crypto ipsec 7

    debug crypto isakmp 7



    Jonathan Tomlin

    Alrighty, I'll try to answer my own question, but I would love for the community to confirm.

    The reason why "originate-only" will begin tunnel negotiations and "bidirectional" does not is because "bidirectional" connection type will only attempt to build the tunnel once "interesting" traffic has been received by the tunnel initiating device (a firewall in this case).

    If no intesting traffic is being received by the tunnel initiating device, it will not attempt to establish a tunnel with the configured end point.

    Please review this response and confirm its accuracy.  I'll reserve my Phase 2 issues for another discussion.


    Recognize Your Peers
    Content for Community-Ad