FlexVPN - Virtual-Access - no route to tunnel

[Rayn12345]

Dear Community,

I have set up a FlexVPN network in a test enviroment consist of 1 Hub (Cisco VA897) and 3 Spokes (1x Cisco IR1101, 2x Strongswan/Linux based Routers with IPSEC&FRR) connected with IPSEC/IKEv2. IPSEC connection is established to all spokes successfully. It also seems that for all 3 spokes a VTI is up. But the Hub add's only a route for the virtual-access/tunnel interface of the Cisco spoke, not for the other two tunnels that were establshed with strongswan and the Cisco tunnel interface is the only one that can be pinged.

This problem appears only when I try to have static tunnel ip addresses on the strongswan spokes. When I let them negotiate the tunnel addresses dynamically, it workes perfectly. Routes are added on the Hub and everything is reachable.

So I assume that the Cisco spoke send some Information about his tunnel interface with the static ip so that the hub can set the route where the strongswan-spokes does not or use an ip that is outside of the vpn ip pool (maybe wrong tunnel source interface).

Now my question: can I debug this on the Hub-side? Shoudnt I see an error if the Hub can not set a route for VTI's? Or could it be a misconfiguration on the Hub?

R1-HUB1#sh ip interface brief
Interface IP-Address OK? Method Status Protocol
Loopback2 172.16.100.1 YES NVRAM up up
NVI0 172.16.100.1 YES unset up up
Virtual-Access1 unassigned YES unset up up
Virtual-Access2 unassigned YES unset up up
Virtual-Access3 172.16.100.1 YES unset up up -> Cisco spoke
Virtual-Access4 172.16.100.1 YES unset up up -> Strongswan
Virtual-Access5 172.16.100.1 YES unset up up -> Strongswan
Virtual-Template20 172.16.100.1 YES unset up down
Vlan1 192.168.202.1 YES NVRAM down down

R1-HUB1#sh ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
S 172.16.100.0/24 is directly connected, Null0
C 172.16.100.1/32 is directly connected, Loopback2
S 172.16.100.20/32 is directly connected, Virtual-Access3

Thanks a lot for your advice!!

[Rob Ingram]

@Rayn12345 I've never used strongswan, but the cisco routers support config exchange which would send the tunnel IP address (amongst other configuration if configured to do so) to the remote peer, I assume the strongswan does not support this. Using dynamic would probably be the best solution in a multiple vendor environment. Any particular reason you wish to use static tunnel IP?

[Rayn12345]

Thank you for your feedback.
I would like to use static tunnel IP's so that I can identify the spokes via them. With dynamic assignment I wouldn't know which one it is. I would have to actively look it up. Or would there be other ways to identify them?

Is there a way to look on the hub to see which config exchanges are taking place?

Many thanks!

[Rob Ingram]

@Rayn12345 this information would be in the IKEV2 debugs if sent by the spoke, use debug crypto ikev2 and debug crypto ikev2 internal. Look for "Config data received" messages.

If strongswan does not support this, use a loopback per spoke, advertise this using a dynamic routing protocol and use this loopback IP address to identify the spokes.

[Rayn12345]

I will have a look. Many thanks for your advice!

[MHM Cisco World]

that not Hub Issue it issue of other two strongswan spokes
I dont know but for cisco the spoke can use under the crypto ikev2 authz policy 
route set interface <<- this add static route 
so match config in all three strongswan spokes

if match 

do

show crypto session 
see if hub have session to all three or only one 

MHM

[Rayn12345]

Thanks.

From what I can configure it should match. "route set interface" is set on the hub.

There are sessions to all three:

R1-HUB1#sh crypto session
Crypto session current status

Interface: Virtual-Access3
Profile: ike_v2_profile
Session status: UP-ACTIVE
Peer: 2.2.2.2 port 5058
Session ID: 97
IKEv2 SA: local 1.1.1.1/4500 remote 2.2.2.2/5058 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

Interface: Virtual-Access4
Profile: ike_v2_profile
Session status: UP-ACTIVE
Peer: 3.3.3.3 port 7786
Session ID: 96
IKEv2 SA: local 1.1.1.1/4500 remote 3.3.3.3/7786 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

Interface: Virtual-Access6
Profile: ike_v2_profile
Session status: UP-ACTIVE
Peer: 4.4.4.4 port 7938
Session ID: 98
IKEv2 SA: local 1.1.1.1/4500 remote 4.4.4.4/7938 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

[MHM Cisco World]

Create an IKEv2 Authorization Policy, the command route set interface will send the tunnel IP address as a static ip address to the peer.

FlexVPN IKEv2 Routing – integrating IT (wordpress.com)

I.e. what you config in Hub is send to spoke not effect the hub itself 
you need to check spoke are all config same as send static route to hub of tunnel ip or not

MHM

[Rayn12345]

Ok, I see. I will check this.

Thanks a lot, the link is great.

[MHM Cisco World]

You are so so welcome 

MHM

[Rob Ingram]

@Rayn12345 as I said in the first reply the strongswan devices need to support sending the tunnel IP address to the hub. The link provided merely demonstrates how to configure this on the cisco routers, which you already have working. You need to determine how strongswan works and whether is supports the same configuration exchange, sending the tunnel IP address to the hub. Else use the workaround suggested in the second post.

[tvotna]

I guess that static route to the dynamically assigned IP address is added on the FlexVPN hub by RRI which is enabled by default, and no IKEv2 attributes need be exchanged in this case. If address is not assigned dynamically, INTERNAL_IP4_SUBNET needs to be sent from the client to the hub in CFG_SET, which strongSwan clients don't do (so far as I know).

[Rayn12345]

@Rob Ingramsince I am a beginner the link just helped me to get a better understandig how things worked.

Unfortunately, I only have access to the Strongswan settings to a certain extent and will clarify it further with the manufacturer of the router. I will let you know as soon as I hear back from them.

I apologise, I should have been more verbose. I use BGP to advertise the local networks, where it is also clear which spoke is involved. I wanted to have the static tunnel addresses as an additional monitoring option, should something go wrong e.g. with the routing protocol. In this case, I think it would be an advantage to be able to identify the spokes via the tunnel address. Especially if you have a large number of spokes. And as this workes perfectly with Cisco Routers, I would have to keep them in separate IP pools. One for static and one for dynamic assignments.

But as I said, I don't have much experience with it yet and can't tell how important static tunnel ip's really are.