ā02-07-2022 10:10 AM
I have various site to site tunnels running on my ASA. I have added a new one but, phase1 is not initiating.
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
!
Solved! Go to Solution.
ā02-08-2022 12:12 PM
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.
ā02-07-2022 10:31 AM
ā02-07-2022 10:31 AM
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/119141-configure-asa-00.html
follow the step in this doc.
need transform-set and need IKEv1 policy.
ā02-07-2022 11:01 AM
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
ā02-07-2022 11:20 AM
@S Kumar what about the output of the debugs?
ā02-07-2022 12:31 PM
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
ā02-07-2022 12:40 PM
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?
ā02-07-2022 12:49 PM
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
ā02-07-2022 11:50 AM
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.
ā02-07-2022 12:29 PM
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.
ā02-07-2022 12:54 PM
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.
ā02-07-2022 12:57 PM
try
show run access-list
see if there is access-list above the one for you tunnel and overlap with it.
ā02-08-2022 12:12 PM
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.
ā02-08-2022 01:18 PM
happy news,
good job friend.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide