Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Cisco (http://www.velocityreviews.com/forums/f27-cisco.html)
-   -   PIX 515e with 2 Different public subnets (http://www.velocityreviews.com/forums/t35279-pix-515e-with-2-different-public-subnets.html)

Forrest 09-07-2004 02:28 PM

PIX 515e with 2 Different public subnets
 
Hello all. We are running out of public IP's and are getting a secondary
block from our ISP. The new block will be on a different subnet so I have a
few question regarding our config.

We have a Cisco 3725 router connecting to our T1 doing bridging back to the
ethernet interface. We have 2 PIX515e's in a cluster handling all the NAT
and static translations. I know the pix can have only 1 default route to
the net so I am thinking that we will need to set up the 3725 to do the nat
translations for the 2 subnets and set up PBR for traffic to the 2 public IP
blocks.

Am I on the right track or am I way off?

Thank you very much!

Forrest



Walter Roberson 09-07-2004 09:31 PM

Re: PIX 515e with 2 Different public subnets
 
In article <chkggr$23ik$1@news3.infoave.net>,
Forrest <fhamm2@blueridgebdc.org> wrote:
:Hello all. We are running out of public IP's and are getting a secondary
:block from our ISP. The new block will be on a different subnet so I have a
:few question regarding our config.

:We have a Cisco 3725 router connecting to our T1 doing bridging back to the
:ethernet interface. We have 2 PIX515e's in a cluster handling all the NAT
:and static translations. I know the pix can have only 1 default route to
:the net so I am thinking that we will need to set up the 3725 to do the nat
:translations for the 2 subnets and set up PBR for traffic to the 2 public IP
:blocks.

:Am I on the right track or am I way off?

If it's the same ISP for the two blocks, then you can skip most of what
you propose.

When your ISP provides you with two IP subnets, they [usually] do so
by *routing* the additional subnet to your existing WAN router.
Your WAN router is then responsible for any necessary *routing*
further inwards. In your case, you would want the second block *routed*
to your Pixen. Pix don't mind at all if you have static's (or
nat 0 access-list) against the outside interface that refer to different
subnets.


For example, if your outside interface is 23.1.3.51 255.255.255.240
then you might have a static such as

static (inside, outside) 23.1.3.54 192.168.1.54 0 0


If you have a second IP block *routed* to your PIX, say
209.37.25.32 255.255.255.224 then there is no problem at all with
adding in an additional statement

static (inside, outside) 209.37.25.41 192.168.1.141 0 0

The PIX will handle *both* IP blocks simulataneously.


I have emphasized "routed" in the sense that for this to work you need
your infrastructure to have the equivilent of

route 209.37.25.32 255.255.255.224 23.1.3.51

(where 23.1.3.51 is the PIX outside address). Handling multiple IP
ranges -can- also work if you use proxy arp, but that requires that
your router have a 'secondary' IP in the other IP range -- and there
are some things that the PIX just won't proxy-arp on behalf of
[in particular, anything named by a nat 0 access-list]. Routing is
much safer.


If the configuration for your PIX statically maps all of the new
IPs to your existing internal IP address range (e.g., notice the
example above, I show both mapped to 192.168.1.0/24), then you do not need
to add a 'route' statement to your PIX. If, though, you need to
handle the ranges separately [perhaps because your new total number
of IPs is bigger than the IP block you had previously assigned to
the inside interface, or perhaps because you are doing something that
does not work with NAT], then you need to add the equivilent of

route inside 209.37.25.32 255.255.255.224 192.168.1.200

where 192.168.1.200 is an *internal* router that knows how to
ferry traffic between 192.168.1.0/24 and 209.37.25.32 255.255.255.224 .
[If, that is, the two distinct IP address ranges need to be able to
communicate with each other internally.]


As for the default route -- you only need one default route anyhow.
You may have two IP address subnets, but both of them need to get
to the same ISP -- so just let them get sent out to the one single
default address. The PIX *routes* to that address, so it doesn't
care whether the source IP is 192.168.1.0/24 or
209.37.25.32 255.255.255.224 : it will ARP for the router IP and
then push the packet over to the router using the appropriate MAC,
paying no attention to the source IP in the packet. [Unless you
are using OSPF and PIX-level policy based routing that is.]


The circumstance under which you need multiple default routes is
that you have two different *connections* to the Internet, not
two different *subnets* on the same IP. If you have two different
connections [whether to the same ISP or two different ISP], then Yes,
you need to get more sophisticated. -Much- more sophisticated if
you want loadsharing, redundant routing, or failover at the ISP
level.


We have two full class C's being handled by a single outside interface of
a PIX 525. The same configuration (with some interface renaming) would
work all the way down to a PIX 501. But our setup is with multiple
distinct IP blocks, not with multiple connections.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Dan Charlesworth 09-08-2004 12:42 AM

Re: PIX 515e with 2 Different public subnets
 
The organization I work for is currently going through a similar process.

It has come to my attention that certain version of the PIX Finesse
Operating System (6.3.1 and 6.3.2 I believe) do not respond to proxy-ARP
requests for addresses on the outside interface that belong to subnets that
the interface itself is not in. This means that any statics that use
addresses in your new subnet will not work if you are using one of the
aformentioned versions.

I have also been told that this functionality has been restored in ver.
6.3.3 and above. I have yet to try this as I cannot get downtime....

I hope that this helps, maybe you can be spared some of the pain that we
have been suffering!

Dan


"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:chl9c1$6oq$1@canopus.cc.umanitoba.ca...
> In article <chkggr$23ik$1@news3.infoave.net>,
> Forrest <fhamm2@blueridgebdc.org> wrote:
> :Hello all. We are running out of public IP's and are getting a secondary
> :block from our ISP. The new block will be on a different subnet so I

have a
> :few question regarding our config.
>
> :We have a Cisco 3725 router connecting to our T1 doing bridging back to

the
> :ethernet interface. We have 2 PIX515e's in a cluster handling all the

NAT
> :and static translations. I know the pix can have only 1 default route to
> :the net so I am thinking that we will need to set up the 3725 to do the

nat
> :translations for the 2 subnets and set up PBR for traffic to the 2 public

IP
> :blocks.
>
> :Am I on the right track or am I way off?
>
> If it's the same ISP for the two blocks, then you can skip most of what
> you propose.
>
> When your ISP provides you with two IP subnets, they [usually] do so
> by *routing* the additional subnet to your existing WAN router.
> Your WAN router is then responsible for any necessary *routing*
> further inwards. In your case, you would want the second block *routed*
> to your Pixen. Pix don't mind at all if you have static's (or
> nat 0 access-list) against the outside interface that refer to different
> subnets.
>
>
> For example, if your outside interface is 23.1.3.51 255.255.255.240
> then you might have a static such as
>
> static (inside, outside) 23.1.3.54 192.168.1.54 0 0
>
>
> If you have a second IP block *routed* to your PIX, say
> 209.37.25.32 255.255.255.224 then there is no problem at all with
> adding in an additional statement
>
> static (inside, outside) 209.37.25.41 192.168.1.141 0 0
>
> The PIX will handle *both* IP blocks simulataneously.
>
>
> I have emphasized "routed" in the sense that for this to work you need
> your infrastructure to have the equivilent of
>
> route 209.37.25.32 255.255.255.224 23.1.3.51
>
> (where 23.1.3.51 is the PIX outside address). Handling multiple IP
> ranges -can- also work if you use proxy arp, but that requires that
> your router have a 'secondary' IP in the other IP range -- and there
> are some things that the PIX just won't proxy-arp on behalf of
> [in particular, anything named by a nat 0 access-list]. Routing is
> much safer.
>
>
> If the configuration for your PIX statically maps all of the new
> IPs to your existing internal IP address range (e.g., notice the
> example above, I show both mapped to 192.168.1.0/24), then you do not need
> to add a 'route' statement to your PIX. If, though, you need to
> handle the ranges separately [perhaps because your new total number
> of IPs is bigger than the IP block you had previously assigned to
> the inside interface, or perhaps because you are doing something that
> does not work with NAT], then you need to add the equivilent of
>
> route inside 209.37.25.32 255.255.255.224 192.168.1.200
>
> where 192.168.1.200 is an *internal* router that knows how to
> ferry traffic between 192.168.1.0/24 and 209.37.25.32 255.255.255.224 .
> [If, that is, the two distinct IP address ranges need to be able to
> communicate with each other internally.]
>
>
> As for the default route -- you only need one default route anyhow.
> You may have two IP address subnets, but both of them need to get
> to the same ISP -- so just let them get sent out to the one single
> default address. The PIX *routes* to that address, so it doesn't
> care whether the source IP is 192.168.1.0/24 or
> 209.37.25.32 255.255.255.224 : it will ARP for the router IP and
> then push the packet over to the router using the appropriate MAC,
> paying no attention to the source IP in the packet. [Unless you
> are using OSPF and PIX-level policy based routing that is.]
>
>
> The circumstance under which you need multiple default routes is
> that you have two different *connections* to the Internet, not
> two different *subnets* on the same IP. If you have two different
> connections [whether to the same ISP or two different ISP], then Yes,
> you need to get more sophisticated. -Much- more sophisticated if
> you want loadsharing, redundant routing, or failover at the ISP
> level.
>
>
> We have two full class C's being handled by a single outside interface of
> a PIX 525. The same configuration (with some interface renaming) would
> work all the way down to a PIX 501. But our setup is with multiple
> distinct IP blocks, not with multiple connections.
> --
> "No one has the right to destroy another person's belief by
> demanding empirical evidence." -- Ann Landers





All times are GMT. The time now is 03:52 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.