I'm implementing a star VPN with a PIX running v6.3 as the central
termination point and multiple Cisco 837 at the remote offices (all
running IOS v12.3).
The question I have is regarding remote site to remote site
communications. Is it possible to route from one site to another
through the PIX or am I required to configure a meshed network? At
this stage, I have everything working except for this one thing. The
amount of traffic between the two sites will be minimal so I'm loathe
to go through the hassle of setting up all the tunnels, however it's
still going to be a requirement.
More about :pix multi ios router vpn routing issue
> I'm implementing a star VPN with a PIX running v6.3 as the central
> termination point and multiple Cisco 837 at the remote offices (all
> running IOS v12.3).
> The question I have is regarding remote site to remote site
> communications. Is it possible to route from one site to another
> through the PIX or am I required to configure a meshed network? At
> this stage, I have everything working except for this one thing. The
> amount of traffic between the two sites will be minimal so I'm loathe
> to go through the hassle of setting up all the tunnels, however it's
> still going to be a requirement.
Great question. Answer: Yes
The logic behind doing a star network with IPSec is a little strange but
it works. This description is very general and works with all IPSec
compatible equipment. I don't work with Cisco PIX devices often so I
can not give specific configurations for the Cisco platform. The
concept should be easy enough to grasp though.
Your network numbering should be very uniform for this to work simply.
Adding more numbering schemes will complicate things since you will need
to add extra tunnels so lets keep it simple. So just pick a format and
stick with it on all sites including your central site. For example.
If you use the most popular private network address scheme 192.168.x.x
then all the sites need to use this convention. If your network is
going to grow beyond 254 sites then perhaps consider starting with
10.x.x.x for maximum growth and flexibility due to this subnet's much
In our example your central site will be numbered: 10.0.0.x
Branch office 1: 10.0.1.x
Branch office 2: 10.0.2.x
Branch office 3: 10.0.3.x
The tunnel between branch office 1 and the central site will be
basically the same as any point to point IPsec connection but the local
and remote subnet definitions are going to be a bit different, that's
it. Encryption settings, phase 1 settings, etc are not involved and can
be however you like but I assume you already have those working.
In the central office the tunnel to branch office 1 looks like this:
Local subnet: 10.0.0.0/255.0.0.0
Remote subnet: 10.0.1.0/255.255.255.0
In the branch office 1 router the tunnel IP configuration looks like this:
Local subnet: 10.0.1.0/255.255.255.0
Remote subnet: 10.0.0.0/255.0.0.0
Notice how the central site subnet is defined as the entire range of
addresses in the 10.x.x.x range? This is what makes the remote site
send all traffic to any subnet in the 10.x.x.x range that is not local
to the central site router. The central router will look up the
destination and if it's not a local subnet it will forward it again to
the correct branch office tunnel.
That's it. Just change your subnet definitions on your tunnels so the
central site contains all the branch subnets and it will work.
Another suggestion, if possible avoid using 192.168.0.x or 192.168.1.x
in any of your networks. Home network gear often uses these numbers by
default and it will make life easier on your remote users if they want
to run a VPN client from home behind a router with these common network
WARNING! Email address has been altered for spam resistance.
Please remove the -deletethispart-. section before replying directly.
Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)