Nested IPsec Tunnels - Need some assistance

ryan07512 · ‎12-12-2014

I have been trying to set up a nested IPsec tunnel configuration, but am running into issues and need some assistance.

I've attached a diagram and configuration files for the various devices. The setup is currently built with Ubuntu VM's and CSR VM's, all running on the same physical machine.

The idea is that I have one client network which sits behind a Cisco router. That router will need to establish an IPsec+IKE tunnel to a Strongswan Linux Edge (which acts as a first layer firewall). Then, over that IPsec tunnel, I need to establish a second tunnel to a remote Cisco router (behind the firewall), and then route between the two client networks.

Additionally, I would like to verify it NAT-T will work on both sides (I can turn this off as needed).

I was initially able to get a VPN set up just fine to Strongswan, but then I read that that in order to do nested tunnels I need to use VTI's. Now, I am having difficulties getting this to work. The first VPN router is no longer able to establish a tunnel to Strongswan, using the same IKEv2 profile and IPsec profile.

Questions:

1. Are VTI's just IPsec, or are they actually IPsec+GRE? Do they work with Strongswan?

2. If I can't use a VTI for the "outer" tunnel, can I get the nested tunnel setup to work?

Any help would be greatly appreciated. I've been banging my head on the wall with this one!

CSR1's crypto debug:

csr1#show crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel2
Uptime: 00:00:00
Session status: DOWN-NEGOTIATING
Peer: 192.168.5.3 port 500 fvrf: (none) ivrf: (none)
Desc: (none)
Phase1_id: (none)
IKEv2 SA: local 192.168.2.2/500 remote 192.168.5.3/500 Inactive
Capabilities:(none) connid:1 lifetime:0
IPSEC FLOW: permit 47 host 192.168.2.2 host 192.168.5.3
Active SAs: 0, origin: crypto map
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 0 drop 739 life (KB/Sec) 0/0

Interface: Tunnel1
Session status: DOWN
Peer: 192.168.3.2 port 500 fvrf: (none) ivrf: EDGE
Desc: (none)
Phase1_id: (none)
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 0, origin: crypto map
Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0

Interface: (unknown)
Uptime: 00:00:00
Session status: DOWN-NEGOTIATING
Peer: 192.168.3.2 port 4500 fvrf: (none) ivrf: EDGE
Phase1_id: 192.168.3.2
Desc: (none)
IKEv2 SA: local 192.168.2.2/4500 remote 192.168.3.2/4500 Inactive
Capabilities:N connid:3 lifetime:0
IKEv2 SA: local 192.168.2.2/4500 remote 192.168.3.2/4500 Inactive
Capabilities:N connid:6 lifetime:0
IKEv2 SA: local 192.168.2.2/4500 remote 192.168.3.2/4500 Inactive
Capabilities:N connid:4 lifetime:0
IKEv2 SA: local 192.168.2.2/4500 remote 192.168.3.2/4500 Inactive
Capabilities:N connid:5 lifetime:0

csr1#

Marcin Latosiewicz · ‎12-12-2014

Ryan,

"I've got a bad feeling about this"

But:

1) VTI - is pure ipsec IPv4 or IPv6 no gre. I heard some people got VTI with swan working - never tried it myself. Remember IOS will negotiate "any any" as proxy IDs.

2) If your "primary tunnel" specifies that iVRF is X, then your nested tunnel should be have tunnel VRF and all the IKE components of VRF X.

Do you REALLY need nesting? Wouldn't it be better to have SWAN as central point and CSR on left establish tunnel to swan and then right hand CSR establish tunnel to swan and routing between the two?

M.

ryan07512 · ‎12-12-2014

For this particular application, I do need nesting. Otherwise, of course there are a lot of other options that would of course make a LOT more sense.

ryan07512 · ‎12-12-2014

This link describes what I want to do, but I just can't seem to get the IKE to route through the outer tunnel:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-3s/asr1000/sec-sec-for-vpns-w-ipsec-xe-3s-asr1000-book/sec-cfg-vpn-ipsec.html#GUID-1CF6B080-0ADC-44A9-AD15-2E9AFD4B1EFA

ryan07512 · ‎12-13-2014

I have it set up now so that I am terminating a tunnel at the StrongSWAN edge. I can then ping my far VPN gateway, and Wireshark is showing the traffic is tunneled through the edge.

The only problem is that ISAKMP packets, for my inner tunnel, are not encrypted. They are sent from the router, bypassing my crypto map setup altogether.