Solved: IKEv2 | Zone Based Firewall | VRF

kasunrajapakse · ‎04-27-2021

------------------- Cisco ASR 1000 -----------------

crypto ikev2 keyring Keyring_HF_Test_AR
peer Peer_Test_AR
address 81.x.x.x
pre-shared-key abc123

crypto ikev2 proposal Proposal_HF_Test_AR
encryption 3des
integrity sha1
group 2

crypto ikev2 profile Profile_HF_Test_AR
match fvrf FVRF
match address local interface Loopback2
match address local 62.x.x.x
match identity remote address 81.x.x.x 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local Keyring_HF_Test_AR

crypto ikev2 policy Policy_HF_Test_AR
match fvrf FVRF
proposal Proposal_HF_Test_AR

ip access-list extended ACL_HF_Test_AR
10 permit ip 10.113.3.0 0.0.0.255 host 10.121.12.60
20 permit ip 10.113.3.0 0.0.0.255 host 10.121.36.250

crypto ipsec transform-set TS_HF_Test_AR esp-3des esp-sha-hmac
mode tunnel

crypto map CMAP_Non_BTOP 10 ipsec-isakmp
set peer 81.x.x.x
set transform-set TS_HF_Test_AR
set pfs group2
set ikev2-profile Profile_HF_Test_AR
match address ACL_HF_Test_AR

interface Loopback2
vrf forwarding FVRF
ip address 62.x.x.x 255.255.255.255

interface TenGigabitEthernet0/0/0
description Uplink_to_Internet
vrf forwarding FVRF
ip address 2.x.x.x 255.255.255.254
ip nat outside
ip access-group iACL in
zone-member security UNTRUST
crypto map CMAP_Non_BTOP
end

crypto map CMAP_Non_BTOP local-address Loopback2

interface Port-channel1.1760
encapsulation dot1Q 1760
vrf forwarding trust
ip address 10.0.22.1 255.255.255.0
zone-member security PO1760
end

######### ZBF #########

Zone-pair name UNTRUST_to_self
Source-Zone UNTRUST Destination-Zone self
service-policy Inbound_IPsec_IPTraffic-policy

Zone-pair name self_to_UNTRUST
Source-Zone self Destination-Zone UNTRUST
service-policy Inbound_IPsec_IPTraffic-policy

policy-map type inspect Inbound_IPsec_IPTraffic-policy
class type inspect Inbound_IPSec_Traffic-class
pass
class type inspect Inbound_IPTraffic-class
pass
class class-default
drop

class-map type inspect match-any Inbound_IPSec_Traffic-class
match access-group name Inbound_IPSec_Traffic

ip access-list extended Inbound_IPSec_Traffic
10 permit esp any any
20 permit udp any any eq isakmp
30 permit ahp any any
40 permit udp any any eq non500-isakmp

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

Hi Guys,
My requirement is as follows.

Remote end device ( 81.x.x.x ) will establish an IPSec with the Cisco ASR ( 62.x.x.x). 62.x.x.x IP is configured inside Loopback 2 as shown. I can get Phase 1 and Phase 2 up. However there is no data flow. I suspect this has something to do with the VRFs and the Zone based firewall.

Traffic is landing on Loopback 2 (which is inside vrf FVRF) and it needs to reach a destination beyond Port-channel1.1760 (which is inside vrf trust). So I would assume that route leaking is required between these two VRFs?

Also, I have a zone pair to allow traffic from UNTRUST_to_self & self_to_UNTRUST. But if traffic beyond Port-channel1.1760 needs to communicate, do I need to allow traffic between zone "self" and zone "PO1760"??

The issue is a bit complicated since this involves VRFs and ZBF.
Any help / advice is appreciated.

Rob Ingram · ‎04-29-2021

If there are no encaps, that router is not sending outbound traffic.

Do you have a zone-pair from OUTSIDE to INSIDE as well?

Did you check NAT configuration like I previously suggested?

