cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3187
Views
65
Helpful
13
Replies

Site2 Site VPN Tunnel Phase 1 is not initiating

S Kumar
Level 1
Level 1

I have various site to site tunnels running on my ASA. I have added a new one but, phase1 is not initiating.

  1. Packet capture shows that ASA is receiving the packets from objLocal destined for objRemote. I used acl_l2l_VPN  for packet capture. "cap mycap int inside match acl_l2l_VPN".
  2. Hit count on the acl_l2l_VPN is increasing every time packet comes in from objLocal but I see no attempt to initiate Phase1.
  3. I have the debugs on with "terminal monitor".
    • debug crypto ipsec enabled at level 127
      debug crypto ikev1 enabled at level 127
    • Crypto conditional debug is turned ON
    • IKE peer IP address filters:
      2.2.2.2/32
  4. Packet tracer does not show that it is going to attempt VPN: "packet-tracer input inside udp 192.168.100.10 2051 10.200.100.10 2051"

    Phase: 1
    Type: CAPTURE
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    MAC Access list

    Phase: 2
    Type: ACCESS-LIST
    Subtype:
    Result: ALLOW
    Config:
    Implicit Rule
    Additional Information:
    MAC Access list

    Phase: 3
    Type: FLOW-LOOKUP
    Subtype:
    Result: ALLOW
    Config:
    Additional Information:
    Found flow with id 91812347, using existing flow

    Result:
    input-interface: inside
    input-status: up
    input-line-status: up
    Action: allow

 

Packets are reaching at ASA and matching on the access-list, why ASA is not initiating the phase1?

 

Here is my relevant config:

!
object-group network objLocal
description Local Network
network-object host 192.168.100.10
!
object-group network objRemote
description Remote Network
network-object host 10.200.100.10
network-object host 10.200.100.20
network-object host 10.200.100.30
!
access-list acl_l2l_VPN extended permit ip object-group objLocal object-group objRemote
!
nat (inside,any) source static objLocal objLocal destination static objRemote objRemote no-proxy-arp route-lookup
!
crypto map localmap 80 match address acl_l2l_VPN
crypto map localmap 80 set pfs group2
crypto map localmap 80 set peer 2.2.2.2
crypto map localmap 80 set ikev1 transform-set my-tset
crypto map localmap 80 set security-association lifetime seconds 3600
!
tunnel-group 2.2.2.2 type ipsec-l2l
tunnel-group 2.2.2.2 ipsec-attributes
ikev1 pre-shared-key my_psk
!

1 Accepted Solution

Accepted Solutions

S Kumar
Level 1
Level 1

Interesting traffic for tunnel was SIP signalling. UDP packets were originating from port 5060 and going to UDP port 5060, since SIP was being inspected by ASA, somehow it was interfering with the tunnel. I had to disable SIP inspection in the global policy for the tunnel to work.

View solution in original post

13 Replies 13

@S Kumar can you provide the output of the debugs?

Please provide the IKEv1 and IPSec configuration

 

S Kumar
Level 1
Level 1

Transform Set:

crypto ipsec ikev1 transform-set my-tset esp-aes esp-sha-hmac

 

IKEV1 Policy:

crypto ikev1 policy 10
authentication pre-share
encryption aes
hash sha
group 2
lifetime 28800
crypto ikev1 policy 11
authentication pre-share
encryption aes
hash md5
group 2
lifetime 28800
crypto ikev1 policy 12
authentication pre-share
encryption aes
hash sha
group 1
lifetime 28800

@S Kumar what about the output of the debugs?

Which debugs should I share?

There is nothing showing up for for peer 2.2.2.2 for the following debugs:

debug crypto ipsec enabled at level 127
debug crypto ikev1 enabled at level 127

@S Kumar

So potentially the VPN is not even attempting to be established.

Is this traffic even routed out the correct interface? Provide the output of "show route"

Can the ASA ping the local IP address?

Rob,

 

You are absolutely correct, ASA is not even attempting for phase-1.

Yes, I am able to ping the local ip address from the ASA. As I mentioned that packet capture is showing that ASA is receiving the packets from the local ip.

 

# show route (public IP's are modified for privacy)

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is MY_ISP_GATEWAY_IP to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [1/0] via MY_ISP_GATEWAY_IP, backup
C 10.10.180.0 255.255.255.0 is directly connected, INT_FAILOVER
L 10.10.180.1 255.255.255.255 is directly connected, INT_FAILOVER
S 10.90.180.0 255.255.255.0 [1/0] via 192.168.180.1, inside
C 2.2.2.24 255.255.255.248 is directly connected, backup
L 2.2.2.26 255.255.255.255 is directly connected, backup
C 192.168.100.0 255.255.255.0 is directly connected, inside
L 192.168.100.2 255.255.255.255 is directly connected, inside
S 192.168.101.0 255.255.255.0 [1/0] via 192.168.180.1, inside
C 3.3.3.8 255.255.255.248 is directly connected, outside
L 3.3.3.3 255.255.255.255 is directly connected, outside

 

Set peer 2.2.2.2 ? Is it the outside interface or loopback of other peer? The ipsec is p2p you apply crypto to outside and use loopback as source of ipsec if asa have route to this loopback.

2.2.2.2 (not a real IP address, I have change the ip for privacy purposes.) is a remote peer IP.

Crypto maps is assigned to my outside interface, as I  mentioned that I have various site to site working tunnels.

Found flow with id 91812347, using existing flow<- this from capture 
this indicate that there is Flow "which I think another IPSec tunnel" and hence the ASA not start phase1 since it already have tunnel "phase1+phase2".
check the overlap between the ACL for each tunnel. 

try 

show run access-list 
see if there is access-list above the one for you tunnel and overlap with it.

S Kumar
Level 1
Level 1

Interesting traffic for tunnel was SIP signalling. UDP packets were originating from port 5060 and going to UDP port 5060, since SIP was being inspected by ASA, somehow it was interfering with the tunnel. I had to disable SIP inspection in the global policy for the tunnel to work.

happy news, 
good job friend.