ISR 1100 Routing IPSEC

[Niklas.D]

Hi there! 

So we are trying to setup the ISR-1100 Router via a VPN to our "corenet" one route via Cabel and one the other route the 4G LTE network.

We can get the traficc to work from 

Int gi0/0/0.903 - 10.240.2.238 to the Checkpoint Firewall 10.240.240.1  

And also from cellular 0/2/0 10.241.1.21 to Chp FW 10.240.240.1 

We tried to then use the Loopback 0 10.220.220.1 to establish the VPN tunnal to Checkpoint FW 10.240.240.1

And that also looks to work. 

But when we try to start traffic from the inside network 10.128.41.1 we get the report from Checkpoint that the traffic is sent unecrypted.  (from 10.128.41.1 to 10.0.2.12) 

So we are stuck on geting inside traffic thru the tunnel

and how can we make the loopback switch between the vlan 903 or the cellular.

should we use the loopback even? 

[Richard Burts · Accepted solution]

Let us start with the easy question. You ask if you should be using the loopback interface as the peer address for the ipsec tunnel. The answer is that if you want the  vpn to operate over 2 outbound interfaces (G0/0/0.903 and cellular) then using the loopback as the peering address is a good solution and yes you should use it.

There are several issues in the configuration which you should address.

1) you have applied the crypto map on the loopback interface. This is not correct. The crypto map should be applied on the outgoing interface(s).

2) the ACL used to identify the traffic for encryption uses permit ip any any. The advice from Cisco is that it causes problems when you permit any any. The ACL should specify the subnets in your network as source and subnets in the peer as destination.

3) I see that you are running OSPF on your outside interface G0/0/0.903. I assume that you are learning the route for the remote peer address via OSPF. Is that correct? This would allow the vpn tunnel to come up and to carry traffic. But it would not provide any way to fail over to the cellular interface. 

4) I do not see any routing using the cellular interface. Are you learning any routes over the cellular interface (does dhcp provide any routes?) Without routes using the cellular there is no way to send vpn traffic via the cellular. It is not clear how you want to use the cellular interface but I am guessing that you want the vlan to be primary and the cellular to be backup. In that case you might want to configure a floating static route for the peer address. If the router is learning the peer address via OSPF and has a floating static using the cellular then the vlan would be primary and the cellular would be backup.

HTH

Rick

[Niklas.D]

Morning Richard 

Thank you for Replying! 

We have done as you adviced and set the Crypto MAP on the interfaces gi0/0/0.903 and interface Cellular 0/2/0

We treid to update the ACL. but we dont know if the one we made is enough? 

*Jul 31 07:30:27.120: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.220.220.1, prot=50, spi=0xC8D4F995(3369400725), srcaddr=10.240.240.1, input interface=GigabitEthernet0/0/0.903 -  We now made this Appear in the log. 

We hade made no config for the route to use the cellular yet, as we dint even get the tunnel on the wierd connection to work. 

[Georg Pauwen]

Hello,

try and set the reverse route in the crypto map:

crypto map vadefaultmap 1 ipsec-isakmp
description Tunnel to MOHQ
set peer 10.240.240.1
set security-association lifetime seconds 28800
set transform-set AES128
set pfs group14
reverse-route remote peer 10.240.240.1

match address IPSEC_ACL

Also, try and see what happens when you remove the access list from the subinterface, e.g.:

interface GigabitEthernet0/0/0.8
description Clientnet
encapsulation dot1Q 8
ip address 10.128.41.129 255.255.255.224
ip helper-address 10.0.4.9
--> no ip access-group CLIENT in
ip tcp adjust-mss 1190

I am not sure what the line 'deny ip any 10.128.41.0 0.0.0.255' is doing in that access list...

[Niklas.D]

Hi There Georg





Just tried this and i still get the same message





crypto map vadefaultmap 1 ipsec-isakmp

description Tunnel to MOHQ

set peer 10.240.240.1

