PIX 515e with 2 Different public subnets

Discussion in 'Cisco' started by Forrest, Sep 7, 2004.

  1. Forrest

    Forrest Guest

    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
    Forrest, Sep 7, 2004
    #1
    1. Advertising

  2. In article <chkggr$23ik$>,
    Forrest <> 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
    Walter Roberson, Sep 7, 2004
    #2
    1. Advertising

  3. 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" <-cnrc.gc.ca> wrote in message
    news:chl9c1$6oq$...
    > In article <chkggr$23ik$>,
    > Forrest <> 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, Sep 8, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page