Did you remove ZBFW configuration for testing to confirm that isn't blocking the traffic?

Or enable logging on your class-default drop?

Generate oubound traffic, then check the policy-map for hits "show policy-map type inspect zone-pair <NAME>"

View solution in original post

kasunrajapakse · ‎04-28-2021

Hi Guys,
Any idea?
Thanks

Rob Ingram · ‎04-28-2021

Hi @kasunrajapakse

You don't have the ivrf specified in the ikev2 profile configuration, this is required when using a crypto map. The default ivrf would be the fvrf. Use "show crypto ikev2 sa" to confirm the actual ivrf.

No you don't need to permit traffic from "self" to "PO1760", the "self" zone is for traffic to/from the router itself, not transit traffic. You would need a zone-pair from inside (PO1760) to outside (UNTRUST). If still a problem, can you enable logging on your class-default drop and provide the output.

FYI, your encryption and DH group values used are weak and insecure, consider using something stronger.

kasunrajapakse · ‎04-28-2021

Hi Rob,
I have slightly changed my design as per the following guide. It looks promising. But I can't define an ACL that should match the interesting traffic. I should be able to config an ACL to define the local and remote LAN subnets that I want to communicate with.

Any help on this? Thank you very much for looking in to this.

https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-architecture-implementation/214938-configuring-ikev2-vrf-aware-svti.html

crypto ikev2 proposal Proposal_HF_Test_AR
encryption 3des
integrity sha1
group 2

crypto ikev2 policy Policy_HF_Test_AR
match fvrf FVRF
match address local 6.x.x.x
proposal Proposal_HF_Test_AR

crypto ikev2 keyring Keyring_HF_Test_AR
peer Peer_Test_AR
address 8.x.x.x
pre-shared-key abc123
!

crypto ikev2 profile IKEv2_Profile_HF_Test_AR
match fvrf FVRF
match address local interface Loopback2
match address local 6.x.x.x
match identity remote address 8.x.x.x 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local Keyring_HF_Test_AR

crypto ipsec transform-set TS_HF_Test_AR esp-3des esp-sha-hmac
mode tunnel

crypto ipsec profile IPsec_Profile_HF_Test_AR
set transform-set TS_HF_Test_AR
set ikev2-profile IKEv2_Profile_HF_Test_AR

interface Tunnel 1
vrf forwarding trust
ip unnumbered Port-channel1.1760
zone-member security IPSEC
tunnel source Loopback 2
tunnel vrf FVRF
tunnel protection ipsec profile IPsec_Profile_HF_Test_AR

interface Loopback 2
vrf forwarding FVRF
ip address 6.x.x.x 255.255.255.255

ip route vrf trust 192.168.10.100 255.255.255.255 Tunnel 1

Rob Ingram · ‎04-28-2021

@kasunrajapakse

You are getting confused, you've defined a tunnel interface so you are now using a route based VPN. You don't define an ACL to identify interesting traffic, you need to create static routes or use a routing protocol - you peer/route over the tunnel interface.

Examples of FlexVPN here and here.

kasunrajapakse · ‎04-28-2021

Hi Rob,
Thanks. Yes, I have moved on to route based VPN.
I found the following document that I could define an ACL within the tunnel interface.

https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/214728-configure-multi-sa-virtual-tunnel-interf.html

What do you think of this? Do you think I can use this to define traffic between the two LAN subnets?

Rob Ingram · ‎04-28-2021

I am aware of Multi-SA, but that's not what you've configured. Multi-SA is used as a replacement for crypto map and used when you are peering with a device that is using crypto map.

What device are you peering with and how is it configured? If the other device is a crypto map you can use my suggestion in the first reply to get the crypto map with VRF working or configure multi-SA. If you control both ends then just use a standard FlexVPN route based VPN.

kasunrajapakse · ‎04-28-2021

Hi Rob,
Thank you for the above comment / feedback.
The peering device is a non cisco and uses policy based VPN.