set security-association lifetime seconds 28800

set transform-set AES128

set pfs group14

match address IPSEC_ACL

reverse-route remote-peer 10.240.240.1

[Georg Pauwen]

Hello,

turn on 'debug crypto ipsec' and ping some IP address on the other side of the VPN tunnel, e.g.:

GrevieRouter#ping 10.0.11.11 source interface GigabitEthernet0/0/0.903

Post the output of the debug...

[Niklas.D]

903 should be the outside interface. and 0/0/0.2 is from the inside



GrevieRouter#ping 10.0.2.12 source gi0/0/0.2

Type escape sequence to abort.

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

Packet sent with a source address of 10.128.41.1



*Jul 31 08:46:41.360: IPSEC(sa_request): ,

(key eng. msg.) OUTBOUND local= 10.240.2.238:500, remote= 10.240.240.1:500,

local_proxy= 10.128.41.0/255.255.255.0/256/0,

remote_proxy= 10.0.0.0/255.255.0.0/256/0,

protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),

lifedur= 28800s and 4608000kb,

spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0.....

Success rate is 0 percent (0/5)



*Jul 31 08:46:56.255: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.220.220.1, prot=50, spi=0xC8D4F995(3369400725), srcaddr=10.240.240.1, input interface=GigabitEthernet0/0/0.903

Type escape sequence to abort.



GrevieRouter#ping 10.0.2.12 source gi0/0/0.903

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

Packet sent with a source address of 10.240.2.238

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

GrevieRouter#

*Jul 31 08:47:11.360: IPSEC:(SESSION ID = 1) (key_engine) request timer fired: count = 1,

(identity) local= 10.240.2.238:0, remote= 10.240.240.1:0,

local_proxy= 10.128.41.0/255.255.255.0/256/0,

remote_proxy= 10.0.0.0/255.255.0.0/256/0

*Jul 31 08:47:11.361: IPSEC(sa_request): ,

(key eng. msg.) OUTBOUND local= 10.240.2.238:500, remote= 10.240.240.1:500,

local_proxy= 10.128.41.0/255.255.255.0/256/0,

remote_proxy= 10.0.0.0/255.255.0.0/256/0,

protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),

lifedur= 28800s and 4608000kb,

spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0

[Georg Pauwen]

Hello,

the destination address is the loopback interface. Post the configuration of the other side (the other VPN endpoint router) if possible...

Also, try and globally configure 'crypto isakmp invalid-spi-recovery'...

[Niklas.D]

10.240.240.1 is the VPN endpoint

and its set ti start the VPN tunnel to 10.220.220.1 

[Georg Pauwen]

Hello,

why don't you just use the actual subinterface on the outside (IP 10.240.2.238) for the endpoint, why the loopback ? Is that a requirement ?

[Niklas.D]

Hi Georg

Yes it is, we want the router to have two ways, one is gi0/0/0.903 (wierd) and one way is the cellular 0/2/0 way.

So if the FiberOptics is cute or the ISP has problems we can use the 4G LTE instead!

That is why we want the loopback to be the peer for the tunnal.

[Georg Pauwen]

Hello,

apply the crypto map to the Loopback interface then...

interface Loopback0
ip address 10.220.220.1 255.255.255.255
crypto map vadefaultmap

[Richard Burts · Accepted solution]

I have a couple of things to address:

- note that in this error message it is about receiving an packet with invalid spi

*Jul 31 08:46:56.255: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=10.220.220.1, prot=50, spi=0xC8D4F995(3369400725), srcaddr=10.240.240.1, input interface=GigabitEthernet0/0/0.903

So this particular problem is not on the router for the original poster but is on the peer. 

- I can not agree with the advice from Georg to place the crypto map on the loopback interface. There are 2 aspects to consider when implementing ipsec vpn: 1) which address to use for peering, and 2) which interface(s) to have the crypto map. Note that these are independent of each other. There is no requirement that the peering address should have the crypto map. The crypto map needs to be applied on the interface used by the ipsec packet to exit the router.

