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

[Jonathan Tomlin]

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]

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.

Thanks

Ajay

[Jonathan Tomlin]

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 10.22.2.22 host 10.33.3.33

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 204.11.22.123

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 204.11.22.123 type ipsec-l2l

tunnel-group 204.11.22.123 general-attributes

default-group-policy IBM_Enterprise_Extender_Policy

tunnel-group 204.11.22.123 ipsec-attributes

ikev1 pre-shared-key *****

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

[ajay chauhan]

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

Ajay

[Jonathan Tomlin]

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?

[Marvin Rhoads]

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

debug crypto condition peer 204.11.22.123

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

...plus 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.

[ajay chauhan]

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 204.11.22.123

debug crypto ipsec 7

debug crypto isakmp 7

Thanks

Ajay

[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.

Thanks!