IPSEC interface not available from VPN0

[JW_UK]

Hi there,

My environment has the following:

• Branch router, ISR4451-X, version 16.12.1b
• vManage, version 19.2.0

I'd like to configure a IPSEC tunnel to Zscaler, the interface should be sourced from VPN0 so that i can use the public IP address attached to my DIA circuit.

The problem is that a 'VPN Interface IPSEC' is not available:

Zscaler guide below (page44):

https://www.zscaler.com/resources/solution-briefs/partner-viptela-cisco-sd-wan-deployment.pdf

I notice the guide was written for the vEdge.

Has anyone been able to do this on a ISR4k?

Thanks!

[dbogdan]

Thanks for responding. SO your turning this on, then back off?  I tried it but nothing happened.  It seems to me that there a routing issue.  I tried adding a route from vrf 10 to the tunnel interface, but that didn't help either.

[JW_UK]

Yes, turning the feature on, so that it can be disabled.

You can verify if you are having the same problem by using the 'show crypto session' command. This will display the IPsec SA traffic flows of your session. 

In the error condition you will see (in my case) Zscaler learnt 172.x.x.x addressing which essentially broke the routing of traffic via the SA. This ties in with your theory of a rouing issue. 

[dbogdan]

Thanks for the reply. I have opened an sr with Cisco on this and they can't get it to work in their lab either. The traffic goes to the tunnel interface, but then never traverses outbound.

[JW_UK]

The Cisco BUG ID is not a public one, but the number = CSCvq47600 

Zscaler bug ID for the same issue = 58687 

Did you clear your crypto session after applying the fix?

[dbogdan]

Unfortunately no. It's in TAC right now. They are trying to recreate it.

[Florian Stroemmer]

Hi everyone,

we had the very same problem on cEgdes (ISR4331) in that we couldn't establish the tunnel to the Zscaler cloud proxy VPN head-end. Once I followed the information presented here in the thread (i.e. permit UDP/500 with a localized policy and default action "drop", for ACL details see https://sdwan-docs.cisco.com/Product_Documentation/Software_Features/Release_18.2/06Policy_Basics/05Localized_Data_Policy/Configuring_Localized_Data_Policy_for_IPv4#Interaction_between_Explicit_and_Implicit_Access_Lists) the tunnel established but with a weird IP address (which changes each time the tunnel is reset) on the customer's end of the encryption domain instead of 0.0.0.0/0.0.0.0/0/0.

e.g.

local  ident (addr/mask/prot/port): (172.50.147.43/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

My contact at Cisco TAC told me that there's a bug where the ZScaler dumps an IP address based on the “config_exchange” request sent by cEdge devices. vManage needs to push the IKE based IPSec configs to the router with CFG_Request disabled but it seems to be enabled in the current release.

Workaround which works in our setup and provides a correct tunnel crypto SA:

Detach the router from the device template and configure the following with "config-transaction"

cEdge(config)# crypto ikev2 profile <profile-name>
cEdge(config-ikev2-profile)# config-exchange request
cEdge(config-ikev2-profile)# commit
Commit complete.
cEdge(config-ikev2-profile)# no config-exchange request
cEdge(config-ikev2-profile)# commit
Commit complete.
cEdge(config-ikev2-profile)# end

After I applied the device template again, the manually changed setting was still there but this might change with future releases (hopefully to the better). We still need to test if traffic is really passing through this tunnel but at the moment the tunnel is established correctly (also after shut/no shut of the outside VPN0 tunnel source interface).

Regards

Florian

EDIT:

unfortunately, it does not survive a reboot. After a reboot the same issue appears again and you have to set the router to CLI mode again and redo the same procedure as described above.

[tranminhc]

I see the same issue when setup ipsec vpn between cEdge and an IOS router. The vpn phase 1 &2 established successfully, however there was no packet decrypted on IOS end router, while packet encrypted and decrypted counters showed normally on cEdge. It seems like someone said packet encrypted through the tunnel but never transmit out to source transport VPN 0 interface.
My solution to fix is simple, just shutdown then no shut the source transport interface.

Hope this helps someone.
Cong

[Florian Stroemmer]

An update to version 16.12.02r solves the bug and the IKEv2 profile contains " no config-exchange request". It is also necessary to permit UDP/500 and ESP to the cEdge as it is blocked by default by the implicit ACLs.

https://sdwan-docs.cisco.com/Product_Documentation/Software_Features/Release_18.2/06Policy_Basics/05Localized_Data_Policy/Configuring_Localized_Data_Policy_for_IPv4#Interaction_between_Explicit_and_Implicit_Access_Lists provides more information about implicit ACLs.

The add-on to the implicit ACLs looks like the following example.

policy
 app-visibility
 flow-visibility
 no implicit-acl-logging
 log-frequency        10
 access-list <ACL-NAME>
  sequence 1
   match
    source-port 500
   !
   action accept
    count Zscaler
    log
   !
  !
  sequence 11
   match
    source-ip <Zscaler peer IP>/32
    protocol  50
   !
   action accept
   !
  !
  default-action drop
 !
!

[andre.ortega]

I have two VPN already configured and working, so ACL is okay. But now I am trying to configure a new VPN and I am getting that error "IKEv2-ERROR:Address type 1615109380 not supported".

Any other thoughts?

What could be causing this?

[andre.ortega]

The peer was configured with the wrong IP... that was my problem.

[SIMMN]

I think I am running into the similar issue here with Zscalar...The ISR is running 16.12.3. But I am using IKEv1 instead of IKEv2. So it has the fix, right? Even it does not, the issue is irrelevant to my setup as I am using IKEv1, right?