Choose one of the topics below for SD-WAN Resources to help you on your journey with SD-WAN
This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC!
We will not comment or assist with your TAC case in these forums.
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.
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.
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?
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.
local ident (addr/mask/prot/port): (188.8.131.52/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).