Cisco Catalyst SD-WAN connecting to AWS via IPSEC to VPN0

[brian.jones]

I have a small SD-WAN setup for a company with two "DC" locations using SDCI/Cloud On-Ramp to my main AWS subscription and two remote sites that connects via the SD-WAN to the SDCI to access the workload. I have two test AWS subscription that are not part of my main AWS subscription that I want to connect to my SD-WAN but I don't want deploy edges to those subscriptions as it is for short term projects, but I need to access those workloads from my two remote sites.  I have a Site-to-Site VPN currently between the test AWS subscriptions and my main remote site to facilitate the connectivity.  I want to move as much as I can to SD-WAN however, I cannot deploy a "service" side VPN for this.  

I want to connect the test AWS subscription to the "DC" locations" via IPSec and have the "DC" edges route the traffic to the remote site or the main AWS subscription as required.   I found little documentation on how to use IPSec on the transport side, but I haven't seen anything that says I cannot.

Can someone direct me on if this is possible and if so, the docs on how to do it?

[MHM Cisco World]

CBC is not standard, when you deal with cisco more you will know that the cipher name cisco use is different than standard name 
but it is same. 
so here config multi SA and make both peer select the match one 
I usually do that if I am not sure which SA I need to use.

MHM

[Kanan Huseynli]

It clearly shows authentication issue several times.

"

IKEv2 IKE_AUTH Exchange RESPONSE
Payload contents:
NOTIFY(AUTHENTICATION_FAILED)

"

Firstly, in vEdge type below:

   authentication-type
    pre-shared-key
     pre-shared-secret $8$qzBthmnUSTMs54lxyHYZXVcnyCwENxJGcxRQT09X6SI=
     local-id          100.0.2.2
     remote-id         100.0.50.2

 Secondly, change PSK on both side for simpler one "Password" (without quotes).

Last but not least, on IOS side under Tunnel0:

ip mtu 1400
ip tcp adjust-mss 1360
tunnel protection ipsec profile P1  (without ikev2-profile, ipsec profile P1 itself has ikev2-profile).

And lets check.

Note: I still see NAT-T happening between devices, they switch to run over udp4500 after first two messages, but it works (send and receive are seen over udp4500), let's ignore for now.

[MHM Cisco World]

I think for IKEv2 if phaseII is mismatch the auth is failed 
MHM

[brian.jones]

I will but keep in mind that the password is already simple, it is just encrypting it in the config.  The PSK is Testing, so I will just change it to be "test".

[MHM Cisco World]

@Kanan Huseynli  he dont use complicate password but he use protect password so when he copy the config we dont see the plain text [password we see it encrypt.

MHM

[Kanan Huseynli]

Now, let's try complicated one:

Testsdwanpassword123

try this.

[Kanan Huseynli · Accepted solution]

Reason for complicated pass is:

From Cisco SD-WAN 19.2.x release onwards, the pre-shared key needs to be at least 16 bytes in length. The IPsec tunnel establishment fails if the key size is less than 16 characters when the router is upgraded to version 19.2.

On SD-WAN devices, there is security check, if PSK length is <16 then it fails. I remember one related topic in community as well (long ago somebody had similar issue), but I just forgot and reminded when reading security config guide:

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/security/vedge-20-x/security-book/config-sec-param.html#c_Configuring_IKE_Enabled_IPsec_Tunnels_12216.xml

[brian.jones]

The PSK length was the issue.  Tunnel came up.  I am going to try to normalize the lab and ensure it will work with the tunnel-interface defined on ge0/0.

[brian.jones]

Okay, so I was able to put the tunnel-interface back by just redeploying the original template and just changing the PSK.  So I feel we are almost there.  So from the PC behind the vedge (sd-wan), it can ping the PC on the IOS (non sd-wan) side, however, I cannot do the reverse.  The ping from the PC on the IOS side cannot ping the PC behind the vedge.

[MHM Cisco World]

Change the static route in non sdwan rtr to use tunnel interface as egress and remove next-hop

MHM

[brian.jones]

I changed the static route on the IOS side to use the tunnel interface.  No change.  Cannot ping the PC behind the vedge.

[Kanan Huseynli · Accepted solution]

For bidirectional flow, put ipsec interface into VPN 20.

Remove all ipsec configuration from VPN0, add to VPN 20.Also, add simple static route (not ipsec route) with remote tunnel IP being next-hop.

Check below commands, adjust if needed (mostly, copy pasted from your .txt):

vpn 20
no  ip ipsec-route 172.16.4.0/24 vpn 0 interface ipsec1 
vpn 0 
no interface ipsec1


vpn 20
interface ipsec1 
ip address 169.254.1.1/30 
tunnel-source-interface ge0/0 
tunnel-destination 100.0.50.2 
ike
version 2 
rekey 14400 
cipher-suite aes128-cbc-sha1 
group 2 
authentication-type 
pre-shared-key 
pre-shared-secret $8$EWhg0Phf6OeE4qWWhhU8Sa5/SQO2io3gsaY7WB/a5FI= 
! 
! 
! 
ipsec 
rekey 3600 
replay-window 512 
cipher-suite aes256-cbc-sha1 
perfect-forward-secrecy group-2 
! 
mtu 1400 
no shutdown 
vpn 20
ip route 172.16.4.0/24 169.254.1.2  

Reason it does work when you ping from vedge side, but does not work when you ping from remote side is nat-filter. When you ping from vedge side, for return traffic nat-filter is created and traffic is allowed even though there is no VPN20 route information in VPN0 (where ipsec interface in your configuration case). When you ping from IOS side, traffic "falls" in VPN0 and there is no route to 172.16.2.0/24.

Note: I checked with route-leaking, but still no luck, nat drops traffic. However, above method puts ipsec in VPN20 (think it like interface tunnel in VRF but underlay -transport interface is in global from IOS XE configuration).

[brian.jones]

I will reconfigure, but I do not recall configuring any NAT rules.  Is nat-filter a default behavior?

[Kanan Huseynli]

Yes, it is default behavior doing nat to the same IP, but I don't have detailed information. NAT is one of the confusing topics and there is no normal document that describes what is happening in reality.

I understood this by packet-trace in my lab (same scenario):

Line 5&6 are example for ping from vedge side, as you see from vedge to ios it is forward, return traffic is punted to be checked by CPU and allowed due to existing NAT-filter.

However, when you check line 13 for example (which is ping from ios side to vedge lan), NAT drops:

So, it is not routing issue (otherwise ping from vedge would also not work), it is something else - in this case nat-filter.

Normally, this should happen when you have NAT on transport interface. I don't know exact reason for this behaviour. Most probably, due to traffic going from VPN X to VPN 0 (some kind of DIA - direct internet access), I also but would like to see detailed documentation.

[brian.jones]

I reconfigured the tunnel for vpn 20 and everything is working as expected.  Thank you for taking the time to help out.