cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

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.

570
Views
15
Helpful
20
Replies
Beginner

Re: IPSEC interface not available from VPN0

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.

Beginner

Re: IPSEC interface not available from VPN0

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. 

 

 

Highlighted
Beginner

Re: IPSEC interface not available from VPN0

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.


Beginner

Re: IPSEC interface not available from VPN0

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?

Beginner

Re: IPSEC interface not available from VPN0

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


Re: IPSEC interface not available from VPN0

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

 

 

CCIE #37979 (R/S)
CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards


This widget could not be displayed.