vpn PIX -VPN 3XXX hub and spooke

[p.emery]

hi

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.

Would you know if such a set up is possible?

thanks for your helps

philippe

[mike-greene]

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.

Hope that helps...

[p.emery]

verry bad

did you use only vpn 3015 and other moeles no pix at all ?

Is it not planned to work with the new VPN releases and the pix 6.2 or maybe 6.3 ?

thnaks for your inputs

philippe

[mike-greene]

It is a 3005 at the core and 506's and 501's at the remote sites.

[msdavis]

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&regional 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

My 2 cents,

Michael