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!

[rbncarvalho · Accepted solution]

Hi JW_UK, 

As far as I'm aware that feature is not supported on cEdge platforms, you can only use IPsec tunnels on the Service Side VPN.

VPN Interface IPsec (for XE Routers)

Use the VPN Interface IPsec feature template to configure IPsec tunnels on Cisco IOS XE service VPNs that are being used for Internet Key Exchange (IKE) sessions. You can configure IPsec on tunnels for VPN 1 through 65530, except for 512.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/System-Interface/systems-interfaces-book/configure-interfaces.html

Thank you, 
Please rate helpful posts

[HashamM]

cEdge supports standard IKE tunnels in 19.x.

"You can create the IPsec tunnel in the transport VPN (VPN 0) and in any service VPN (VPN 1 through 65530, except for 512)."

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/Security/Security-Book/security-book_chapter_01.html?bookSearch=true#c_Configuring_IKE_Enabled_IPsec_Tunnels_12216.xml

[rbncarvalho]

Hi HashamM, 

Can you point specifically on the vManage how we can do that?

The link you shared is for a vEdge setup, the one I've found is for cEdge 16.12.x.

Could you please clarify, as I'm waiting for this feature being available for some months now.

Thank you, 

Best Regards, 

[prastrip]

Transport side Ike based IPsec is not available in cedge. It's in roadmap. We may get it in march release if everything will be on track.

At the moment,you can use service side ipsec in cedge. Thanks 

[JW_UK]

Thanks rbncarvalho & HashamM 

I followed the guide and created the IPSEC interface on the service side instead of VPN0, unfortunately I'm getting a IKEv2 failure:

IKEv2:% Getting preshared key from profile keyring if-ipsec1-ikev2-keyring
IKEv2:% Matched peer block 'if-ipsec1-ikev2-keyring-peer'
IKEv2:(SESSION ID = 0,SA ID = 0):Searching Policy with fvrf 0, local address X.X.X.X
IKEv2:(SESSION ID = 0,SA ID = 0):Found Policy 'policy1-global'
IKEv2-ERROR:Address type 1622425149 not supported

My assumption is that although the IPSEC is created on the service side, by sourcing the tunnel from the interface with a public IP address in VPN0, the cEdge would VRF jump to VPN0.

I'll log a TAC case next.

[JW_UK · Accepted solution]

Resolved.

IOS XE routers must source IPSEC interfaces from the Service side VPN (not VPN0), but also, it is necessary to add a inbound IPv4 ACL to the Interface in VPN0 to permit UDP 500 (IPSEC) and if using NAT UDP 4500 as well.

After the tunnel is established you can add a IPv4 static route on the Service side with a next hop of the Tunnel interface to route traffic via the tunnel. Be aware the static route will only be withdrawn from the routing table if the Tunnel goes down.

Zscaler support IP-SLA HTTP probes to check the cloud proxy health, on traditional routers you are able to use 'track' features to, for example, change the admin distance of a static route based on the results of the IP-SLA test. I'm unsure if Viptela using IOS XE has this same capability. This does present a bit of a problem for inteligent traffic steering.

Hope this helps.

[piniman]

Hi, can you please post the config that solved your problem. I have a similar problem with an IPSec Tunnel to an external Firewall. Template applied to Service VPN 1, Source interface from VPN 0 (Internet Interface with public IP to reach external Firewall via Internet). Thank You

[JW_UK]

Hi piniman,

Create an ACL in Policies > Local Policy > Access Control Lists
Permit port 500
I also have the Default Action as ‘Accept’ in my POC.
Copy the ACL name (CTRL C) you’ll need it for the next step.

Edit your ‘Feature Template’ for the ‘VPN Interface Ethernet’ that is applied to your physical interface in VPN0.
Under ‘ACL/QOS’ add a ‘IPv4 Ingress Access List’ using the name of the ACL you created in the first step.

[piniman]

Thank You.

Can you also post the config for the VPN template. I think i have the problem with the Source Interface (i receive  "IKEv2-ERROR:Address type not supported" in log).

You wrote " had to change source interface to Service VPN"

Which Interface did you use? Do you had to apply some NAT config?

Source Interface in my setup is the WAN Interface connected to the Internet. Communication over the IPSec Tunnel should be done via VPN1.

[JW_UK]

My template for 'VPN Interface IPsec' looks like this:

Then, this template is added under the Service VPN :

I thought it was all working fine, however I now have a new problem.

IKEv2 is working for Phase 1, but IPSEC is failing.

For some reason the ISR4K is creating 16 SA's whilst Zscaler only support a maximum of 8 SA's, therefore the tunnel is currently unusable.

I'd be interested to hear if you have the same issue?

[dbogdan]

Any luck getting this to work?  I opened an SR with TAC for the exact same reason.

[piniman]

Hi, made some more tests and my problem is the following

IPSec tunnel can be established if remote end is configured without any specific encryption domains for the communication and with a transport network within the tunnel (for routing purpose - like in GRE Tunnel)

All traffic must be accepted and specific routing is needed to direct traffic into specific tunnels.

To a remote end configured with encryption domains i wasn´t sucessfull

[dbogdan]

Looks like its working after I added the ACL to the outside interface.  I also had to mention the same ACL in the local policy for this to work.   Has anyone ever created an exception list to bypass zscaler in certain situations and go out the DIA door instead?

Thanks again for this article.  I shared this with TAC too.  

[JW_UK]

Hi  dbogdan,

Are you seeing encrypts and decrypts over your IPSEC tunnel?

In my case even after adding the ACL entry there was another step which was needed to fix this tunnel. I believe it is specific to ISR4K's and being fixed in the November code release.

It’s a bug where the ZScaler dumps an IP address based on the “config_exchange” request sent by cEdge devices.

The CLI based workaround for it (on cEdge).

BR12-1X(config)# crypto ikev2 profile apple

BR12-1X(config-ikev2-profile)# config-exchange request

BR12-1X(config-ikev2-profile)# commit

Commit complete.

BR12-1X(config-ikev2-profile)# no config-exchange request

BR12-1X(config-ikev2-profile)# commit

Commit complete.

BR12-1X(config-ikev2-profile)# end