cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1637
Views
10
Helpful
12
Replies

Ikev2 IPSEC with virtual-access interface not encrypting traffic

Cisco router have route based Ikev2 IPsec tunnel to Fortigate . The WAN IP on Fortigate is dynamic because of redundancy . So I have used virtual-access interface. Phase1 /Phase2 comes up but unable to encrypt traffic from Cisco side. Fortigate is able to encrypt traffic and send to Cisco.  All works fine if fortigate IP is static and have configured tunnel interface with "tunnel destination x.x.x.x" command is used.   

The relevant config from router:

interface Loopback2
ip address 172.19.100.1 255.255.255.248
zone-member security INSIDE

!

interface Virtual-Template1 type tunnel
description !!! To FortiGate !!!
ip unnumbered Loopback2
ip mtu 1400
zone-member security INSIDE
load-interval 30
tunnel source 208.x.x.x
tunnel mode ipsec ipv4
tunnel protection ipsec profile OII_OFF_PROF

!

#Sh ip int br

Virtual-Access1 172.19.100.1 YES unset up up
Virtual-Template1 172.19.100.1 YES unset up down

Crypto Config:

crypto ikev2 proposal OII_EROV
encryption aes-cbc-256
integrity sha256
group 2
!
crypto ikev2 policy OII_POLICY
proposal OII_EROV
!
crypto ikev2 keyring OII-keyring-OFF
peer NO_EROV
address 0.0.0.0 0.0.0.0
pre-shared-key ***************
!
!
!
crypto ikev2 profile OII-profile-OFF
match identity remote address 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local OII-keyring-OFF
lifetime 43200
dpd 10 3 periodic
virtual-template 1

!

crypto ipsec transform-set OII_OFF_SET esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile OII_OFF_PROF
set transform-set OII_OFF_SET
set ikev2-profile OII-profile-OFF

 

us-test-R01#sh cry ipsec sa

interface: Virtual-Access1
Crypto map tag: Virtual-Access1-head-0, local addr 208.x.x.x

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 1.x.x.x port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0    !!!! No encryption !!!!
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10   !!!! able to receive traffic from fortigate!!!!
#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.: 208.x.x.x, remote crypto endpt.: 1.x.x.x
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0
current outbound spi: 0xC0B4854E(3233056078)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0xE21750A6(3793178790)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 2101, flow_id: ESG:101, sibling_flags FFFFFFFF80000048, crypto map: Virtual-Access1-head-0
sa timing: remaining key lifetime (k/sec): (4607998/2245)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xC0B4854E(3233056078)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 2102, flow_id: ESG:102, sibling_flags FFFFFFFF80000048, crypto map: Virtual-Access1-head-0
sa timing: remaining key lifetime (k/sec): (4608000/2245)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:
us-test-R01#

12 Replies 12

@Romanpreet Singh Do you have NAT configured that could be unintentially translating the traffic?

Is there routing in place to route the traffic via to the correct tunnel?

No NAT configured on router and I cant even ping opposite tunnel IP and no encaps for that. 

Am I on right path to use virtual-access interface in case of dynamic peer? 

 

us- test-R01#ping 172.19.100.2    !!! opposite tunnel IP on Fortigate !!!

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

us- test-R01#sh ip nat trans   

us- test-R01#

us- test-R01#

SVTI-DVTI.png

this is config of DVTI, 

No need tunnel source and tunnel destination for Virtual-Template.

Removed tunnel source but sorry, still the same. No enacps.

@Romanpreet Singh without testing my theory, I don't think the cisco router is even going to know that the fortinet is connected via the dynamic VA interface, as there won't be an entry in the routing table....which is why you cannot ping it.

clear crypto ipsec sa 
and check again 

share 

show crypto ipsec sa <-after change 

Hi MHM

Removed the tunnel source.  Output is enclosed at end of this message.

 

I guess the issue is ' down' protocol status of virtual-template interface. Because of that, the tunnel subnet is not showing as ' connected' in routing table and the router is unable to reach tunnel peer IP.

Virtual-Access1     unassigned    YES unset   up up
Virtual-Template1 172.19.100.1 YES manual up down

 

