Re: Cisco IPSec LAN-TO-LAN

mediaos718 · ‎07-16-2018

I have an IPsec LAN-to-LAN tunnel between a Cisco router and a Palo Alto FW. The tunnel remains UP-ACTIVE if there is interesting traffic - The tunnels goes down if there is no interesting traffic. The problem I am having is that I cannot bring the tunnel up from the Cisco side - If I initiate a ping from the Cisco side to go through the VPN, this will not bring the tunnel up. If I initiate the ping from the Palo Alto side then the tunnel comes up.

How do I have to configure the Cisco router to keep the tunnerl UP-ACTIVE at all time?

How can I bring the tunnel up from the Cisco router side?

rypto isakmp policy 10

encr aes 256

authentication pre-share

group 5

lifetime 28400

crypto isakmp key MYVPN! address x.x.x.x

crypto isakmp invalid-spi-recovery

crypto isakmp keepalive 10 periodic

crypto ipsec transform-set MYSET esp-aes 256 esp-sha-hmac

mode transport

!

crypto map MYMAP 10 ipsec-isakmp

set peer x.x.x.x

set security-association lifetime kilobytes 65000

set transform-set MYSET

match address Dublin_Subnet

ip access-list extended Dublin_Subnet

permit ip host 192.168.100.1 host 10.117.0.160 log

!

a.alekseev · ‎07-16-2018

What is the 192.168.100.1?

mediaos718 · ‎07-16-2018

This is a loopback on the local router for testing - When the tunnel is up and running I can ping across using the source loopback interface.

Loopback on local router: 192.168.100.1

IP on the remote side: 10.117.0.160

Cactus-01#ping 10.117.0.160 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.117.0.160, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/39/48 ms

a.alekseev · ‎07-16-2018

Disconnect the tunnel
And show the problem

Deb crypto isakmp
Deb crypto IPSec

mediaos718 · ‎07-16-2018

See attached for the log file.

I disconnected the tunnel and it did not connect back:

Cactus-01#sh crypto session

Crypto session current status

Interface: GigabitEthernet0/1

Session status: UP-ACTIVE

Peer: x.x.x.x port 500

IKEv1 SA: local x.x.x.x/500 remote x.x.x.x/500 Active

IPSEC FLOW: permit ip host 192.168.100.1 host 10.117.0.160

Active SAs: 2, origin: crypto map

Cactus-01#clear crypto session

Cactus-01#sh crypto session

Crypto session current status

Interface: GigabitEthernet0/1

Session status: DOWN-NEGOTIATING

Peer: x.x.x.x port 500

IKEv1 SA: local x.x.x.x/500 remote x.x.x.x/500 Inactive

IPSEC FLOW: permit ip host 192.168.100.1 host 10.117.0.160

Active SAs: 0, origin: crypto map

nterface: GigabitEthernet0/1

Session status: DOWN

Peer: x.x.x.x port 500

IPSEC FLOW: permit ip host 192.168.100.1 host 10.117.0.160

Active SAs: 0, origin: crypto map

a.alekseev · ‎07-16-2018

I did not see requested debugs

debug crypto isakmp
debug crypto ipsec

conf t
int GigabitEthernet0/1
no crypto-map XXX
crypto-map XXX
end
ping 10.117.0.160 source loopback 0

Richard Burts · ‎07-16-2018

Can you check with the administrator of the Palo Alto and verify that their configuration does not specify their role is originator?

I agree that seeing debug output from your machine would probably be helpful, especially at this point the debug for ISAKMP.

HTH

Rick

HTH

Rick

mediaos718 · ‎07-16-2018

Hello Richard, As per the admin of the Palo - The Palo is not the originator. In addition, the ACL matches on both ends. I attached a new set of log in the previous reply.

Richard Burts · ‎07-16-2018

The log that you posted has very interesting information in it. Going through the log I see that negotiation for ISAKMP begins, proceeds, and seems to complete the phase 1 negotiation successfully. But then your router receives a message from the Palo Alto that it should terminate the session

Jul 16 19:55:21.263: ISAKMP:(1275):deleting SA reason "Recevied fatal informational"

state (I) QM_IDLE (peer x.x.x.x)

So it looks to me like your side is ok and that something on the Palo Alto is the cause of the issue. Can they run some debugs or other diagnostics and perhaps identify why they are sending the message to terminate the session?

HTH

Rick

HTH

Rick

mediaos718 · ‎07-16-2018

See attached for the new log:

Cactus-01#sh debugging

Generic IP:

ICMP packet debugging is on

TELNET:

Incoming Telnet debugging is on

Cryptographic Subsystem:

Crypto ISAKMP debugging is on

Crypto IPSEC debugging is on

Crypto IPSEC Error debugging is on

Crypto IPSEC states debugging is on

Crypto IPSEC message debugging is on

