VRF-aware VPN IPSEC - %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.

[loris.marcellini]

Hi there,

I have the following scenario:

MP-BGP - MPLS:      PE31 <-- --> PE30

IPSEC Tunnel:          PE30 <-- --> CE35

The network is working fine for the MPLS part, also I can ping the CE35 from PE30 through the VPN IPSEC and so encapsulating the traffic matching the crypto-map...

Here is the encryption domain:

PE30:
ip access-list extended into_VPN
permit ip host 200.200.200.200 host 100.100.100.100
permit ip host 201.201.201.201 host 100.100.100.100

CE35:
access-list 199 permit ip host 100.100.100.100 host 200.200.200.200
access-list 199 permit ip host 100.100.100.100 host 201.201.201.201

The first source (PE31 200.200.200.200/32 it's working fine):

R30#ping vrf custa 100.100.100.100 so lo10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
Packet sent with a source address of 200.200.200.200
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms
R30#sh crypto ipsec sa
interface: Ethernet0/1
Crypto map tag: mymap, local addr 1.1.1.1
protected vrf: custa
local ident (addr/mask/prot/port): (200.200.200.200/255.255.255.255/256/0)
remote ident (addr/mask/prot/port): (100.100.100.100/255.255.255.255/256/0)
current_peer 1.1.1.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 23, #pkts encrypt: 23, #pkts digest: 23
#pkts decaps: 23, #pkts decrypt: 23, #pkts verify: 23
#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.: 1.1.1.1, remote crypto endpt.: 1.1.1.2
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/1
current outbound spi: 0x3AFB0987(989530503)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0xE2974B16(3801565974)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 5, flow_id: SW:5, sibling_flags 80000040, crypto map: mymap
sa timing: remaining key lifetime (k/sec): (4171502/2062)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x3AFB0987(989530503)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 6, flow_id: SW:6, sibling_flags 80000040, crypto map: mymap
sa timing: remaining key lifetime (k/sec): (4171502/2062)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:

Unfortunately I've put two sources in the crypto-map, the latter is a loopback on PE31 (201.201.201.201/32) that I can see in the received routes via IBGP through the MPLS cloud:

R30#sh ip bgp vpnv4 vrf custa 201.201.201.201
BGP routing table entry for 1:1:201.201.201.201/32, version 15
Paths: (1 available, best #1, table custa)
Not advertised to any peer
Refresh Epoch 1
Local
31.31.31.31 (metric 11) from 31.31.31.31 (31.31.31.31)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:100
mpls labels in/out nolabel/20

Unfortunately the ping sourced from PE31 is not going to be encapsulated.. looks like is not matching the acl on PE30, and I can't understand why:

output ping source (PE31):

R31#ping vrf custa 100.100.100.100 so lo10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
Packet sent with a source address of 201.201.201.201
.....
Success rate is 0 percent (0/5)

output destination (CE35):

%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /100.100.100.100, src_addr= 201.201.201.201, prot= 1

So now, someone could give me an help?
Actually I think it should be a problem related to the MPLS encapsulataion etc.. any ideas??

You can find all the configuration attached together with a network scheme.

Many thanks

[Olev Vallaste]

Hi Loris,

Are pings working from 201.201.201.201@R31 to Lo10@CE(R35) in only one vrf in the simpliest case? I mean that:

 - without IPSec between R30 and R35

 - without route-leaking between vrf "custa" and vrf "internet" on R30 and R31.

For example let it be only  vrf 'custa', so that:

Lo10@R31 [vrf custa]  --> MP-BGP --> [vrf custa]@R30 -->Lo10@R35

If it will work, add IPSec again between R30 and R35 and try to ping and looks on debug on R30:

debug crypto ipsec

debug crypto isakmp

debug crypto interface

[Vinit Jain]

Hello Loris

I have tweeked your configuration a bit and this works perfectly fine.

Please let me know if you have any questions.

Regards

Vinit

PS: Please mark the question as answered if your problem is resolved.

[Olev Vallaste]

Hello Vinit,

From your config CE-faced interface not in vrf, so IPSec on R30 is not VRF-aware.

But is it profit or negative -  depends from desired target scheme. If Gi0/2@R30 (CE-faced interface with crypto-map) really need to look toward Internet (in fact it is interface on our PE toward ISP), so that  IPSec tunnel established  through Internet toward some customer equipment, I would say that is profit, because maintain full internet table in vrf in ISP-faced-PE (R30 in the case) - possible, but not very good, as to me, and your tweek looks very elegant.

[Vinit Jain]

Hello Olev

In most cases, if you are having an ISP, you dont really have to make it as a part of VRF. with MPLS VPN, you can still have a VRF but VRF Aware IPSec on top to MPLS VPN causes some more overheads. Secondly, with the older method, you were importing the RT in custa vrf, which will increase the overhead on that VRF as well. 

Please let me know if you have any further questions.

Regards

VInit

PS: Please mark the question as answered if your query has been resolved.

[Olev Vallaste]

Hello Vinit,

I agree with you decision at all.

I just mentioned that in result it is not vrf-aware ipsec, which the topic starter would like to test.

But let's waiting the topic starter answer.

[Vinit Jain]

Let me do some more research on it and get back to you. 

[Vinit Jain · Accepted solution]

Hello Olev

just figured the problem. Since there is no route-leaking concept between vrf's using static routes, it was not working but since you have reverse route, it creates an in-memory static route which acts as route-leaking in this case.

So, to solve this problem with your older configuration of two vrf's, you can configure "redistribute static" on router PE30 under vrf custa address-family.

 address-family ipv4 vrf custa
 network 192.168.103.96 mask 255.255.255.240
 redistribute connected
 redistribute static
 exit-address-family

Once you configure it, you will see that PE30 is advertising 100.100.100.100/32 prefix to PE 31.

This will solve your problem.

Regards

Vinit

[Olev Vallaste]

Hello, Vinit

Thank you for explananations.

Topic starter - Loris, not me)

I'm just trying to help and understand which target Loris wanted to reach)

Anyway, thank you again and let's wait what Loris says.

[Vinit Jain]

Thanks Olev

Please let me know if you have any further queries related to this. I will also try to document it in a support community document so that it is helpful for others as well.

Regards

Vinit

PS: Please do rate useful posts

[loris.marcellini]

Hi Vinit,

thank you for the full explanation about the provided solution, it worked perfectly indeed.

Actually I would like to give you one more question, what's the reason why I wasn't able to get encapsulated the traffic coming from the remote-PE31 even if I was meshing the vrf by the import between each other? I mean, why the default-route wasn't enough to reach the destination... or better I was reaching the destination, but the traffic from PE31 was not being encapsulated?

So it's the exact 100.100.100.100/32 necessary to forward the traffic throughout the tunnel?
I know the PE30 has the static route to 100.100.100.100/32  generated by the reverse-route, but actually I though the default on the PE31 was enough... 

Just to lab againg in depth I've  also tried to add the "redistribute static" and deleting the default route, and the 100.100.100.100/32 has disappeared from the bgp routing table on the remote PE31, why was it?

Many thanks for you support,
Best Regards

L.

[Vinit Jain]

Regarding the 100.100.100.100/32 being disappearing, you will have to first perform the ping from PE30

Check out the document that i wrote few hours back:

https://supportforums.cisco.com/document/12714611/static-ipsec-mpls-vpn

The prefix will not be advertised until the ping is not performed from PE30. I might still have to do some more research on the same.

Hope this helps.

Regards

Vinit