us-hou-R01#sh ip cef 172.19.100.2
172.19.100.2/32
nexthop 10.154.63.50 GigabitEthernet0/0/1

 

See, the tunnel peer ip is being learned from inside Lan interface instead of being shown as 'connected.

 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

us-hou-R01#sh cry ikev2 sa
IPv4 Crypto IKEv2 SA

Tunnel-id Local Remote fvrf/ivrf Status
1 208.x.x.x/500 111.x.x.x/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 43200/46 sec

IPv6 Crypto IKEv2 SA

us-houston-test-R01#sh cry ipsec sa

interface: Virtual-Access1
Crypto map tag: Virtual-Access1-head-0, local addr 208.x.x.x

protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 111.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.: 208.x.x.x, remote crypto endpt.: 111.x.x.x
plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/0
current outbound spi: 0xC0B48B07(3233057543)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0x28C0E134(683729204)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 3421, flow_id: ESG:1421, sibling_flags FFFFFFFF80000048, crypto map: Virtual-Access1-head-0
sa timing: remaining key lifetime (k/sec): (4608000/3593)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xC0B48B07(3233057543)
transform: esp-256-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 3422, flow_id: ESG:1422, sibling_flags FFFFFFFF80000048, crypto map: Virtual-Access1-head-0
sa timing: remaining key lifetime (k/sec): (4608000/3593)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:

https://www.cisco.com/c/en/us/support/docs/security/flexvpn/116346-configure-eigrp-00.html

 

the virtual-template is always up/down 
virtual-access is what must focus on.

BUT I must mention some think what routing protocol you run over tunnel ?
you must run any routing EIGRP BGP or try static route, we must inform router that to reach remote LAN you must use tunnel, or config set route with AAA authz.

interface Virtual-Template1 type tunnel
description !!! To FortiGate !!!
ip unnumbered Loopback2 <- config LOOPBACK  to be in same subnet of spoke tunnel IP
ip mtg 1400<-OK
zone-member security INSIDE<-OK
load-interval 30<-OK
tunnel source 208.x.x.x <-optional and as we see the tunnel head is use same source
tunnel mode ipsec ipv4 <-OK
tunnel protection ipsec profile OII_OFF_PROF <-OK


Loopback is in the same subnet (/28) as peer tunnel IP.

I have static for remote Lan and tried the routing protocol but the issue is that router is not able to identify that the peer tunnel ip is over the virtual-access interface. as you can see the 'sh ip cef' output, that ip is being learned from inside Lan interface maybe from a summary route. Whereas it should be learned over the tunnel as specific /28 route.

So, peers not reachable to each other and hence no neighborship on routing protocols.

I'm also working with tac, but till now they are also clueless on this issue.

I See that this config is OK and Virtual-access is UP/UP and also have assign IP address
Your previous config.
interface Loopback2

ip address 172.19.100.1 255.255.255.248
zone-member security INSIDE

!

interface Virtual-Template1 type tunnel
description !!! To FortiGate !!!
ip unnumbered Loopback2
ip mtu 1400
zone-member security INSIDE
load-interval 30
tunnel source 208.x.x.x
tunnel mode ipsec ipv4
tunnel protection ipsec profile OII_OFF_PROF


BUT as you mention you config static route? this will not work since the tunnel is template and not up until the IKEv2 end  exchange phaseI & II.

what you need 

crypto ikev2 authorization policy default <- this for cisco check fortigate if they have same feature 

route set remote LAN-behind-Fortigate <- this is same as set route for IKEv1 and add static route ONLY after IKEv2 end exchange phaseI & II.

if Fortigate don't have this feature ? you can use any routing protocol like EIGRP in both peer and make both peer know route behind each other 
example of cisco Peer 

router eigrp X

 network router-LAN 

 passive-interface default

 no passive-interface Virtual-Template1

 

Hi

This feature is new to me so can you please share more info on configuring that.  

route set remote LAN-behind-Fortigate <- this is same as set route for IKEv1 and add static route ONLY after IKEv2 end exchange phaseI & II.