Crypto Key Management Interface debugging is on

IKEV2:

IKEv2 error debugging is on

IKEv2 default debugging is on

IKEv2 packet debugging is on

Cactus-01#

Cactus-01#sh run int gig0/1

Building configuration...

Current configuration : 121 bytes

!

interface GigabitEthernet0/1

ip address x.x.x.x 255.255.255.0

duplex auto

speed auto

crypto map MYMAP

end

Cactus-01#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Cactus-01(config)#int gig0/1

Cactus-01(config-if)#no crypto map MYMAP

Cactus-01(config-if)#crypto map MYMAP

Cactus-01(config-if)#exi

Cactus-01(config)#exi

Cactus-01#ping 10.117.0.160 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.117.0.160, timeout is 2 seconds:

Packet sent with a source address of 192.168.100.1

.....

Success rate is 0 percent (0/5)

Cactus-01#sh cry

Cactus-01#sh crypto sess

Cactus-01#sh crypto session

Crypto session current status

Interface: GigabitEthernet0/1

Session status: DOWN-NEGOTIATING

Peer: x.x.x.x port 500

IKEv1 SA: local x.x.x.x/500 remote x.x.x.x/500 Inactive

IPSEC FLOW: permit ip host 192.168.100.1 host 10.117.0.160

Active SAs: 0, origin: crypto map

Cactus-01#sh crypto session

Crypto session current status

Interface: GigabitEthernet0/1

Session status: DOWN

Peer: x.x.x.x port 500

IPSEC FLOW: permit ip host 192.168.100.1 host 10.117.0.160

Active SAs: 0, origin: crypto map

Georg Pauwen · ‎07-16-2018

Hello,

Cactus-01#ping 10.117.0.160 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.117.0.160, timeout is 2 seconds:

Packet sent with a source address of 192.168.100.1

.....

Success rate is 0 percent (0/5)

Can you even ping without the crypto map ? Post the full config of your router...

a.alekseev · ‎07-16-2018

ok

Can you now collect
debug crypto isakmp
debug crypto ipsec

Do the same

conf t
int GigabitEthernet0/1
no crypto map MY_MAP
crypto map MY_MAP
end

but start ping from other side.

mediaos718 · ‎07-16-2018

See attached for the new log:

Cactus-01#sh debugging

Generic IP:

ICMP packet debugging is on

TELNET:

Incoming Telnet debugging is on

Cryptographic Subsystem:

Crypto ISAKMP debugging is on

Crypto IPSEC debugging is on

Crypto IPSEC Error debugging is on

Crypto IPSEC states debugging is on

Crypto IPSEC message debugging is on

Crypto Key Management Interface debugging is on

IKEV2:

IKEv2 error debugging is on

IKEv2 default debugging is on

IKEv2 packet debugging is on

Cactus-01#

Cactus-01#sh run int gig0/1

Building configuration...

Current configuration : 121 bytes

!

interface GigabitEthernet0/1

ip address x.x.x.x 255.255.255.0

duplex auto

speed auto

crypto map MYMAP

end

Cactus-01#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Cactus-01(config)#int gig0/1

Cactus-01(config-if)#no crypto map MYMAP

Cactus-01(config-if)#crypto map MYMAP

Cactus-01(config-if)#exi

Cactus-01(config)#exi

Cactus-01#ping 10.117.0.160 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.117.0.160, timeout is 2 seconds:

Packet sent with a source address of 192.168.100.1

.....

Success rate is 0 percent (0/5)

Cactus-01#sh cry

Cactus-01#sh crypto sess

Cactus-01#sh crypto session

Crypto session current status

Interface: GigabitEthernet0/1

Session status: DOWN-NEGOTIATING

Peer: x.x.x.x port 500

IKEv1 SA: local x.x.x.x/500 remote x.x.x.x/500 Inactive

IPSEC FLOW: permit ip host 192.168.100.1 host 10.117.0.160

Active SAs: 0, origin: crypto map

Cactus-01#sh crypto session

Crypto session current status

Interface: GigabitEthernet0/1

Session status: DOWN

Peer: x.x.x.x port 500

IPSEC FLOW: permit ip host 192.168.100.1 host 10.117.0.160

Active SAs: 0, origin: crypto map

Georg Pauwen · ‎07-16-2018

Hello,

on a side note, with Cisco to Cisco site to site VPNs, the access lists specifying the interesting traffic should mirror each other, I am not sure if that is a requirement for Cisco to Palo Alto as well, but you might want to check what is configured on the Palo Alto side...

Georg Pauwen · ‎07-16-2018

Hello,

I just checked a few PA configs, I am not sure if the Palo Altos support periodic keepalives, I think they require a value. So that means you would have to replace 'periodic' with a value (default is 5 I think):

crypto isakmp keepalive 10 periodic

crypto isakmp keepalive 10 5