Given the requirement here to have 2 paths to the peer it certainly makes sense to use the loopback interface  for peering. But that does not mean that the crypto map should be applied to the loopback.

Some of the output posted suggests that the ipsec vpn may be coming up on this router. Can the original poster do this test and post the output:

show crypto ipsec sa

from a device in the local LAN attempt access to a device in the remote LAN

show crypto ipsec sa

HTH

Rick

[Niklas.D]

Hello here is the output i belive you where asking for,

interface: GigabitEthernet0/0/0.903
Crypto map tag: vadefaultmap, local addr 10.240.2.238

protected vrf: (none)
local ident (addr/mask/prot/port): (10.128.41.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)
current_peer 10.240.240.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 2, #recv errors 0

local crypto endpt.: 10.240.2.238, remote crypto endpt.: 10.240.240.1
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0.903
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

interface: Cellular0/2/0
Crypto map tag: vadefaultmap, local addr 10.241.1.21

protected vrf: (none)
local ident (addr/mask/prot/port): (10.128.41.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)
current_peer 10.240.240.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 10.241.1.21, remote crypto endpt.: 10.240.240.1
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb Cellular0/2/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

GrevieRouter# ping 10.0.2.12 source 10.128.41.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.12, timeout is 2 seconds:
Packet sent with a source address of 10.128.41.1

*Jul 31 14:47:32.155: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 10.240.2.238:500, remote= 10.240.240.1:500,
local_proxy= 10.128.41.0/255.255.255.0/256/0,
remote_proxy= 10.0.0.0/255.255.0.0/256/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 28800s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0.....
Success rate is 0 percent (0/5)
GrevieRouter#show crypto ipsec sa

interface: GigabitEthernet0/0/0.903
Crypto map tag: vadefaultmap, local addr 10.240.2.238

protected vrf: (none)
local ident (addr/mask/prot/port): (10.128.41.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)
current_peer 10.240.240.1 port 500
PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 3, #recv errors 0

local crypto endpt.: 10.240.2.238, remote crypto endpt.: 10.240.240.1
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0.903
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

interface: Cellular0/2/0
Crypto map tag: vadefaultmap, local addr 10.241.1.21

protected vrf: (none)
local ident (addr/mask/prot/port): (10.128.41.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.0.0/0/0)
current_peer 10.240.240.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 10.241.1.21, remote crypto endpt.: 10.240.240.1
plaintext mtu 1500, path mtu 1500, ip mtu 1500, ip mtu idb Cellular0/2/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:
GrevieRouter#
*Jul 31 14:48:02.156: IPSEC:(SESSION ID = 1) (key_engine) request timer fired: count = 1,
(identity) local= 10.240.2.238:0, remote= 10.240.240.1:0,
local_proxy= 10.128.41.0/255.255.255.0/256/0,
remote_proxy= 10.0.0.0/255.255.0.0/256/0
*Jul 31 14:48:02.156: IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 10.240.2.238:500, remote= 10.240.240.1:500,
local_proxy= 10.128.41.0/255.255.255.0/256/0,
remote_proxy= 10.0.0.0/255.255.0.0/256/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
lifedur= 28800s and 4608000kb,

[Richard Burts]

Thank you for running the test and providing the output. In fact it shows that the vpn is NOT working. But it also provides an important clue about this problem. Note this line of the output

Crypto map tag: vadefaultmap, local addr 10.240.2.238

It is important to note that your router believes that its local address is 10.240.2.238 which is the address where the crypto map is applied and not the address of the loopback which is what you want to be using. To fix this issue add this command to your config

crypto map vadefaultmap local-address loopback0

The default is for the router to choose its own peer address as the address of the interface where the crypto map is applied. Since you want to use the loopback interface you must identify that in the config. Please add this and let us know if the behavior changes.

HTH

Rick