Site-to-Site VPN Questions

[kabskawt]

I am new to this deployment so please bear with my ignorance and I welcome to hear/know your inputs regarding the potential issues,common issues and best practices on setting up multiple site-to-site tunnels (hub and spoke) to minimize/avoid major issues in regards to establishing the tunnels. The spokes in terms of IPs (internal) is something we don't have a control and no information at the moment so I would expect later on there would be a potential issues of overlapping as well as incompatibility issues due to different appliances/hardware that will be linking to the main site/HQ.

We are using a standalone (FDM manager) FPR-1140 (FTD 7.2).

In regards to the overlapping networks most solution that I found is to do a NAT(e.g. SNAT/DNAT) but I came across about carriers/Telco/service providers using the public IP as encryption domain, so I was trying to figure out on how to implement such setup but I cannot bring the tunnels in my lab test. 

#1 Encryption Domain
I would like to check if I am doing this correctly for the VPN tunnel setup under the encryption domain portion if Public IPs will be used?

For the Local Network encryption domain - I put my internal network (e.g. 172.16.0.0/16) 
For the Remote Network encryption domain - the same as the peer public IP (e.g. 1.1.1.1) 


#2 For hardware incompatibility potential issues
I honestly think that I am missing a lot of things in this part like do we need to place another brand or do a alternative like using opensource firewall just in case it is incompatible with FTD etc? Based on your own experienced, how do you managed this issue? 


#3 Management Perspective
Based on our network setup, would it be easier if we use Route based VPN instead of Policy based VPN? The spoke can are estimated to be 30~ 60 sites. The traffic that will from/to between Hub and spoke are low and only specific services are required to route to the tunnel but because data security is a concern a tunnel must be setup.


Thank you in advance.

KBS

[Rob Ingram]

@kabskawt if you have set the remote protected network as 1.1.1.1, is the remote side doing the translation or are you performing translation on your side? If you need to translate on your send, you need to check your NAT rules are working correctly - run packet-tracer to simulate the traffic flow and confirm it is translated.

The FTD should be able to perform the basic VPN functionality fine.

For traffic to spokes you control I would recommend a route based VPN, using a dVTI on the Hub and VTI on the spokes to simplify the design - however dVTI is only supported if using the FMC for management. Regardless whether you use dVTI, I would recommend using an FMC, you have more managment functionality compared to the FDM, you could use the cloud based FMC (cdFMC). https://secure.cisco.com/secure-firewall/docs/cloud-delivered-firewall-management-center

[kabskawt]

@Rob Ingram
Thank you for your inputs. I will check regarding the FMC, this one probably requires a separate license ?

if you have set the remote protected network as 1.1.1.1, is the remote side doing the translation or are you performing translation on your side? If you need to translate on your send, you need to check your NAT rules are working correctly - run packet-tracer to simulate the traffic flow and confirm it is translated.

KBS: I am running this test setup in my lab so in this case the other end (Spoke) is doing the NAT. Technically, this would work as long as NAT rules are set accordingly, let me check and troubleshoot my lab setup. I am running this lab test in case we will face this later on. I assume that I am doing the correct set up ( setting the remote network as peer public IP)  for those spokes that will require us to use public IP as encryption (given that NAT is set accordingly).


KBS

[Rob Ingram]

@kabskawt yes cdFMC requires a separate license.

When you set the protected networks as the peers remote public IP address, this has to be mirrored on the other side of the VPN, meaning the other peers's local protected network is their public IP address.

[Aref Alsouqi]

The encryption domains would be the internal subnets, your local subnet and the remote subnet, usually we don't use the ISP public IP addresses as encryption domains.

For the overlapping subnets showing on the diagram you shared between the HQ and site3 as you mentioned you need to NAT the source (local encryption domain) and the destination (remote encryption domain) subnets. In this case the remote peer VPN configuration would need to use the translated of your local encryption domain subnet as the remote encryption domain.

For the hardware compatibility, as @Rob Ingram mentioned any security edge device nowadays would support IPsec just fine, so I wouldn't be concerned about this.

The route based VPN could be more effecient and require less configuration to be applied, however, both ends of the tunnel would need to support it, alternatively nothing wrong with going for policy based VPNs.

Finally, I would use IKEv2 if possible as it has a few advantageous compared to IKEv1 but it has to be supported on both peers of the tunnel.

[kabskawt]

@Aref Alsouqi 
Thank you for your inputs. 

The encryption domains would be the internal subnets, your local subnet and the remote subnet, usually we don't use the ISP public IP addresses as encryption domains.

KBS: I understand but I read those other setup whereby they use the public ip as encrpytion domain due to overlapping subnets or the peer have multiple tunnels connecting to them making their setup less troublesome and not to create a lot of NAT rules. So I am curious on how to do this setup in case we will face this requirement later on. As the remote peers for this project is unknown until they onboard (decided to peer). 

KBS

 

[Aref Alsouqi]

You're welcome. I still can't see a use case of using the public IPs in the encryption domains. If you have overlapping subnets then as previously mentioned you can easily manage this one by creating a NAT rule on your peer and NAT the source and destination in this case. If the remote peer has multiple IPsec tunnels it will still have its crypto map configs that will send the traffic of each tunnel to the right remote peer IP based on the defined encryption domains.