cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1125
Views
6
Helpful
38
Replies

IKEv2 Issue, can\t bring tunnel between Cisco Router and Palo Alto

Hi, 

I'm getting strange issues when I cannot bring up the tunnel between Cisco Router and Palo Alto FW,

On Cisco router side I'm getting this on debug IKEv2:

==================================================================

*May 10 06:34:55.253: IPSEC:(SESSION ID = 1) (key_engine) request timer fired: count = 3,
(identity) local= 192.168.1.1:0, remote= 192.168.1.2:0,
local_proxy= 0.0.0.0/0.0.0.0/256/0,
remote_proxy= 0.0.0.0/0.0.0.0/256/0
*May 10 06:34:55.255: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 192.168.1.1:500, remote= 192.168.1.2:500,
local_proxy= 0.0.0.0/0.0.0.0/256/0,
remote_proxy= 0.0.0.0/0.0.0.0/256/0,
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 28800s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*May 10 06:34:55.261: IKEv2:% Getting preshared key from profile keyring PRIMARY
*May 10 06:34:55.261: IKEv2:% Matched peer block 'palo'
*May 10 06:34:55.262: IKEv2:Searching Policy with fvrf 0, local address 192.168.1.1
*May 10 06:34:55.263: IKEv2:Found Policy 'PRIMARY'
*May 10 06:34:55.270: IKEv2:SA is already in negotiation, hence not negotiating again
*May 10 06:35:25.254: IPSEC:(SESSION ID = 1) (key_engine) request timer fired: count = 4,
(identity) local= 192.168.1.1:0, remote= 192.168.1.2:0,
local_proxy= 0.0.0.0/0.0.0.0/256/0,
remote_proxy= 0.0.0.0/0.0.0.0/256/0
*May 10 06:35:25.255: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 192.168.1.1:500, remote= 192.168.1.2:500,
local_proxy= 0.0.0.0/0.0.0.0/256/0,
remote_proxy= 0.0.0.0/0.0.0.0/256/0,
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 28800s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
*May 10 06:35:25.260: IKEv2:% Getting preshared key from profile keyring PRIMARY
*May 10 06:35:25.261: IKEv2:% Matched peer block 'palo'
*May 10 06:35:25.261: IKEv2:Searching Policy with fvrf 0, local address 192.168.1.1
*May 10 06:35:25.262: IKEv2:Found Policy 'PRIMARY'
*May 10 06:35:25.268: IKEv2:SA is already in negotiation, hence not negotiating again
*May 10 06:35:34.021: IKEv2-ERROR:Couldn't find matching SA: Negotiating limit reached, deny SA request

*May 10 06:35:34.022: IKEv2:(SESSION ID = 0,SA ID = 0):Received Packet [From 192.168.1.2:500/To 192.168.1.1:500/VRF i0:f0]
Initiator SPI : 981433F14FD6564B - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST
*May 10 06:35:34.023: IKEv2-ERROR:: A supplied parameter is incorrect

=============================================================================

Cisco WAN IP: 192.168.1.1 Cisco Tunnel IP: 10.1.227.1

Palo Alto WAN side: 192.168.1.2 Cisco Tunnel IP: 10.1.227.2

On Palo side its default policy, no restrictions in terms of policies

Basically here is my configuration for Cisco Side (I'm also attatching screenshots of Palo Alto configuration below in attached messages)

==========================================================================

crypo ikev2 proposal PRIMARY
encryption 3des
integrity sha1
group 5
crypto ikev2 policy PRIMARY
proposal PRIMARY
crypto ikev2 keyring PRIMARY
peer palo
address 192.168.1.2 255.255.255.0
pre-shared-key local cisco123
pre-shared-key remote cisco123
!
crypto ikev2 profile PRIMARY
match address local 192.168.1.1
match identity remote address 192.168.1.2 255.255.255.0
authentication local pre-share
authentication remote pre-share
keyring local PRIMARY
lifetime 28800
crypto ipsec transform-set PRIMARY esp-3des esp-sha-hmac
mode tunnel
crypto ipsec profile PRIMARY
set security-association lifetime seconds 28800
set transform-set PRIMARY
set ikev2-profile PRIMARY

interface Vlan1000
ip address 192.168.1.1 255.255.255.0
end

fusion_1#show run int tu1000
Building configuration...

Current configuration : 191 bytes
!
interface Tunnel1000
ip address 10.1.227.1 255.255.255.252
tunnel source 192.168.1.1
tunnel mode ipsec ipv4
tunnel destination 192.168.1.2
tunnel protection ipsec profile PRIMARY
end

ip route 0.0.0.0 0.0.0.0 192.168.1.2

=======================================================================

 

What I'm doing wrong here? Thanks in advance

 

 

 

38 Replies 38

Any Update

MHM

So, I've change the device in LAB to different one, now I can see that Phase 1 completed, tunnel on Palo side is up, but tunnel is down on Cisco side, currently struggling on it


Router#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA

Tunnel-id Local Remote fvrf/ivrf Status
4 172.16.1.1/500 172.16.1.2/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/906 sec

IPv6 Crypto IKEv2 SA

 

On Palo I see tunnel is UP, and Im getting "IKEv3 child SA negotiation failed when processing traffic selector, cannot find matching IPsec tunnel for received traffic selector"

thoughts? at least there is some progress now

That very good 

In router do 

Show crypto session 

Can yoh share it here 

MHM

Now I can see tunnels on both sides are up, but I can't even ping from Cisco tunnel as source to Palo Alto tunnel IP


Interface: GigabitEthernet0/0
Session status: DOWN
Peer: 172.16.1.2 port 500
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 0, origin: crypto map

Interface: Tunnel10
Profile: TEST
Session status: UP-ACTIVE
Peer: 172.16.1.2 port 500
Session ID: 1
IKEv2 SA: local 172.16.1.1/500 remote 172.16.1.2/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 4, origin: crypto map

 

 

Ping 172.16.1.2 source 172.16.1.1

And can you elaborate more about this 

Interface: GigabitEthernet0/0
Session status: DOWN
Peer: 172.16.1.2 port 500
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 0, origin: crypto map

Share this 

MHM

Ok my bad, I've added crypto map under the interface before during tshoot, now I removed it, so I have only default route on Cisco side towards tunnel, same on Palo Alto side - default route to tunnel as exit and no proxy ID's, seems its currently working, I will try to bring up BGP over it now

 

 

Great

Run bgp use VTI IP as neighbor and it will sure work.

MHM

Thanks a lot for you help! I will 

Friend you are so so welcome 

Goodluck 

MHM