Understanding IPSEC tunnel architecture that must pass through an Hub and Spoke transport provider
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2019 09:51 AM - edited 02-21-2020 08:55 AM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2019 10:36 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-10-2019 12:50 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2019 10:03 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-10-2019 12:50 PM - edited 03-10-2019 12:59 PM
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
