we are wondering if there is a solution to "route" VPN traffic between offices using only the "hub and spoke" VPN topology, for each nodes to VPN-communicate to each other, without relying on "mesh" VPN topology.
In other words, when we will have PIXes in all country & regional offices, if we establish VPN with "mesh" topology, IPsec/VPN definition on these PIXes will grow exponentially, making configuration files very complex and cumbersome to manage. We are wondering if there is a solution where we can define one IPsec/VPN definition between country & regional office PIXes and the HQ VPN concentrator (or PIX), so that only HQ VPN concentrator (or PIX) will contain all the complex definitions so that it can "route" VPN traffic between country & regional offices, using the "hub and spoke" topology.
Hi, we ran into this problem about six months ago with one of our clients with 50 remote sites. The PIX will not route VPN traffic in a hub and spoke environment. This will only work in a fully meshed topology and the configs can get very big. The concentrator 30xx is a good solutions here, it will route VPN traffic in a hub and spoke environment, it is easy to configure and it works well.
The PIX is designed to not allow traffic entering an interface to exit that same interface. This is be design to stop any use in proxy type attacks. I don't believe that this is possible with the current PIX code. I think that the VPN concentrator solutions have the ability to do this.
I would caution you on such a solution though. The PIx is designed to move lots of traffic. If traffic is growing exponentially, the bandwidth constrains at the hub site as well as the latency, may make this undesirable. For instance if traffic is going from Germany to France and hub is in US, that traffic would cross the globe twice (latency) and impact the US hub twice unnecessarily (bandwidth).
If you use certificates and work to genericize your configurations you may find that the configurations are not as complex as you may think. The "mesh" needs only to contain sites with resources that are universally necessary (HQ®ional ofcs). The clients that do not publish resources, only need configs for tunneling to the mesh. If you are able to seperate the supernets of those clients vs mesh, you may find that you have two semi-generic configurations, one for the mesh and one for the clients. The clients only need updating when the mesh changes, unfortunately the mesh, needs to change with each client or mesh change.
There is still a lot of configuration and updates, but it is not exponential based on client additions
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...