topic Re: Understanding IPSEC tunnel architecture that must pass through an Hub and Spoke transport provider in Network Security

Understanding IPSEC tunnel architecture that must pass through an Hub and Spoke transport provider

CiscoBrownBelt — Fri, 21 Feb 2020 16:55:28 GMT

I attached a pic to help - don't have Visio.

Let's say HQ router is head end router with all IPSEC configs for remote sites.

The circuit goes to another location (Provider in diagram) who handles the physical connections to the remote sites.

So remote end configs for the tunnels are still built on devices at the remote site router or ASA, etc. correct?

So does the Transport provider just need our public ip addresses since they are not supposed to know about the tunnels?

Re: Understanding IPSEC tunnel architecture that must pass through an Hub and Spoke transport provider

Rob Ingram — Sat, 09 Mar 2019 18:36:19 GMT

Hi,
I assume the provider will just route the traffic?......therefore you just need IP reachability between the HQ and Remote sites, using there external/public IP addresses.

The VPN tunnels will be built between the HQ router and the Remote site devices. The provider wouldn't know about your internal networks, they'd be routed via the tunnel, encrypted and therefore transparent to the provider.

HTH

Re: Understanding IPSEC tunnel architecture that must pass through an Hub and Spoke transport provider

Dennis Mink — Sun, 10 Mar 2019 06:03:22 GMT

you are spot on blue belt. your tunnels are established between (public) peer IP addresses. as far as your provider is concerned it only sees isakmp and ESp traffic, it does not see what is encrypted inside it. so as long as your provider routes the peer addresses, you are fine. as soon as the physical circuit drops, the remote end will continue to bring up the tunnel, until it can, i.e. the circuit is recovered.

Re: Understanding IPSEC tunnel architecture that must pass through an Hub and Spoke transport provider

CiscoBrownBelt — Sun, 10 Mar 2019 19:50:26 GMT

Great info!
So below I see one main tunnel I guess then a bunch of child SAs underneath (just as it shows in the GUI/ASDM). To my understanding, all the child SAs are different remote sites that go through the transport provider. My main tunnel is the "1682665127 X.X.X.6/500 X.X.X.0/500 READY RESPONDER". Does this sound about right?

Session-id:2758, Status:UP-ACTIVE, IKE count:1, CHILD count:14

Tunnel-id Local Remote Status Role
1682665127 X.X.X.6/500 X.X.X.0/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA384, DH Grp:21, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/18416 sec

Child sa: local selector X.X.X..0/0 - 1X.X.X..255/65535
remote selector X.X.X..160/0 - X.X.X.1/65535
ESP spi in/out: 0x6d1f4027/0xbbe517cf
Child sa: local selector X.X.X.28/0 - X.X.X.255/65535
remote selector X.X.X.60/0 - X.X.X.91/65535
ESP spi in/out: 0xbb935ee4/0xa7642a72

Re: Understanding IPSEC tunnel architecture that must pass through an Hub and Spoke transport provider

CiscoBrownBelt — Sun, 10 Mar 2019 19:59:55 GMT

Great info!

So below I see one main tunnel I guess then a bunch of child SAs underneath (just as it shows in the GUI/ASDM). To my understanding, all the child SAs are different remote sites that go through the transport provider. I am basically trying to interpret the below because to my understanding, we have VPN tunnels that go through one transport location that handles the connections to the remote sites. Is my main tunnel is the "1682665127 X.X.X.6/500 X.X.X.0/500 READY RESPONDER". Does this sound about right? How is this configured?

Session-id:2758, Status:UP-ACTIVE, IKE count:1, CHILD count:14

Tunnel-id Local Remote Status Role
1682665127 X.X.X.6/500 X.X.X.0/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA384, DH Grp:21, Auth sign: PSK, Auth verify: PSK

Life/Active Time: 86400/18416 sec

Child sa: local selector X.X.X..0/0 - 1X.X.X..255/65535
remote selector X.X.X..160/0 - X.X.X.1/65535
ESP spi in/out: 0x6d1f4027/0xbbe517cf
Child sa: local selector X.X.X.28/0 - X.X.X.255/65535
remote selector X.X.X.60/0 - X.X.X.91/65535
ESP spi in/out: 0xbb935ee4/0xa7642a72