-
However, Going back to your 1st comment, I didn't have any iVRF configured in the ikev2 profile. So I have done that now.
I can now see both my vrfs (FVRF & trust). However there is no traffic flow yet. I can see crypto ipsec sa up, but no encrypt/decrypt packets. But having done that, I can see the remote subnet 10.121.36.250 learned to my inside vrf (trust)

ASR100#show crypto ikev2 sa

Tunnel-id Local Remote fvrf/ivrf Status
1 62.x.x.x/500 81.x.x.x/500 FVRF/trust READY
Encr: 3DES, PRF: SHA1, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/318 sec

ASR1000#show ip route vrf trust | inc 10.121.36
S 10.121.36.250/32 [1/0] via 81.x.x.x, TenGigabitEthernet0/0/0
ASR1000#

Could it be the Zone Based Firewall blocking traffic between the interfaces ??
My traffic flow is as follows.
Remote Traffic >>> TenGigabitEthernet0/0/0 >>> Loopback 2 (VPN end point) >>>Port-channel1.1760 (LAN side).
=======

ASR1000#show crypto ipsec sa

interface: TenGigabitEthernet0/0/0
Crypto map tag: CMAP_Non_BTOP, local addr 62.x.x.x

protected vrf: trust
local ident (addr/mask/prot/port): (10.113.3.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.121.12.60/255.255.255.255/0/0)
current_peer 81.x.x.x 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.: 62.x.x.x, remote crypto endpt.: 81.x.x.x
plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb TenGigabitEthernet0/0/0
current outbound spi: 0xDF44B6(14632118)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0x5712FCB2(1460862130)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 6297, flow_id: HW:4297, sibling_flags FFFFFFFF80000048, crypto map: CMAP_Non_BTOP
sa timing: remaining key lifetime (k/sec): (1843200/3512)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xDF44B6(14632118)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 6298, flow_id: HW:4298, sibling_flags FFFFFFFF80000048, crypto map: CMAP_Non_BTOP
sa timing: remaining key lifetime (k/sec): (1843200/3512)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:

Rob Ingram · ‎04-28-2021

@kasunrajapakse

Possibly. Did you look at my comment in the first response about creating zone-pair from inside to outside and vice versa if necessary?

If you want to confirm that it is a ZBFW issue disable it, test and work from there.

I see you have NAT enabled, ensure you "deny" traffic between the networks defined in the crypto ACL to ensure this traffic is not natted.

If you've a security zone defined on the outside interface don't also have an interface ACL, just include that as part of the self to untrust/outside policy.

kasunrajapakse · ‎04-29-2021

Thanks Rob,

I'm in the process of making the "LAN >> WAN" zone pair. Do you think the following could work? Do I need to allow IPSec traffic from LAN >> WAN as well?

PO1760 = LAN
UNTRUST = WAN

zone-pair security PO1760_to_UNTRUST source PO1760 destination UNTRUST
service-policy type inspect PO1760_to_UNTRUST_Traffic_Policy

policy-map type inspect PO1760_to_UNTRUST_Traffic_Policy

class type inspect PO1760_to_UNTRUST_Traffic_Class
pass
class class-default
drop

class-map type inspect match-any PO1760_to_UNTRUST_Traffic_Class
match protocol icmp
match protocol tcp
match protocol udp

Rob Ingram · ‎04-29-2021

@kasunrajapakse Looks ok

kasunrajapakse · ‎04-29-2021

Hi Rob,

Zone pairs added to allow traffic from LAN to WAN. But no luck.
When i check IPSec sa on the ASR - I see the following.

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 16, #pkts decrypt: 16, #pkts verify: 16

Number of decaps matches the encaps on the remote end. So I think the packet is coming to the ASR ands decrypted. But for some reason it's not encapsulating the packets back and replying (This is my understanding )
I don't see anything useful on the debugs either.

Running out of options to do.

Rob Ingram · ‎04-29-2021